Migrate or bin the domain controller....

Davek0974

Free Member
Mar 7, 2008
2,633
312
Hertfordshire
I'm working towards an upgrade of our system, gets done every 4-5 years but usually as an upgrade, this time i want to go a bit deeper. Here is our setup...

Esxi5 host running a VM with 2003sbs on it which also runs sql server 7, DC, AD, DNS, file sharing and 32bit printers - this image was created from our original server which was setup in 2004 - 2003sbs was never meant to be virtualised but i managed it and its been running fine, however its getting way old now and needs to go.

We also have a VM with 2008r2 on it which runs desktop sharing and 64bit printers.
There are a couple of legacy XP VM's as well.

I have just finished setting up a test box with Esxi6, one VM running windows 2016 server and sql server 2016, both in demo mode. The idea was to prove that I can create a new SQL server and safely import data form our 2003sbs/sql7 database as well as converse properly with it from our front-end application. Today it passed all my tests and was fairly easy to set up.

So, i need to look at the main system now- upgrade the Esxi5 to 6 then the control centre and client interfaces. Then decide on what to do with the domain controller - It seems they are normally upgraded but here is my question - as this machine/image has been running for so long, it has had many weird and wonderful things done to it - GPO tweaks, installs and so-on, most if not all of which are not relevant anymore. So, should i remove as many connections as possible from the domain then kill the DC box and build a fresh one from the ground up or try an upgrade.????

The new server VM plan is...
w2016 server running DC, AD, DNS, all printers, network antivirus(Trend) & file sharing.
w2016 server running SQL server 2016 alone,
w2008r2 existing server running desktop sharing alone.
Win10 for my main workstation.

I have 20 users, mostly on Wyse thin-clients, so not many user accounts to set up, DHCP is currently handled by our router but we are mostly static IP's.

Any mega pit-falls here??
 
So, should i remove as many connections as possible from the domain then kill the DC box and build a fresh one from the ground up or try an upgrade.????

You could you build domain controller on 2016 and add as secondary domain controller, let it sync and them promote as primary as well as all the FSMO roles.. Once completed, if needs be increase the domain level from 2003 to required level.

The new server VM plan is...
w2016 server running DC, AD, DNS, all printers, network antivirus(Trend) & file sharing.
w2016 server running SQL server 2016 alone,
w2008r2 existing server running desktop sharing alone.
Win10 for my main workstation.

Best practice is to keep the DC clean with minimal roles like DNS, DHCP.
Build Admin Server for things like Network Antivirus, fire sharing etc..

One question though, what is your backup/DR strategy when the brown stuff hits the rotating blades?
 
Upvote 0
Thanks
so if a secondary DC syncs, does it keep all the GPO junk in the main DC - we most likely could do with getting rid of this now.

Current domain/forest level is 2000

So its ok to have the DC do DNS, DHCP but thats about it?
Sounds reasonable, will only be a small footprint VM then

For backup we use Veeam backup and recovery - it creates mountable backups and also, being virtualised means in a full loss scenario we only need a bare server box, a copy of Esxi and i could be back up in about an hour of getting the new server. The backups are stored on and off-site daily on a 5 day rotation.
 
Upvote 0
so if a secondary DC syncs, does it keep all the GPO junk in the main DC - we most likely could do with getting rid of this now.

Yes GPO will re-sync..

Thinking about it more and not so many users (20), it does the beg the question is better to start over or migrated.. If it was me and if all users are in the same location, then I would go with fresh DC and start over..
So its ok to have the DC do DNS, DHCP but thats about it?
Yes, I personally class these as core services roles, especially if you want to bring the DHCP from your router so DNS & DHCP are under one roof..
Sounds reasonable, will only be a small footprint VM then

DC would not have to be a large VM probably 2 x vCPU and 2GB RAM..
For backup we use Veeam backup and recovery -

Coolio, Backup & DR taken care off..
 
Upvote 0
Sounds good.

I favour the fresh start approach - not many user accounts to set up and will cut away any dead wood.

Can the server be set up on the domain as a member and then after killing the old DC, be promoted to DC? I'll have to read up on that.

I've started moving file sharing away from the existing DC onto a blank 2008r2 VM as an interim measure, there are a lot of things to test here.
 
Upvote 0
Correction - i have stooped that exercise as it was fruitless unless we stay with it as 2008r2 - i gather that is pointless?

Pity as i like 2008 a lot :)

Seems there is no easy path from 2008 to 2016 so it would mean doing it all again soon, I will leave it where it is for the moment.

To go any further I need to upgrade our Esxi Hypervisor version, that i need to get some help on i think.

Then we need to get activation licenses for 2016 - we have tons of 2008 and 2012 codes but no further :(
 
Upvote 0
Thanks - that's a leap into the unknown for me ;)

Not sure what to do at present - we have oodles of activation codes for 2008r2, but its an old system again. We have codes for 2012 but our hypervisor will not take it without upgrade.

I cant upgrade the hypervisor until i get a support contract sorted again, its a risky upgrade an i have never done it so will need walking through i feel.

Budget is restricted of course.

Cheapest option is to go all 2008r2 but although that is very cheap, it only advances us 5 years from our 2003 box - worth the hassle??? I like 2008r2, for me its a good OS as it does not have the childish mobile-web feel and look of 2016, but then again i'm a dinosaur :)

Scratching my head at present.

What would you guys do?
 
Upvote 0
2008 R2 mainstream support has ended, but security updates will continue to 14th Jan 2020. 2012 R2 mainstream support will end next year on 9th October but security updates will continue 2023.

It depends on your refresh lifecycle. If you going to need security updates until 2023 then go with 2012 R2.

As I do prefer clean desktop, but saying that most of my time is spend writing scripts & code, but do appreciate clean start menu like 2003 & 2008.

Have you ever consider using Hyper-V instead of VMware ESXI? However, I do perfer ESXI to hyper-V has being bare-metal hypervisor, but cost would be cheaper as it is just Windows Server..

For a small amount of users, have you consider moving the machines in to the cloud, to see if overall it would be more cost effective in the long run without hardware maintenance, running cost etc.. Food for thought..
 
Upvote 0
Thanks
We looked at cloud but our main use is SQL access from our front end - the lag involved in cloud use made that a non-starter for us.

We had a lengthy chat yesterday and here is what i am working towards (based on being budget restricted) - move everything up to at least 2008r2 - this will get us onto a level playing field and fully into 64bit territory. The extended support until 2020 will be ok as by that time our server hardware will be due for replacement so a full upgrade can then be made on fresh clean hardware.

In working towards killing off the 2003sbs VM, I have since spun up a copy of 2008r2 for user file and printer sharing tasks, another copy for the sql database server, and eventually another one to take the role of DC, AD, DNS, DHCP - I am going for a fresh build on this, not the upgrade.

All this is being done on our existing Esxi setup - as i am using thin provisioned disks now they are not taking much space - so far its going well. I would not leave VMWare yet as we are paid up on licensing/support and also on Veeam Backup etc.

Its not a brilliant solution but it is 5 years more advanced, I know 2008r2 reasonably well, its stable and apart from £2k on SQL licenses its free :) The good thing is that the licenses will work on newer versions when we do the next jump.
 
Upvote 0
We looked at cloud but our main use is SQL access from our front end - the lag involved in cloud use made that a non-starter for us.

That I can understand, even with using solutions to help with performance are available, but that would then start adding to the bill pricing out the cloud option.

Sounds like your got your plan sorted now which meets your business requirements & budget.
 
  • Like
Reactions: Davek0974
Upvote 0
Yeah, as i said, it's not a brilliant plan but getting rid of the 2003sbs image is my main target and as you said, it fits the budget.

Setting up sql2008r2 now, will be testing import and connectivity later on. :)
 
Upvote 0
Yeah, as i said, it's not a brilliant plan

I always say, don't question the methods, question the results..

It makes me cringe sometimes when people say to me you need the latest and greatest.. No, unless there is specific feature or function that prevents the job getting done. As long has it is reliable, secure (with updates available) and gets the job done what more is needed.

I've been around that latest and greatest usually has more problems than previous versions...
 
  • Like
Reactions: Davek0974
Upvote 0
I have read all the previous posts and understand the thinking and the challenges. I do think you could move the whole lot to a VMWare private cloud environment and remove the headache of maintaining hardware, software upgrades and everything. My company could build you a completely private virtualised cloud that would allow you create your VM's in whatever you need. You could then shift everyone to session based computing and access the SQL server as if it was next you. We have clients doing this right now and they have never looked back.
 
Upvote 0
SQL access from our front end - the lag involved in cloud use made that a non-starter for us.

All that MS gobblygook means very little to me but, as above, as the users are on thin clients anyway, so assume the desktop is vitualised, where is the lag?
 
Upvote 0
The lag would be in the internet connection - its average at best :(

Question - if we were cloud based with thin clients, how do things like printers, credit card terminals etc connect?
 
Upvote 0
We have many sites with moderate broadband and cloud desktops work fine.

Remote Desktop Services detects local printers, card machines, smart cards and they work just fine.
 
Upvote 0
Thanks all but i think we'll stick with physical servers for now mot cloud.

New domain controller - is it ok to set it up on an isolated network, install the required roles and features etc, setup DHCP pool and so-on, then remove as much as possible from the existing domain, kill the DC and connect the new one, then start reconnecting clients?

As it's a fresh-build DC, should i give the domain a new name to save hassle, presumably the old name will be tied to things which may not exist anymore on the new box?

We now have the sql server up and running on its own server image, all tests passed and i am nearly done removing all workload from the old system.

Backup plans are running in test-phase, all seems good so far.

One more thing - what OS would make a good replacement for my desktop? I really have a dislike of win10 ;) I could use 2008r2 I guess?
 
Upvote 0
In the end, i set the new DC up as an isolated image, all DC roles are up and running apart from DHCP which i'll add after install on the network.

Spent the day adding/editing user accounts and grappling with Group Policy which controls desktop redirection for our RD users - I must admit that Group Policy is far easier to play with on 2008r2 compared to 2003sbs.

Hopefully, if it went as well as i think it did, i should be able to remove the users from the live domain, kill it off, connect up and add them to the new one.
 
Upvote 0
@EmC007 as if you have been around a while you will know @Davek0974 is the sort of guy that wants to touch his technology.

100% correct, very astute of you :)

I have a general dislike of cloud, it fits well for some uses but I still prefer knowing exactly where my data is all of the time and if it fails then its only my fault. Maybe one day but i doubt it :)

Everything is in place now, dealing with licensing etc at present. Just about ready to roll out but i'm off next week so will delay it until i return.
 
Upvote 0
Just getting back to this after a break for normal work :(

Is it possible to have two domains on the same network?

i.e.
Network 192.168.1.xxx
Domain controller1 / Domain1
Domain controller 2 / Domain2

Currently all pc's are on DC1, DC2 is ready to go but not connected, I was thinking of connecting up DC2 to the network, then instead of moving the pc's to a workgroup, killing DC1 and starting DC2 and connecting the pc's to it, to just swing the pc's from DC1 to DC2.

DHCP is not configured yet as that is still handled by our router.

DNS will need altering on the users but that's do-able, I am just unsure if disconnecting from the domain will delete netwrok printer connections etc - I could really do without this happening.

Is that possible / logical / sensible......
 
Upvote 0
Hmmph...

I thought i'd be smart and plug in the new DC, build a two-way trust from the old domain to the new one, then start migrating my users over one by one.

Of course trusts are not supported on the old server - w2003sbs :(:mad:

Anyone got an idea how i can make this switch painless?

Dave
 
Upvote 0
Update and closure...

Old DC is finally turned off:)

Changeover was a bi*ch though, plenty of snags with sql server and login details, just a few final adjustments to do and i think thats job done.

Today was probably the worst I've had for some time, 5am start as that's the only quiet period apart from weekends. Must remember to enable the sql server [sa] account and turn on sql authentication next time ;) Logins were a pain, for some reason remote desktop users were not being assigned rights to login remotely - go figure :rolleyes: So that really threw me off course for a few hours, a few tweaks to security groups and a reboot finally fixed it and everyone was finally allowed back on:)

One tip to others doing a domain controller change without migrating - even if you recreate the user accounts with matching names and passwords on the new domain controller, all users will be assigned a new, default windows user experience when they first login! Sounds unimportant but things like email settings and data, user documents etc are all left behind and can be a serious PITA to recover into the new account.


Thanks to all that helped, much appreciated.
 
Upvote 0
Changeover was a bi*ch though, plenty of snags with sql server and login details, just a few final adjustments to do and i think thats job done.

Today was probably the worst I've had for some time, 5am start as that's the only quiet period apart from weekends. Must remember to enable the sql server [sa] account and turn on sql authentication next time ;) Logins were a pain, for some reason remote desktop users were not being assigned rights to login remotely - go figure :rolleyes: So that really threw me off course for a few hours, a few tweaks to security groups and a reboot finally fixed it and everyone was finally allowed back on:)

And exactly what part of this painful process is better than using cloud services? Even with a relatively thin Internet connection you could have migrated to Office 365 with cloud SQL (if you still needed it over and above SharePoint), saved a ton of cash and many headaches.

If you don't trust the advertising you can trial Office 365 for free, then once you see what you can do, run in parallel until cut over.

Be more gentle on yourself :)
 
Upvote 0
Hmmm, but we don't use any office products, just a custom written front-end to a sql database plus reporting with crystal reports and a few other little apps. We are not your average office environment.

At the end of the day, it was was painful but have learnt a hell of a lot about domain controllers and servers in general, will we need to do it again? Doubtful, probably never.

I still prefer this to cloud ;)
 
Upvote 0
Hmmm, but we don't use any office products, just a custom written front-end to a sql database plus reporting with crystal reports and a few other little apps. We are not your average office environment.

At the end of the day, it was was painful but have learnt a hell of a lot about domain controllers and servers in general, will we need to do it again? Doubtful, probably never.

I still prefer this to cloud ;)

Okay. You're obviously a different breed to me. I prefer simpler, more secure solutions, and I promise I won't try to persuade you to my way of thinking.;)

It is worth pointing out though that the perception of Office 365 being just something to do with Office products is false. MS do market it that way, probably because that is what most buyers want. However, Office 365 is as much infrastructure as it is applications.

Office 365 is file storage - no need for your own server(s)
It is email - no need for your own or remote mail server(s)
It is database - SharePoint online is the biggest database you can imaging - no need for SQL server
It is collaboration - no need for a local area network
It is security and control - no need for local Active Directory - users only have access to files and folders that have been shared with them

And all that is available on an Office 365 E1 licence for £5 per user per month

Please note: I do not sell Office 365 or any other Microsoft product, I just offer solutions
 
Upvote 0
But Dave has a 'legacy' bespoke system with client based front end and client based crystal reports and and an sql database that performs his required business functions.

The only easy component to 'put in the cloud' from an infrastructure view point would be the sql database, but there is likely zero value add in doing so.

Presumably the current business systems are operationally suitable so therefore there are no plans to re-engineer. If there were such plans, it should start from a business process engineering point to design the best operating model, then move down to the business application architecture and then the implementation architecture, doing that today may well end up with a bespoke set of web apps and a cloud infrastructure - but to suggest that O365 is a good target platform without going through the stages is pure speculation.
 
  • Like
Reactions: Davek0974
Upvote 0
Having been involved in and led more business system migrations than I care to remember -

Changeover was a bi*ch though, plenty of snags with sql server and login details, just a few final adjustments to do and i think thats job done.

Today was probably the worst I've had for some time, 5am start as that's the only quiet period apart from weekends. Must remember to enable the sql server [sa] account and turn on sql authentication next time ;) Logins were a pain, for some reason remote desktop users were not being assigned rights to login remotely - go figure :rolleyes: So that really threw me off course for a few hours, a few tweaks to security groups and a reboot finally fixed it and everyone was finally allowed back on:)

has to be a good place to start to examine the business case for change. Enduring pain and expense for the simple reason that 'it's always been done that way' is not a good recommendation.
 
Upvote 0
Not necessarily - I think the lesson here is not to replace a domain controller with brute-force!

It would have been far easier if we had migrated from old to new but due to the state of the old one this was not a good idea so we had to just deal with it.

Job done now and all are happy.
 
Upvote 0

Latest Articles