So using the catch all this went very well. If you plan ahead a little your biggest group of servers and desktops can be left in your catch all site.
Things I learned: Go slow, that was unquestionably what went wrong the first time I did it. DNS will need some help, it just doesn’t clean up quick enough on its own. I needed to delete a few SRV entries after moving DC’s to their new sites. They created their new entries just fine. Clients will take a bit to figure out they are in a new site. They actually store their current site in the registry. HKLM\software\microsoft\windows\currentversion\group policy\State\Machine\Site-Name Windows 10 does not like changes to its Site at all. Just taking a DC out of the site if it was using it can make it go wonky. Temp profiles, long logon’s. It takes a few reboots for it to calm down. DCDiag, repadmin /kcc repadmin /syncall and Echo “%logonserver%” are your friends. Restarting FRS after moving DC’s between sites is a good idea. From: [email protected] [mailto:[email protected]] On Behalf Of Kennedy, Jim Sent: Monday, March 21, 2016 4:21 PM To: [email protected] Subject: [NTSysADM] RE: Help a AD Sites Noob out. This looks like a killer migration strategy Bonnie. 10.0.0.0/8 on my current primary site. Then carve out a site and subnet at a time. And next week is spring break, I can test on a building that isn’t even in use. “ When overlapping IP subnets exist in Active Directory, the IP subnet with the smallest matching subnet mask is used.” https://technet.microsoft.com/en-us/magazine/2009.06.subnets.aspx From: [email protected] [mailto:[email protected]] On Behalf Of Miller Bonnie L. Sent: Friday, March 18, 2016 10:14 AM To: [email protected] Subject: [NTSysADM] RE: Help a AD Sites Noob out. We used to have to control a lot with ADS&S with a hub-and-spoke topology as well, and what you can do depends on whether your infrastructure can actually communicate fully with all of the available DCs, or if clients in some sites can’t actually talk to others due to filtering. This looks pretty good at explaining some of it: http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ So, if your client machines can’t actually talk to all DCs, they you’ll need to create your own site links and not use the bridging. If your clients CAN actually talk to all of the DCs, then you may be looking at some other underlying problem with AD replication, DNS, or even just timing of doing it all too quickly for the clients (including servers like Exchange) to get the updated information they need. Exchange in particular uses the Microsoft Exchange Active Directory Topology Service to find DCs, so could just need a restart to get updated once the new site information is online—Someone else (MBS?) might have better info on that process. If I was recreating sites right now, I would create the site, create the links, and move the DC object. Then, wait for AD & DNS to fully replicate (and verify replication is working and srv records are showing up correctly) out before reassigning subnets, so that you know clients will be able to get their DC locator information from DNS correctly. Of course at this point, just one site to start with, and watch for Auth services like Exchange as you go =) -Bonnie From: [email protected] [mailto:[email protected]] On Behalf Of Kennedy, Jim Sent: Friday, March 18, 2016 6:40 AM To: [email protected] Subject: [NTSysADM] RE: Help a AD Sites Noob out. Had all of them in the same Default IP site link. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Coleman, Hunter Sent: Friday, March 18, 2016 9:36 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] RE: Help a AD Sites Noob out. Did you create the site links? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kennedy, Jim Sent: Friday, March 18, 2016 7:11 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Help a AD Sites Noob out. Never paid much attention to sites, but now I am going to. I have 12 buildings with dedicated gig fiber back to one of them were the data center is housed. Not a lot of traffic, 10 to 15 percent tops. So never worked with sites to control replication or logon traffic. But now I have a piece of software that is doing a fair number of GC lookups and it would seem that my desktops have decided over the years to all talk to one DC. There are DC’s in each of the five buildings, the 7 smaller ones do not have one. There are currently two all-encompassing subnets, in one site with all the DC’s in that site. So yesterday I decided to make sites. Put in all the subnets for all the buildings, and created 5 sites each with at least one DC, and put the appropriate subnet’s in those sites. It went ugly really fast. Authentication broke enterprise wide, Exchange couldn’t auth and stopped working. For the most part if it involved auth it broke. Nuke the sites and subnets and moved it all back to two /16’s in one site and in about 30 minutes all was well. What did I do wrong?
