Skip to main content

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.

Comments

Popular posts from this blog

Windows 10 Enterprise Eval - gotchas

After an annoying turn of events where my Windows 10 Enterprise USB drive failed, attempts to install Win10 onto a computer failed miserably. I turned to the net and managed to get my hands on Microsoft's Windows 10 Enterprise Evaluation. I have an enterprise key so I thought - cool! Here's the opportunity to get it going and to then upgrade the license later. Full install, patched etc and all is swell. Except when I try to upgrade. I straight up tried changing the licence key only to get a variety of errors, most of which are pertaining to the activation system being unavailable. The I try this: https://winaero.com/blog/upgrade-windows-10-evaluation-to-full-version-easily/ but it doesn't work either. Next I'll try this: h ttp://www.edugeek.net/forums/windows-10/174594-upgrading-windows-10-enterprise-90-evaluation-full.html And if all else fails, in goes the bootable USB I've now created. If only I'd had this in the first instance I would not be writing t

Plone - the open source Content Management System - a review

One of my clients, a non-profit, has a lot of files on it's clients. They need a way to digitally store these files, securely and with availability for certain people. They also need these files to expire and be deleted after a given length of time - usually about 7 years. These were the parameters I was given to search for a Document Management System (DMS) or more commonly a Content Management System (CMS). There are quite a lot of them, but most are designed for front facing information delivery - that is, to write something, put it up for review, have it reviewed and then published. We do not want this data published ever - and some CMS's make that a bit tricky to manage. So at the end of the day, I looked into several CMS systems that looked like they could be useful. The first one to be reviewed was OpenKM ( www.openkm.com ). It looked OK, was open source which is preferable and seemed to have solid security and publishing options. Backing up the database and upgradin

Fixing a black screen after doing a Kali Linux update

Kali Linux is a rolling Linux distribution designed for security and penetration work. You can find details on it here: www.kali.org . We run this excellent product for a range of different security work and it's been great. I built the image in VMplayer, then shared it to the team and we've all been at it since. A recent update broke it though - black screen, no network and completely unresponsive. There are lots of posts about similar things - mostly to do with graphics adaptors, however, we found that executing the following at a root prompt fixed it. But how to get to the root prompt from a blank screen? Linux has a number of terminals available to the user - most of us use the graphical one to do our day to day, but you can access a command line prompt without much trouble. Simply hold CTRL-ALT and then F2 or F3 down at the same time and it drops you to a command line login. BOOM. Time to fix it up. For me, and for the other fellas in the team, all it too was to