Migrate or start from scratch a AD?


Recommended Posts

Hello,

The other day Ive just been told that it is possible that this summer we will upgrade to WS2012R2 since WS2003SBS's support finally ends :D

That's the good part; The bad is that Im gonna have to do it and no idea how so Ill problably start testing that around these next months...

Now Ive read there is NO direct path to update from WS2003SBS to WS2012R2 (update to 2008 then to 2012) or some trick workarounds.

Right now we have

DHCP

AD

DNS

We also have a (rebellious) NAS that depends on AD for its permissions.

Running on that with about 18 users. Is it worth migrating or should I simply start from scratch? I say start from scratch because since this was setup back in the day without me, maybe I can set it up correctly :)

Like I said, no clue or idea how to do this except Google and YouTube.

Link to comment
Share on other sites

Build 2012 R2 server, add to existing domain as a DC, migrate everything over and demote the 2003 SBS. Bear in mind that Exchange isn't included with 2012 so that will need to be done separately.

Link to comment
Share on other sites

Hello,

Build 2012 R2 server, add to existing domain as a DC, migrate everything over and demote the 2003 SBS. Bear in mind that Exchange isn't included with 2012 so that will need to be done separately.

When I said start from scratch, I ment everything even deleting the current domain and redoing it with the same name. Nothing about migrating :)

Just in case, to make it clear :)

18 users, I'd start from scratch personally.

Lets me make the AD/domain clean and also I would be able to document everything done/setup, to make sure there isn't any weird settings.
Link to comment
Share on other sites

Don't confuse the SBS products with the standard servers, they are very different! SBS 2011 was the last of that line, you could only have one SBS on a domain but as many normal servers as you want.

 

Migrating the AD to a new server would be far easier than demoting all the clients and re-adding the new domain, like I said earlier I personally would add the new server as a new DC so that AD is migrated to it and demote the SBS off the network.

Link to comment
Share on other sites

You could set it up from scratch, but then you've got to add the 18 PC's to the domain again.  Off the top of my head I can't recall if you have to remove them from the old domain, and then join them to the new AD.  This may mean each user then ends up with a new profile on their PC and loses personalised settings which you may end up having to deal with.  Just a thought.  So as Tomo has said, migrating the domain would be the simplest solution unless you are having major issues with your current setup?

 

You will also need to look in to setting up an Exchange server and how you are going to move their mailboxes across, or at least the content stored within them (presumably via backed up PST?).  If you migrate the domain though and install a new Exchange server you might get away with simply moving them from SBS to the new Exchange server overnight.

 

Presumably you are also using SBS for file sharing, how will you handle this with 2012 R2?  DSF might be a good option to look in to here, so data migration is something you may also need to consider.

 

What about printers, will you have a printer sever or are printers installed locally?

 

Do you have one server currently, how many do you need for 2012 R2?  Typically you are advised to split server roles across separate servers, which means additional licences.  Although you could some doubling up with the small amount of users you currently have.

 

And don't forgot to look in to a backup solution, is your current backup solution compatible with 2012 R2?

 

Sorry for the slightly chaotic nature of my post, just some random thoughts going through my head.

 

However you decide to undertake this project there are number of things that need to be looked in to and planned.  Once you've planned what you want to do I would look to put it in to as detailed a document as possible and get it agreed/signed off with management.  Might be overkill now, but down the line it may come in handy.

 

You certainly won't be bored :)

Link to comment
Share on other sites

I would migrate mainly due to having to force a strong reset for everything in the domain. This can be pretty painful...

 

All ACLs need to be reset on things such as the NAS... Computers have to be rejoined... Users have to resetup all of their settings... The list goes on.

 

The biggest pain from the migration would be dealing with Exchange. As you don't have a clean Exchange Migration line. You'll have to pull up to Exchange 2007 then 2010 then 2013 if memory serves. As 2010 or 2013 can't direct migrate Exchange 2013.

Link to comment
Share on other sites

Theres no reason to start from scratch even if you're using Exchange. I'd just add a 2012 R2 DC as Tomo said and move the users to Office 365 or export the mailboxes to PST files, blow away Exchange 2003 (and SBS) and install your new Exchange environment. After, set up your mailboxes and import the .pst files.

If you had a significantly larger environment, I recommend bringing up a 2008R2 VM and installing Exchange 2010 as an interim. As long as you make sure it's fully patched, a double-migration isn't that bad.

-Forjo

Link to comment
Share on other sites

I would migrate mainly due to having to force a strong reset for everything in the domain. This can be pretty painful...

 

All ACLs need to be reset on things such as the NAS... Computers have to be rejoined... Users have to resetup all of their settings... The list goes on.

 

The biggest pain from the migration would be dealing with Exchange. As you don't have a clean Exchange Migration line. You'll have to pull up to Exchange 2007 then 2010 then 2013 if memory serves. As 2010 or 2013 can't direct migrate Exchange 2013.

Agree completely.

And FYI -- you can skip 2007. You can move mailboxes from 2003 directly to 2010. After, 2003 needs to be uninstalled and then you can move mailboxes to 2013. I did it with a 2008R2 VM. You don't even have to activate it as you'll be done long before the evals have expired.

-Forjo

Link to comment
Share on other sites

Hello,

Don't confuse the SBS products with the standard servers, they are very different! SBS 2011 was the last of that line, you could only have one SBS on a domain but as many normal servers as you want.

There is only one server here and (logically) one domain.

 

 

 

You could set it up from scratch, but then you've got to add the 18 PC's to the domain again.  Off the top of my head I can't recall if you have to remove them from the old domain, and then join them to the new AD.  This may mean each user then ends up with a new profile on their PC and loses personalised settings which you may end up having to deal with.  Just a thought.  So as Tomo has said, migrating the domain would be the simplest solution unless you are having major issues with your current setup?

Well, there is a hassle to it I suppose but wouldnt it be better do it once perfect and documented than down the line in 2020 or whatever redo it all?

You will also need to look in to setting up an Exchange server and how you are going to move their mailboxes across, or at least the content stored within them (presumably via backed up PST?).  If you migrate the domain though and install a new Exchange server you might get away with simply moving them from SBS to the new Exchange server overnight.

No Exchange here.

 

Presumably you are also using SBS for file sharing, how will you handle this with 2012 R2?  DSF might be a good option to look in to here, so data migration is something you may also need to consider.

Right now all files are stored on a NAS which is a member of the domain. That NAS gets users/groups from the AD and applies permissions to the NASs files based on that.

What about printers, will you have a printer sever or are printers installed locally?

All printers are networked or local.

 

Do you have one server currently, how many do you need for 2012 R2?  Typically you are advised to split server roles across separate servers, which means additional licences.  Although you could some doubling up with the small amount of users you currently have.

Only 1 server.

 

And don't forgot to look in to a backup solution, is your current backup solution compatible with 2012 R2?

Backups are NAS based.

 

 

I would migrate mainly due to having to force a strong reset for everything in the domain. This can be pretty painful...

 

All ACLs need to be reset on things such as the NAS... Computers have to be rejoined... Users have to resetup all of their settings... The list goes on.

Yes, it would be potentionall a pain but its like holding off surgery....

 

The biggest pain from the migration would be dealing with Exchange. As you don't have a clean Exchange Migration line. You'll have to pull up to Exchange 2007 then 2010 then 2013 if memory serves. As 2010 or 2013 can't direct migrate Exchange 2013.

No Exchange here.
Link to comment
Share on other sites

What I would do since it seems like a simple network and you want to change things around anyway, build from scratch.  If it were larger you would use ADMT to transfer to a different domain and migrate everyone over as seamlessly as possible.  That way you would move the pc's over without disjoining and rejoining, you would move users over without recreating the wheel, you would move groups and membership over.  25 users you really don't need to go through all of that unless you really wanted to learn the utility (which isn't a bad idea ;) and why I am mentioning it.  But it isn't a simple point, click and done utility...lots of prep work and testing to be done).

Link to comment
Share on other sites

I would do from scratch as well.  Were you not having issues with your NAS and permissions anyway?  Since you don't have exchange to deal with?  What is used for mail currently?

 

Keep in mind that from scratch is more than likely going to mean some pain for users, lack of access to files on the nas?  While you join the nas to the new domain and then make sure all the permissions are setup.  Then move the users machines into the domain so they have access.

 

Also would assume some pain with their profiles on their machines?  Now sure how you have those setup now, etc.

 

But scratch does allow you as you mentioned to document everything, get all the ducks in a row as you add a test machine, etc.

Link to comment
Share on other sites

Hello,

I would do from scratch as well.  Were you not having issues with your NAS and permissions anyway?

Solved, but yes. Some I imagine that this being a 2013 NAS and we running a WS2003 SBS, things might be old and outdated...

Since you don't have exchange to deal with?  What is used for mail currently?

Hosting currently gave us POP3 mailboxes (this year IMAP) so we use that. Exchange, depending on costs and compatibility, is something Im weighing in but again, a lot of (in home) testing needs to be done.

Keep in mind that from scratch is more than likely going to mean some pain for users, lack of access to files on the nas?  While you join the nas to the new domain and then make sure all the permissions are setup.  Then move the users machines into the domain so they have access.

Yup, it does seem somewhat very painful to do. I would document everything before hand and it is delicate I imagine.

The thing that does easyme somewhat is that the NAS can have its own users/groups. To ease the transision, I would always make local users and have them access this way.

Also would assume some pain with their profiles on their machines?  Now sure how you have those setup now, etc.

Yup, this would also bring potentional "trust" problems with their profile; The other day, the dumbass of myself, had PC1 with W7 to the domain. I made another partition with W8.1 and called it...guess what....PC1. Joined it as well. Went back to the W7 partition and told me there was a trust issue. Had to undomain both partitions with the local admin, remove it from the AD box, redomain the W7, etc. Took a quick minute but solved it. 

But scratch does allow you as you mentioned to document everything, get all the ducks in a row as you add a test machine, etc.

Goddamn you Illinois men have some weird sayings! :laugh:

Anyways, yeah, documenting would be important this way the next guy ( :( ) could always know what to do.

Link to comment
Share on other sites

getting all of your ducks in a row is more american than specific to illinois. 

 

http://www.wisegeek.org/where-did-the-term-get-your-ducks-in-a-row-come-from.htm#didyouknowout

 

as far as local profiles go, there is a utility to map their existing profile to a new user of a new domain...again why I recommend admt, this gets around needing that utility.  but if you must:

http://www.forensit.com/domain-migration.html

Link to comment
Share on other sites

http://demazter.wordpress.com/2010/04/29/migrate-small-business-server-2003-to-exchange-2010-and-windows-2008-r2/

 

I used that to migrate from SBS 2003 R2  to Server 2012 and Exchange 2010 in 2012. Was easy enough and worked just fine.

 

Used Hyper-V in Server 2012 to create a Exchange 2010 VM and installed it on that.

 

So as long as your machine has enough RAM you'll be just fine or just set a new physical machine as the host for Exchange.

 

----

Moved to Server Support

Link to comment
Share on other sites

Hello,

Moved to Server Support

Thank you. I dont know why I posted it in the Network section.

 

 

I'd say scratch as well.

 

Just make sure that the new server's Domain isn't the same name as the old one and you could use the profile transfer wizard: https://www.forensit.com/move-computer.html

 

No worrying about users losing settings then ;).

It would be the same.

About user's settings and such...what settings are we talking about exactly? I know desktop arrangement, wallpaper, etc. all that but besides that?

Link to comment
Share on other sites

If you're coming from a 2003 based environment and have the opportunity to start from scratch, take it - you'll be better off (especially for future upgrades).

If this was coming from a 2008/2008R2 based original deployment then I would look to migrate.

Link to comment
Share on other sites

I wouldn't use the same domain name..  change it up a bit, change the tld or be more descriptive, etc.  This is a good time say use a .lan or .tld that does not match up with public registered domains - this removes any issues with internal and external name resolution.  Maybe you have yourdomain.com for web and use yourdomain.net for internal, etc.

 

As to profiles, possible you loose application settings, bookmarks, etc.  Its not like the anything will get removed the old profile will still be there, etc..  But users can be bitchy -- but my recycle bin icon use to be in the top left corner of the screen, now you have it the bottom left ;)

Link to comment
Share on other sites

Hello,

I wouldn't use the same domain name..  change it up a bit, change the tld or be more descriptive, etc.  This is a good time say use a .lan or .tld that does not match up with public registered domains - this removes any issues with internal and external name resolution.  Maybe you have yourdomain.com for web and use yourdomain.net for internal, etc.

 

As to profiles, possible you loose application settings, bookmarks, etc.  Its not like the anything will get removed the old profile will still be there, etc..  But users can be bitchy -- but my recycle bin icon use to be in the top left corner of the screen, now you have it the bottom left ;)

I wouldnt even know what to change it to.

Lets say our company (this is a example) is named "McDonald Hamburgers". Our website is "mdh.com" Our internal FQDN is currently "mcdonald-hamburgers.local" and use "MCDONALDN" as our domain. Between them, there is currently NO relation between them at all.

Based on that, what do you suggest as a name change?

Link to comment
Share on other sites

Nice that your using .local  -- based on your example I would maybe say do MCDS.local, no reason to have such a long domain name..  or MH.local maybe.  No reason why your internal can not match up with your external, just use different tld like your doing to your internal could be mdh.local as well.

 

But I would make sure that the FQDN and the netbios version of your domain is different while you run them at the same time.

Link to comment
Share on other sites

Hello,

Nice that your using .local  -- based on your example I would maybe say do MCDS.local, no reason to have such a long domain name..  or MH.local maybe.  No reason why your internal can not match up with your external, just use different tld like your doing to your internal could be mdh.local as well.

 

But I would make sure that the FQDN and the netbios version of your domain is different while you run them at the same time.

Well, it seems then that

mdh.com

mdh.local

MDHN

Would be good names :) Short and sweet.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.