With the newly released SharePoint 2010. I had an excellent opportunity to get approval to migrate to the new environment. I wanted to utilize the new features available for future projects that I have been developing in preparation.
The environment I’m moving, consists of about 110 subsites in one site collection. A single app/front end server attached to a stand alone SQL server. The content database is approximately 4 gigs. So, all in all, a quite small environment. But it is the focal point for collaboration for the company. customized fairly extensively to meet the needs of the different departments. Also, it has been pushed out in group policy as all 14,000 employees’ home pages. Obviously, this migration has to be performed smoothly and quickly. Below is a detailed process I developed while planning the migration. Also, I included a development (2nd tier) server to move the WSS 3.0 environment to in order to clean it up before the migration.
I have to say first off, that the pre-upgrade check failed. But a detailed analysis showed the features that failed, were not going to be used in the new environment. So that in itself would not have proved the migration process a failure, but would cause the pages they were used on, to show as unavailable or broken. The catch with plugins is that even if they are uninstalled and removed from the original environment, the feature reference will remain within the default.aspx pages they were used on in a site by site basis. After migration, the default.aspx pages can be accessed in SharePoint Designer 2010 and opened in advanced mode. From there the feature references can be removed.
Communication regarding the migration is going to be essential to the success of the project. Without the assistance of the end users, you will find you will probably have more functionality and process bugs than you can handle at one time. As this update comes with a significant visual upgrade, putting your SharePoint’s best foot forward is essential. You will want the migration to be as pain free as possible for the end users. Help them know what to expect as this is a new roll out.
Discuss with Designers, the purpose of migration, new functionality and their required cooperation with the sites they are responsible for, to assist in locating issues on their sites.
Migrate the site over to Foundations and test navigation & functionality.
Resolve breaks on front end servers.
STSADM-backup site collection from production environment.
Xcopy .dat file to WSS 3.0 development server.
STSADM-restore site collection to development server.
Remove custom web parts and customizations that are incompatible with Foundations.
SharePoint Designer 2007 – default.aspx – remove 3rd party web part references from the master default.aspx file of sites that have been modified by the webpart.
If anonymous access has been enabled on the original production environment and needs to be receded, it would be a preferable practice to disable this feature on the development server before the step of restoring the site to the development server in the migration process. Once anonymous access is disabled, it will automatically remove the access to all sites configured for anonymous access.
Disable anonymous access within Central Administration and set permissions on top level site to have domain users as read only users.
(done automatically on the move to the dev server as Anonymous is already disabled.)
Set all sites that originally had Anonymous access to a read only Active Directory security group such as “SP_Read”.
(There will be spots that will be missed as there are detached subsites that will have had anonymous access calendars, etc. Will need to coordinate with Content Admins to have them verify their site is fully functional)
After the restore to the development server has been complete and resolving any inconsistencies in the WSS 3.0 environment, the migration process can occur.
Stop and detach the WSS 3.0 content database of development SharePoint environment in SQL Server.
Xcopy database & log files to BI SQL Server.
Attach WSS 3.0 database to BI SQL Server.
Create web application in central admin on new production server.
If already exists, delete existing content database within Central Admin.
In PowerShell, perform a test migration to verify the database move & check log with following TEST script:
test-spcontentdatabase -name corp-srce-dev-migration -webapplication http://newserverapplication/ >c:results.txt
Mount Database to Web Application with the following script:
mount-spcontentdatabase corp-srce-dev-migration -databaseserver corp-bi-sql2 -webapplication http://newserverapplication
The WSS/Foundations environment does not have masterpage/navigation hierarchies inherent by default, because of this, the top global navigation bar is not by default configured as a universal navigation bar. This will need to be manipulated within the default.master and/or v4.master pages within the 14 hive. The default master pages are located here: C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATEGLOBAL*.master
Modify current master page to include new navigation properties.
Visual “4” Upgrade
Due to WSS site templates not being inherent of the parent pages, they will have to be visually upgraded individually. When I performed the migration, the v4.master file was not put into the master page _catalog folders on each site. This will have to be copied in manually. To complete this process, the following steps must be followed:
In SharePoint Designer 2010, copy the v4.master page into the _catalog folder of the site.
View site within browser and set v4 view as permanent by setting visual up grade as permanent in site settings.