- Tue, May 26 2020 at 1:29 am #1556317
For various reasons a OU branch with a DC has to be disconnected from the rest of the forest and keep it isolated (without Internet connection)
We know the implications of losing the trust between the DC of this branch and the rest of DCs. However, I would like to know a couple of things:
– Does this have any other implications for the branch to keep on working for let´s say 2-3 months? All local hyper-v and virtual machines will keep on working? Can we update manually uploading to the local WSUS Server all Windows updates?
– What would be the procedure to bring this branch back to the forest? Restore the trust first of the DC to the rest of DCs? Will that restore the trust for each server within the OU or we do have to do it manually for each server?
Anything else we should take into account?
I have searched around but I haven´t found anything relevant
- Tue, May 26 2020 at 3:17 am #1556318
There are various things that will happen. Your DC will loose a connection to the FSMO masters, like PDC and RID. If a user in the branch office changes his password it will be changed on that local DC, but not replicated elsewhere. This will lead to conflicts etc.
If you have sites correctly in AD, your local server/PC will change its password to your local DC. But this will not be replicated again and will lead to conflicts. Losing a domain trust is a single computer issue, restoring one does not restore any other.
Im not really sure what all things could happen, but if you need something like this to be working, my best practice advice would be to setup a separate domain, which will be isolated and everything can work flawlessly there. Then you can setup trusts between the domains to access resources in each other.
- Tue, May 26 2020 at 3:46 am #1556319
Many thanks for answering so quickly!
The issue here is that the OU will get back to the domain after 2-3 months, so creating a different domain and make them to trust each other is not on the table.
The issue here is that the servers are being relocated to a new site that has to be finished. We are thinking of two choices here:
- Keep the machines turned off until the OU can be connected and restore trust.
- Turn them on (that´s why the question arised) as soon as we are able to have the new data center ready even when IS NOT connected to the rest of the OUs of our domain. The idea is to turn them on from time to time to apply manually WSUS updates.
From my point of view I´d choose the first option but we are pondering the benefits of installing critical updates, that´s when we think of the second choice and its drawbacks.
Does it make sense now?
- Fri, May 29 2020 at 5:37 am #1556390
Sorry for late reply.
I have never tried what you describe, but theoretically I would say to following.
- Create a site in AD for that branch, specify a DC for this site. This should ensure that all servers in that site would communicate with the site DC.
- Once the internet is down, if a computer requests to change its password, it should be done against the local DC and should succeed. This should ensure the secure channel to the domain is OK.
- All local changes will not be replicated to other DCs. If there is no change for that object on different DCs, once the line is back, the local DC should replicate the changes up.
For the computer account password change of the DC itself, I would assume, that the change will occur on the local machine and will be also written to the AD object on that local DC. But it will not get replicated to other DCs. So after longer period of time, that DC can be out of sync with the domain, and once you recover the line, you would need to reset it. But that should not affect the other servers, as they successfully changed its password against the local DC.
As I said, never tried. It might not work that way, but I would assume it should.
If you care only about your local servers password change issue, your other option is to disable the password change for those servers in registry. Google it out, its and easy fix.
Hope that helps at least a bit.
- Thu, Jun 4 2020 at 10:35 am #1556485
how did you handle your topic in the end? 🙂
- Thu, Jun 4 2020 at 10:49 am #1556488
Thank you for getting back! We haven´t turned on the servers yet. Hopefully everything will go fine as you said 🙂
- Thu, Jun 4 2020 at 10:57 am #1556490
Worst case you will have to reset the secure channel which can be easily done by Powershell.
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
and providing proper account.
Your welcome, let us know how did it go when your back .)
- You must be logged in to reply to this topic.