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
Post a Comment