Cornelius J. van Dyk's SharePoint Brain Dump

Well I've been catching up on my To Do list this morning. One of my items is this MONSTER post that I've been working on… it seems forever! Anyway, it is finally completed and scrubbed and I hope it provides some useful information for you…

This Step-by-Step guide will detail my journey through the upgrade wilderness and will hopefully help you migrate your SharePoint Portal Server 2003 medium farm to Microsoft Office SharePoint Server 2007. I have intentionally documented mistakes that I made and ran into to allow this guide to also help you trouble shoot some of the most commons issues you could expect to run into. By documenting my pain, I'm hoping to save you some pain.

At the time I struggled through this migration, there was hardly any documentation around it. Microsoft has done a good job since then of creating good documentation to assist in these processes. When deploying a server farm, be sure to read this TechNet Article first:
http://technet2.microsoft.com/Office/en-us/library/356d3a0b-fc26-455c-9afb-6d2ffdceef841033.mspx?mfr=true

When adding servers to a farm, be sure to read this TechNet article:
http://technet2.microsoft.com/Office/en-us/library/b4279ff9-2842-475a-8d7f-cc90711c47271033.mspx?mfr=true

Before we commence, it is important to note the configuration of the SPS 2003 farm. I'm going to be using a farm together with Kerberos authentication because in the REAL WORLD most configurations are that way, not the single server/NTLM configurations that most documentation and demos use and show you.

Please note that this guide is MASSIVE to say the least. It over 7000 words long and contains almost a 100 screen shots so it's going to take you a while to get through this. You may want to download it for future reference from the Downloads section. Now grab your coffee, fire up your remote desktops and let's get going. J

The farm is configured as follows:

• SPWEB
  • Windows Server 2003 SP1.
  • SharePoint Portal Server 2003 SP1.
  • Windows SharePoint Services 2.0 SP1.
  • SharePoint Web/Search server roles.
• SPJOB
  • Windows Server 2003 SP1.
  • SharePoint Portal Server 2003 SP1.
  • Windows SharePoint Services 2.0 SP1.
  • SharePoint Job/Index server roles.
• SPSQL
  • Windows Server 2003 SP1.
  • SQL Server 2000 SP4.
  • SharePoint database store.

* IT IS IMPORTANT TO NOTE THAT YOU HAVE TO SIGN ONTO THE SHAREPOINT SERVERS WITH THE SERVICE ACCOUNT THAT HAS ADMIN RIGHTS THROUGHOUT THE FARM, INCLUDING THE SQL SERVER.

You may need to add the account to the local administrators group in order to logon using the account.
If we take a look at the portal BEFORE the upgrade, we see the following:

We are now ready to commence the upgrade by following these steps:

1. If your portal is not yet upgraded to SP2:
   1. Upgrade WSS to SP2.
      1. Download the Windows SharePoint Services 2.0 Service Pack 2.
      2. Download the SharePoint Portal Server 2003 Service Pack 2.

         

      3. Begin by double clicking the "WSS2003SP2-KB887624-FullFile-ENU.exe" file.
      4. Setup will prompt you to confirm that you wish to install the update.

         

      5. Click "Yes" to proceed.
      6. You will now be presented with the End User License Agreement.

         

      7. Click "Yes" to accept the EULA.
      8. Setup will now unpack the installation files.

         

      9. Once Setup is complete, you will be prompted to restart the server.

         

      10. Click "Yes" to restart the server.
   2. Upgrade SPS to SP2.
      1. Begin by double clicking the SPS2003SP2-kb887623-fullfile-ENU.exe file.
      2. You will be presented with the End User License Agreement. Click "Yes" to accept the EULA and proceed.

         

      3. Setup will now unpack the installation files and proceed with the installation.

         

      4. You will receive a prompt to configure error reporting. Decide which option is best for you and click the appropriate button.

         

      5. Setup will NOT notify you of the need to restart your server, but believe me, IT IS NEEDED! So go ahead and reboot your server one more time.

         Congratulations! You have completed your portal web server upgrade to Service Pack 2.

         REPEAT STEP 1 ON YOUR SPJOB SERVER.

         Once your job server has been upgraded to SP2, you can proceed with the MOSS installation.

2. The prerequisite for installing MOSS is the .NET Framework 3.0. Download it here. If you need the full download versions, you can get the x86 version or the x64 version depending on your platform.
   1. Double click the "dotnetfx3setup.exe" file.
   2. Setup will unpack the installation files.

      

   3. Once all the files have been extracted, you will be presented with the .NET Framework 3.0 End User License Agreement.
   4. Ensure you've read the agreement and agree with its terms.
   5. Select the "I have read and ACCEPT the terms of the License Agreement" radio button.
   6. You can also check the "Send anonymous information about my setup experiences to Microsoft Corporation" check box if you wish to do so, but it is not required to continue.
   7. The "Install" button should now be enabled.
   8. Click the "Install" button.

      

   9. Setup will now minimize to the system tray and conduct a background installation. You can double click the icon if you wish to see more detailed installation status.

      

   10. Setup will proceed to download the remaining components of the installation package.

       

   11. After the download is complete, Setup will commence the actual installation.

       

   12. Once Setup completes the installation, you'll be presented with the final status screen.
   13. Click "Exit" to complete the installation.

       

   14. You will need to restart your system for the new framework to take effect.
   15. If you don't have any other applications open, click "Restart Now" or otherwise, click "Restart Later" and manually shut down your application and restart your system.

       

       REPEAT STEP 2 ON YOUR SPJOB SERVER.

3. Now proceed with the main MOSS installation.
   1. Launch MOSS from either the CD or the folder location where the installation files was copied by double clicking the "setup.cmd" file.

      

   2. The file, being a DOS command file will open a black command window as it processes in the background prior to launching Setup.

      

   3. Once Setup launches correctly, you will be presented with the Product Key screen.
   4. Enter your 25 character product key.
   5. A green check mark should appear behind the product key indicating a valid key.
   6. Click "Continue".

      

   7. You will be presented with the End User License Agreement screen.
   8. Ensure you are familiar with the contents of the EULA.
   9. Click to check the "I accept the terms of this agreement" check box.
   10. Click "Continue".

       

   11. You are now presented with upgrade options.
   12. On the "Upgrade" tab, select the "Yes, perform a Gradual upgrade" option.

       

   13. Click on the "Server Type" tab or press Alt+T to activate the server type tab.

       

   14. By default the "Complete – Install all components…" option is selected. If it is not selected, select it now.
   15. Click on the "File Location" tab or press Alt+F to select it.

       

   16. Depending on your server configuration, you may have to changes these settings. In our case, we have a small OS drive C:\ and then the main data drive as D:\, so we change our application and file location as well as our index file location to the D:\ drive maintaining the same path.
   17. It is important to note that the index files generally are about 150% the size of the SQL database files they represent so if your SQL data files are 10 GB in size, then you would want to ensure that the index file location has at least 15 GB free space in order to hold all the data. This figure varies with content types for example if you're storing a bunch of binaries or video files, there generally isn't that much to index besides properties and name so your index size would be considerably smaller. Our figures are just used as a safe guidance rather than a rule.
   18. Click the "Install Now" button.
   19. Installation will begin and Setup will provide you with feedback related to installation progress.

       

   20. Once the installation is complete, you will be notified.

       

   21. IMPORTANT NOTE: UN-check the "Run the SharePoint Products and Technologies Configuration Wizard now" check box option.

       The reason we do NOT run the wizard directly after installation is because part of the upgrade wizard's prerequisites is that PRESCAN must have been run on our environment. Because PRESCAN is only dropped onto our server by Setup, it stands to reason that we cannot have run it before now.

   22. Click the "Close" button to close Setup. Don't worry, we'll get back to the Config Wizard soon enough.

       REPEAT STEP 3 ON YOUR SPJOB SERVER.

4. We can now proceed with the MOSS configuration.
   1. Conduct a PreScan.
      1. Locate the "prescan.exe" application. The default installation location for this file is in the "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN" folder. NOTE: This is NOT the program file installation location you specified earlier. This is the location of the WSS services which is almost always installed to this folder location. In our example, we installed the program and data files to the D:\ drive, but the PreScan tool is still installed to the C:\ drive.

         

      2. You should also see the "preupgradescanconfig.xml" file listed with the "prescan.exe" file.
      3. Open a command window.
      4. Navigate to the source location for PreScan. The easy way to do this is to copy the Address URI from Windows Explorer, excluding the "C:\" part, and then in the command window after confirming that the prompt is on the same drive as the URI and typing "cd\", right click in the command window and select "Paste" from the popup window. Saves a LOT of typing. Alternatively you could use "cd\pro*\com*\mic*\web s*\12\bin". It might also be a good idea to add this path into your command prompt default path for the future because you're going to spend a LOT of time in this folder using the likes of STSADM.exe etc.
      5. Enter the "prescan /c preupgradescanconfig.xml /all" command.

         

      6. PreScan will provide progress indicators, rudimentary indicators but indicators nonetheless.
      7. If you have a customized portal solution, or anything but a blank standard portal installation for that matter, odds are you will run into this.

         

      8. As you can see, PreScan failed.
      9. Note the names of the files that PreScan had written.
      10. Navigate to the folder location PreScan had noted.

          

      11. Locate the files in question.
      12. The Summary XML file will contain an inventory of sites in the portal. This list is very useful when you're putting together a communication plan for the migration of sites as it will identify unghosted pages. Sites that contain unghosted pages will not migrate and automatically inherit the cool new features of Office SharePoint Server 2007 and Windows SharePoint Services 3.0. Instead these sites will need to be reverted back to template in order to accomplish this and this fact need to be communicated to your users. Failure to do so is a recipe for disaster and aversion to adoption of the new platform so PLEASE communicate, communicate, communicate!

          

      13. Opening the Log text file however is the one we're interested in as it contains the listing of sites that caused errors during PreScan.

          

      14. In our example, you can see that the test5 site is using a template that could not be located on the server. In most cases you will be doing this as a dry run on staging servers with production backups for data so errors like this is possible. In this case, we debug the issue by opening a browser and navigating to the site in question.

          

      15. As you can see, we simply got an error on the site.
      16. You can navigate to the original site as well to see what the template looks like. In our example, the original master site turned out to be a Business Scorecards Accelerator (BSA) site. We had not installed BSA on the staging server thus the error occurred during PreScan. Remedy the situation by installing the BSA into the staging server and rerunning PreScan.
      17. Another alternative is to do some cleanup throughout this process. We saw that the site called "test5" had very little on it, in fact, it is safe to say the site had never been used. Being a test site, it is probably OK for us to delete the site. You can delete the site by navigating to the parent site's Sites and Workspaces page. Remember to check with the site owner before proceeding with this course of action.

          

      18. Remove the site by clicking the Delete link, but ONLY if you are ABSOLUTELY sure the site is not in use anymore. Remember to contact the Site owner!
      19. When you scroll to the bottom of the log file you will notice a summary of site collections that experienced problems during PreScan.

          

      20. In our example, the Test5 was under the /ED site collection and as such /ED is listed as a problem.
      21. It should be obvious why the SocrecardDevelopment site collection was listed as well.
      22. Looking at the original site it's clear it's a BSA site.

          

      23. The log file also provides some useful summary stats derived from PreScan.

          

      24. As you can see, it notes the number of site collections, the number of web sites, the number of custom templates and the number of unghosted pages. These are all important to note as each will have some effect on your upgrade process. Unghosted sites will need to be reverted back to template. It is a manual process and knowing how many sites will need to be addressed helps in the planning of the upgrade.
      25. Correct all the issues at hand and rerun the PreScan tool.

          

      26. This time around, provided all issues were addressed, the PreScan should complete successfully.

          

   2. Execute the configuration tool to configure MOSS.
      1. Using the "Start/All Programs/Microsoft Office Server/SharePoint Products and Technologies Configuration" option, restart the Config Wizard.

         

      2. You will be presented with the Config Wizard Welcome Screen.

         

      3. Click the "Next" button to continue.
      4. You will receive a services reset warning dialog that warns you about the need to restart certain services such as IIS and some SharePoint services.

         

      5. Click the "Yes" button to confirm and proceed.
      6. You will receive a Language Pack warning message that states the need to install additional language packs at this point. If you do indeed need to install more language packs, this is the time to do so. You can download the following language packs.
         1. MOSS 2007 Language Pack for X86.
         2. MOSS 2007 Language Pack for X64.
         3. WSS 3.0 Language Pack for X86.
         4. WSS 3.0 Language Pack for X64.

             

      7. For more information on deploying the language packs, see the TechNet site.
      8. Leave the dialog window open and conduct your language pack installations.

         

      9. Once all language packs have been installed, click the "OK" button to proceed.
      10. You will be presented with the Server Farm Connection screen.

          

      11. VERY IMPORTANT! Select the "No, I want to create a new server farm" option NOT the "Yes, I want to connect to an existing server farm" option if this is your SPWEB server cycle. This is a very confusing option because you already have a server farm and instinctively you would want to just add to the farm as opposed to creating a new. To clarify, we're not doing anything with the old farm which is why we need to create an entirely new farm.
      12. Click the "Next" button to continue.
      13. Next you will be presented with the Database Settings page.

          

      14. Enter the name of your SQL Server into the "Database Server" edit box e.g. "SPSQL".
      15. By default the Config Wizard will have populated the "Database Name" edit box with "SharePoint_Config". You can change this value if you want or you can simply accept the default setting. It is recommended that your retain the "Config" moniker in the name though as it will help you identify your database later on during administration and backups.
      16. By default the Config Wizard will enter the domain service account in the "Username" edit box. This is the same account that is used as the service account for our existing farm i.e. the account that has "Security Administrator" and "Database Creator" roles on the SQL Server and it should also be the same account we're logged into the server with. Ensure that the account is entered as DOMAIN\USER. If you only enter the USER portion of the account name, it will automatically try and authenticate as a local user i.e. SERVER.DOMAIN\USER.
      17. Enter the password for the service account in the "Password" edit box.
      18. Click the "Next" button to continue.
      19. In my case, we got the following error dialog window. If you do not get an error, simply skip ahead to step xxiv:

          

      20. After locating the log file and opening it, we searched for the "ERR" code and found the following. I have highlighted the important parts in RED:

1. At first I thought it was a SQL Named Pipes issue, but once I looked a little closer at the error, I noticed that the server name was that of the WEB server and not the SQL server. Let's take a look at the screen information used again.

   

2. As you can see, I incorrectly entered the SPWEB server name instead of the SPSQL server name.
3. Correct the error and click the "Next" button again.
4. Next you will be presented with the Admin Web App screen. This is one of the new things to SharePoint administration that I'm very happy and excited about. In SharePoint 2003 you had to manually go and change the Central Admin web's port from the server command line using STSADM. I don't know how many of you had ever tried that, but it's painful to say the least… not because it's hard to type a command in the command window, but because the IIS web isn't similarly updated which means you had to go into IIS and change the port assignment manually in there as well. With SharePoint 2007, that problem is no more… unless you forget to do the next step.

   

5. The Config Wizard will automatically assign a port for the Central Admin application, but I find it easier to specify the port number. That way it makes remote administration much easier. It also standardizes your administration of different servers if your admin port is consistent so:
   1. Check the "Specify port number" check box.
   2. The Edit box should become white and editable.
   3. Change the edit box value to a common value you want to use.
6. The Config Wizard will default to NTLM authentication and here is where I have a real problem with MOST of the demo's and documentation out there. Most administrators worth their salt will be using Kerberos thus in the REAL WORLD you'll find Kerberos being the standard option, but most demos do NOT show that and most speakers and authors will simply select NTLM. Kerberos is the better option and with this version, also the recommended route to take. Select the "Negotiate (Kerberos)" option. NOTE: The system administrator will have had to configure Kerberos beforehand so ensure this was done prior to following these steps. For help in the Kerberos configuration process, please see this KB article: http://support.microsoft.com/kb/832769
7. Click the "Next" button to continue.
8. You will receive a Kerberos warning dialog window.

   

9. Click the "Yes" button to continue.
10. You will be presented with the Settings Review page.

    

11. Click the "Next" button to continue.
12. The Config Wizard will now configure MOSS on your server, create the new farm database etc. You will be presented with visual feedback related to progress.

    

13. Once the Config Wizard completes its configuration of SharePoint, you will be presented with the success page.

    

14. Click the "Finish" button to complete the Config Wizard.
15. The Config Wizard will close and an IE browser pointing to the SharePoint Central Administration page will open. Because the site is not currently defined in any of IE's trusted zones, you will be prompted to logon.

    

16. Due to the content on the SharePoint site, IE will popup a security warning.

    

17. Click the "Add" button.
18. You will be presented with the Add Sites dialog window.

    

19. IE will automatically populate the server name in the edit box.
20. Click the "Add" button to add the site to the Trusted Sites zone.
21. Click the "Close" button to continue.
22. The main Central Admin page will load.

    

23. You will notice the SPJOB server listed in the Farm Topology as "Not Configured". It is now time to configure the SPJOB server.
24. The natural instinct is to go ahead and repeat the configuration process from step 4.b.i. above on the the SPJOB server, but this time instead of creating a new server farm, connecting to an existing server farm. Unfortunately, this will not work as you would expect. I'm going to detail the steps I followed and explain the issue that I encountered for educational and informational purposes, but if you're just interested in continuing your setup, skip the following section completely.

     

    NOTE: Do NOT follow the next 12 steps! This is detailed for information only! Continue again at step xlv.

     

    1. Continuing in the tradition of repeating steps done on the SPWEB server on the SPJOB server as well (this also includes multiple SPWEB servers), I started by repeating steps 4.b.i. through 4.b.ix on the SPJOB server.
    2. When I got to the "Connect to a server farm" screen, instead of selecting "No, I want to create a new server farm", I selected the "Yes, I want to connect to an existing server farm" option because we had already created the server farm when we ran the config wizard on the SPWEB server.

       

    3. Click the "Next" button to continue.
    4. You will be taken to the Database Settings page.

       

    5. This time, the page will look a little different in that there will an additional control. The "Retrieve Database Names" button, just to the right of the "Database server" edit box. The "Retrieve Database Names" button will be disabled though. The "Database name" control is also a dropdown list instead of an edit box.
    6. Enter the name of the database server into the "Database server" edit box e.g. "SPSQL".
    7. The "Retrieve Database Names" button will now become enabled. Click it.
    8. The Config Wizard will retrieve the name of the database you used to create the original farm and populate it in the "Database name" dropdown list. If you kept the default database name during the SPWEB configuration phase, this value should now be "SharePoint_Config". If you have multiple configuration databases from multiple farms, select the correct database name that was used during the SPWEB configuration phase from the "Database name" dropdown list.
    9. The Config Wizard will also populate the "Username" edit box with the content account by default. If you want to configure a different user account for the SPJOB server you can change this value now.
    10. Enter the password for the account you're going to use into the "Password" edit box.
    11. Click the "Next" button to continue.
    12. One would expect that executing steps 4.b.xxiv. through 4.b.xlii. above on SPJOB would yield the results one requires, but it does not.

        Starting with step 4.b.xxiv. there is a major flaw in the config wizard. The problem is that it does not consider multiple servers. What I mean by that is that if you do execute steps 4.b.xxiv. through 4.b.xlii. you will end up with the Config Wizard overriding your existing Central Admin application settings. This is because it will be trying to setup Central Admin to run from the SPJOB server instead. It was previously configured to run from the SPWEB server. Recovering from this would be very tedious indeed.

        Ideally, the future versions of the Config Wizard would include one simple check box on step 4.b.xxiv. titled "Skip Central Admin configuration" which would allow you to simply skip this entirely.

        As it is, there is no such option and using the Config Wizard for all but the very first server configured is not possible. Some thought also need to be paid to the fact that the first server you configure would be the server that runs your Central Admin application. All other servers will point to it for Central Admin functions.

         

25. To resolve this dilemma, we have to turn to the command line yet again (I told you you'd be spending a lot of time in the 12 hive! J) and to a tool called psconfig.exe. The psconfig.exe utility is obscure and not very well documented, but you can find what documentation does exist on it at the psconfig.exe TechNet page. Open a command line on the SPJOB server using Start/Run/cmd.
26. Change directory to the 12 hive at "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin".
27. Enter the following command:

     

    Psconfig.exe –cmd configdb –connect –server SPSQL –database SHAREPOINT_CONFIG –user DOMAIN\SPSERVICEACCOUNT –password SPPASSWORD –cmd services provision

     

    where:

• SPSQL is the name of your SQL Server.
• SHAREPOINT_CONFIG is the name of your configuration database.
• DOMAIN is the name of your domain.
• SPSERVICEACCOUNT is the name of your SharePoint service account, the same account which you are currently logged on with.
• SPPASSWORD is the password of your SharePoint service account.

1. You should see visual feedback such as the following:

    

   

    

2. Once completed, we will be conducting all our processing from SPWEB so you can now logoff from the SPJOB server.
3. Return to Central Admin on the SPWEB server and refresh the page to show the new changes.

    

   

    

4. As you can see, the newly activated services are running on the SPJOB server. The SPJOB server needs to be configured as the Job/Index server though. Click on the server name itself.

    

   

    

5. As you can see, the server will initially be configured as a second Web Front End (WFE) server. Additionally, there is also some services running on the server that we do not need at this time, such as the "Document Conversions Launcher Service" and the "Excel Calculation Services". Since we want the SPJOB server to serve as the Index server, we need to change the role assignment and disable any unwanted services. Begin by clicking the "Stop" action of the "Document Conversions Launcher Service".

    

   

    

6. You will be prompted to confirm that you wish to disable the service. Click the "OK" button to continue.
7. The page will refresh and the status of the service should show either "Stopping" or "Stopped".

    

   

    

8. Next, click the "Stop" Action link for the "Excel Calculation Services". Again, you'll be prompted to confirm that you wish to disable the service on the server.

    

   

    

9. Click the "OK" button to continue.
10. Finally, we want to assign the SPJOB server as the Index server so we select the "Search Indexing" option.
11. Now that the SPJOB server is configured, we need to navigate back to the Operations page by clicking on the "Operations" tab at the top.
12. Scroll down to the bottom of the page to the Upgrade and Migration section.

    

13. Click the "Site content upgrade status" link.
14. You will be presented with the Site Content Upgrade Status page.

    

15. There should be a list of servers listed on the left under the "URL for Previous Version" column, and in our case, the SPWEB server should be listed.
16. To the right of the server name, there should be a "Begin upgrade" link under the "Next Action" column. Click the "Begin upgrade" link.
17. You will be presented with the Set Target Web Application page. Pay close attention to the page. If you note a "No Indexers" indicator at this stage, you cannot proceed and must address this issue first.

     

    

     

18. The problem is that indexing was not assigned to a server properly. Begin by clicking the "Operations" tab in the top menu.
19. Now, in the "Topology and Services" section, click the "Services on server" link.
20. By default the current i.e. SPWEB server will be listed with all its services. Click the server name to change to the SPJOB server.
21. Ensure that the "Office SharePoint Server Search" service is running. If it is not, start the service by clicking the "Start" link under the "Actions" column.
22. Now click the "Office SharePoint Server Search" link itself.

     

    

     

23. For the SPJOB server, the "Query and Indexing" option should have "Use this server for indexing content" selected. It probably isn't set which is why there were not indexers showing up before. Select this option.
24. Unselect the "Use this server for serving search queries" option for the SPJOB server.
25. Enter your contact email address.
26. Enter the user ID of the services account that will be used to process search for the entire farm in DOMAIN\USER format. This is normally the same account as the content access account.
27. Enter the password of the services account.
28. Scroll further down to reveal the remaining options on the screen.

     

    

     

29. For the "Indexer Performance" setting, the default should be "Partly Reduced". This is a good setting to use initially and it can be changed later as you experiment with performance settings.
30. Change the "Web Front End Crawling" setting from "Use all web front end computers for crawling" to "Use a dedicated web front end computer for crawling". The SPJOB server should be showing up in this drop down. If it is not, select it from the drop down.
31. Click the "OK" button to continue.
32. Repeat steps lxvii through lxxvii for the SPWEB server, but set it instead to "Use this server for serving search queries".
33. Once completed, click "Operations" in the top nav bar again.
34. Scroll down to the "Upgrade and Migration" section and click the "Site Content Upgrade Status" link again.
35. On the "Site Content Upgrade Status" screen, click the "Begin upgrade" link on the right again.
36. This time there should be no error noting "No indexer". The purpose of this page is to set the location at which the original content can be accessed until the migration is completely done. By default SharePoint will populate the "Port" edit box with a random port number. Enter a port number in the "Port" edit box that you wish to use. You could use the default generated number, but it's usually better to use a number that's easy to remember because this is the port on which your original portal content will be published e.g. in our case the original portal was available on http://spweb. By entering "8000" for the port, the original portal will be available under http://spweb:8000 in the future.

    

37. The purpose of this page is to set the location at which the original content can be accessed until the migration is completely done. By default SharePoint will populate the "Port" edit box with a random port number. Enter a port number in the "Port" edit box that you wish to use. You could use the default generated number, but it's usually better to use a number that's easy to remember because this is the port on which your original portal content will be published e.g. in our case the original portal was available on http://spweb. By entering "8000" for the port, the original portal will be available under http://spweb:8000 in the future.
38. You can enter a host header in the "Host Header" edit box if you wish to use one.
39. Scroll down the page to get to the Application Pool settings.

    

40. If you already have a pre-created application pool, you can select the "Use existing application pool" radio button, but in our case we need a new pool so select the "Create new application pool" option.
41. In the "Application pool name" enter the name of the pool you wish to create. We're just using "MOSS" for our pool name.
42. Decide if you wish to have the security account be a network service or a configurable account. In our case, we have a domain account created for this purpose, so we will go ahead and select the "Configurable" option.
43. Enter the domain account name into the "User name" edit box in the format DOMAIN\USER.
44. Enter the password that was set for this account into the "Password" edit box.
45. Select the "Restart IIS Automatically" option.
46. Scroll down further to Security Configuration section of the page.

    

47. If you are using NTLM authentication, you can use the default setting. In our case, as in most real world cases we have configured Kerberos so under the "Authentication provider" section, select the "Negotiate (Kerberos)" option.
48. In the "Content Databases" section, ensure that the "Automatic database name selection" is selected.
49. In the "SSP Database Settings" section, enter the name of a database to use in the "SSP Database Name" edit box.
50. Enter the name of the Search database to use in the "Search Database Name" edit box.
51. Scroll down to the Index Server section.

    

52. You should see the Index Server set as SPJOB.
53. Ensure that the "Path for index file location" option is set correctly. This should default to the value you originally set when you installed MOSS. In our case, we are using our D:\ drive for storage, so the setting reflects that.
54. Click the "OK" button to continue.
55. Because we are using Kerberos, you will get a warning popup dialog window related to Kerberos security.

    

56. Click "OK" to confirm Kerberos authentication is what we want to us.
57. You will be presented with an Operation in Progress screen.

    

58. Depending on the size of your portal, this page may take a long time to process because it is building a list of all site collections in your portal to be upgraded. Once SharePoint completes building the list of site collections to upgrade, it will present you with the Site Collection Upgrade screen.

    

59. IMPORTANT NOTE: You must upgrade the root "/" site collection BEFORE you can upgrade any of the other site collections. The root site collection will upgrade all your portal areas.
60. Select the "/" site collection check box.
61. Scroll to the bottom of the page and on the right hand side, click the "Upgrade Sites" button.

    

62. You will be presented with a pre-upgrade Stat Report page.

    

63. This page will indicate the number of site collections that was selected for the upgrade as well as the amount of storage that the site collection(s) currently use.
64. Click the "Upgrade sites" button to begin the upgrade process.
65. You will be taken to an "Upgrade Running" status page.

    

66. The page will automatically reload every minute and status information will change over time. Depending on the site of the collection, the upgrade may take some time.
67. We now find that we have an error and our upgrade job failed. This was unexpected.

    

68. There are 3 items to note on the screen:
    1. The Status – "Job failed".
    2. The location of the log/debug file which is located in the "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs" folder under the name "Upgrade.log". Several other log files can be found in this folder as well.
    3. The "Resume" button that will be used to resume the upgrade job once the issues in question have been resolved.
69. Locate and open the "Upgrade.log" file specified in the error report.
70. Search for "[ERROR]" to locate the error that caused the failure.

    

71. Note that because the log file is a debug log, the GUID of the feature that caused an error during installation is actually written on the line preceding the line with [ERROR] in it. In our case, the failure was caused by a feature that could not be deployed to the /MySite site collection. Part of the problem is that the Feature might have to be forced to install and since the migration code does not use the -force option, it could fail. That is what happened in this case. In order to forcibly install the features, we need stsadm again.
72. Make a note of the feature GUID.
73. Scan the entire "upgrade.log" file noting all the feature GUIDs that caused errors. There may be several.
74. Open a command window on the SPWEB server again.
75. Navigate to the bin folder using "cd\pro*\com*\mic*\web s*\12\bin".
76. You should find yourself in the "C:\Program Files\Common Files\Microsoft Shared\web server extentions\12\bin" folder.
77. Enter "stsadm -o activatefeature" to get the proper syntax to use from help.

    

78. Now enter the following code for each feature/site that failed:

    stsadm –o activatefeature –id <GUID> -url <Site URL>

    1. Replace the <GUID> value with the failed feature GUID each time.
    2. Replace the <Site URL> value with the failed site address each time.
79. In our example, the commands would be:
    1. stsadm -o activatefeature -id 22a9ef51-737b-4ff2-9346-694633fe4416 –url http://test4-spweb-01/mysite -force
    2. stsadm -o activatefeature -id 306936fd-9806-4478-80d1-7e397bfa6474 –url http://test4-spweb-01/mysite -force
    3. stsadm -o activatefeature -id 22a9ef51-737b-4ff2-9346-694633fe4416 –url http://test4-spweb-01/C5/teams -force
    4. stsadm -o activatefeature -id 306936fd-9806-4478-80d1-7e397bfa6474 –url http://test4-spweb-01/C5/teams -force

    

80. Return to the Upgrade page and click the "Resume" button to resume the upgrade attempt.
81. Upon successful completion of the migration, you should see the summary page.

    

     

82. At this point in time, your SPS Portal Areas would have been migrated. Site collections are migrated in the same fashion until the entire farm has been migrated...

Kick it Fave it Digg it Reddit Del.icio.us