-2

I have a remote DC that has been unable to completely replicate AD for at least 90 days so has been tombstoned, had their site-to-site link severed, and has been purged from the organization's main AD infrastructure. This is fine, we do not wish to fix this or bring their now-local AD back into the fold; the office will move forward as its own separate AD office. We were in the middle of preparing for an AD migration when their link to the rest of AD failed, however no changes were made yet.

Currently, none of the domain admin credentials that we have work on that DC. I have 5 different domain admins who swear they know their password, and know what their password was the last time AD replicated successfully. None of us are able to log in, nor can we use the master Enterprise Admin account, which is a password that has definitely not changed between when everything was working correctly and now.

It is not possible that all our domain admins do not remember their password. The passwords do not have an expiry on them, and it is not that we're being forced to change our password, the local DC just thinks they're wrong. The local admin says he hasn't done anything to their DC while we were working on preparing for the AD migration, and his account only had administrative rights over their users and their OU so he shouldn't have been able to change any of our passwords or anything similar.

So how could this have happened? Does booting into DSRM on a DC do something to all domain admin accounts if you bung it up? AKA, did our local guy try to take matters into his own hands and break something? Is it possible that the server was compromised in some way that would cause this?

The only other server on-site is a domain joined file server which local administrator credentials still work to access, so it isn't a huge problem.

The existing DC is Server 2008 R2 as is the existing file server, and all computers in the office are on fully updated Windows 7 machines.

Further relevant details: We have one global domain in our forest that has remote domain controllers in multiple offices, each office is an AD site. One of those offices is separating from our global infrastructure. Before we could properly migrate them out of our domain, their ISP collapsed and their internet connection was lost. Since that site is not coming back to our control, it was removed from the domain. To assist with them migrating to their own domain we were going to run ADMT, but since their local DC cannot be authenticated against with admin rights, we cannot run ADMT.

User profiles are workstation local with a home drive stored on the file server which we have administrator access to, so manually moving data is an option.

I have several thoughts/questions about how to proceed:

  1. I can restore their site and DC and go through the whole un-tombstoning process, but this is a significant amount of work just to get them to a point where we can remove them from AD again.
  2. We can scrap their entire local AD and get them to deploy a new one, and migrate all the computers to a new environment, but this is also a significant amount of work.
  3. If we decide to go with option 2 our biggest concern will be getting user profiles migrated from the current AD to the new one. Is there a tool that can assist with this given that administrative access to the current domain is non-existent? Or is this basically going to just be, create the new AD, join the PC, initialize the new user profile and copy data from the old profile to the new one and reconfigure accounts?
  4. Is there a better way of doing this that I'm not thinking of? All the tools I know of to assist with something like this require administrative access to the source AD.
  • You're sure the PC's at that location are using the local AD server, and not a remote AD server? – longneck Jun 29 '16 at 16:30
  • Why are you trying to access an orphaned DC? Consider it dead and gone and move on with your life. – HopelessN00b Jun 29 '16 at 16:40
  • @longneck yes, all PCs are connected to the local DC. – RobbieCrash Jun 29 '16 at 16:41
  • 2
    Create a new DC for that site, and set it up right this time, rather than trying to fix the tombstoned one. Tombstoning is Active Directory's way of saying "you've been so fucked up for so long that you're dead to me". – HopelessN00b Jun 29 '16 at 16:51
  • 2
    Specifically, even with a healthy DC, Microsoft does not support pruning or grafting of DCs out of, or into, other domains. You can do a trust, and you can do a migration, but you can't merge or split domains. – mfinni Jun 29 '16 at 18:10
0

This is out of the realm of what you'll be able to fix yourself.

As I see it, you have two options:

  1. Open a support ticket with Microsoft. If you don't have an existing support agreement, you'll have to pay.
  2. Your option 2: scrap their entire local AD.

The cost of option 2 in terms of downtime, lost productivity and IT time probably dwarfs the cost of option 1.

  • Option 2 : for workstation migration, USMT would do it but it needs access to the old domain, IIRC. It might be able to get the job done if you have a known local administrator password for all workstations. – mfinni Jun 29 '16 at 18:09
  • If we were interested in rejoining the site to our global AD, I'd open the ticket with MS, or just go through that process by hand, but we're not wanting to do that. @mfinni they have the local admin accounts for all computers there, just no AD admin accounts. – RobbieCrash Jun 29 '16 at 18:43
  • Well, that's a horse of a different color. I didn't realize you DON'T want it connected to the global domain. So you want a completely separate forest? – longneck Jun 29 '16 at 18:44
  • @longneck I really don't actually care that much how the office operates going forward as they're not going to be under our control/responsibility anymore. As far as I'm concerned, they're out of our infrastructure and the way they proceed is not my problem. We just need to help get them to a point where their local admins can do their job, and make sure their users are able to work as well. If things had gone well, we would've ran ADMT and given them full control of their new domain/forest/whatever they wanted, and said good bye. – RobbieCrash Jun 29 '16 at 19:24
  • Then usmt is perfect. You can collect the state to the c: drive of the user's computer, join the computer to a new domain, and then log in as the user on the new domain and apply the state. – longneck Jun 29 '16 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.