Prescan Error: Exception scanning web, The system cannot find the file specified.

Just recently, I ran into a problem running the prescan utility where a series of sites reported the following errors:

Error: Exception scanning web: http://intraneturl/sites/samplesite
System.IO.FileNotFoundException: The system cannot find the file specified.

Error: The following site has not been scanned. Id = f3b05792-52a4-4a85-9b26-19905f23cf46 and Url = /sites/samplesite

Error: Prescan has encountered sites or lists that were not updated because they cannot be accessed using the SharePoint Products and Technologies object model. The most likely reasons for Prescan to skip a list are covered in the Knowledge Base article at: http://go.microsoft.com/fwlink/?linkid=69958&clcid=0x409.

The recommended Knowledge Base article indicates that the problem may be caused by database corruption which can be solved using the databaserepair command line operation of stsadm. Running the command should produce a list of orphaned objects. Calling the command again with the "deletecorruption" parameter would delete the orphaned objects.

But what if the command doesn't find any orphaned objects? This was the problem I ran into. Running the databaserepair command would always produce the following response.

<OrphanedObjects Count="0">

First I decided to take a look at the sites that where reporting the "Exception scanning web" error; opening these sites in the browser returned the following "list does not exist" error.

This led me to believe there might be something wrong with the site definition. With a little more research, I found that all of the sites reporting this error were in fact based on the same site definition.

Cause: As it turns out, the Site Definition used had been commented out in the "WebTemp.xml" file (I've seen many people do this to prevent certain site definitions from showing up in the list of available templates.)

Note: None of the sites identified by the error "The following site has not been scanned. Id = SOMEGUID and Url ....." were the cause of the problem; it was always a sub-site, specifically the ones that generated the "Exception Scanning Web" and "FileNotFoundException" errors.

Solution: Make sure any site definitions used are included in one of the "WebTemp.xml" files (they must not be commented out.) After correcting (or updating) the WebTemp.xml files, you'll need to run an IISReset. You should then be able to browse the sites without receiving an error and re-run the prescan.exe utility (hopefully you wont run into something else).

Technorati Tags: SharePoint,Upgrade,WSS,Prescan,Troubleshooting,OrphanedObjects

del.icio.us Tags: SharePoint,Upgrade,WSS,Prescan,Troubleshooting,OrphanedObjects

SharePoint Site Enumeration Page: Get a list of all the sites in your SharePoint farm from Central Administration

Updated 8/25/2008: Updates to formatting in code blocks and removed recursive call that was causing duplication.

In my previous post "Iterating through SharePoint Web Applications, Site Collections, and Sites (Webs)" I provided a simple script to iterate through all web applications, sites and site collections. In this post, I will use much of that code to create an application page that returns a list of all the sites in the farm in XML. I will also create a feature to display a link to the application page from the Application Management section in Central Administration.

Click here to download the Solution Package (WSP)
Click here to download the source files

First I create a new file called EnumerateSites.aspx in c:\program files\common files\microsoft shared\web server extensions\12\template\admin. I will be accessing the page from the Central Administration site; I prefer to put such pages in the "admin" folder which is not accessible from regular SharePoint sites, as opposed to the "layouts" folder.

Since this file will be returning a list of all the sites in XML, we need to make sure the browser renders it properly. To do so we change the content type of the page to "application/xml"

<%@ Page Language="C#" ContentType="application/xml"%>

Next,we create references to the necessary SharePoint and XML assemblies:

<%@ Import Namespace="Microsoft.SharePoint.Administration" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Import Namespace="System.Xml" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

Since we are only displaying XML we wont need to reference a master page; so the rest is pretty much the same code from the previous post executing in the OnLoad event of the page. I use the XMLTextWriter class to build the XML document, and incorporate a number of "try catch" statements throughout the code to ensure that any errors that may be encountered are properly displayed in the XML. I've pasted all of the code for the application page (including the 2 previous excerpts) below:

<%@ Page Language="C#" ContentType="application/xml"%>
<%@ Import Namespace="Microsoft.SharePoint.Administration" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Import Namespace="System.Xml" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<script runat="server">
    protected override void OnLoad(EventArgs e){
        // Get references to the farm and farm WebService object
        // the SPWebService object contains the SPWebApplications
        SPFarm thisFarm = SPFarm.Local;
        SPWebService service = thisFarm.Services.GetValue<SPWebService>("");

        // Prepare the XML Writer
        XmlTextWriter xmlWriter = new XmlTextWriter(Response.OutputStream, Encoding.UTF8);

        //Start the XML Document
        xmlWriter.WriteStartDocument();

        //Create a Web Applications Element
        xmlWriter.WriteStartElement("webapplications");

        //**********************************************
        // NOTE: From here on everything is executed in
        //       "try catch" blocks. This is done to
        //       facilitate troubelshooting in case any
        //       errors surface. The error is caught and
        //       rendered in an xml "error" element.
        //       since the pages MIME type has been
        //       changed to XML, allowing the error
        //       to surface would render the xml document
        //       unreadable in IE.
        //***********************************************
        try
        {
            //Iterate through each web application
            foreach (SPWebApplication webApp in service.WebApplications)
            {
                //Create an XML Element for each web application
                //and include the name in the "name" attribute
                xmlWriter.WriteStartElement("webapplication");
                xmlWriter.WriteAttributeString("name", webApp.DisplayName);
                try
                {
                    //Create a sites element for the site collections
                    xmlWriter.WriteStartElement("sites");

                    //Iterate through each site collection
                    foreach (SPSite siteCollection in webApp.Sites)
                    {

                        //Create an XML Element for each site collection
                        //and include the url in the "url" attribute
                        xmlWriter.WriteStartElement("site");
                        xmlWriter.WriteAttributeString("url", siteCollection.Url);

                        //call the recursive method to get all the sites(webs)
                        GetWebs(siteCollection.AllWebs, xmlWriter);

                        //close the site element
                        xmlWriter.WriteEndElement();

                    }
                    //close the site collection element
                    xmlWriter.WriteEndElement();

                }
                catch (Exception siteError)
                {
                    //if an error occurs write the error message to
                    //an error element
                    xmlWriter.WriteElementString("error", siteError.Message);
                }
                //close the web application element
                xmlWriter.WriteEndElement();
            }
        }
        catch (Exception webAppError)
        {
            //if an error occurs write the error message to
            //an error element
            xmlWriter.WriteElementString("error", webAppError.Message);
        }

        // close the web applications element and document
        xmlWriter.WriteEndElement();
        xmlWriter.WriteEndDocument();
        xmlWriter.Close();
    }
    //*************************************************
    // This method is used recursively to display all
    // webs in a site collection. The Web Collection
    // from the site collection is passed in along with
    // the XML writer to continue writing the XML Document
    // where the calling method left off
    public void GetWebs(SPWebCollection allWebs, XmlTextWriter xmlWriter)
    {
        //create a webs element to contain all sites(webs)
        xmlWriter.WriteStartElement("webs");
        try
            {
            //iterate through each site(web)
            foreach (SPWeb web in allWebs)
            {
                if (web.Permissions.DoesUserHavePermissions(SPRights.FullMask));
                {
                    //Create an XML Element for each site(web)
                    //and include attributes for the url, title,
                    //and template information
                    xmlWriter.WriteStartElement("web");
                    xmlWriter.WriteAttributeString("url",web.Url);
                    xmlWriter.WriteAttributeString("title", web.Title);
                    xmlWriter.WriteAttributeString("WebTemplateID", web.WebTemplateId.ToString());
                    xmlWriter.WriteAttributeString("WebTemplateName", web.WebTemplate);

                    //close the site(web) element
                    xmlWriter.WriteEndElement();
                }
            }       
            }
        catch (Exception webError)
            {
                //if an error occurs write the error message to
                //an error element   
                xmlWriter.WriteElementString("error", webError.Message);
            }
        //close the webs element   
        xmlWriter.WriteEndElement();     
    }
</script>

With the page saved in the admin folder, you could just access it via the URL of your central administration site:
(i.e. http://centraladminsite/_admin/enumeratesites.aspx)

I personally prefer to build a Custom Action which adds a link to the page from Application Management in Central Administration. The steps to do this are relatively simple:

1. Create a new folder for the feature and call it "EnumerateSites". We will use the feature to add a link to the page from Central Administration.
   
   
2. Open the folder and create a new empty file naming it FEATURE.xml
   
   
3. Open the file and paste the following XML, replacing NEWGUID with a newly generated GUID.
   
   
   

   <?xml version="1.0" encoding="utf-8" ?>
   <Feature xmlns="http://schemas.microsoft.com/sharepoint/"
   Id="NEWGUID"
   Title="Enumerate Sites in XML"
   Hidden="FALSE"
   Scope="Farm"
   ActivateOnDefault="TRUE"
   Version="12.0.0.0">
   <ElementManifests>
   <ElementManifest Location="Elements.xml" />
   </ElementManifests>
   </Feature>
   

4. Save and close the file.
   
   
5. Create another file, this time naming it "Elements.xml" and paste the following XML, replacing GROUPGUID and ACTIONGUID with newly generated GUIDs (use the same GUID in both occurrences of GROUPGUID):
   
   

   <?xml version="1.0" encoding="utf-8" ?>
   <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
   <CustomActionGroup Id="GROUPGUID"
   Location="Microsoft.SharePoint.Administration.ApplicationManagement"
   Title="Application Management Utilities" Sequence="1010" />
   <CustomAction
   Id="ACTIONGUID"
   GroupId="GROUPGUID"
   Location="Microsoft.SharePoint.Administration.ApplicationManagement"
   Sequence="10" Title="Enumerate Sites in XML" Description="">

   <UrlAction Url="_admin/enumeratesites.aspx" />

   </CustomAction>
   </Elements>
   

6. Save and close the file
   
   
7. Package the EnumerateSites.aspx page and feature using your method of choice. Don't have one? Checkout WSPBuilder by Carsten Keutmann
   
   
8. Deploy your solution and you are done!

You can access the page from the Application Management section of Central Administration, you'll see a new section titled Application Management Utilities with a link to Enumerate Sites in XML.

Click on the link to get an XML page enumerating all of the sites in your farm, it should look similar to the following

Click here to download the Solution Package (WSP)
Click here to download the source files

Technorati Tags: SharePoint,Features,ApplicationPages,WSS,MOSS,CustomActions

del.icio.us Tags: SharePoint,Features,ApplicationPages,WSS,MOSS,CustomActions

Iterating through SharePoint Web Applications, Site Collections, and Sites (Webs)

I've often had to write code that iterates through all of the sites in a SharePoint farm. The requirement may be as simple as getting an inventory of sites, or I may need to execute code against each site such as; changing the theme, logo, or activating a feature. Whatever the case may be the logic is simple:

1. Get all of the Web Applications
2. For each Web Application
3. Get all of the Site Collections
4. For each Site Collection
5. Get all of the Sites (webs)
6. For each of the sites (webs) 
   • Get Site Information or Execute Code (i.e. change theme, logo, master page, activate/deactivate feature)
   • Get all of the Sub Sites (webs)
     • Repeat step 6

How its done:

Note: Before executing the code make sure that the user executing the logic has the required permissions on every site, or else it wont work. What is the required permission? It depends on what it is you are doing; chances are you'll be executing this as an admin and should have full control. The following code will iterate through Central Administration and Shared Service Provider Sites, take caution when changing anything on those sites.

Make sure your code references the "Microsoft.SharePoint.Administration" namespace.


public void BeginProcess()
{
     // Get references to the farm and farm WebService objects
     // the SPWebService object contains the SPWebApplications
     SPFarm thisFarm = SPFarm.Local;
     SPWebService service = thisFarm.Services.GetValue<SPWebService>("");

     foreach (SPWebApplication webApp in service.WebApplications)
     {
        //Execute any logic you need to against the web application
        //Iterate through each site collection
        foreach (SPSite siteCollection in webApp.Sites)
        {  
            //do not let SharePoint handle the access denied 
            //exceptions. If one occurs you will be redirected
            //in the middle of the process. Handle the AccessDenied
            //exception yourself in a try-catch block
            siteCollection.CatchAccessDeniedException = false;

            try
            {
                 //Execute any logic you need to against the site collection
                 //Call the recursive method to get all of the sites(webs)
                 GetWebs(siteCollection.AllWebs); 
            }
            catch (Exception webE)
            {
                 //You should log the error for reference
            }

            //reset the CatchAccessDeniedException property of the site
            //collection to true
            siteCollection.CatchAccessDeniedException = true;
        }

     }
}

public void GetWebs(SPWebCollection allWebs)
{
     //iterate through each site(web)
     foreach (SPWeb web in allWebs)
     {
         if (web.Permissions.DoesUserHavePermissions(SPRights.FullMask));
         {
             //Execute any logic you need to against the site (web) 
              
         }
     }        
}

 

Updated 7/22/2008: Added code to handle access denied exceptions at the GetWebs level.
Updated 8/25/2008: Removed recursive call that was causing duplication.

Technorati Tags: SharePoint,Development,WSS,MOSS

del.icio.us Tags: SharePoint,Development,WSS,MOSS

SharePoint 2007 Infrastructure Update - Read the instructions before you install

The Microsoft SharePoint Product Group has updated their blog post  Announcing: Availability of Infrastructure Updates post with some prerequisites  and installation instructions; they are highlighted in yellow and easy to follow. Please read them before installing the update.

If installing the Update for Office SharePoint Server 2007, be sure to read the instructions in TechNet:  Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007.)  Keep in mind that instructions will vary based on how your farm is configured; the following is an excerpt from TechNet addressing a multiple server farm scenario.

1. Do the following:

   • If you are installing the Infrastructure Update for Microsoft Office Servers on a single computer server farm, click Next and then proceed to step 9.

   • If you are installing the Infrastructure Update for Microsoft Office Servers on the first server in a multiple computer server farm, on the Completing the SharePoint Products and Technologies Configuration Wizard page, do not click Next. Instead, repeat steps 1 through 7 on the next computer in the server farm.

   • If you are installing the Infrastructure Update for Microsoft Office Servers on one of the remaining servers in a multiple computer server farm, click Cancel on the Completing the SharePoint Products and Technologies Configuration Wizard page, and then click Yes in the dialog box that appears. Repeat steps 1 through 7 on the next computer in the server farm.

2. After you have completed steps 1 through 7 on each computer in the server farm, return to the first computer and then on the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

3. If a dialog box appears that informs you that you must run setup on every server in the server farm, click OK.

The update is relatively large, so be sure you follow the instructions. For a detailed description of the update see the support article:  Description of the Microsoft Office Servers Infrastructure Update: July 15, 2008

 

Technorati Tags: SharePoint,MOSS,WSS,Hotfixes,Updates

del.icio.us Tags: SharePoint,MOSS,WSS,Hotfixes,Updates

SharePoint 2007 and Project 2007 Infrastructure Update

Microsoft has released a Infrastructure Update for WSS 3.0, Microsoft Office SharePoint Server 2007, and Microsoft Office Project Server 2007.

I've gathered the following highlights of the updates for each of the products from the Microsoft download pages:

WSS 3.0

"Key updates for Windows SharePoint Services 3.0 include:

• Platform performance improvements and fixes.
• Several backup and restore fixes.
• Several core Workflow fixes. "

Reference and Download:
Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)

Office SharePoint  Server 2007

"Key updates for SharePoint Server 2007 include:

• New Search features such as federated search and a unified search administration dashboard.
• Several core fixes to Search to improve performance and scale.
• Platform performance improvements and fixes.
• Several core fixes to the publishing Content Deployment features to improve reliability.

Key updates for Project Server 2007 include:

• Timesheets and My Tasks stability and usability improvements
• Queue management user interface improvements
• Project Server 2003 to Project Server 2007 migration fixes
• Database performance improvements to enhance the cube building process and Project Professional Save/Publish scenarios

Key updates for Search Server 2008 and Search Server 2008 Express include:

• Platform performance improvements and fixes since RTM "

Reference and Download:
Infrastructure Update for Microsoft Office Servers (KB951297)

Installation Instructions:
Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007)

Project 2007

"Key updates for Microsoft Office Project 2007 include:

• Cost Resources Calculation fixes
• Improved Local Project Cache stability
• Improved Custom Fields stability "

Reference and Download:
Infrastructure Update for Project 2007 (KB951547) - English

Check out the Aggregated Feed  from the SharePoint Team Blog for additional information.

Technorati Tags: SharePoint,MOSS,Updates,Search,Hotfixes

del.icio.us Tags: SharePoint,MOSS,Updates,Search,Hotfixes

SharePoint Solution Development; Define and Design Guidelines

In my previous posting, "SharePoint Solution Development, Planning for Success", I wrote about how the lack of a clear definition and design will almost undoubtedly impact the success of a SharePoint solution development effort (and just about any other development effort for that matter.)

In this posting, I will share with you some guidelines regarding what to include in your definition (scope and business requirements) and your design. The list is by no means complete (hence the term guidelines), and everything on the list will not apply to every scenario. Feel free to contribute your own guidelines and lessons learned.

Note: The following guidelines do not cover topics having to do with Governance or Information Architecture, there is plenty of information available on those already (check out: New governance content for SharePoint published on TechNet and  SharePoint Governance - Key to a Successful Deployment on the SharePoint Team Blog.) These recommendations are meant to compliment that work, which I believe is equally as important.

So to what extent do we define? This will vary per solution, organization, and how much risk you are willing to take. At a minimal your definition should include a list of requirements that the business owners and project sponsors are willing to sign off on as the ultimate factors in determining the success of the project.

• Meet with a representative of each of the primary roles; a system administrator, site owner, an author, editor, a contributor. Have them describe what they expect to do with the system keeping the focus on the "what" not the "how". Your more complex scenarios may depend on additional roles, be sure you include those as well.
  
  
• Document the functional and non-functional aspects of the current solution (if one is already in place). Don't just focus on the negative aspects of the current solution, also look at (and document) the positives. Your solution should improve on the negatives without taking away from the positives.
  
  Note: Keep in mind that the current solution may be a manual process. If so, document it as well
  
  
• When performing an upgrade, you may think there isn't much to define.  Remember, we don't want to take away functionality so its important that we capture what they have. At a minimum your scope and requirements document should include:
  
  
  • An inventory of the custom and/or modified site definitions, libraries and lists, as well as the sites that are using them (running prescan.exe will give you most of the site definition information you'll need.)
    
    
  • An inventory of Content Databases
    
    
  • A list of unghosted pages (also generated by prescan.exe)
    
    
  • A list of any custom web parts
    
    
  • Custom Application and/or Administration Pages
    
    
  • Try to identify any applications that may be leveraging SharePoint via its web services.
    
    
  • Anything else being used that didn't come out-of-the-box.
    

The design is more tricky, this is where I find that most projects fail; not always because of a poor design,  more often a lack of one. Do not confuse your scope or requirements documents for design documents. Every project needs a design. If the design seems obvious, then it shouldn't take you long to write it down before you start doing the work.

For a standard/out-of-the-box implementation your design document should include:

• A list of web applications that will be created including those for Central Administration, Shared Service Providers, and My Sites when applicable. (Alternatively these can be included in an infrastructure design or build out document)
  
  
• The names and parameters of your content databases
  
  
• A list of Site Definitions that will be used
  
  
• A list of initial site collections and/or sites that will be created including the corresponding site definitions and content databases.
  
   
• The SharePoint Lists and Libraries that will be created for each one of the initial sites
  
  
  • The columns that will be created with those lists or libraries in addition to the ones created out-of-the-box
  • The relationships between lookup columns and lists
  • Any associated workflows
  • The document templates
    
    
• Any Content Types and Site Columns that will be created
  
  
• Any Custom Groups and the corresponding permissions they will be given
  
  
• The Content Sources, and Search Scopes (when applicable)
  
  
• Custom Profile Properties and Property Mappings (when applicable)
  
  
• Custom Managed Properties (when applicable)
  

Note: Always keep in mind that SharePoint is not a relational database and make sure the business clearly understands the risks involved with such designs. Recommend an alternative approach if you feel its the right way to go. Document your recommendations and any assumed risks and have the business users sign off on them.

When performing an upgrade make sure your design document includes the SharePoint 2007 equivalents of any custom web parts (some 2003 web parts may not be compatible), application pages, site definitions, list and libraries, that may have been created for the SharePoint 2003 environment. It may be a good opportunity to put governance in place and rethink the information architecture. Take a look at "Good SharePoint Upgrade Articles and Posts" from the SharePoint Team Blog.

For other scenarios requiring customizations or custom development such as; application pages, custom workflow's, event handlers, and features; your design document should include the following in addition to the above mentioned items.

• Document the methods and objects you'll use in your custom application pages, web parts, and event handlers; making sure you understand the limitations ahead of time. Try to limit the number of assumptions you make by referencing the SDK as often as necessary. Consider using diagrams whenever possible.
  
  Note: Try to use the out-of-the-box web parts rather than developing new ones, you may find that there is little you cant do. Look to the Business Data Catalog and corresponding web parts. If the web part is going to be used for configuration purposes, consider using a custom application page.
  
  
• Create use cases for your Visual Studio and SharePoint Designer workflows , documenting what the system should do and how its going to do it, not just the users. 
  
  
• If your solution includes InfoPath forms; document all the groups and fields. Specify their name, type, and whether or not the group or field is repeating. Indicate which fields will be published in SharePoint.
  
  
• Document how your solution will be packaged, consider creating multiple packages to separate unrelated Features, Application Pages, and/or Site Definitions.
  

Remember to keep the users involved, they'll take ownership in the solution and be a lot more understanding when problems arise.

Technorati Tags: SharePoint, WSS, MOSS

SharePoint Solution Development, Planning for Success

Almost every successful development project goes through some sort of formal lifecycle; a process that involves a series of steps leading up to the completion of the project and its transition to a production environment. There are endless variations to this process, also known as methodologies or development frameworks, some of the more commonly known flavors include; Microsoft Solutions Framework (MSF), and the Rational Unified Process (RUP).

While many of these methodologies vary significantly in execution, most of them share many of the same principles;  define, design, develop, test, deploy, stabilize. Every one of these principles always appear in one form or another. Depending on how long you've been in this industry, you are probably familiar with them and their importance. If you are not, or simply don't believe that they are all that critical, your probably just starting your career or perhaps should consider taking on another one.

So how does this process relate to SharePoint? In the same way it relates to any other Application Development project. Yet somehow, with SharePoint solutions, many of the principles are often disregarded. I know that's a general statement, but based on what I see every day in the SharePoint development forums, comments on blogs, and helping out my clients; I find there is a big void in the  SharePoint solution development process, and its spreading more every day.

Luckily the cause is not difficult to identify, and having any sort of formal development experience (particularly in enterprise environments) the remedy is clear.

I believe that the cause itself arises from the very nature of the product, how its sold, how its perceived. The product itself, or its perception as "a product", rather than a platform or series of services, leads most businesses to believe that it can simply be implemented out-of-the-box. While Microsoft and many others in the SharePoint community have stressed the importance of Governance, and Information Architecture (which have been very well perceived,) I find that that these topics simply aren't enough. They help address many of the operational and organizational issues having to do with a successful SharePoint deployment, but do very little in regards to the functional aspects of the solution. As a result, the developers end up having to make many last minute decisions, the solutions aren't very scalable (at least not from a functional standpoint), and become very difficult to maintain. In the short term, the developers and support personnel become very frustrated with the solution, in the long term nobody is happy.

The remedy is simple, and likely already in place in your organizations software development methodology. I find that almost every problematic SharePoint project lacks a clear definition and a design, this is where the real problem lies.

In one of my next blog posts (likely the following one), I will share with you some guidelines on what to include in your definition and design documents.

Added July 7th, 2008 - I've posted the follow up to this post:
SharePoint Solution Development; Define (Requirements Gathering) and Design Guidelines

Technorati Tags: SharePoint, WSS, MOSS