Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 426
  • Last Modified:

Active Directory Migration to SBS

I tend to support large infrastructures so don't do much with SBS.  My question is, is there a tool, or a document that outlines how to migrate a "proper" full 2003 AD Domain to a new SBS server.  I.e transfer the roles etc, with the outcome to switch off the old 2003 DC.
0
Mdc2050
Asked:
Mdc2050
  • 4
  • 2
1 Solution
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Demazter has created an article here people like.  But in short, you can run the tool on the SBS 2011 DVD to ensure the domain is ready (AD is at the correct version and a couple of other little things) and then you just install SBS in migration mode.  You'll then need to do a few things to get the users into the proper management consoles/OUs to be managed as SBS wants to manage things, but it's not teribly difficult...

A few things:
If you've NEVER done this before, DO IT!  On test systems.  VMs are great to create test environments - build one and do this a couple of times to get used to it and ask specific questions.

If you don't want to spend the time learning it (time is money), hire someone to do it correctly.

Consider using Jeff Middleton's SBSMigration.com kits - they are widely considered amongst the best migration methods out there... not free, but relatively minimal cost that saves time and allows you to easily start over if something goes wrong.
0
 
Cliff GaliherCommented:
The short answer is no, there is no such document. And it has been my experience that creating such documentation would be quite complex. You can use the SBS migration wizards and tools to accomplish most of what you need, and the documentation will walk you through a lot of it. However a standard AD installation does not create any of the OUs or group policies that SBS does. And in a migration, all of those non-SBS settings are preserved, which the SBS wizards will likely balk at. And that is where creating a non-SBS to SBS migration document becomes troublesome. There are too many variables and potential configurations from the source server to take into account to make an easy step-by-step process repeatable and put it in a small readable form.

What I usually recommend, especially if you are not familiar with SBS, is to install SBS on a clean VM not attached to the network. Look at its AD layout and group policies.

Then get the AD topology on your source server as close as you can to the clean install. In some cases, you won't be able to complete this...such as group policies specific to 2008 R2. But you can get darn close.

Perform your migration.

Then make any remaining changes so your migrated install, from a topology and GP standpoint, matches your live install.

It is a bit of work, but not particularly difficult once you get used to it.

-Cliff
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
I feel silly asking this, but are you sure?  I did a migration almost a year ago from a 2000 Server to SBS 2011 (had to do an interim migration to Server 2003 to get AD up to spec and then pull in the user attributes on console... but it works great and was pretty simple to do.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Cliff GaliherCommented:
Yep, I'm sure. And I also don't doubt your experience. But that exactly highlights my point about the difficulty in documenting a one-size-fits-all migration document.

 Some non-SBS to SBS migrations can be *very* easy of the AD topology is not too complex. Other topologies will actually cause migrations to fail because SBS doesn't know where to look for certain attributes. In most cases, as long as the admin didn't get *too* creative with OUs and delegated permissions, the migration will be straightforward. But I've seen and been called in on ugly ones. It is best to clean up AD before migrating, not after. And trying to document that process....oofta. too many moving parts and potential "oopses."

I will say this, that is one benefit of a swing kit from Jeff. He's been selling and supporting them long enough that with each support issue he has had, he can flesh out the document to help make sure it doesn't happen again. His kits are some of the most thorough out there, and still come with support for those edge cases where the documentation still isn't enough.

-Cliff
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Fair enough.  Most sites I've walked into have no idea about delegation on OUs.  And I make a point of running DCDIAG and checking event logs and ensuring that when I start, the only errors there are ones I'm expecting to see for a good reason.
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
And I might add, it's one of the reasons I tell people either LEARN THIS or pay someone who knows what they are doing... That's become a point I make in ALMOST all my posts these days.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now