Let me leave a few notes behind about some of the glitches during the migration from SBS 2003 to SBS 2008. I don’t have many answers but perhaps it will help someone to know that I’m able to commiserate with them. (Loyal clients – this is not aimed at you and it won’t help you get your work done. I’ll be back to general interest topics next week!)

As background: I was migrating an SBS 2003 server with a very basic configuration – no ISA, no use of Sharepoint, a single NIC and external firewall, and no particular pre-existing issues.

MIGRATION WIZARD

Microsoft provides a detailed guide to the migration procedure. (Have you noticed that Microsoft’s documentation has been getting better and better lately? There’s much less ambiguity about what to click next – each step is described in precise and accurate detail.) The guide was great.

SBS 2008 begins a migration when a USB stick with an answer file is inserted in the new server before the SBS 2008 installation starts. Several people have reported that the USB stick has to be present when the server is turned on or SBS 2008 is likely to miss it. After installation, the first and most important item on the SBS 2008 is the “migration wizard” that leads through all the steps required to be successful.

I was about two-thirds of the way through the wizard when I took a break and installed the Server 2008 updates that were waiting. When the server restarted, the migration wizard crashed with a mysterious error that proved impossible to fix. I researched it and got nowhere. I removed a couple of the updates that conceivably might have unsettled something and got nowhere.

The wizard never came back to life. Fortunately most of its steps only lead to help files that describe the process for actually accomplishing each task by going into AD or MMC consoles or the like. I think – I think – I was able to finish the migration and cover the remaining steps without the wizard. There is still room for some surprise glitch – I’m going to cross my fingers when I demote the source server.

MAIL MIGRATION

I expected the mailbox migration to be slow but was still surprised. The Exchange 2003 mailbox store was about 25Gb after I pruned and archived as much as I could from the biggest mailboxes. The mailbox move took just about ten hours.

PUBLIC FOLDERS

I had no luck moving the public folders, and didn’t really expect to, given the reports I had read. That may have been the result of a pre-existing glitch on the source server – this server, like several other of my SBS 2003 servers, throws up an error message when I try to do anything to the public folders in Exchange Server Manager. I’ve researched that one, too; I’ve removed the SSL requirement from EXADMIN in IIS, and a few other things suggested in other places, to no avail. I exported the public folders to a PST and stored them for now, since public folders were not being actively used and may not need to be implemented at all on the new server.

BACKUP

The most mysterious problem involves the backup system. The firm had been using ShadowProtect to back up to an NAS and two rotated external Maxtor hard drives. The backup built into SBS 2008 looks like it will be just fine but it does not directly back up to an NAS. I connected a Maxtor drive, formatted it, and ran the backup wizard. Hmm. Error message at the very end.

Since the message says “Cannot configure backup schedule,” I started trying every scheduling option – once a day, twice a day – as well as swapping in the other (identical) hard drive, and couldn’t get anywhere. I couldn’t find anything in the logs at all. I got the flavor that it might be caused by the server disliking the external hard drives.

I’d like to talk to the person who thought it would be helpful to write: “If this problem persists, contact the person who provides you with technical support.” It made me irritable.

ShadowProtect claims that the current version will back up SBS 2008 servers. With any luck I’ll be able to install that and never know the answer to this one.

PHONE PASSCODES

This isn’t a glitch, just something to warn your users about. By default, Exchange 2007 enforces a new passcode requirement on Windows Mobile phones (and iPhones) syncing with the server. Users are forced to set up a four-digit password that will be tapped in every time the phone is used. I’m sympathetic to all the reasons that this is an important security measure, but I’m also sympathetic to the desire to keep my job and not be fired by the attorneys who began flipping out immediately. It’s possible to turn the requirement off in Exchange Management Console / Organization Configuration / Client Access / Windows SBS Mobile Mailbox Policy, which then allows it to be turned off on the phones. The iPhone balked and refuses to relax, even after the policy was changed, which apparently is a known glitch.

SERVER CERTIFICATE

I was determined to allow my users to continue to use the familiar URL for remote access, even though it didn’t match the naming scheme preferred by SBS 2008. The email domain is www.bigfirm.com, say, and my users have been reaching RWW at www.bigfirmnet.com for years. I have a GoDaddy SSL certificate for www.bigfirmnet.com and heck, I just like it. Plus I’ve got migrations coming up where I know it will be difficult to work with the web hosting company to set up a subdomain and MX records for the primary domain name.

The Internet address wizard insists on getting the primary address and only allowing RWW to be reached at the same address with a prefix – remote.bigfirm.com or something like it. I had to work around that by lying to the wizard that the primary domain name was bigfirmnet.com, which (in Advanced Settings) would then let www.bigfirmnet.com be the remote access address.

When that was in place, then I could set the primary email addresses back to @bigfirm.com in Exchange Manager / Organization / Hub Transport / Email address policies / Windows SBS Email Address Policy.

ONECARE

Windows Live OneCare has been a trusted friend but it does make me a little crazy sometimes. SBS 2008 expects to get feedback from each workstation about its security status and apparently OneCare isn’t set up to let that happen. So far I haven’t found the firewall port or other hack that will let the workstations report in, so they’re all showing in the server console as “unknown.” I can’t even find a definitive statement that it’s possible or impossible with the standalone version of OneCare. I’m not going to install OneCare for Server so I may just not get good feedback in the console until we switch to Trend Micro. I was hoping to procrastinate on that – everyone has been used to OneCare for a long time – but change happens.

DRIVE MAPPING

Drive mapping is supposed to be accomplished in Group Policy now. I was comforted that other people online said they had trouble with it, because I couldn’t make a mapped drive appear on a workstation no matter what I did in Group Policy. After a fruitless half hour of researching and trying things, I put the nice simple logon script in the folder and assigned it to everybody. I feel kind of crude, but it works.

SHARED PRINTERS

Another little headache – it was easy to install 64-bit drivers for network printers and share them from the server. At least, it was easy once I stopped clicking on the “Add printer” button and getting an “Access denied” message when it tried to set up a TCP/IP port. Right-click in the Printers folder and click on Run As Administrator / Add printer – ah, that’s intuitive! Sheesh.

Out at the first workstation, I was reminded forcibly that there were no 32-bit drivers around, so I downloaded the corresponding 32-bit drivers for a few of the printers (a couple of HP Laserjets and a Toshiba copier) and went to add them on the server using Additional Drivers on the Sharing tab. The server thought that was a terrible idea – it never agreed that the 32-bit drivers corresponded with the 64-bit drivers. (I read somewhere that it was known problem with some HP drivers but I had the same epxerience with the Toshiba drivers.) So I parked the 32-bit drivers where I could get to them, went back to the workstation, and browsed to the 32-bit drivers when the workstation tried to connect to the shared printer and rejected the 64-bit drivers. Nope! The workstation also didn’t agree that it was a match. It was the closest match, trust me – these were the identical 32-bit and 64-bit drivers for the same model running the same PCL level.

Fortunately, we already had reason to be running a Windows XP virtual machine on the second server with Hyper-V. I’ve shared all the printers from there and I bet it’s rock solid.

A migration is a complex project! I think it went smoothly. These are the kind of glitches that happen constantly, every day at every level. Some of them will happen to me the next time, others will come up that are brand new. It’s the nature of IT today. With luck I’ll bring good instincts and a lot of experience and use them both the next time I come to your office!