通过

MOSS 2007 Upgrades and The SharePoint Configuration Analyzer V.Next

  • 项目

 MOSS 2007 Upgrades and The SharePoint Configuration Analyzer V.Next

With the Beta 2 release of Microsoft Office SharePoint Server 2007 (MOSS) and Windows SharePoint Services 3.0 (WSS), my team and I are in the process of helping our customers develop their migration plans and testing to deploy MOSS 2007 and upgrade their existing SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 production environments..

There is a wealth of information already publicly available to help you with your planning, such as the IT Content for 2007 Office System Beta 2, and the various SharePoint related blogs from Microsoft Resources (See Fellow Bloggers on my blog), but when it comes to gathering and preparing for the upgrade, it still requires a lot of manual steps to ensure your migration/upgrade goes smoothly.

From talking to various Microsoft Peers, MVPs, and a bunch of other folks who just "live" SharePoint day in and day out, I can think of no better set of tools to assist with this preparation than SPSiteManager, SPUserUtil, The SharePoint Configuration Analyzer, and SPReports for the reasons noted below in the section "What can I utilize today". This also helps solidify to me, that the work that myself and a group of other SharePoint folks are doing to bring the next iteration of all these tools together, is a very worthy task. I'll be referring to a lot of the documentation included in the Planning, Deployment, and Operations Guides from the IT Content for 2007 Office System Beta 2, so it would be good to follow along.

What can I utilize Today

SPSiteManager

This tool is located in the SharePoint Utility Suite. In the Upgrading to Office SharePoint Server 2007 documentation (MOSSUpgrade.doc in the IT Content for 2007 Office System Beta 2 documents), in the section "Review upgrade best practices", you'll note that item 4 refers to the following:

"You can use the Adding content prevented lock on the Manage site collection quotas and locks page in SharePoint Central Administration to lock site collections. For more information about locking sites by using quotas, see Configuring Site Collection Quotas and Locks. "

If you only have one or two sites to do at a time, then it's a snap to just visit the site and quota page for the site and set the settings appropriately, but...if you need to do a batch of sites, then repeating those steps can be tedious and daunting if there are literally 100's of sites you need to perform this on.   

Instead, you can use the SPSiteManager operations "locksite" and "resetquota".

You can specify one site or many to lock or do a quota reset using the following options: 

  • A specific URL using a absolute URL to the site via the –url argument
  • A selection of URLs by using the –mask argument.
    1. You can expand this site search using the –allvs switch to look for matches across all virtual servers
  • A selection of URLs contained in a Site Distribution Document.
  • See the documentation for SPSiteManager for more details on each of these operations.

In the section "Estimate how long upgrade will take", beginning with "Additional factors in your environment can also contribute to longer upgrade times, including: "

Very large document libraries For example, a document library with over 250,000 documents all in the root of the document library (rather than in folders) will take a long time to upgrade, and might not be successful. Following the 2003 and version 2 guidelines for using folders to break up large document libraries can help you manage the library size. For example, the same document library, rearranged so that the 250,000 documents are divided into 125 folders should upgrade more easily.

Use the SPSiteManager "analyze" operation to scan your system. SPSiteManagers analyze operation checks against the capacity planning guidelines and writes warnings to it's output flagging where sites/webs/document libraries/lists etc have exceeded capacity planning guidelines. Not only should you do this to prepare for a successful migration, but you should monitor this in general so that your SharePoint environments perform appropriately. (See my previous post "A sampling of the analysis data from the new version of SPSiteManager", and I will be following up with another post specifically on this topic.)

Very large databases SQL Server best practices recommend that databases be no larger than 30 GB, beyond that performance can slowly degrade. Windows SharePoint Services version recommends no more than 50 GB in a database. If your databases are larger than that, it is recommended that you divide them up into smaller databases before running upgrade. Larger databases not only take longer to upgrade, but can make it harder to recover if upgrade does not complete successfully. There are community-supported tools available to move site collections between databases. For more information about reconfiguring content databases to suit these recommendations, see (This link is not yet available. It will be available in later versions of this content.).

There are cases, however, where your databases may have grown larger than these recommendations, and cannot be split. For example, you can only move Windows SharePoint Services version 2 site collections, and MySites, not portal areas. If you have a portal site with many large areas, it cannot be split up in SharePoint Portal Server 2003. In this case, the Stsadm.exe backup and restore commands can help you split the content up into more manageable chunks or you can consider migrating the content from large portal areas to Windows SharePoint Services version 2 site collections. For more information, see Microsoft SharePoint Products and Technologies Resource Kit Chapter 28 - Disaster Recovery in SharePoint Products and Technologies.

To perform this step, you can use the repartition operation in SPSiteManager to divide your databases into smaller databases. In fact, I hope their statement "There are community supported tools available to move site collections between databases" are actually eventually going to refer to SPSiteManager :) On that second paragraph, where they state to use STSADM backup and restore commands on your portals site collection, is incorrect. They may be referring to SMIGRATE, but you can not use STSADM backup/restore operations on a Portal Site Collection. In fact, SPSiteManager blocks this from occurring if it sees that the site collection is based off of a portal template.

The process to do this manually is tedious and painful (See the section in the SPSiteManager documentation titled "Automate site collection repartitions"). SPSiteManager automates the entire process for you for each site. You can easily move sites between Content Databases on the same SQL server, or across content databases on many SQL Servers. You can also move sites across virtual servers in the same farm with the repartition operation.

 Caution Be sure you are following the capacity planning guidelines from the old and new versions before you attempt to upgrade. If you have exceeded the guidelines for best performance, the upgrade process might take longer, or might not succeed (for example, the process might time out repeatedly on the same large document library). If your deployment does not meet the recommended capacity guidelines, you should consider whether you need to do some work to meet those guidelines before attempting the upgrade. Again, a trial upgrade can help you with that decision.

Heed this warning. Use SPSiteManager or something to analyze your sites and ensure they are within capacity planning guidelines.

In the sections titled "Create Communication Plan"

  • Site collection owners The owner of each site collection. You need to be able to notify site collection owners that the upgrade process is about to happen, and alert them to any issues you find when you upgrade their sites. If you are doing a gradual upgrade, you must also communicate with the site collection owner to determine whether their site has been completely upgraded and any customizations re-applied before you delete or inactivate the old site.

  • Site designers and developers If you have custom templates, Web Parts, Web services, or other custom elements associated with your sites, you need to work with the people responsible for developing or customizing those elements to make sure that you can create new versions of these custom elements, or to verify that these elements have upgraded correctly. For more information about potential issues with custom elements, see Use a trial upgrade to find potential issues.

  • Site users Although site users won't need to be included in making decisions about the upgrade process, you do need to let them know when it will take place and what they should expect.

And "Communicate downtime to site owners and users"

Now that you're nearly ready to upgrade, you need to communicate with the owners and users of your sites that their sites are about to be upgraded. As part of this communication, you should include information about:

  • Whether site owners and users will be able to use their sites during the upgrade process. All sites are unavailable during an in-place upgrade.

  • How long you expect the upgrade process to take and when their sites will be ready to use again.

  • Whether the site owners or users will have to re-do any customizations after upgrade (so that they can record information about the customizations now).

An update to SPSiteManager already has additions that report and give you a list of site collection owners across your farm, this should hopefully be live within the next week. You can also use SPUserUtil to gather the user information.

In the section titled "Develop new custom site definitions and create upgrade definition files", you first need to see where all your sites are that are utilizing these site definitions, or just a general list of what site definitions are in use. The prescan tool does a good job of "Totaling" up the use of specific site definitions, but SPSiteManager's analysis output can be utilized to give you a web by web list of what each web used as it's base site template.

You can also use the SDD file generated from SPSiteManger to help you create the "Upgrade definition files" as referred to in the section "Create upgrade definition files" section of the upgrade docs. I'm also considering creating an option in SPSiteManager to assist you with creating this upgrade definition file. At this point, I'm not sure if folks would find it useful or not.

SPUserUtil

This tool is located in the SharePoint Utility Suite.

As noted above in regards to the "Create Communication Plan" and "Communicate downtime to site owners and users" sections of the Upgrading to Office SharePoint Server 2007 documentation (MOSSUpgrade.doc in the IT Content for 2007 Office System Beta 2 documents). You can also use this tool to audit your users in your system. See my post "SharePoint Account Management using SPUserUtil - Part 3 - Auditing Accounts" for more information on this.

The SharePoint Configuration Analyzer

The SharePoint Configuration Analyzer is a tool that you can download from the Microsoft Download Center to analyze and report on your Microsoft Windows SharePoint Services installation and content. SharePoint Configuration Analyzer reports on a wide range of configuration errors and also copies a set of log files, configuration files, and other data to a results folder for further analysis or archiving.

SharePoint Configuration Analyzer is particularly useful for analyzing and troubleshooting Web Parts on your servers. For example, you can configure SharePoint Configuration Analyzer to list each Web Part installed on a virtual server and to report on all of the pages that contain an instance of each Web Part. This is useful when upgrading a Web Part to a newer version or when deleting a Web Part. Before upgrading or deleting the Web Part, run SharePoint Configuration Analyzer with these options selected. Then, by using the usage data, contact all owners of pages containing the Web Part you are about to upgrade or remove, giving them notice of the impending change.

Note: SharePoint Configuration Analyzer is not supported, and is available as is. It does not change the state of your Windows SharePoint Services nor does it repair errors that it reports. SharePoint Configuration Analyzer only copies its analysis results, along with any configuration files, log files, or other data that you requested, to its results folder, as described in this topic and in the SharePoint Configuration Analyzer Help.

You can use this tool to help look for custom web parts, etc. SPSiteManager gives you an average number of web parts per use on site pages, but this tool can be used with other more specific web part analysis at this time. SharePoint Configuration Analyzer verifies the following and reports any errors it finds:

SharePoint Configuration Analyzer verifies the following and reports any errors it finds:

  • Microsoft Internet Information Services (IIS) settings match Windows SharePoint Services requirements.

  • Web Part and Web Control assemblies are installed in a way that is compatible with IIS.

  • All virtual directories for a virtual server share the same application pool.

  • Web Part and Web Control assemblies listed in the SafeControls list exist.

  • Web Part instances on pages are associated with Web Part assemblies.

  • Policy files listed in Web.config files exist.

  • A copy of Microsoft.sharepoint.dll is not installed in the \bin directory.

SPReports

SPReport is a command-line utility that gathers metrics about a site and its sub sites, the document library and other lists in each site, and the documents in each document library.

SPReport uses the SharePoint object model to retrieve information about the current configuration and hence, the tool needs to be run locally from a SharePoint Web front-end server. The current version of SPReport cannot be run remotely.

The current release of SPReports is located at: https://www.gotdotnet.com/workspaces/workspace.aspx?id=8eb2bfa3-aac8-4b5a-b3a2-5accb29970eb

As you can see, there is a lot of overlap between the SharePoint Configuration Analyzer, SPSiteManager, and SPReports, thus the reason the authors of all these tools (including myself) decided to incorporate all of these tools into one. (See The Next Big Thing - The SharePoint Configuration Analyzer V.Next)

So what's the hold up?

Well, I still have to perform a service to my direct customers :) And additions to my tools mostly come out of necessity. Work on the tools usually happens either at night, if if I find a direct problem I'm working with my customers in which I see that it's easier to add that functionality to SPSiteManager, or one of my other tools, rather than ad-hoc create something else specifically for that need. I also ensure that what I'm making the change for, is a "Common" problem across all customers, and I see it as a lacking feature that we need. I've also been fairly busy (again) in general customer visits, as well as preparing to wrap up our year end. (Writing my review, finalizing other important tasks for customers, handling a bunch of reactive issues, etc), but I'm getting to a settling point again, and will have some more time to move forward with SCA.Next.

I've also had to make some quick additions to the existing code base, as I've seen things that needed to be added quickly before moving on with SCA.Next (See SPSiteManager update coming soon) There may be one more addition I make to this before releasing and moving on which is the Content Source Auditing and Various Alert help operations as noted in that post, but I have not decided.

Hopefully, one day, I can just sit and write support tools such as these...but until that happens, I just have to wait till I have an hour or so to write up an additional features. 

I "AM" however, currently finishing up the specs for SCA.Next to include all the above features, and then move forward with coding it all up.

In the end, I hope these tools help you with your MOSS 2007 upgrade planning and deployment. If you have any questions, feel free to leave a comment or email me! I try to respond within a reasonable time to all direct requests, just understand that I still have my day job to complete first :)

- Keith

Comments

  • Anonymous
    July 12, 2006
    Dude this is a great write up that I will definately be pointing my customers to. Thanks!!

  • Anonymous
    July 20, 2006
    Great work!! :)

  • Anonymous
    July 20, 2006
    "Windows SharePoint Services version recommends no more than 50 GB in a database. If your databases are larger than that, it is recommended that you divide them up into smaller databases before running upgrade"

    Could you not work with the SQL Server team to get the table/index partitioning on MSSQL 2005 sorted? like automatic range partitioning by content DB or partitioning by size in case of VLDBs(i.e. MSSQL would create a new partition when size gets to 50 GB)?
    This issue would apply to most MS applications using MSSQL as a backend e.g. in my case also the BizTalk MessageBox ....

  • Anonymous
    July 21, 2006
    This best practice limit simply boils down to recovery time.  If if you did that, you would still need to determine your database size based on the amount of time it might take you to recover a complete database.  Also, site data has to remain in the same content database, i.e. you cannot split a site collection across databases, all of it's webs have to reside in the same database.   We can't trigger to create a new db as your SIte Collection grows, as we would not be able to split the site collection up across the databases.

  • Anonymous
    August 03, 2006
    Here is an assortment of various 2007 Microsoft Office SharePoint Server Documentation / Reference Materials...

  • Anonymous
    August 24, 2006
    The comment has been removed

  • Anonymous
    October 06, 2006
    Question: I've heard 50GB is a database limit. I need to support 10TB+ and I'm concerned about management

  • Anonymous
    November 12, 2007
    2007 MOSS Resource Links (Microsoft Office SharePoint Server) Here is an assortment of various 2007 Microsoft

  • Anonymous
    February 18, 2008
    Gracias a Mark Kruger (SharePoint MVP) por esta lista de recursos de SharePoint donde podréis encontrar

  • Anonymous
    May 01, 2008
    PingBack from http://miguel.cheapnewsguide.com/mossreportconfiguration.html