Well there were two possible cases. The first is reload in place. This is where you take a DC and reload the OS that was on it with a newer version of the OS and repromote. We had an automated load process that once the image was copied to the DCs spare disk it would take about an hour or so to rebuild into a new DC and then the DCPromo time would vary based on whether you could use IFM or not. A non-IFM promo could take hours and hours of course depending on the WAN Line. An IFM would be relatively quick.
The second is actual replacement of a machine. In this case, a machine would be loaded next to an existing machine with a name of oldnameB. Then when ready for promo, the old machine would be demoted, renamed to oldnameC, and shut down, new machine would be renamed and reIPed and then promoted. Again, depending on promo method, time could vary. An alternate to this is just to load the new machine after the old one has been renamed, a complete server build only took 30-60 minutes this includes getting all of the third party software, etc into place as it was all automated/scripted. If you use the same IP address, name resolution is in good shape with the exception of the registration of the new GUID host record which needs to be replicated which shouldn't be an issue. If the IPs aren't the same then you have to wait for name resolution replication for the new HOST records and WINS (only if you require it). Other than that, the biggest issue would be SPNs which really isn't anything big, that is normal replication and should be fine relatively quickly. There was a point in the very early days of 2K (August 2000 or so) when we were deploying something like 15 or so DCs a day and there was an issue in a script that produced the sites/site links and the DCs SPNs weren't properly updated in the main AD. I ran into that one afternoon around 1PM on the day I was supposed to go on a vacation. I crashed on it and figured out the SPNs weren't in sync and manually synced them and everything was fine and I went on vacation that evening after 6PM and came back in a week and wrote it up for MS. I have never seen that issue again, not sure if I have just been luckier or MS changed something with how the SPNs are set. If the demotion of the original DC didn't go well (or failed outright) you need to clean up the objects in the AD and then let them replicate around, in that case I wouldn't wait any longer than my replication latency for a domain (which in the largest domain of 100 or so DCs was maybe 45 minutes under 2K and about 15-20 for K3). The only serious issue I have ever really had with changing DCs out was with dumb applications that were hard coded to point at specific DCs. With those, the application owner had to get the buy-in from the Enterprise Admins to ACCEPT the hard coded requirement. I.E. If someone just did it and the DC went down or was being worked on, it was on the app owners head, not the domain admins. Otherwise the app owner needed to find a way to make their app auto failover properly or they had to fail it over themselves when something was changed or failed. I went into several "we are going to kick your butt" meetings over that point and we always won the arguments. The Enterprise Admins can not be responsible for every half assed attempt at anyone using the Domains. The only hard coded requirement that we had accepted as a responsibility while I was there handling Ops was for the ADC for Exchange and that was with a distinct limited time frame with a defined End of Life. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M. Sent: Tuesday, December 20, 2005 6:45 AM To: [email protected] Subject: RE: [ActiveDir] Reducing number of Global Catalogs Hi joe, If it's not too much trouble, could you list the steps you take (including wait times) to replace a DC with the same name? I am especially interested in how long a particularly named DC would not be available to the AD audience. Thanks! Mike Thommes -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, December 19, 2005 9:43 PM To: [email protected] Subject: RE: [ActiveDir] Reducing number of Global Catalogs What kind of issues did you have Mark? I have replaced literally hundreds of DCs and maintained the names and have had no issues over the years. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris Sent: Thursday, December 15, 2005 1:06 PM To: ActiveDir.org Subject: Re: [ActiveDir] Reducing number of Global Catalogs Have fun, I have had some great experiences reusing DC names. -----Original Message----- From: "Simpsen, Paul A. \(HSC\)" <[EMAIL PROTECTED]> Date: Thu, 15 Dec 2005 09:48:53 To:<[email protected]> Subject: RE: [ActiveDir] Reducing number of Global Catalogs No we are sticking with the same names and so far we have had no issues. I make sure all records referring to the DC are removed before renaming the new machine and running dcpromo. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris Sent: Wednesday, December 14, 2005 5:39 PM To: ActiveDir.org Subject: Re: [ActiveDir] Reducing number of Global Catalogs Are you going to use new netbios names for the DC's ?. -----Original Message----- From: "Simpsen, Paul A. \(HSC\)" <[EMAIL PROTECTED]> Date: Wed, 14 Dec 2005 16:07:52 To:<[email protected]> Subject: RE: [ActiveDir] Reducing number of Global Catalogs Appreciate the input, it verified what I had thought. But when I started seeing if single domain, etc. well I had to ask. And yes refreshing = dcpromo out and dcpromo on new HW. Thanks Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Wednesday, December 14, 2005 2:15 PM To: [email protected] Subject: RE: [ActiveDir] Reducing number of Global Catalogs The IM is a domain FSMO role. SO the only concern is WITHIN the domain.... No matter what forest structure you have for each domain the following applies: * If all DCs in a domain are GC, there is no other choice where to put the IM. So no issue here * If at least other DCs in a domain (besides the IM) are not a GC, then the IM should not be on a GC your method will work as long as the last DC, that is not a GC, being refreshed (do you mean re-installed?) is also the IM cheers Jorge From: [EMAIL PROTECTED] on behalf of Simpsen, Paul A. (HSC) Sent: Wed 12/14/2005 8:09 PM To: [email protected] Subject: RE: [ActiveDir] Reducing number of Global Catalogs Let me ask if there is any issue with IM if all your DCs are GCs in your domain, which is a child, but not all the DCs in the forest are GCs? We have been refreshing our DCs and making all GCs but the IM is running on the last one to refresh which is not a GC. We plan on transferring this role to a GC while we refreshing the DC it currently resides on. It will be a GC when finished. Should I/we rethink this? We are at function level 2003. Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 10:47 AM To: [email protected] Subject: RE: [ActiveDir] Reducing number of Global Catalogs Really, how so? I 'solve' it by insisting that all DCs be GCs. neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 14 December 2005 16:15 To: [email protected] Subject: Re: [ActiveDir] Reducing number of Global Catalogs The issue with IM on GCs is solved in Windows 2003 for multi-domain forests... Chuck PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
