23 Dec 2010 12 Comments
Ever tried to run the PreUpgradeCheck command at your MOSS farm and received a frightening long list of issues that takes forever to solve manually?
If you are like me you refuse to do any manual work that takes more than 2 hours (and you’ll have to re-do it for every farm) – so I’ve tried to script all the required fixes. This is one of those posts that I’ve been working on for months so I hope you appreciate it – I’m a bit proud of the script at the end of the post.
The goal is to have a PowerShell (v1.0) script fix every one of those blocking issues you see in the PreUpgradeCheck report. On my own very messy (intentionally so!) farm with 40+ databases and site collections and a large number of solutions I’ve managed to fix all but the one about my operating system needing an upgrade to Server 2008. That one I’ll not work on
Note: It will only work of you have installed SP2 and cumulative update from October 2009. At least. I recommend that you work of as new a version as possible.
The script will remove invalid “stuff” from your sites so be absolutely sure that every solution that you care about is deployed to the farm – otherwise all features, files and webparts from missing solutions will be removed from the sites.
The script will also publish unpublished pages if they contain some of these invalid webparts.
I give you no warrenty – backup your farm first. I’m pretty sure I won’t mess it up though…
What it does
The script will check a number of things in your farm by working on the output of the “stsadm –o enumallwebs” command.
I use some direct SQL to get information out that is not possible through the API, but all modifications are done through the SharePoint 2007 API in a supported way only.
The script currently does 5 things:
Remove Invalid Webparts
(AKA: “The following web part(s) are referenced by the content, but they are not installed on the web server“)
This is the method I started with and by far the biggest timesaver.
It uses the “stsadm –o enumallwebs” to get a list of webparts that’s currently missing in your farm. They have been uninstalled at some point and are now those webpart with “Fatal Errors” on some of your pages. Some of the missing webparts are not even listed as failing with fatal errors (they have socalled “bad markup”) they are just listed on the page with and ID and no description (i.e. if you go to a given page and add “?contents=1″ to go to the webpart maintenance page).
Trouble is that there can be lots of these and there is no easy way to find all the pages.
This function will query the SQL for the pages where these webparts are (both the one with fatal errors and the ones with “bad markup”) and then remove them through the API. The offending pages will be published (if not already), whatever checkouts they may have been there is overridden, the webparts are removed and the page re-published.
It will take all pages not just the one in document libraries (i.e. those that came through features)
Note: I’m only handling the case of shared webparts I did not have any user specific webparts in my test farm so I’m uncertain how that will be handled.
Note2: I’ve copied the PublishListItem from some of Gary Lapointes excellent extentions and converted them to powershell. It seems that no one has been as thorough handling special cases as he.
Remove Orphaned Site Collections
(AKA: “Issue : Orphaned site collections“)
Site collections can get orphaned in a number of ways; the fix is simply to delete those.
You will not lose anything (new) as those sites were not accessible before anyway.
Remove Uninstalled/missing Features Activated at Web scope
Features that have been uninstalled at some point often linger in the content databases because they are still activated in some web or site. That activation is not deleted when the feature is removed though the feature will have no actual function anymore.
The script will run through all those SPWeb’s and deactivate the offending features.
Note that I’m not crawling all webs in the site I only access those with missing features.
Remove Uninstalled/missing Features Activated at Site Collection Scope
(AKA: “The following feature(s) are referenced by the content, but they are not installed on the web server“)
Similarly features may be activated at site collection level and forgotten. In this case these features are not reported by the “stsadm –o enumallwebs” command and I have to run through every Site Collection in the farm to locate the features.
Remove Missing Setup Files
(AKA: “The following setup file(s) are referenced by the content, but they are not installed on the web server“)
After features have been uninstalled it is quite common that they forget to remove the files they installed on the farm. I suppose it’s just the way SharePoint works. If a feature installs a file in a document library somewhere changes are it will remain.
What are those files? Some examples are stuff in the style library, webpart gallery, master pages, page layouts, etc…
This method uses SQL to find where the missing files are still references and deletes them from the lists. It even deletes files that have been unghosted which could actually still be accessed because SharePoint has made a customized copy of it.
I’m still considering if it would be better to only remove the ones that are still ghosted.
Note: In my tests some page layouts could not be removed because they were still being referenced in the farm. That is clearly an error in my farm, however the script will not fix that. It really does require special handling by a human to decide what to do. I suppose it’s a good thing that they are not removed in this case as some things might otherwise break.
What it does not no
Out of scope of script:
- Fixing the OS version
- Fixing the database version
How to Execute
First of all the script requires you to be site collection owner on every site collection, farm admin and have owner rights in every content and configuration database. Pretty much all you can get.
In the beginning of the script there is a few switches that you should know:
- The logging level, set it to 3 to get lots of info: $verboseLevel = 3. Lower is less.
- The “$whatif” ´switch. Set it to “$true” to have the script simulate a run but not change anything in your farm
- The “$targetdb” that can limit the script to a single content database only. Blank equals all databases a name indicates one (note: Not the site name)
I’ve built in a lot of error handling and logging to let you know what’s going on.
Note that STSADM must be included in the path setting.
Recommended sequence of execution
Everything need to run on the SharePoint 2007 server and it must have (at least) PowerShell 1.0 installed.
- Backup all content databases. This is not optional. Easiest to use stsadm –o backup
- Use stsadm -o preupgradecheck
- Run script on one or all databases with the “whatif” statement set to true
Check and recheck the output and verify that it looks correct to you.
- You may want to reduce the logging level a bit
Run with $whatif set to $false, i.e. let it work!
- Depending on your confidence in me you can ask to work on only one database at a time
Check the output!
- Errors and warnings will be written both to the output stream (what is piped down in your logfile) and on the screen
- Run preupgradecheck again and see the result J
Note to run the script use something like “powershell -file FixUpgradeIssues.ps1 >>fixupdateoutput.txt”, i.e. always pipe the output to a file that you can investigate later.
Runtime is about 5 minutes on my 40+ database test system so reasonably ok given the task.
I’ve been working on this script for a couple of months and have fixed a huge number of issues and funny edge cases; however I’ve likely missed a few. Let me know in the comments.
Good luck J
Download the Actual Script
All 850 lines of powershelling are not pretty in a blog post, so you can download it here.
[Updaet 25-12-2010: Now with correct file]