Monday, 13 May 2013

Adventures with migrating Windows SBS2008 to Windows SBS2011 - Part 2

We take up the exciting adventures in migrating Windows SBS2008 to Windows SBS2011. The day is getting older and the laborious task of migrating Exchange data looms before us. We start by creating new Public Folder stores and configuring them. There is quite a bit of jumping backwards and forwards from the source (old server) to the destination (new server) during this process. Note there is a bit of command line work here – I highly recommend using tab complete where possible. If you haven’t used this before, type the first bit of a command or location and hit the TAB key – it will bring up the first match to those characters. Keep hitting Tab until you get what you want. Typically if it’s a multipart command, I’ll type a few letters, TAB, then a few more letters, another TAB etc until I minimise the number of letters I have to type to the bare minimum. It’s very *nix-y J

The mailboxes for the users – fortunately small – are in the process of migrating. Next will be data files and shares. We expect this to take the bulk of the time for the process. Note that the public folders suggested waiting 24 hours for them to complete the migration (No way!). This particular site has no data in the public folders so we can safely blow past this part.

The exchange migration was relatively straightforward and simple for us – not a lot of data and all over in about 30 minutes. On to the file migration and starting with the UserShares I was pleased to see that the command used was Robocopy. As you’d know from this blog I really like robocopy and its venerable cousin xcopy. Those applications have been great tools in my arsenal. We also set up the second partition – all the line-of-business data will go in here and we’ve got around 70GB of data to transfer for that. The robocopy transfer of the UserShares folder ran at about 500MB / minute so we’re looking at about 140 minutes for the big data transfer. We thought we’d get a bit of a jump on a few other bits of the migration – namely WSUS but the source server was running flat out keeping up with its new brother’s demands, so that was a no-go. Much of the migration of Fax, internal website and a few other features we were able to skip as this organisation doesn't use them. We’re at 9.25 hours so far and making good time (touch wood).

We RDP’d into the old server – turns out the console was misbehaving and started cleaning up WSUS. This process took 10 minutes by itself. Then it was time to set it up to migrate to the new server. The data copy was still proceeding and the log file was over 6MB in size already. We reviewed WSUS and decided to stop the migration – we’ll download it afresh and configure it only for the existing machines, cleaning up lots of other stuff in the meantime.

Creating a spreadsheet for all the share permissions is a handy thing to do. If you've got a lot of folders, with complex permissions I find this to be a good way to keep them all straight. It’s also a good opportunity to review Security Group membership and how these groups are applied to folders.  Robocopy with the switches the documentation suggests /COPY:SOU brings across all your ACL information so security is pretty easy to get going.

We’re up to the finish of the migration. We need to demote the old server, remove Exchange and a few other tasks. It’s a bit scary – this is the end stage. Luckily we still have the backup in case things go pear shaped. Here we go.

Removing Exchange 2007 from the old server proved challenging. There was a few difficult moments, an early “Who’s your daddy!” cry, then some silent weeping and finally success. I won’t bore you with details – sufficient to say it’s a bit of a process but our Google-Fu was up to it. The actual process of removing Exchange was surprisingly slow too – the files took a long time to delete. Not sure why – they aren't that big, and yet, 15 minutes after it started deleting them, it’s still going.  Once this process finished, we removed A/D Certificate services and then demoted the server. Rebooted and remove from network. Apparently we should now be done with the old server.

Uh Oh! It turns out that the users’ roaming profiles weren't properly copied across! Oh Noes! Powered up the dirty old server and started copying data across to a USB memory stick. Although it’s only 5GB the files are all little and so the copy time is suggesting 1 hour 20 minutes (!) I think this is uncool and my colleague agrees. Fortunately this does give us time to try and fix another issue that’s cropped up – the desktop PCs haven’t updated where they are supposed to get the redirected folders (Desktop and Start Menu) from. They’re still looking at the old server. So, with more swearing – as it is now 6:30PM and we've been at this since 8am this morning – we tackled the next issue. The desktop PCs registry’s suggest they are looking in the right place but the folder redirection still fails (it’s looking at the wrong place still so the issue of having no data there isn't yet a big one). Running gpupdate /force hasn't seemed to fix it yet. We’ll update the files, then try again – especially because the RedirectedFolders is empty – we had copied that data across so not sure what happened there.

This is a longer than anticipated process – the 5 or so GB of data is all very small files and so takes ages to copy across – more than an hour to copy it off, and only about 20 minutes to copy back in.

We found that the desktops were continuously looking in the wrong place – they were using the old server’s name in the UNC. Rather than update a million shortcuts on desktops and keep fighting the desktops I added a CNAME in the DNS to point the old server name back to the new server. Everything started working! We did find a multitude of strange, legacy shares that required recreation, so try to get all this down on paper before you get started. By this time we’d been at it for 15 hours each and we were starting to get a bit pissy. Thankfully Outlook and most other apps continued to work – we didn't need to create new profiles or anything.

We found that Exchange also had no outgoing connector to send email out. Internal email worked fine and the server was receiving mail but we couldn't spam, uh, I mean email, anyone. There was no Hub Transport Send Connector created. We got this going and suddenly the queued mail we had sudden flowed through. It was quite spectacular really – we’d sent a *lot* of test emails J

It was at this stage we made the executive decision that all the major boxes had been ticked and the network was operational. We had allotted 16 hours for each of us and we came in at 15.5 hours. Not too bad at all. We’ll no doubt have some problems on Monday but for now we’ll knock off and collapse at home. I hope some of this information is informative or at least entertaining. Here’s hoping your migration goes as well or better.

No comments:

Post a Comment