Migrating servers

themagicone

Not really a cert ? but figured I'd see if anyone has done it. I need to transfer 2003 SBS to 2011 SBS Friday. They are running Exchange also. I have the document from MS about the transfer and have done basic 2003 to 2008 migrates. Anything in particular I should be watching out for?

slinuxuzer

Never worked much with SBS, but you will want to look out for the shares and NTFS permissions, if they've setup alot of weird permissions you may not have access to the entire folder structure, so you may need to use Subinacl to add yourself to the ACL's. Also, robocopy will be your best bet to migrate user data. Sorry I can't help you with exchange, also with server migrations I never change the servers name during a migration, this actually is a frequent request in large corportations, probably won't be requested with what your doing, but its a really bad Idea to ever do that so I said so here.

A word on robocopy, I always run it on the destination and I map a drive to the destination and turn on as much logging as possible, also for retrys you will want to manually specify the number or retires to 1 and the wait period to 1 second, the default is 3 retries and 30 seconds, thats a total of 90 seconds in between files it can't copy, this can take massive time if you have several files fail, I just always go through and search the log when the copy is done for denied and fail, access denied will be your most common error.

Good Luck!

ptilsen

I've done a few 2003 SBS to 2011 SBS migrations now and a half-dozen or Exchange 2003 to 2010 migrations. There are definitely some gotchas. My biggest recommendation is that you have an extremely versatile backup and back-out plan. This is more important than everything that follows. The whole experience can be daunting the first time you do it, but if you follow MS's article to the letter you will be successful.

SBS 2011 uses SQL Server 2008 R2 Express, which has an arbitrary 10GB limit. This limit is not present when using SharePoint in SBS 2003. The document doesn't make that clear until well after you've started the migration. I've seen an office of 5 people manage to pull a 17GB SharePoint database. Also, the SharePoint migration in and of itself is overall pretty painful.

Yes, Robocopy is a good way to do the file migration. Have the files copied well before you do the actual file share cutover, especially on the users' folders. You can Robocopy again to get changes after your initial copy and it will go quick, only updating changed files. Robocopy /copyall /e [src] [dest] /r:5 /w:2 would be my recommendation. Use logging or redirect to text file if you can't be sure you'll see the output. Another method is to use DFS, but this requires either a small amount of files or a large period of time. You should not need to map a drive for robocopy, and it will not help; the share is either accessible or it isn't.

The tip about NTFS ACLs is a good one, although SubInAcl is not a tool you should need. Some overzealous user or administrator may inadvertently make even domain admin unable to access a file, but you will be able to take ownership. Robocopy will give you output if there are failures. If there are problems, takeown and xcacls are all you need.

Make absolutely sure the source system is healthy, with working FRS SYSVOL replication. Given that SBS systems are inherently single DC, it is very easy to not have working FRS and have it not affect you. But you don't want to install SBS 2011 and have it not be there and working. Run all the updates MS recommends and all the BPAs. In addition, run Chkdsk, Sfc /scannow, and comb event viewer for problems with hardware, DNS, AD, FRS.

SBS 2011 is very much designed to work in it's own way. Use it as such. It's console is not there for show. It does different things with different Windows and MS features and you more or less have to do things the SBS way or you are not going to have a good time.

A big one is Exchange. Get users to clear out there mailboxes well ahead of time, and make sure it's actually purged the mailboxes. I've seen Exchange 2003 to 2010 migrations for small businesses (regardless of whether they use SBS or standalone Exchange) take in excess of 24 hours. The mailbox migration process is not a fast one, and small businesses are notorious for not keeping clean mailboxes. If you have multiple users with mailboxes bigger than a few GB, stop and get them to delete or archive items. No one is ever happy to do that, but they're also unhappy that they're email is down Monday morning, and as far as they're concerned it's your fault.

On the same note, if you're using a spam filtering service a la MXLogic or Postini, spool your email for the entire migration. This is the safest route, and should you have to revert to a backup due to some catastrophic failure, there is no data loss. On the same note, make the source server unavailable for client access. No OWA, no Outlook, no Active Sync, and certainly no POP or IMAP. Assuming you have a weekend with no one internal working, just turn off NAT or access rules in the firewall giving them access.

If users will remain on Outlook 2003, there is a GPO you should enable. I forget what it's called offhand, but it basically forces the "always encrypt connection" option in Outlook on. Your Outlook clients will potentially have problems and have to be manually reconfigured without it.

If you can complete the entire migration during scheduled downtime, you can make the whole damn thing seamless with DNS. Old server name points to new server IP, and use setspn. This is assuming you've fully decommissioned the source server.

Don't forget autodiscover. You need to manually create the Autodiscover SRV record internally and externally.

Make sure you set Exchange to use the already-configured FQDN. If destination tries to make it's Exchange client access URLs remote.domain.local and mail clients are expecting mail.domain.com, you'll have problems. Make sure you either have the exported .pfx file for your SSL certificate or are prepared to issue a new one immediately to avoid certificate problems. Make sure if clients get certificate problems that you read through the message and troubleshoot the right issue (DNS vs CAS FQDN settings vs certificate private key vs certificate chain, etc). It's so easy to miss something, but never assume you know what you missed. The messages can be cryptic, but they almost always point to the exact issue.

Take a manual export of Public Folders to PST, if practical. It's easy to screw up Public Folders in an Exchange migration, and the export gives you an easy recovery option.

When you decommission source, actually decommission it. Uninstall Exchange, DNS, DHCP, WINS. Remove all file and print shares. Demote the server. Remove from domain. If there are hardware problems, virtualize it and finish the decommission. If you can't, you have to get into ADSIedit. Have MS support ready to talk to you. Sometimes they can be hard to communicate with, but the support is good and they will get you through a crisis.

Have your printer drivers ready well ahead of time. Sharing from R2 (SBS 2011) to 32-bit clients, especially XP clients, has some big caveats. Have the requisite sets of same-version, same-language (PCL vs PS) print drivers available for all client platforms if you're doing print sharing. If the office is more than a dozen people, having to get print drivers Monday morning is going to hurt everyone, a lot. But do remember, the business comes first. Print sharing can be impractical for very small offices -- a quick workaround that will make the end-user happy is to map an IP printer. Yes, sharing is more manageable and as such preferable, but if you have nine printers that aren't working and you have to spend five or ten minutes per printer and a dozen workstations, you have a very unhappy set of end-users. You can map IP printers for them in ten or twenty minutes with GPO or 90 seconds a pop manually. The customer doesn't care how you get them printers, just that they have printers. But all of that is moot if you are prepared and have the print drivers you need.

If they have a BES server and no active support from RIM, they must be prepared for it to not work. That said, I've seen ancient versions of BES magically work with no changes on Exchange migrations. Don't count on that, but it happens.

If you have never migrated a file server, DC, or Exchange server, an SBS migration will be a painful way to learn. Read the MS document in its entirety and look for answers if you are not 100% clear on any section. I can probably keep rambling and in doing so more or less poorly document the entire migration process in depth. I guess my point is, don't do this if you aren't ready. Yes, it can be really easy if you know what you're doing. If you don't, it can and probably will be very painful.

themagicone

Now I am little scared. My boss hasn't even done this type of migration. I have only done a few 2003 to 2008 transfers on my test server. Tomorrow I need to do a live 2003 to 2008 transfer. I'm cutting my teeth on this very quickly. Well by what you are telling me I might as well plan on spending my weekend on site. Thanks for the heads up.

Everyone

themagicone wrote: »

Now I am little scared. My boss hasn't even done this type of migration. I have only done a few 2003 to 2008 transfers on my test server. Tomorrow I need to do a live 2003 to 2008 transfer. I'm cutting my teeth on this very quickly. Well by what you are telling me I might as well plan on spending my weekend on site. Thanks for the heads up.

Tell him you want help from an outside consultant, if agrees, get in touch .

ptilsen

themagicone wrote: »

Well by what you are telling me I might as well plan on spending my weekend on site.

Only if you don't have reliable remote console and power. About 70% of the migration is starting the mailbox transfer and walking away. I've done most of these migrations from my bedroom. But I did have to go on-site downtown during the middle of an SBS 2003 to 2011 migration when source locked up on me. That was not a fun Sunday.

themagicone

What would you suggest for remote solutions? My company uses a site that goes off of logmein. Personally I'm a fan of team viewer or should I just get RDP working on both machines and use different ports?

Everyone

No VPN? Connecting via VPN then using RDP works great if you can.

Hypntick

Everyone wrote: »

No VPN? Connecting via VPN then using RDP works great if you can.

This on top of having a DRAC or ILO and you never have to leave your house. Now when you've got a DRAC and someone has unplugged the cable for some reason, that's always a fun trip.

Everyone

Hypntick wrote: »

This on top of having a DRAC or ILO and you never have to leave your house. Now when you've got a DRAC and someone has unplugged the cable for some reason, that's always a fun trip.

An IP KVM can also be useful.

ptilsen

DRAC or iLO is your best bet. You don't need a VPN unless you have some sort of regulatory body requiring it. NAT alone is sufficient and faster. RDP, LogMeIn, etc. are all fine for remote access. It's a matter have having direct console and power access in case something goes wrong. If both source and destination are VMs, that makes it much easier. I have never done a migration on-site unless I had to. I've done dozens from my bedroom, usually over RDP and/or LMI, occasionally utilizing iLO when needed. IP KVM and a remote power device can substitute some form of RAC if needed.

Be more concerned about your backup than remote access. You don't want to have to restore source from a 400GB NTBackup file that's missing 12 hours of email in the Exchange database.

undomiel

And make absolutely sure that you have a good system state backup before starting the migration as it is the only way to get back to square one reliably if things go horribly wrong. Also take good note of who is in the domain admins group. Expect them to start having problems with ActiveSync and/or BES. You'll want to read up on adminSDholder, SDProp and adminCount. Five common questions about AdminSdHolder and SDProp - Ask the Directory Services Team - Site Home - TechNet Blogs

And I definitely agree with all the recommendations for an iDRAC, iLO or some other sort of IP KVM. They can really help a lot with letting you do the whole migration from your comfy chair at home.

themagicone

So I am doing a basic 2003 to 2008 migration tonight. When should I move the user shares? This server is a mess but most, if not all shares are on a drive named D. The new server has a drive D also. So should I just use robocopy to copy the whole drive? Would this before or after I transfer the domain? Thanks

ptilsen

You can still follow the Microsoft whitepaper. I would follow it more or less to the letter -- it's just that it doesn't include all the caveats and details. You can't copy the files until you've installed the new server, which in turn joins it to the domain. After you've joined it, I seem to recall copying files as being one of the first few steps. But like I said, you want to do things the SBS way, so follow the whitepaper on 2003 to 2008 SBS migration.

ptilsen

If you're doing 2003 to 2011 as you first said:
Download: Migrate to Windows SBS 2011 Standard from Windows SBS 2003 - Microsoft Download Center - Download Details
If it's 2003 to 2008 as your more recent post indicates:
Download: Windows SBS 2003 to 2008 Migration Guide - Microsoft Download Center - Download Details

Follow Microsoft's instructions as closely as possible. Do not deviate if you don't have to, and don't skip unless you know a feature isn't used or needed. I still follow these white papers for SBS migrations. Non-SBS is not as challenging or rigid, but you have to do it right for SBS to not blow up in your face.

themagicone

Thanks. Actually I have 3 transfer going on. Tomorrow is 2003 to 2008 r2 Non-SBS. Friday is 2003 to 2011 SBS and ongoing is a 2011 to 2011 SBS transfer. The 2011-2011 has already blown up in my face, I demoted it from AD using DC Promo and it wouldn't boot no more. I tried to get the new machine to join the current domain but it wouldn't find it.

Anyways... I have the paper work for the 2003 to 2011. I'm going to talk to my boss tomorrow about investing in a IP KVM that we can move around as we do more and more of these transfers.

As of right now I am working on the 2003 to 2008 r2 non-sbs. I just started a complete 100% backup to the new computers 2nd hard drive. 15 to 18 hours to complete. Once that is done I will do the adprep commands to prep the AD to be moved to 2008. Join the new box to the old, take control via CLI then demote the old server. Just need to figure out exactly how to move the file server portion and the shares. Like I said before I am really cutting my teeth on this. I really appreciate the help you have provided.

ptilsen

Ahh, non SBS is a different beast. But, it's easier to do and harder to completely destroy the universe in doing. Install Windows; join to domain; configure firewall and NIC; install AD DS role service; adprep /forestprep; adprep /domainprep; dcpromo; install DHC, file, print, etc. as needed; copy files; recreate file shares; recreate print shares; setup time sync (recommend NTP to us.pool.ntp.org); transfer FSMO roles; demote source; install and migrate other applications if needed; remove source from domain and take offline; change DNS to point source A record to destination IP (or replace A record with CNAME); run setspn to add old name to new system and/or update scripts/policies to map to new FQDN. That's roughly the process of a 2003 to 2008/2008R2 standalone DC/file/print/DHCP migration. You can do it in phases or all at once. The share migration is more transparent if you can do the whole thing at once.

I'm not sure that Microsoft has a single white paper that really captures that quick and dirty breakdown. There are some Technet articles on various migration processes, but I think they really missed the mark in terms of the classic small business standalone DC not running SBS. The reality is, a lot of SMBs don't use Small Business Server but do use their server(s) in a similar capacity.

undomiel

Were there no good backups before? To save yourself time for the files I would rely on the regular backups (after making sure they're viable backups) and just take a system state backup. Then go through with the joining to the domain and migrating over the shares. When you do your robocopies be sure to pay attention to the logs for what has failed. Otherwise you may find yourself missing some import files. Something else you may want to look into when you're moving lots of shares is the file server migration toolkit. Download: File Server Migration Toolkit - Microsoft Download Center - Download Details It can simplify some of the migration pains, though it can also add complexity to other file share migration pains.

Make sure everything has fully replicated to the new DCs before you go around demoting old DCs. Otherwise you may find yourself restoring that system state backup. Make sure you've moved all of the roles over as well.

Actually reading back through some of the problems you mention it sounds like you could use some good studying into DNS and Active Directory. Here are some links for you:
How DNS Support for Active Directory Works: Active Directory
Troubleshooting Active Directory
How Domain Controllers Are Located in Windows

themagicone

Thanks everyone. I just started this job this week and I am having my doubts. My boss makes it very hard to understand the requirements. Just when I thought I had the 2003 to 2008 transfer down tonight I get an email that they have a CMS that must stay on that current server. That throws a huge curve ball. I went through the whole server and I didn't find no CMS. So now not only do I need to figure out how to transfer AD, File server and the like, but figure out how to keep the CMS active while transferring the AD DC to a new server. This is way over my head.

undomiel

You're going to find that this is some of the best training that you've ever gotten. On the job trial by fire training. It'll be painful while you're going through it but you'll be a stronger admin for it. Now for your particular problem someone knows about that CMS, you just need to track down who it is. If you're just demoting the server and not actually getting rid of it then you shouldn't have too many problems with it. Check for service accounts, they may need special permissions reassigned for that particular server since it is no longer a DC. Also check the settings to see if it is dependent on any particular shares i.e. hardcoded UNCs. Does your boss have other employees that you can consult with? Or can you consult with him yourself? It sounds like you could use some more definite direction.

ptilsen

It sounds like your employer is a bit reckless, TBH. I would work through these types of migration with a junior engineer before letting him do one on his own. And I certainly wouldn't let anyone migrate a server if they didn't have good documentation and/or familiarity with its configuration. Also, any migration like this is a project. We have a work plan, we schedule it out and make sure the client knows what to expect and that we meet their expectation. A typical migration like this is a minimum of 40 billable hours budgeted. A full SBS 2003 to SBS 2008/2011 migration including a new physical server would be around 80 hours. The are budgets allowing for a lot to go wrong, but it really can take a lot of work to get it right.

If you're not seeing some of things I've mentioned above, then your employer is irresponsible at best. What type of company are you working for? A small MSP?

Edit: Trial by fire can be a good thing, but not at the risk of your client's data and system availability. This is a great learning experience but learning needs to not involve insufficient planning. I would typically put almost as much time up front on a migration as I do on the actual migration. Five or ten hours of planning and documentation, another five or ten on testing backups, finding drivers, checking software compatibility, etc.

Hypntick

ptilsen wrote: »

I would typically put almost as much time up front on a migration as I do on the actual migration. Five or ten hours of planning and documentation, another five or ten on testing backups, finding drivers, checking software compatibility, etc.

I will second this completely, doing more leg work up front will allow a much smoother transition when the fun begins. I don't believe you can ever over prepare to do something like this. Also it's always a good idea to make sure your backups are working, never know when you might need them.

themagicone

Well I started my 2003 SBS to 2011 SBS transfer yesterday. Site has only 4 computers and 4 users. I documents the OS, applications and printers. Took me 7 hour on site just to update and get the source server healthy. I'm at the point now of moving users mailboxes and shares. That is going to take better part of the day to do. It may only be 4 users but their mailboxes are like 5 to 10 gigs a piece. Plus the shares are almost 10gig. After that I need to figure out how to move an ACT database. So far it's gone smoothly but I have long ways to go.

themagicone

So the transfer went smoothly. Everything is up and running. I have to wait till tomorrow to make sure everyone still can log in and has access to what they need. Also, I can't take down the old server till we move some other applications and DB's. The only issue I'm still having is that I would like mail.domain.com to point to remote.domain.com/owa instead of a default iis screen. Also, some issues with certs (cert is for remote.domain.com and doesn't list the autodiscover.domain.com, etc so it gives an error). Thanks everyone for the advice.

undomiel

Glad to hear that things went well. If you add a redirect in IIS from the root to /owa you'll need to go into the CliantAccess\OAB folder and add Authenticated Users read permissions to the web.config file that gets created, otherwise you'll start having sync issues with Outlook 2007/2010 clients and they won't be able to download OAB updates.

ptilsen

Undomiel's tip includes the solution to your DNS problem: Redirect the root directory (but not sub-directories!) to https://remote.domain.tld/owa.

For autodiscover, you can and probably should implement an SRV record:
A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service

You can also implement a wildcard SSL certificate, but proper configuration can eliminate any need for a wildcard certificate.

Be sure to also set your client access methods to use the FQDN mail clients are expecting.