Upgrading to SharePoint 2010 with Powershell

Powershell commands that are useful during SharePoint 2010 Upgrade

Get-Command –noun sp* – this is the equivalent of the stsadm –help or doing a what feels like a command line dir for the list of commandlets.  When you start off, this seems like it should be easier.  If you simply stick with the SharePoint commandlets in the beginning, it will feel A LOT like running operations and parameters against STSADM.

Test-SpContentDatabase – Used to validate a database against a given web application.  This command can be used with any post SP2 2007 database or with any SharePoint 2010 database.  While not required the insight gained will essentially reveal the WHAT IF errors and warnings associated with upgrading the database while making NO changes to the database.  The database itself need to be part of any farm and simply needs to be online in SQL.  Also works for version to version and even incremental upgrades between patches.

You should always run test-spcontentdatabase on your 2010 farm before adding ANY content database to your farm despite the version.  Even if you can spin up a 2010 instance you should run this command even if you’re planning on using in-place upgrade.  This insight is invaluable and is NOT the same as what you’ll get out of stsadm –o preupgradecheck.

>Test-spcontentdatabase –name %Nameofdb% –webapplication %http://nameofwebapp%

Mount-SPContentDatabase – Used to attach a database or multiple parallel databases to the farm.  Essentially is nearly the same as the STSADM –o addcontentdatabase.  It does actually have more options when you start looking at parameters on the surface in each command.  This is where the power of powershell competes on a command level.  If you’re doing parallel content database attach for example, this powershell method is recommended.  You’d simply run each of these in different command/management windows.

Running mount-spcontentdatabase –? will provide the context for adding a content database into the farm.  Note you can run multiple of these at the same time by simply opening up multiple windows.

 

>Mount-SpcontentDatabase –name %nameofdb% –webapplication %nameofwebapp%

Upgrade Status in SharePoint 2010

Viewing Upgrade status in Central Admin provides much more insight into the upgrade process including how long it’s been running, number of errors & warnings, and even what step it’s on in the process.

Note scrolling down provides even more insight including the thread and process ids, path to the upgrade and error logs for this session.

Looking and the error logs

Looking at the screenshot above you can see a path to the log file.  This is also where you’ll find the upgrade-timestamp.log and error-timestamp.log

Opening up the Error log, it’s amazing how similar the errors are to the test-spcontentdatabase almost identical.

Upgrade-SPContentDatabase – Don’t be confused about the this command as doing upgrade, it is strictly for resuming.  This command is used to only to resume a failed Upgrade.  It can be used on in-place upgrade failures for failed databases or database attach upgrade failures.  In contrast the STSADM –o Upgrade command can resume binary and database upgrade, but more holistically.  I’ve found the STSADM to be the fail safe command as it will check both the binaries and all of the databases.  If you have problems with one particular database the upgrade-spcontentdatabase will obviously the best choice to target the resume of the upgrade.  It’s not just used for failures, but to restart the upgrade of a database where issues have been addressed.

One other option is the psconfig.exe –cmd upgrade –inplace v2v –passphrase < passphrase > –force this command should be used for troubleshooting in-place upgrades with early binary upgrade failures and even goes another level higher than stsadm.

 

Upgrading the SSP to Services Apps with Powershell

Upgrading the SSP is definitely the tricky part of db attach, while I do think most small and medium organizations will skip this in lieu of building out the services fresh, those with large complex search configuration will likely not want to loose their content sources at a minimum. 

 

Upgrade-SPEnterpriseSearchServiceApplication – Upgrade the Search Service Application Instance.  This commandlet it designed to upgrade the content sources and configuration of search and to upgrade it into the new service application.

Upgrade-SPSingleSignOnDatabase – Upgrade the SharePoint Single Sign on database to Secure Store Service Application.

Upgrade-SPProjectWebInstance – Upgrade Project Server databases.  Obviously this only applies with Project Server deployments, but I know there are definitely many out there.

Get more insight on these commands at TechNet or by simply typing the listed command followed by –? or –examples or –detailed or -full

If you really care about your SSP, In-Place Upgrade gives you more of your settings and config in SSP, Why not consider a hybrid approach…

While I’m really not a fan of in-place as a primary strategy to upgrade you farm, I do think many will choose to do database attach for the main portion of their farms.  Many will choose to use a hybrid approach to upgrade the services configuration.

SharePoint 2010 replaces the SSP concept with “service applications.” So, each SSP upgrades these service apps.  If you have many SSPs you’ll find a TON of databases as each of your SSPs will be exploded into these services.

• Search Service application
• User Profiles Service application
• Excel Service application
• App Registry (for backwards compatibility)
• Managed Metadata Service application

Much of what will be missed in the database attach upgrade is simply settings and configuration with the exception of search, audiences, and profiles. 

The biggest complaint I expect to hear is profiles.  Why is there no profile powershell script for upgrading the profiles?  There is obviously a lot of data in the profiles that is driven by the users that is not just settings.  I think this will ultimately drive a lot of people into the hybrid approach for getting the actual profile data.

Using Hybrid Upgrade Approaches

Imagine using db attach for all your content databases, then simply detaching them and running in-place upgrade on a farm with no content databases.  This will upgrade the SSP into those service applications above which can then be backed up with the 2010 built in backup tools and then restored into your 2010 farm.

See Hybrid approach #2 in the MS Upgrade Approach poster for Microsoft’s view of detaching databases to get your services and settings across by driving a post in-place upgrade of the services.  I do think there’s a lot of ways to do this.

There’s a lot more flexibility for thinking outside the box here….

For example, why not make a backup of your farm, then restore to a new farm.  Detach all the content databases run In-Place upgrade to upgrade farm services and settings.  Then now you’ve got a 2010 farm you can go with your scheduled database attach upgrade.

Hybrid approach #1 (read only databases) really speaks to something that everyone should be doing with every db attach which is simply setting the databases to read only even if you use #2 it doesn’t keep you from running with #1 (read only databases).

Want to talk more about this?

I’ll be including this walk through demo with more discussion on hybrid approaches and SSP considerations and more in detail in my 400 Level Upgrade Drill Down session at the Experts Conference in LA April 25-28.  If you haven’t registered, be sure to use the Discount Code: ATGNVET

See you there.

For more Resources and insight on 2010 Upgrade see my SharePoint 2010 Upgrade Insight series.