My Blog

I decided to finally get with it and create my own Blog. I don't know how often I'll be blogging, as I stay fairly busy, but I'll try to post here every so often. Since most of the work I do relates to Microsoft Exchange, probably much of what I blog about will relate to that, but I'm sure that there will be occasional (or frequent) blogs about my family.

About Me

I grew up near Ann Arbor, Michigan and went to college at BYU (Brigham Young University). In 1992, I took 2 years off from school to serve a full-time mission for my Church (the Church of Jesus Christ of Latter-day Saints) in Frankfurt, Germany. I've been married for 11 years and have 4 beautiful children. I have been working with Exchange since 1999.

SBS Migration hell
I recently helped a friend with a swing migration from one (really old) SBS 2003 server to another (new) SBS 2003 server. As there is currently NO process provided by Microsoft to migrate SBS servers (at least none that I am aware of), my friend had purchased the SBS Swing It Kit, provided by Jeff Middleton (SBS MVP) to assist us in this project.

SBS (Small Business Server), if you haven't worked with it before, is designed for small businesses and is also designed to run on 1 server. As such, your 1 SBS server is set up to host many roles on the same box - we're talking Active Directory, Exchange, SQL, Sharepoint, and optionally, ISA and some others. There are license limits in place that only allow you to have a certain number of clients (I want to say 75?), which is why it should only be used for small businesses.

On to our experience. The SBS box in question was just running SBS Standard, which probably made it a "little" bit easier, but not much. A brief overview of the swing migration process is that you have to bring up a temporary DC, transfer everything to that, remove all references to the existing DC, then add your new server (which has the same name as the old server) back in. This by no means details all of the steps involved (which are quite numerous), so I'd encourage you to check out the Swing It kit previously mentioned if you have to go through this process. Anyways - adding the new server didn't pose any problems. AD and DNS replicated with no issues and we were able to do the things we needed. The problems began when we tried to add the new server (with the same name as the old one). We couldn't get AD to replicate. After a few hours of mucking around, we found the issue. Ready? It was the Windows Firewall service! Why on earth the Windows Firewall would decide to prevent Active Directory replication is beyond me, but it did. Once the service was disabled, replication took place within a few minutes and we could then proceed.

Probably the most difficult part about a migration like this is getting the Exchange data transferred. Luckily, as long as the server name (along with a few other things) is the same, you should be able to mount the database from the old server with no issues. I've done this several times for regular Exchange servers, and it's the method that you used to have to follow with Exchange 2000 (build recovery Exchange server in a new forest that has same name, same admin group, same database name, etc.). However, another catch was that there hadn't been a successful full backup in a few weeks, so there were LOTS of log files. To be on the safe side, we brought those over as well, even though the stores were in a clean shutdown state. The biggest nightmare for us was actually getting the stores to mount, though. Let me state for the record here that at 4am in the morning, patience is not my strong suit.

I had applied Exchange 2003 SP2 while I was still copying the databases and log files from the old server to the new one (hooked up old drive via USB 2.0 enclosure), and even though the stores were dismounted when I ran the SP, after it was done, it tried to mount the stores, and replay all the log files. This *obviously* wasn't going to work, as the databases didn't even exist yet! Anyways, to make a long story short, I killed the store.exe process so the SP install would finish. Once that was done, and the stores and logs were transferred, I tried to mount the stores, only to have it fail with some comical error about files not being in the right state, or some such nonsense. I re-transferred the databases and logs again, and verified the databases were still in a clean shutdown state (eseutil /mh), but no dice. Running out of time, I thought I'd try to re-run SP2 and see if something had gotten mucked up the last time. This time, like the last, it replayed all the log files, then it purged them (I don't think I've ever seen an SP purge log files - hehe). With that done, all I had to do was mark the databases as being able to be overwritten, then I was able to mount them successfully.

The other problem we encountered was with the migration of the shares. Because there was a lot of data in the user shares, we decided we didn't have enough time to move the data, so we hooked up the old hard drive into the new server, and re-created the shares. Though I could have sworn that we checked, apparently the new share for the User Shared Files (where My Documents gets redirected to) was set to share perms of Read only. Remember that Windows uses the most restrictive set of permissions when you are accessing a share, so even if you have full control at the NTFS level, if your share permissions are read-only, you aren't going to be writing anything to that share, bucko. That was easy enough to clear up.

Sooo - 12 hours, and a severe case of sleep-deprivation later, migration is done. A few minor problems cropped up later on, but my friend was able to take care of those.

My observations:1. Why in the world does an SBS migration have to be this difficult?2. Has anyone at Microsoft tried to migrate SBS servers? If so, do they expect small businesses to ever do this without hiring an sbs expert?3. I don't like SBS. I really don't. Some people love it. I'm not one of them. It felt like a very dummified [1] version of Windows Server 2003, with wizards galore, and progress bars that leave no indication of what exactly it is doing.

I've promised myself to never touch another SBS server, and above all to never do another SBS migration. I'll leave those to the SBS experts, something which I don't claim to be.

It's really a shame that you ran into so many problems... but you kept referring to "running out of time". Which is something you don't have to worry about with a SwingMigration, since the network is never really down and it can be done over a number of days if you like.

Also, it's no wonder the Windows Firewall Service caused problems... it's not supposed to be used on an SBS.

Lastly... the fact is that the wizards aren't a dummified (nice word) version of Windows Server, but rather a "smartified" one. Consider that you would never put all of those components into a single box if you were running a standard setup... those wizards (which are really just scripts) ensure that everything that's in the box is fine tuned and configured properly to not cause one thing to step on another's toes.

Give one a try in a non-production environment, and I think you'll find that you will start wanting the wizards on the other servers you work with.

I'll agree that our approach wasn't the traditional approach to a Swing migration, but unfortunately we did have a limited time window, which probably contributed to my frustration and bad experience.

As to the Windows FW service - I agree there as well, but the install was done using the SBS media, and the Windows FW service was there and enabled, so I dunno.

I also agree that no one in their right mind would install all these things on a regular server, but I still disagree on the wizards. If I'm running a wizard, I want it to at least *show* me what it is doing. These don't. I take that back - some of them do. It's a good thing that they do fine-tune the box, but I don't like the way they work.

As far as wanting the wizards on other servers, I'll also respectfully disagree. I have not yet found a need for any of the wizards (such as those in SBS). These same sentiments have been expressed by virtually every other person I know who administers "regular" Exchange servers. I expect that those who work with SBS every day have come to love the wizards, but I don't work with SBS every day, and my experience thus far is that I detest them.

Microsoft did publish an SBS 2000 to SBS 2003 migration document that advocates the use of the "Active Directory Migration Tool" and it's completely useless. (SBS_MigratingSBS2k.doc) Actually it's rather dangerous. This official method instructs the installer to basically destroy the existing network and leave a lot of nasty issues for the users behind. (Microsoft actually outlines two days of downtime to fix client computer issues, etc!) I think my boss would have seriously questioned my abilities if I had gone that route with our migration.

I thought doing a "Swing" migration was fairly easy. I didn't buy the "kit," but Jeff Middleton wrote a chapter about it in a book I bought (Advanced SBS 2003 Best Practices) and he explained the steps in sufficient detail there. This method seemed like a much more logical approach instead of starting with a new server name, domain name, IP address, and etc as Microsoft recommended. I'm sorry to hear that you had such a hard time with it... I only had about 4 hours of downtime with the migration. A great deal of that was the cost of copying 20-30gb of data over 100mbps ethernet. (Robocopy works great to preserve security and other attributes.)

I'm mixed about the wizards. I dislike the internet connection wizard or whatever it's called because I've found it can leave very annoying (hidden) side effects. The backup wizard is pretty nice, though NTBackup is already rather painless to use. What they really should add is a "Migration Wizard" that will do all of the tedious ASDIEdit and NTDSUtil work involved in a swing migration, plus resolve any simple to moderate issues in mounting the old Exchange store.

It makes no sense to me as to why they have all of these "wizards" in the OS but make migration such a manual process. Given the size and resources of Microsoft, it's just amazing to think that they've left their SBS customers (repeat customers at that) blowing in the wind on these migration issues. Spending money on an SBS license plus CALs and then basically needing to fork out another $xxx for a 3rd party migration guide and support is just nuts.

I've heard good things about another tool for server migration - secure copy. Take a look at this review in WindowsItPro. Sounds really promising for me. We are thinking of migrating server data to new hardware and I've heard that Secure Copy can make things much easier.