First, let me just say it is excellent that Microsoft has changed their attitude toward SBS migration, and the SMB market is very appreciative of that. This is the first version of SBS that has an in-the-box, MS-supported migration path from a previous version of SBS. Big kudos to the SBS team for this.
After installing SBS2008 using the answer file for a migration, the SBS console contains a group of wizards and instructions. Some of the migration tasks are handled for you, and others are links to help files with instructions for performing migration tasks.
However, like any of Microsoft’s first efforts in a given direction, the going is a bit rough. Some of the manual migration tasks could have been done in a wizard, and others were omitted entirely.
If one were to follow this migration wizard strictly, and do no more than is listed, the customer would be left with a non-functional network (from their point of view). They would come in on Monday morning, log in, and their network drives would not map. Their printers would not function. Their web browser, if it opened to http://companyweb, would display no data. Their desktop shortcuts would not work.
While this wizard is certainly helpful, with lots of useful information, it falls short in actually guiding a consultant to a conclusion that would be called successful by any customer’s standards. If I followed this guide, and did nothing more, my customer would not pay the bill for this migration.
I have seen (and cleaned up) the aftermath of a project done this way. It is the sort of event that prompts a customer to start looking for a new IT company.
</soapbox>
Every network is a little different, and MS could not be expected to cover all eventualities – but there were a number of tasks I performed after the wizard that I would reasonably expect to perform during any migration.
Click here to skip down to the post-migration-wizard tasks that I performed.
What follows below is a list of steps I went through during this migration. First, I did a migration from a freshly built SBS 2003 to SBS 2008 in a test lab, and of course it went perfectly. Then I did a real migration in a production environment, and it was a far more interesting journey.
Preparation and Pre-Wizard Migration Steps:
A. Checked to ensure that I had a restorable backup.
B. Cleaned up unnecessary files taking up space.
C. Powered down my SBS2003 VM and resource server VM, took snapshots, and powered them back on.
D. Edited Autounattend.xml and inputted the proper settings for my environment (this is not necessary for an SBS 2008 migration, but since I already covered doing a fully unattended SBS 2008 load, I figured I’d include this bit).
E. Ran SBSAFG.exe to create an SBS answer file for this migration, and put it into a virtual floppy disk along with the autounattend.xml file.
F. Created a VM with 4 CPUs, 8GB RAM, C:60GB, D:125GB, virtual floppy with answer files, ISO file of the SBS DVD.
G. Set the SBS2008 VM to boot into BIOS on first boot.
H. Booted the SBS2008 VM and adjusted the time (it was 8 hours off) and boot sequence.
I. Rebooted the VM and it started setup.
Note: I experienced some issues with the disk sizing, either due to geometry issues, conversion math issues, or something. Anyway, the answer file specified that the disk size should be 61440 KiB. This should fit neatly into a 60GB container, but apparently does not. This is undoubtedly due to the difference between SI values and Binary values, and the confusion between them. See this web site for details.
Also, here is a handy calculator:
Anyway, I adjusted the answer file to use 60000 instead of 61440 and it’s all good.
J. Waited for the unattended installation to finish.
K. Received an error about the source server not meeting minimum requirements for migration.
Things missing:
· AD Schema needs to be extended to Windows 2008 level.
· Domain and forest functional levels need to be set to Windows 2003.
· Hotfix needs to be installed to extend time limit for multiple SBS servers in one domain.
Note: This is the “Point of no return” as it were. Obviously, it is possible to proceed past this point, stop, and still recover – but cleanup will be required, and possibly technical support from Microsoft.
L. Ran the Source tool on the source SBS server, which failed because I was running it as an account that did not have the required permissions. I ran it again successfully using the administrator account.
The source tool updated the schema, installed the hotfix to extend the multiple SBS server deadline, adjusted Exchange to allow migration, and required a reboot. I rebooted.
M. After the reboot, I upgraded the domain and forest functional levels to Windows 2003. This did not require a reboot.
N. Clicked the “Check Again” button on the SBS2008 server. It found that all of the issues were resolved, and continued forward. Note: During this phase, in addition to the schema changes above, the new SBS server appears in AD users and computers in the domain.
It should be noted here that during this phase, I ran into a serious road block that took me more than a few hours to resolve. The underlying issue and the solution are detailed in another blog entry.
The initial SBS wizard completed with errors. The error was “An update could not be applied”. I won’t lose any sleep over that one.
O. Added two partitions, one 12 GiB volume for the pagefile, and one 125 GiB volume for data. (You can choose your own preference here)
P. Adjusted the pagefile to be a system managed pagefile on the 12 GiB volume. (Again, your preference)
Started the Migration Tasks in the wizard provided by SBS:
On the Windows SBS Console, I clicked the Migration task, but it would not let me run it as the built-in administrator. It wants me to create an administrator user for the tasks. This is annoying because many of the tasks will require elevation, which means using the runas command to run them as the built-in administrator.
I created an administrative user using the SBS console, and during that process it failed to send a welcome e-mail to the new user using webmail. The error message is: “Service Discovery failed in looking up the CAS Server in the target AD Site.” I guess this has something to do with SSL certificates for the website. This problem solved itself later when I moved my certificate over.
A. Change Data Locations:
i) Change Exchange server data locations
(1) (Clicked OK to continue without backing up the server)
(2) Chose the location for the Exchange data and moved the databases.
ii) Change the Sharepoint Data location
(1) (Clicked OK to continue without backing up the server)
(2) Chose the location for the Sharepoint data and moved the database.
iii) Change the User data location
(1) (Clicked OK to continue without backing up the server)
(2) Chose the location for the user data.
iv) Change the users’ Redirected Documents location
(1) (Clicked OK to continue without backing up the server)
(2) Chose the new location for the redirected documents.
v) Change the Windows Update Repository data location
(1) I chose not to move this.
vi) Clicked Task Complete and Next
B. Configure the Network:
At this point, I was expecting to have to use netsh to export the DHCP database from the old server and import it to the new, as I did during my test migration. However, when I attempted to do so, I discovered that SBS08 had already disabled the DHCP server service on the source server, and created a new one without regard for any reservations or static IP addresses I may have had on my network (in fact, this created an IP address conflict – way to go, MS!). I was, however, able to stop DHCP on the new server, start it on the old server, retrieve my DHCP database, delete the scope on the new server, and import my previous database to the new server.
I used the netsh utility to export the scope from the source server, and import it on the destination server. This turned out to be premature, because the DHCP scope got wiped out again later – so my advice is to export the DHCP database from the source server before you begin the entire process, and then after every step that changes the networking via an SBS 2008 wizard, check the DHCP scope and re-import if necessary. If you’re doing this on a weekend and it doesn’t matter if the machines lose their DHCP leases, then just wait until everything else is done and do this step last.
You’ll want to use the NETSH utility with elevated permissions at the CMD promp, as follows:
1. On the SBS2003 server, run this at a command prompt:
netsh dhcp server export c:\dhcp.data 192.168.0.0 (substitute your internal network subnet)
This saves your DHCP database to a file o the root of C on your old SBS server.
2. Copy that file to C:\ on your SBS2008 server.
3. Stop and disable DHCP on your old SBS server.
4. On the SBS2008 server, enable and start the DHCP service.
5. On the SBS2008 server, run this at a command prompt:
netsh dhcp server import c:\dhcp.data 192.168.0.0 (substitute your internal network subnet).
Normally, when doing a migration, I recommend setting the DHCP scope to a low lease duration – but in this case, I think an 8-day lease duration is probably best, especially since the DHCP server address will remain the same if you swap IP addresses at the end, and you will get to keep your DHCP database if you export it with the netsh command.
C. Connect to the Internet (Clicked to start the CTIW).
The CTIW wizard ran successfully, trashing my DHCP scope again. I restored it again.
D. Configure the Internet address.
i) Start the Internet Address Management Wizard
(1) Selected “I already have a domain name”.
(2) Selected “I want to manage the domain name myself”.
(3) Typed my domain name into the field.
(4) Clicked the Advanced button.
(5) Chose not to use a domain prefix. (My SSL certificate does not have one.)
(6) Clicked OK, Yes on the warning, and Configure.
(7) Viewed the warning about the wizard failing to administer my firewall (good!).
The second part of this wizard deals with self-signed certs, which I am not using.
Skipped the self-signed cert bit because I have a real one.
I’ll see about moving the cert later if not prompted to do so.
ii) Task Complete -> Next
E. Migrate Network Settings.
i) Migrated DNS forwarders.
ii) Migrated the Mobile Users Group.
iii) Clicked to open the help for migrating SSL certificates.
iv) Followed the instructions for migrating my certificates (2 of them).
v) The “Add a trusted certificate” only allows one at a time.
vi) I have a second one which I will figure out how to add to another SSL website later.
vii) Task Complete -> Next
It should be noted at this point that the migration wizard trashed my internal authoritative DNS zone for my external domain name, and replaced it with a single host record for the new domain. How rude. I modified it manually to restore my DNS records.
F. Migrate Exchange mailboxes and settings.
i) Migrate Exchange mailboxes and settings. This brings up a help topic telling you how to:
(1) Remove Internet connectors from the Source Server.
(2) Migrate POP3 connectors (optional) from the Source Server.
(3) Move the Offline Address Book
(4) Move mailboxes from the Source Server to the Destination Server
(5) Move Exchange Server public folders.
It should be noted here that public folders and mailboxes have default size limits on them that should be adjusted before moving anything.
Before I started this, I fixed my FQDN in the SMTP connector so that the two exchange servers could talk to each other properly.
My event log had errors about communication between the servers, and I could not move a mailbox. This turned out to be because permission inheritance was blocked on the source server. This is a fairly common practice, because it was required in order to use EXMerge when migrating mailboxes into SBS2003.
Setting permission inheritance and restarting all Exchange services was not enough to resolve the issue. It was necessary to restart the source server. Once the source server was rebooted, the test mailbox moved successfully. I then started moving them all.
While the mailboxes were moving, I took care of the other tasks as well:
ii) Remove internet connectors from the source server
(a) Moved my smart host setting to the Send Connector on the new server first.
iii) Migrate POP3 connectors.
(a) None to migrate. Skipped.
iv) Move the offline address book.
(a) Followed the help file instructions.
v) Move the Public Folders
(a) Followed the instructions.
Additional notes here: When SBS works itself into the Exchange system, it disables the previous default recipient policy, and adds a new one. This does not cut off access to additional e-mail domains that might be in the old policy, but things in the old policy should be migrated to the new one anyway.
vi) Finish migrating Exchange and removed the old server from the organization.
vii) Task Complete -> Next
There are some procedures not covered in the migration help files regarding decommissioning the old server. In the page of the migration wizard where it told me that I would need to do so, there may have been a link to an MS article on doing so, but I didn’t see it. I’ll look for this next time around.
Basically, removing the old Exchange server entails deleting the routing group connectors (both sides) that were created when SBS2008 joined the organization, modifying the home server for the recipient update services, and uninstalling Exchange from the old server (SBS Disc 2 is required).
G. Remove legacy group policies and logon settings.
i) Clicked the link for removing legacy login scripts, which was a help file explaining how to remove them.
(1) I was not using SBS_Login_Script.bat. I removed my custom login scripts.
Login scripts stored in the netlogon share are being replaced with GPOs. This is due to the fact that UAC events are being triggered by conventional scripts. However, the SBS migration wizard does not specifically tell you to put your scripts into GPOs.
ii) Went on to the help section for removing legacy GPOs.
(1) I had already removed the default SBS GPOs long ago.
iii) Removed the WMI filter GPOs they referred to in the help.
iv) Task Complete -> Next
H. Migrate Users’ Shared Data.
i) Clicked the link for “How do I migrate…”, and it brought up a help topic.
(1) I used Robocopy with the /COPY:DATSO switch to migrate data.
(2) Recreated shares as appropriate.
I. Migrate SharePoint Web site
i) This opened a help topic with instructions to follow on both servers.
I started working through these instructions, and got to the part where it was going to have me create a new website called “Old Companyweb”.
At first, I thought that that this was not truly a migration and integration of the old SharePoint with the new – this was adding the old one so people could still access it, while someone manually moves things over to the new one.
I read further, and found where it says that it will, actually, upgrade the old site to SharePoint 3.0 as part of this process. I recommend, therefore, that you do NOT name the site “OldCompanyWeb” as they suggest, and instead name it something that the customer will be happy to keep using as you move forward – like for example, CompanyWebSite, or put their company name in it, or something. Further, when you detach the database files and move them over, you may want to take the time to rename the database files to something that does not include the old server name, for cleanliness – although this is behind the scenes.
J. Migrate Fax Data.
i) This was an automated process, which ailed for me because there is no fax service installed on the source server.
ii) Task Complete -> Next
K. Migrate Users and Groups.
Users and groups have already been migrated, but require some tweaking to show up in the new SBS console.
Note: This section is ripe for automation. Why didn’t MS make a wizard for this?
Note: I found out later that the Change User Role wizard removed all of my users from their previously assigned groups. Thanks, MS, that’s very helpful for a seamless migration!
i) Clicked the link for “Display the security group migration instructions.”
(1) Followed the instructions.
ii) Clicked Next to get to the Migrate User Accounts section.
(1) Clicked the link for Run the Change User Role Wizard.
(2) Ran the Roles wizard a couple of times for my user base.
L. Demote the Source Server
i) Clicked the link for “How do I demote the Source Server?”
(1) This help topic simply tells you to dcpromo down the old server.
Note: The help topic regarding demoting the source server is sadly lacking. It does not mention that you will need to update any static DNS or WINS pointers that you have on your other servers, workstations, or network appliances.
It also fails to mention that after you demote the old server, it might be helpful to remove its computer account from the Active Directory and run the netdom command to add an alias with the old server’s name, to help with any static shortcuts or registry entries on the workstations that might be pointing to the old server name.
M. Checked the box for “My source server is no longer a domain controller” and finished the wizard.
Things I did after the wizard:
1. Changed the server name and IP address of the source server so that it is still available on the network, but the old name and ip is available.
2. Exported the DHCP database in anticipation of the CTIW wizard trashing it for me again when I changed the server IP to match the previous source server’s IP.
3. Took a screen shot of my internal DNS zone for my external namespace in anticipation of the CTIW wizard trashing it for me (not worth the extra effort of exporting the DNS file, there are only a few records in there, I can fix them afterward.)
4. Ran the Connect to the Internet Wizard and adjusted the server IP address to be the IP the source server used to have. This is a helpful step because it avoids the necessity of changing static DNS settings and other settings that point to the IP address of the old server in network appliances, other servers, statically assigned workstations, firewalls, etc.
Note: The CTIW said it did not properly configure e-mail. It told me to run it again, and it failed again. I had to go into the Exchange Console and manually adjust the IP address bindings on the Receive Connectors.
5. Imported my DHCP database, made necessary adjustments, and fixed my DNS zone.
6. Ran the netdom command to add the computer name alias, and adjusted the registry setting to allow the netdom fix to work.
7. Added my login script into a new GPO called Login Scripts and applied it.
8. Installed printer objects with the exact same printer name and share name as on the source server, and tested network printers on workstations.
Some additional things that came up:
1. IE’s phishing filter was enabled via GPO. Some users don’t like that. I modified the GPO to allow the user to decide.
2. IE’s homepage was set to http://companyweb. Some users don’t like that, etc.
So that’s it, in a nutshell. Your mileage may vary, of course. This is my first SBS 2008 migration from SBS 2003, so I’m sure I missed some things. Perhaps later, some other tips/tricks will come up that make some of the above unnecessary, or even incorrect. We can only hope.
