Win2k Server rejoining domain after long inactivity

A

asuh

Limp Gawd
Joined
Jan 14, 2004
Messages
316
About 6-12 months ago, we decided to shut off the server from our domain because there were connectivity and network issues with this server, but we never disjoined the network. Thus, it still exists as a DC. Since that time, the network has been running pretty well. This network consists of 2 Win2k Active Directory PCs (including this one), about 5 other servers, and about 35-40 clients. So, for the past 6-12 months, we've only had 1 Active Directory server.

The time has come that we want to try to connect the inactive server to the domain after many months of inactivity. Since that time, as well, there have been many new users and computers added through Active Directory.

I would love some advice on the best way to bring this server up such that it would cause the least headaches on our part. The preference would be to just turn the computer on and log in as usual, but knowing that there were problems previously, and the long inactivity since we last used it on the network, what would be the best way of doing this?

I checked all of the FSMO roles and they point to the correct server. The main activity that must occur is the sync of new info from the active AD to the inactive AD. Is it as easy as I'm making it sound like?

Thank you for any info!
 
It should be that simple. Were any of the FSMO roles seized from the old server?

You may want to play it safe and reformat anyways, but I think you'd be OK as long as no roles were seized from the old server.
 
nope, as far as I can remember, no roles were seized. When I checked everything, the roles were all pointing to the correct server.
 
I'm not sure if you can tell afterwards if a role was seized or not.

You clearly don't have any software or data on this server of value, since its been down for 6 months. I say it isn't worth the risk of hosing AD; play it safe with a format & reinstall.
 
Basically just turn the server back on.. Anytime you make a change to AD its gets a new " I think its called UPN number" Basically the ad database with the highest number always wins.. Example you current rev number is 12981 and the number of the turned off server is 1002 ad will see the ad database is not current and it will update the database with all the new info and bring the rev number up to 12981.. So all info will be over written and updated..

Side note if you are worried about the AD server causing problems you have two choices.. Durning off hours make your current AD database read only.. power up old server and that way you know that server will not write anything to AD.. Check AD Repl mon and see if that Dc is up to date.. Make the database read right then done...

Now you cannot just format and reinstall a server unless you or orphaned objects in AD that could cause problems down the line esp if you upgrade to 2003 AD..
Here is a q artice that will tell you how to manually removed object from ad using adsi edit..

http://support.microsoft.com/default.aspx?scid=kb;en-us;230306

I would preform a SS backup on a DC before you do this is case you botch up and need to restore AD.. When you do a SS backup on a Dc gives you the option to back the AD database..
 
if you aren't brave enough to bring the server back online to run dcpromo on it to demote it, then you're going to have to break out ntdsutil and remove the server from AD that way. i would just do as mobilecommand suggested and make sure AD is backed up, bring the server online, demote it, and then you can format and reinstall.
 
I think you people forget its windows were talking about here :p

I would suggest formatting the drive and reinstall the system. Bring a clean install onto the production network.A few hours and its on and running with no possible issues of the old AD database causeing overwrites on the new database.

Consider this. A few hours to install, update, and configure a fresh install with no disruption to the network. or haveing the chnace of your production enviroment going belly up... i know what i would do :D
 
Digital-Vortex said:
I think you people forget its windows were talking about here :p
Click to expand...
either that or we're not blindly bashing windows for the fun of it. the chance of overwriting AD changes that have been made in the last few months is incredibly low. he's got more problems leaving a phantom DC in AD and he needs to get rid of it one way or another. this is something you fail to address in your "slash and burn" approach to the problem. simply reformatting the system and leaving the ghost DC in AD is not an option.

he can either bring the system online and then demote it. or he can format the system and use ntdsutil to remove the DC from AD. personally i would bring the system online and demote it. of course you want to prepare for the worst and make sure you can recover from "the worst."
 
Hey guys, thanks for all your great suggestions!

I realize that I'm getting the same exact opinions from multiple people, thus I hear your messages loud and clear. This being said, I now need to take the next steps.

I think I will not bring the server back into the network, as many people have stated. What I need to figure out is two things:

1. How important is it that I metadata cleanup? There is no critical data on the offline server and it could easily be reloaded now

2. Since this server is still registered in the current domain's server AD and I don't plan to bring it back online to the existing domain, do I need to clean up all of the previous entries of this downed server from the DNS, DHCP, etc or just leave it be? Here's what we were thinking. I'm not sure that bringing back a reloaded version of Win2k Server with the same exact hardware is going to be allowed since this computer was previously already joined to the domain and currently is listed in the DNS and AD. It can't really join the domain twice, can it?

Please send any links about demoting through ntdsutil that you can find because I guess this is gonna be my best option, unless I read a better one.

Thanks for your answers!
 
http://www.petri.co.il/delete_failed_dcs_from_ad.htm

you should definitely remove the DC from AD. if you look ino your event logs on your other DCs you will see a lot of errors. now it seems like nothing is wrong, but you've got a replication topology setup with this DC in it, and your other DCs are constantly trying to find it. i have not come across what the negative effects are aside from the event log entries, but this sort of issues will certainly not make your network function better.

so you need to use ntdsutil. like i said- i'm voting for not using ntdsutil. if you can simply bring the system back online, synch it up, and then demote it i would classify that as the safer option as opposed to using ntdsutil. anyway, the link at the top should help you with ntdsutil if that's the route you want to take. that guy knows is stuff.

btw, you could run ntdsutil on the downed DC first. bring that system up, but unplugged from the network. you'll see your live DCs on that system. as practice try running ntdsutil on there to remove them. the practice/experience will be useful once you need to do it for real.
 
thanks for that link, big daddy. it was very detailed and worked well.

I have gone through all of the steps and now have one problem. After cleaning up the metadata using ntdsutil and then deleting all of the DNS objects, I then went into AD Users and Computers to delete the Domain Controller. When I tried to delete it, it gave me the following message:
The DSA Object Cannot Be Deleted
Click to expand...
This is a problem. If I can't delete it out of Active Directory, I believe this means I cannot repromote it as a domain controller. Any ideas?
 
look at the end of this article:http://www.petri.co.il/fix_unsuccessful_demotion.htm
you may simply need to use adsiedit to complete the removal. the following articles seem to back that up.
http://support.microsoft.com/default.aspx?scid=kb;en-us;318698
http://support.microsoft.com/default.aspx?scid=kb;en-us;328775
http://support.microsoft.com/default.aspx?scid=kb;en-us;216498

if those work for you could you point out exactly which article you followed to succesfully fix the problem. i'm going to need to run through this process myself in the next few weeks. thanks
 
Hey big daddy, the links you provided to me were great! thanks a bunch, all the problems were solved.
 
You must log in or register to reply here.
Back
Top