Blog: SBS 2003

I have done a couple SBS 2003 to SBS 2008 migrations in the past and because the customers were relatively small with less than 20 users, we opted to just build the new SBS 2008 server with a completely new domain and then migrate the data. We would recreate all the user accounts, mailboxes, and shares and choose a maintenance window to do the switchover. It works fine for companies with low complexity and downtime flexibility. However, I just started an SBS 2003 to SBS 2008 migration for a company that operates pretty much 24-7 and they have a fairly high complexity level on the application side.

I have tried some of the SBS 2000 -> SBS 2003 migration tools and they were pretty pathetic, but I had to have an easier way for this migration. After some research, I came across a set of processes that you can use to migrate SBS 2003 -> SBS 2008. They are documented pretty well by Microsoft here: http://www.microsoft.com/downloads/details.aspx?FamilyID=52b7ea63-78af-4a96-811e-284f5c1de13b&displaylang=en.  The process is pretty tedious...I won’t get into it here. You can read the doc if you are interested.

The gotcha is what I encountered during the migration install. [more]When you provide the unattended install file for the SBS 2008 install, first it goes through and installs the OS. After a reboot, it starts the actual migration process. I was watching closely and noticed that it seemed to hang at about 20%. I looked at the event logs on both ends and couldn’t find anything then after some a search on Google I found a user blog that mentioned accessing the sbssetup.log file via file share during the install. I checked it out and it indicated that the new SBS server could not find a server in its AD site to replicate with. I reviewed AD sites and services and noticed that there was no subnet associated with the current default AD site. I added the subnet and waited a few minutes and the progress began to move forward…yeah success!

No so fast. It move about 10% and stalled again. Again after looking in the log file, it was an AD replication problem. This time the SBS 2003 server had a sysvol replication journal wrap problem. I found the MS article on how to fix it and applied the registry fix and restarted NTFRS. Again, progress.

The migration ran for another 3 hours and stopped about 95%. Another log reviewed showed the problem was DHCP related. I connected remotely to the DHCP service and I could see that the scope was getting created and the server options were set, but the reservations were not there. I started reviewing those thinking there might be something there holding it up. By accident, I found that one of the MAC addresses in one of the reservations had a trailing space following the MAC. I removed that reservation and after a short wait, the migration continued and finally finished….6 ½ hours later.

So two things. 1. Watch the log file 2. Get lucky

Have you run MSINFO32 to get OS information and been greeted by this error: "Windows cannot open Help and Support because a system service is not running. To fix this problem, start the service named 'Help and Support'."  You then go to the services listing and find that 'Help and Support' is not there.

Microsoft indicates this is a known issue on SBS 2003 after installing SP2 (I have seen and resolved this same behavior on Standard Edition as well).  Here is the fix: [more]

1. open a command prompt and change directory to %windir%\PCHealth\HelpCtr\Binaries
2. -run 'start /w helpsvc /svchost netsvcs /regserver /install'
3. -once complete, refresh your Services listing and you should see 'Help and Support' ready to be started
4. -after starting that service, run MSinfo32 again

http://support.microsoft.com/kb/555912

Research on a recurring event-1005 error on an SBS 2003 box clued me into some interesting facts.  When SBS 2003 first came out, the Directory Services Restore (DSRM) password automatically sync'ed itself to the 'administrator' account password.  But when Win2003 SP1 was released, it 'broke' this behavior.  So, some early SBS03 customers might have had their DSRM password auto-changed several times before SP1.  If so, it could be difficult to determine that password should the need arise to restore AD.  As easy way around this scenario would be to proactively change the DSRM password manually.  As long as SBS is at SP1 or later, it should stay 'static'.

http://support.microsoft.com/kb/322672

http://www.smallbizserver.net/Articles/tabid/266/articleType/ArticleView/ArticleID/68/PageID/74/Default.aspx

I recently worked on a problem where some PCs at a customer site were not able to login. I checked the server and it showed many group-policy errors in the App OS log listing the 'GPT.INI' file.  I also noticed the group-policy mgmt console was not able to open any GPOs - said there was a rights error.  'Net View' only listed the server and no workstations.  I had one of the users experiencing the problem reboot and her system said no domain controller was available.  Further research indicated that 5 minutes after last server reboot, these services crashed:

• TCPIP Netbios Helper
• Alerter
• Windows Time
• Webclient
• WinHTTP web-proxy auto-discovery

The Windows Time was able to restart itself, all others were stopped. Restarting the netbios helper service appears to fix the main problem (all PCs came back in the net view list), including the group policy App errors and mgmt console issues.  More research on the Internet indicated others had problems with the webclient service killing the netbios helper on Server 2003 and that SBS was supposed to have the 'webclient' service disabled by default due to security issues

If you want to restore a SBS 2003 box that was upgraded from SBS 2000 using tape backups from Backup Exec, here is the process…and believe me this is abbreviated. [more]

1. Install SBS 2000 so that you can get the system path to be c:\winnt and some necessary dlls that will break the kernel if you try to go directly to SBS 2003. It is temping to use an unattended install and skip directly to SBS 2003 with a  custom install point, but I speak from experience…it doesn’t work. No need to install and configure DNS…I know it sounds like it will break, but it won’t. The only component that should be installed is SBS. Don’t install Exchange, ISA, SQL or the optional components….JUST SBS. Trust me. Be sure to name the domain the same as it was before during setup.
2. Your goal is to get to SBS 2003, but before you upgrade your SBS 2000 install, you must install Windows 2000 SP3, then SBS SP 1a, then Windows 2000 SP4. Having fun yet?
3. Upgrade to SBS 2003 and then fix what didn’t work when you upgraded it….just kidding this actually works pretty well considering.
4. Your next step is to get Backup Exec up and running. So either reinstall Backup Exec on the SBS 2003 box and inventory your recovery tape or install the tape drive and Backup Exec to another server and do it there. Really doesn’t matter where you do it from. Make sure your backup exec service account has access to your restored server if you moved it to a different server.
5. Reboot your restored SBS 2003 server into AD recovery mode by pressing F8 at boot time. It’s like booting to safe mode, but it’s a different option on the same screen.
6. Do the authoritative restore, but DON’T restore anything that has anything to do with SQL, Exchange. That includes program files directories, databases, all the other items that are included in the doc link below. Yeah, this seems strange, but bare with me. Oh, and if ISA was originally installed, you can restore it, BUT if it was set up to log to a local SQL MSDE database (which most are because it is an SBS install and I think that is the default behavior), it won’t work. Exactly how ISA will act once restored is somewhat of a mystery so best of luck to you. IMO, just remove it and deal with it after all this mess is done.
7. Reinstall SQL Server and Exchange Server from media. I know, I know….you have a backup of it so why do you have to reinstall it from the CD that you don’t have. Because…
8. Using single user mode, restore the master SQL Server database first then restore all the other databases.
9. Reinstall Exchange with the /disasterrecovery option. Follow the instructions in the doc…just follow the doc. Just get ready to run eseutil on your databases because they will need it, especially if circular logging was turned on at the message store level (and if you are the one that turned circular logging on…shame on you!). Mount your databases after all the consistency checking is complete.
10. Now, take a breath, go get a burger from Whataburger because by now it is 2:00 in the morning and that is the only place open.
11. Address the literally hundreds of issues that will arise after you have done this procedure.

Here is a link to the unabridged version:  http://seer.support.veritas.com/docs/243037.htm 

Oh, and in all this you better hope you are restoring to similar if not the same hardware. The support on this process from Backup Exec goes right out the window if you aren’t restoring to the same/similar hardware. And you MUST have the media to reinstall all this stuff. Gathering this type of stuff seems trivial, but it is actually one of the MOST difficult parts of this process, especially if the customer is not a volume license holder.

Apparently, if you use the main setup.exe instead of the SBS setup.exe when installing Exchange on SBS a registry value is created that tells the system to wait 10 minutes for Exchange services to shutdown.  For more information, see the following article:

http://support.microsoft.com/kb/827610