new domain controllers, need to keep old IP addresses.

[tehsteve86]

Hi everyone!

 

We have two domain controllers DC-A (2008 SP2) & DC-B (2008 SP2). They appear to have been upgraded a long time ago from from 2003. I can tell this because the domain and forest functional levels are sitting at 2003.

 

Unfortunately, we do not have DHCP running on any of the DCs. It is distributed by our SonicWall. After I get this current problem situated, I will finally get around to setting up DHCP.

 

And this is where my first problem starts. I need to accomplish this task with next to no downtime for my users. Meaning, we have a lot of devices that have their IP addresses configured statically. Unfortunately, the last IT guy bitlocked his system and kept all the documentation on there. I will not be able to reconfigure DNS on them until I do a factory reboot on each

 

This is the reason why I would like two build two domain controllers, promoto FSMO, raise functional levels, and setup DHCP... all while keeping the existing IP addresses of the old ones. Then I will decommission the 2008 after the process is complete.

 

I did a lot of research and put together documentation the best I could.

I'd like this community to look over it and provide any edits and suggestions before I begin. I do have a Veeam-backup in case anything goes wrong, which is ran nighty.

 

 

 

1. Setup the 2012 servers as DCs and DNS with different IPs on the same subnet.

2. Shutdown one of your two 2008 DC/DNS servers (service should still be available due to the secondary DC/DNS server that is still up)

3. Change IP of one of your two 2012 servers to the IP of the server you just shut down

4. Either reboot the 2012 server or, ipconfig /registerdns and restart the netlogon service

 

this is the part I go confused about (below)

---

5. Disconnect shutdown 2008 server from network, change IP and reboot or /registerdns and restart netlogon. (Might as well reboot and reconnect since there should be any service impact.)
Note: Make sure you have the loopback address (127.0.0.1) configured as the last DNS server on the 2008 servers' interface so it can reference itself while disconnected from the network. Which is an MS best practice anyway.

didn't I already shut it down in step 2? I can pull the network cable, power back on, change IP + config loopback, reboot. Is this part correct that is in red?

---

6. Transfer FSMO roles to the 2012 server, give some time to replicate.

7. Demote the 2008 domain controller you've changed (i run DCPromo on itself I am assuming? Will I need to go into my AD structure and manually delete any records?)

8. Raise functional levels of environment.

 

If anyone can edit my documentation and perhaps provide answers to my questions in red, I would be extremely grateful.

Or if there is an easier way to accomplish keeping the same IPs as the old DCs, I would appreciate it too!

Cheers to all! You are a great help!

[sc302 Veteran]

You do not need to do a factory reboot on any of your computers to update dns.  dns is dynamic and gets updated when your computers update the IP's.

 

 

You need to determine a few things. 

 

1. what is the purpose of the statically assigned addresses

2. what is currently in use as far as addresses go

 

You can easily turn up dhcp on the server and disabling on the sonicwall without really effecting anyone provided you do not have overlapping addresses in use.  Otherwise, have everyone turn off their computers at night, disable dhcp on the sonicwall, enable on the server.  When the computers turn on in the morning, they will pull the address from the server not the sonicwall. Enabling dhcp is something really simple to do, you are over complicating it with wanting to create new servers to host the domain just for the sake of being able to bring up dhcp on them...dhcp is not necessary on a domain controller, it is an add on service that can be added at any time...

 

Also what is the point of having the 2012 servers on the same ip of the existing domain controllers...why not have them have their own.  Are you worried about the statics out there?  Leave the 2008 servers continue to be dns servers, then migrate over to the 2012 ips when you have time.  This is not entirely correct: Note: Make sure you have the loopback address (127.0.0.1) configured as the last DNS server on the 2008 servers' interface so it can reference itself while disconnected from the network. Which is an MS best practice anyway. You have a statically assigned address on the nic, it will be able to reference itself when it is not connected to the network if you put in the network ip in the dns field...I have never used 127.0.0.1 on any of my setups (I have created more domain controllers/domains than most people). 

 

As to your #7...just run dcpromo on the server.

[mdnh]

Yup, dns updates dynamically, no worries.

You should make a 'best practice' domain migration to 2012, I don't get the point why you will keep the old IP adresses. Just migrate over, move roles and services and voil

[sc302 Veteran]

Some good reading:

http://blogs.technet.com/b/askpfeplat/archive/2012/09/03/introducing-the-first-windows-server-2012-domain-controller.aspx

 

 

http://support.microsoft.com/kb/324801

 

 

http://www.elmajdal....al_Catalog.aspx

[xendrome]

Yeah this is pretty easy, install DHCP role on the new server, create a DHCP scope that is outside of the existing scope on the Sonicwall, activate it, and then disable the Sonicwall DHCP.

 

As existing DHCP leases are expired they will grab a lease on the new DHCP scope.

 

Then after all of them are in the new scope, you could change the scope back to the Sonicwall scope and they will get back in the range they used to be in.

 

I think that would work and be simple enough.

[tehsteve86]

Let's take DHCP completely out of the equation. I will take care of that in 5 years.

 

I need to rebuilt the DC/DNS servers while keeping the same IP addressing on the new boxes.

 

I am also not allowed to touch the few other devices that are statically configured because lack of security clearance, so I can't set them to update DNS automatically.

 

Third party software will be then installed on the boxes, which are already pre-configured on the firewall with all the good port forwarding stuff.

 

My objective is to keep the same IP addresses.

 

I understand you guys are trying to help me work faster & smarter, but it is vital for me for the IP addresses to stay the same on the new controllers.

 

The new controllers have to be built to meet new GPO policy standards in the organization.

[mdnh]

Why do you need to use the same IPs?

So you need to

- move all roles to old dc #1

- demote and shut down old dc #2

- install new 2012 dc, give same ip adress as old server #2 and migrate domain to 2012r2

- move all roles to new dc #2

- demote and shut down old dc #1

- install new 2012 dc, give same ip adress as old server #1 and finish migrating domain to 2012r2 by distributing roles and services to the dcs and go ahead finishing the migration

[mdnh]

 

I understand you guys are trying to help me work faster & smarter, but it is vital for me for the IP addresses to stay the same on the new controllers.

 

The new controllers have to be built to meet new GPO policy standards in the organization.

So my 'sketched' post is exactly what you need to do.

[tehsteve86]

nyz thank you for your patience and understanding

 

I will follow the decommissioning steps provided here:

https://technet.microsoft.com/en-us/library/cc771844%28v=ws.10%29.aspx

 

I keep running into information about performing a "metadata" cleanup. Is this necessary?

[sc302 Veteran]

So then the hardest part is when to switch over to the new dc's.  Like I said, you can keep your existing 2008 servers in play esp if they have special software....You won't need to completely remove them off of your network.

 

I would leave those servers in play that have applications that are being accessed from the internet, don't know why someone would expose a dc to the internet directly...if that gets compromised do you understand the ramifications of that?  If anything, I would leave them as a secondary dns server.  But if you must remove them, by all means do so.  You will simply have to plan a cut over during a time that is slow to cut over the ip of the dc....any databases or files that are on that server may need to be transferred over or copied over.   It may be worth to clone the server and do a offline direct upgrade to 2012 to see if there would be an issue with the upgrade process vs doing a complete change....this way you can plan for bumps or simply turn off the old one and turn on the new one with little to no down time.

 

 

If done properly you will not need to do a metadata cleanup, but it wouldn't hurt to check things there to make sure that they have been removed.

[tehsteve86]

If the 2008 servers remain in play, then they will have different IP addresses by this time.

 

The client-side software, have the IP they connect to hard-coded into the application.

 

I will have to reload the new servers with the special software one way or another.

 

Everything I do is a triple labor process LOL.

 

Or I can submit a ticket and have it bounced around until everything is properly setup the way it should have been from the beginning. Yeah. Not happening!

[sc302 Veteran]

If the 2008 servers remain in play with dns, the ips do not need to change...

 

The clients would still access the servers as they are now.

 

You would not have to reload the special software on the new servers

 

The difference would be that the new dcs would be authenticating active directory.  dns would still function.  You can plan to change the dns of the secure computers/printers/whatever at your leisure. 

 

The 2008 servers would become member servers of the domain that host an application and dns (it would be a secondary dns server vs the primary AD dns servers)...AD would be offloaded to the new servers.  DNS could then slowly be migrated when you get the people who have authorization to do so at their leisure.  DNS would be replicated to the secondary dns servers in this scenerio.  This would have the least amount of downtime (a reboot) as there will be no downtime while data migration happens and the least amount to configure/reconfigure.

 

 

But you can continue down the path of doing it your way, it is much simpler and far less work the way you see it.  I see it as being more work and has a higher percentage of failure.  When ever you completely migrate off a system, there is a potential to miss something that needs to come over.  If all you are doing is replicating services, then moving services off, there is less of a chance to miss something as all is replicated.

[mdnh]

No worries, it will run better than ever. I had a upgrdaed 2003 server before as well and it caused lots of issues. Btw, keep the software installations on the dcs as low as possible, those guys need to run stable. Good luck!

[+BudMan MVC]

"I will take care of that in 5 years."

 

what??

 

There is little advantage to running dhcp or dns in an AD shop on anything other than the AD.  While I can understand not moving dhcp until your setup is refreshed and clean.  Why would it take 5 years??  This is what jumped out at me from this thread.

 

In general this a pretty straight forward process if you bring a new DC online.. The keep old IP addresses I don't really see how that applies at all.. Why do you think you need to keep them?  And even if you wanted clients to keep their old ones - just export your dhcp leases from whatever your running it on now.  Import it, turn off your old one - turn on the new one, etc.

[binaryzero]

I hope you're going through the correct change management processes your company has - I wouldn't be doing this is 1 session (spread it over a couple of days). I'd also be doing this sort of work outside of business hours to minimise any risk to the users. Your manager should know this and approve you being onsite outside of business hours. 

[mdnh]

Sure thing, this will take some time. Mind the tombstone cycles, double check all, heavily use PowerShell to verify your domain's integrity. I guess these are things he should be aware of already. As of his writing I don't guess he's a noob. Steve, would be nice hearing your efforts, get back to me in case of any question. Best of luck again.

[tehsteve86]

I am doing this right now actually, but ran into an issue

 

The old domain controllers have been properly decomissioned. I see absolutely no errors running health checks. Exchange is running fine. Everything appears normal, but I did run into an issue I can't wrap my head around.

I meticulously went through DCPromo on the old DCs, which didn't throw any errors. And then I removed lingering entires within DNS & AD Sites & Services. I double check this about 10 times.

 

So now I have 1 domain controller on Server2012R2 and it appears to be functioning properly. Here are some stats:

 

C:\Users\administrator.XXX>nltest /dclist:XXX.local
Get list of DCs in domain 'XXX.local' from '\\XXX-DC01.ZZZ.local'.
    XXX-DC01.ZZZ.local [PDC]  [DS] Site: Default-First-Site-Name
The command completed successfully

 

C:\Users\administrator.ORLANE>NetDOM /query FSMO
Schema master               ZZZ-DC01.XXX.local
Domain naming master        ZZZ-DC01.XXX.local
PDC                         ZZZ-DC01.XXX.local
RID pool manager           ZZZ-DC01.XXX.local
Infrastructure master       ZZZ-DC01.XXX.local
The command completed successfully.

 

dcdiag /test:dns ran perfectly fine. No issues. I will spare you the spam.

 

 

... I was just about to build server #2. I joined it to the domain and decided to do an ipconfig/all before giving it a static entry in the network adapter just out of my curiousity.

 

What I came across here, I didn't like what I saw. I'm about to call it a night. I've been looking over everything to find these rogue entries, for the past 3 hours.

 

 

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel® 82574L Gigabit Network Connec
n
   Physical Address. . . . . . . . . : (removed)
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 172.18.3.217(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.248.0
   Lease Obtained. . . . . . . . . . : Saturday, March 21, 2015 11:05:12 PM
   Lease Expires . . . . . . . . . . : Sunday, March 22, 2015 11:05:12 PM
   Default Gateway . . . . . . . . . : 172.18.1.254
   DHCP Server . . . . . . . . . . . : 172.18.1.254
   DNS Servers . . . . . . . . . . . : 172.18.1.89
                                       172.18.1.100
                                       172.18.1.13
   Primary WINS Server . . . . . . . : 172.18.1.89
   Secondary WINS Server . . . . . . : 172.18.1.100
   NetBIOS over Tcpip. . . . . . . . : Enabled

 

 

Sooo.... 172.18.1.89 (old dc)is showing it's ugly face as a DNS & WINS. I have looked for this entry everywhere and coming up empty.

The 172.18.1.13 is an APC element manager that we run. I have no idea how it inserts itself into the DNS list either.

 

As soon as I get DNS displaying correctly when I do an ipconfig /all, I will build the second DC and test replication.

 

Any suggestions would be appreciated. I am almost done!

 

& just to reiterate, there is absolutely nothing to be found in DNS & AD Sites & Services in regards to these IP addresses of 172.18.1.89 & 172.18.1.13.

 

The .100 entry is my domain controller i just built & want to be using.

 

 

Here are other places I check up on.

Logged into the APC Environment Manager & noticed the DNS Entry of the .89 & .100 in there. Only kept .100. Refreshed everything. No change.

[sc302 Veteran]

Make the changes necessary in your dhcp server. That doesn't get changed when you dcpromo out. Manual config in dhcp.

[tehsteve86]

disregard this post!

[tehsteve86]

You sir are a master!

 

I found my issue in SonicWall / Network / DHCP Server / Lease Scopes / DNS&WINS tab!

 

WOOT!

[tehsteve86]

Update 03/22/2015 - 11am est

 

Looks like the rogue DNS entires that came up in ipconfig /all have been cleared. Before I went to bed I decided to "update" a couple static DNS entries on other servers & Xerox printers to show 172.18.1.100 and 172.18.1.101.

The 101 entry is Domain Controller #2 I am building. I figure I will eliminate the .89 altogether due to DC01 being a 100 and I didn't want DC02 to have .89. Just a little pet peeve I have with incrementing adressing lol.

No devices appeared to go down on Network Monitor tools I ran, so that is good

 

As of this moment, I have statically assigned .101 IP address, + subnet, + gateway on my DC02.

I did a ping from another computer on my network to DC02, and it is still showing the old IP address before I statically assigned it.

Though, pinging DC02 from DC01 already shows the correct IP address on the DC02 box.

No big deal, I will just wait for everything to propogate for a bit & if that doesn't work, I can just delete the records from DNS manager, reboot DC02, and then the new records should be there.

However, I don't think I even need to do this since DC01 already resolved DC02 just fine. I'm positive it's just propogation timing at this point.

I need to step away for a few hours because I'm on my way to a baby christening.

After I get back DC02 should be ready to have the AD & DNS roles & features installed. After that completes, I will double check the static DNS addressing of DC01 & DC02 to make sure they are pointing to eachother for correct replication.

 

Tomorrow after work, I will update my VMWare 5.5 Hosts inside the ESXi Network Manager to replace the DC02 DNS entry of .89 (decomissioned) to .101 (new box).

All Hosts are running properly still since the DC01 DNS .100 entry never was changed and doesn't need to be updated.

 

So far this little project is going real smoothly. And most importantly, 0 downtime on the email server which easily pulls in 2GB of emails daily. /wipes forhead.

 

I was planning to shut down the .89 Domain Controller now that is is decomissioned, but I noticed there is somekind of  DynDNS.vb script on it and I haven't figured out what the script actually does.

Because that box went through a DCPromo.exe, it is now just a regular server on the domain, but holds the name of DC-A. No big deal since my Domain Controllers are DC01 & DC02.

I'll check with my director to see what the VBS script does and if he can migrate the script to another location, so I can fully power off .89 (DC-A),

I guess it wouldn't hurt to leave it running, but 1 little script would mean a 40gig server taking up space on storage and it also might cause confusion for other SysAdmins thinking they are connecting to a domain controller lol.

 

That's my update.

 

Next week I plan to setup the DHCP server & then setup the DHCP server on DC02 using the 20/80 rule.

 

 

Original DC-A = 172.18.1.89

Original DC-B = 172.18.1.100

Decomissioned DC-B & powered offline.

Assigned DC-01 address of old DC-B & transferred FSMO roles. DC01 is now my PDC.

Made DC02 = 172.18.1.101 & setup proper roles & features.

Original DC-A, which isn't a DC anymore is still running because of a question I have to my director with a .VBS script.

^ that should help why I still have a box running named DC-A, I know my post might have caused some naming confusion. Sorry for that. It was vital that I keep at least one IP address from the original Domain Conrollers the same.

 

20% of the time was spent building & waiting for Windows Updates on the new DCs.

70% of the time was spent on finding where rogue DNS enties originated from, which turned out to be coming from my SonicWall lol.

10% of the time was spent on proper configuration of the roles and features.

 

 

Cheers everyone!

[mdnh]

Sounds great. Btw, if you run your dhcp servers under server2012r2 you can configure a dhcp failover cluster which is really neat and better than split scope, imho.

https://technet.microsoft.com/en-us/library/hh831385.aspx

[tehsteve86]

That is real neat, I didn't even know about this yet lol. Thank you very much for the info! Do you think split-scope will evenetually be phased out for failover cluster?

 

I looked over the creation of DHCP in DC02 via your link and it looks like the steps are exactly the same as configuring normal DHCP.

I'm a little hesitent at this point because you must "authorize" DC02 before you can move to the next step of configuring the failover cluster.

 

So for a few minutes, both DC01 & DC02 will be both be running the exact same settings. What impact will these few minutes have on my environment? Possible IP conflict/collisions?

 

Real good info!

[mdnh]

It depends on your strategy what to use, a failovercluster is always better if one machine crashes, the other will serve the scopes. You have to authorize dhcp servers anyway, even if you use split scope. It's safe and there should be no impact.

Configure your dhcp server as needed and then make the clustering as described in the link I've posted. It's running rock solid here.

Best of luck.

[tehsteve86]

thanks!

 

So far so good with the Domain Controllers on my end

Running smoothly and AD Replication Status Tool is showing everything successful.

 

I will circle back when I have the failover running. I don't think I will setup separate scopes though.