The Migration is complete...sort of...

Well, sort of.  Companyweb still has to be restored.

 

Man, what a job.  I ran into some serious "issues", mostly related to virtual server.  I actually did the migration TWICE.  Once on Saturday, different servername, took me about 8 hours.  Then once again on Sunday, took me about 5 hours, same servername.  I documented most of the issues that I ran into and will post them in the coming week or so.  I need to organize them so they are usable and readable.  I will stand by my previous comments...whatever backup strategy you use for your customers,  make sure to test the restore procedure.  I now know the issues with using Virtual Server in this manner.  I knew from the beginning I could always restore Active Directory...I just wasn't sure of the "details".  I could probably now run through the entire process in about 4 hours.  Most of the time on Sunday was the actual install of SBS, copying files, etc. 

 

One tidbit is that I had (have) my replica DC in Virtual Server set to "always start" if the Virtual Server service stops and restarts.  The thought behind this is that if my Winxp box bluescreens and reboots, the replica DC will automatically "turn on" when the XP box boots up.  Makes sense, right?  Well, in order to enable this option you have to specify an account for Virtual Server to use.  Well, I chose domain\administrator and the password..  So, in my migration there was a time when there was no SBS on the network, only the Domain Controller in Virtual Server.  I made the mistake of rebooting the XP machine and the Domain Controller in Virtual Server would not start.  Some weird NTM error.  It took me a while to figure out that there was no way for Virtual Server to authenticate/validate "domain\administrator" because there was no "Domain" present since SBS was gone and the Virtual Server Domain Controller was the only Domain Contoller! 

 

Another weird issue relating to Virtual Server had to do with the Virtual Server "add-ons".  The Domain Controller in Virtual Server was originally running on Virtual Server 2005.  Well, I installed Virtual Server 2005 R2 on my new box and copied the VHD files over to the new box and booted her up.  Well, it is recommended that you install the new R2 "virtual server add-ons" to update them to the R2 version.  Simple enough and I did do that.  Well, during my migration I needed to install the Group Policy Management MMC on the Domain Controller running in Virtual Server.  When I tried to install it, I got a weird error from Virtual Server talking about "undo disks" and a pending "virtual server add-on install", like I didnt reboot after the "add-on" install (which I did)..  It gave me a yes/no question regarding cancelling the "add-on" install.  Clicking no aborted the Group Policy Management MMC install.  I tired it again and this time I clicked yes and the MMC install proceeded as normal.  I went back to work on the migration and that's when things went south real quick.  All of a sudden things started failing.  Replication was busted.  I promise everything was running like a clock and then the bottom fell out!  What I found is that the "aborted" install of the "add-ons" broke Virtual Server networking and I had no connectivity between my Virtual Server Domain Controller and my newly installed SBS box.  A reboot of the Virtual Server Domain Controller fixed that.

 

Going off track a bit...PSS doesn't support a migration scenario from “start to finish” in a "Break/Fix" case.  We do offer a solution for customers who need help with the entire process; it's called "Advisory Services".  Here is a link to more information on Advisory Services:  https://support.microsoft.com/gp/advisoryservice.  There are too many variables!  Also, when is the “finish”?  When SBS is installed?  When clients can logon to the domain?  When Outlook works on the clients?  When all the shared printer data has been migrated?  When all of the RPC over HTTP Outlook clients can connect?  On a PSS case, there is a “beginning” and an “end” to a case.  The “end” of a migration will vary wildly depending on the migration scenario, customer’s confidence level/ability, business needs, timeframe (start on Friday night, end on Sunday night), etc.  If you asked me to lay out a "catch-all" migration scenario, it would turn into "War and Peace".  I could do it but the flowchart would break off into an infinite number of paths depending on your network layout, software environment, etc.  Also, when calling PSS regarding migration "issues", our support is generally "what's the error in the specific step?".  We focus on that one piece, resolve that issue and close the case.  With an Advisory Services case for a migration scenario, we (PSS) proactively ask questions regarding network layout (Visio diagrams if available), software on the network (only the Microsoft stuff, of course) and "what do you want your network to look like at the end of the day" (from a software perspective).  We then take al that information, put it in a blender, add some various tidbits from the tech support kitchen (special sauce is used in those "special" cases) and come up with a plan to get the customer to their desired destination.  Even in those "planned" scenarios with the experts at the helm, stuff happens and we have to adjust the plans on the fly.

More gems from my experience coming soon, stay tuned!

 

Petergal

Comments

• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  February 15, 2006
  I would strongly recommend anyone to look at the Swing Migration methodology for migrating servers about. It really removes a lot of the pain that Peter has experienced.