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.

3. The anti-spam software requires MAPI and CDO. I had to install them. Here’s a blog entry about that.

4. The antivirus software wants to use .Net Framework 1.1, which is 32-bit only. Fortunately, it knows that this would kill OWA and other 64-bit application pools in SBS 2008, and warned me about it in time to cancel the installation.

 

After much Googling, it seems that this may be something that can be worked around, but the app installer does not know this, so it doesn’t really help. I will need to install the application console on another server, and push the Exchange and File System Antivirus components to the SBS server over the network.

 

 

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.

 

Tags: answer file, deployment, Exchange, from boot to welcome, lua, Migration, replication, SBS 2008, SBSAFG, unattended

I’m replacing my wife’s computer. There is a flatbed scanner attached which I use for documents that are too big for the sheetfed scanner on my own computer, documents that are bound to something, or when I want a higher quality image than the sheetfed scanner can deliver.

I decided to go ahead and give her the computer with Vista on it, because the way she uses the computer, she won’t really notice the Vista pain I feel.

Unfortunately, the flatbed scanner is an older model, for which there is no Vista driver support. The scanner is “end of life” after a few years.

After much grumbling, I bought a shiny new scanner that looks nearly identical to the old one. I decided (here goes my masochistic streak) to try installing it as a normal, non-administrative user would. I logged on with the wife’s user account and put the CD in the drive.

Thus begins my tale of woe.

Naturally, I get the UAC pop-up, and I allow it. After a couple of other prompts and an install wizard, it finishes. So far, so good. I stuffed an empty Cheetos bag onto the glass and pushed the one-touch scan button. To my amazement, the one-touch software fired right up and started scanning. It finished, then dutifully started opening the Paperport software to store the image.

Bam! Error #1. the SimpleSearch Indexer has stopped working. Problem Details: Appcrash in ssindexr.exe.
A few seconds later: Bam Bam! Error #1. The PDF Import Filter also crashed.

The Paperport Desktop opened and was completely empty.

Another try, then. I uninstalled the thing, emptied the Temp folder, deleted the Paperport folder from Program Files, and made the user account a local administrator. Also, I browsed the CD, right-clicked the setup.exe, and told it to run as administrator. Same process, same result.

OK, I figured I’d give Tech Support a bit of a hassle and call them up. They painstakingly wrote down every error and version number, and then had nothing useful to say. They wanted to put me on hold to “check my resources”. I asked if they’d like me to uninstall the program, empty the Temp folder, disable User Account Control, reboot, and try again while I was on hold. Affirmative. I should leave the scanner driver (one-touch) in there, but do the rest.

So right about the time they came back on the line, I was logging in again. I stopped to talk to them about the issue. No, there aren’t any “known issues” specific to my errors, but yes, they usually do recommend that people turn off UAC before installing (the software has no pop-ups and the docs say nothing to this effect). I should go ahead and try it again, and it should work this time.

I did. It didn’t.

I wished them good day and hung up, sensing that I had gotten as much useful information from them as I was likely to.

I cleaned it all up again, set the local administrator password, enabled the local administrator account, rebooted and logged in as Administrator, and ran through the setup again. This time the Paperport software opened without error (yay!) but the one-touch software was no longer linked into Paperport. I had to uninstall and reinstall it as well.

Finally, I was able to push that button and get a perfect scan of my Cheetos bag.

OK, time for a user profile swap! I reset my wife’s user account to a power user, turned UAC back on, rebooted, logged in as her, and the Paperport software started without error. Of course the one-touch software had lost its link with Paperport. To get THAT back, I had to uninstall one-touch and reinstall it. Then it had the link, but when I pushed the button on the scanner nothing happened. I removed the scanner from Device Manager and scanned for new hardware, which was found and installed. Then the scanner button worked, it scanned, and it even opened Paperport and delivered  - but it did NOT deliver the scanned image into the Paperport desktop.

Sigh.

I finally got this to work by setting the user account as an admin again, turning UAC off, logging in as the user account that would be using the scanner, and using the “RUNAS” command to fire up a privileged CMD instance, then changing directory to the CD drive and executing cdstart32.exe from the CMD window.

At long last, I got my Cheetos bag scanned in, while logged in as the proper user! Sing praises!

Oops, wait a second, the destination was a local My Documents folder. I couldn’t select the network drive to store the documents in during setup, because while using RUNAS, it used the local administrator account, which does not have the drive letter mapped. So I opened Paperport and used the Folder Manager to add the right one. Doesn’t work.

Sigh.

Time to log in as Administrator, map the drive letter, log back in as the user, use the RUNAS command again (Will I have to turn off UAC and reboot? Probably), uninstall and reinstall this damned thing again.

How is the average user supposed to do this? I suspect they tested this exactly one way: On a standalone PC, with UAC disabled, as a local administrator account.

I guess it’s my fault for not buying the $499 network-friendly model, right? As if its installation would not have the same issues.

Well, I won’t bore you with the rest of my battle. I’ll get there eventually.

Cheers!

Update: The software has a particular quirk. It REQUIRES that the local My Documents folder is part of the PaperPort Folders lineup in order for it to scan things into PaperPort. To clarify, I reinstalled it, and it would scan things into PaperPort, but put them in the [MyDocuments]->OneTouch Docs folder. I found the registry key for that destination end edited it, and then it would put things into the mapped network drive just fine. Then I removed the local MyDocuments from the PaperPort Folder Manager, and even though the software was set to place things in the mapped network drive, scanning to PaperPort broke.

It seems that it is not actually necessary to use the RUNAS command to install the software. At least, not after you’ve uninstalled and reinstalled eight or nine times - maybe the stuff that needs that level of security stayed in there after the first time. We all believe that their uninstaller cleans out everything it put in there, 100%, right?

Anyway, another uninstall/reinstall got back the ability to scan to a PaperPort folder, then another registry hack to make it scan to the folder I wanted it to go to, instead of the default (there was no place in the UI to set this). So I’m just going to shrink up the local documents folder tree and pretend it does not exist.

So the path to success goes like this:

1. Cut off your security at the knees by setting your user account as a local administrator and disabling UAC.
2. Install the software, leaving everything at default. It gives you the option to change the initial desktop folder during installation - don’t do it! It will break the Scan to Paperport feature.
3. Hack the registry to make the change that should totally have been included in the UI. The keys to alter are:
[HKEY_CURRENT_USER\Software\Visioneer\OneTouch 4.0\LinkManager 4.0\ScanSoft Applications]
“DefaultFolder”=”X:\YourPaperportDesktop”
[HKEY_CURRENT_USER\Software\Visioneer Backup\LinkManager 4.0\ScanSoft Applications]
“DefaultFolder”=”X:\YourPaperportDesktop”
4. Add that folder to your PaperPort Folder Manager and set it as default, but DON’T remove the local one.
5. Set your security back up the way you want it and test that it still works.

Tags: lua, One-Touch, Paperport, UAC, Visioneer

There is a new security feature in Windows 2008 and SBS 2008 called LUA (Local User Administrator). Basically, it’s another effort to break away from the time-honored tradition of logging into the computer with an account that has absolute control, when it is not necessary to do so. As malware becomes more sophisticated, it is increasingly dangerous to do so.

This latest feature has some definite drawbacks for the unaware though. You can find yourself unable to do certain administrative tasks, and not know why not. After all, your account is in the local administrators group. Heck, it’s even in Domain Admins, Schema Admins, and Enterprise Admins! Your account is effectively a god, and yet you can’t run a command-line backup.

I ran into this the other day on an SBS server, using the “wbadmin” utility. I got errors indicating that my permission level was not high enough, yet my account had all of the attributes listed above. It was, in fact, the admin account created for me by the SBS wizard. The actual “real” Administrator account was disabled - a default feature in SBS2008.

So in order to run the wbadmin utility, I had to enable the Administrator account, change its password so that I knew what it was, and then use RunAs to run the utility.

This is not so bad on the surface of things. It’s good security, and tolerable if you know about it. That’s where it all falls down though. None of the documentation I found regarding wbadmin, whether related to Windows 2008 or SBS2008, mentioned LUA or the fact that the real Administrator account was the only one I could use to run the commands they were telling me to run, nor that the account was in fact disabled.

I think we need a little work on that documentation, MS.

Tags: lua, runas, Security, wbadmin