[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1556
  • Last Modified:

DFS will not work after server restore, new namespace or replication groups fail

Windows Server 2008 R2 with two domain controllers.  DFS was set up and working properly between these servers.  One server had an issue, so we restored it back to an image from 6 days ago.  The image was made just prior to installing DFS Role Services on the server.  So after the restore, we DFS was reinstalled.  Replication is no longer working.  I tried deleting the namespace and the replication group and adding it back from scratch to no avail.

If I create a diagnostic report in DFS Manager, I find the following error for the server that was restored (SHSMASTER)
Cannot access the local WMI repository
Affected replicated folders:  All replicated folders on this server.

For the other server, MASTER2 (not the restored one) it shows this error:
DFS Replication cannot replicate with partner MASTER for replication group Group1.  The partner did not recognize the connection or the replication group configuration.  The DFS Replication service used partner DNS name .....etc.

The other test I ran was adding new namespace.  When I do this, the last step of the wizard produces this error:
\\domain.local\testnamespace: Properties on the namespace cannot be set.  The domain-based namespace was created successfully but is currently unavailable for management due to Active Directory Domain Services replication delays and might not have default parameters configured properly.  This can occur when you create a domain-based namespace from a management console in an un-trusted domain. Please allows some time for Active Directory Domain services replication and refresh the namespace later.


0
pcspcs
Asked:
pcspcs
  • 8
  • 3
1 Solution
 
Neil RussellTechnical Development LeadCommented:
Oh dear! Yet again somebody who restores AD Servers from images. I have one thing to say.....

SYSTEM STATE BACKUPS

You will almost certainly have to trash the server you restored from an image and that wont be all. but its a start.

Never use image backups for AD servers unless they are from like last night AND then they MIGHT work.
0
 
pcspcsAuthor Commented:
Trashing the server is not a good option.  Ideas on how to troubleshoot and resolve this would be welcomed.
0
 
Neil RussellTechnical Development LeadCommented:
You may need to dcpromo to demote it, take it out the domain, add it back in and dcpromo it again. Inbetween those steps you may need to do an AD Clean up on the other server.

Restoreing an AD DC from an image is a no no.... It almost always causes more issues than you can ever hope to solve.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
pcspcsAuthor Commented:
After reading this article: http://exchangeserverpro.com/event-id-2095-and-the-usn-rollback-adventure  I see that I have some serious work to do.

However, I do have a question:  in my case, it would be far easier to do away with DC2 because it was only recently added and there's almost no data on it.  It was pretty much there to be a backup of Active Directory and a secondary DNS server.  Also, there has not been much of any major activity in Active Directory at least it terms of adding or editing users and such in the past 6 days.  So I'm wondering if it would make sense to demote and remove DC2 instead, and then just move forward with the state of AD that's on DC1, the one that was restored from image.

If it matters any, users are still logging in and using DC1 without any problems that I know of at the moment.  Based on the article, I suspect I'd start seeing problems when doing AD functions like adding new users.

Would it be reasonable to demote and then remove DC2 instead, then cleaning up references to it in DNS and Sites and Services?  I could then add a new DC, even naming it something different, like DC3, to avoid any conflicts that might still be around from the old name.  

0
 
pcspcsAuthor Commented:
To be clear, my question now becomes: would I be okay to demote and remove DC2, and use what's current on DC1 (the restored one) as the starting point, adding a new DC to that to become my AD backup?  Rebuilding DC1 would be tough given everything including roaming user profiles are stored there.
0
 
pcspcsAuthor Commented:
I did think of one other option.  These servers are virtual machines and the image I spoke if is actually a snapshot.  We have a snapshot of both DCs taken within one hour of each other 6 days ago right before installing DFS.  I could restore both of them to that point together.  Would that be better?  

There are several other servers on the domain that are not DCs.  They are applicationservers and web servers.  I could copy the shared user files from the DC to one of those before rolling back, using XCOPY to preserve permissions, then copy back after the restore so that no data would be lost.

Would this he a better option?

Advice needed urgently.  Thanks!
0
 
Neil RussellTechnical Development LeadCommented:
The problem with restoring both to a point in time a week ago is that its probable that most if not all workstations will have updated their domain passwords by now and you will have to remove and add again all of those workstations from the domain, and servers of course.

Now how big a task that is depends on how many workstations you have.

Also of course you will lose ALL emails since that week has passed, unless you do seperate exchange backups?

0
 
pcspcsAuthor Commented:
This is a bit of a special-purpose network in that it's only purpose is to host an application that's accessed via a thin-client connection.  It's using Graphon's Go-Global software where connections look similar to an RDP-connected client in that each user does get a profile created (roaming profile).  They don't show up as workstations in AD though since they are remote.  There are no locally-connected workstations.  And users are prevented from changing their passwords, so those won't have changed.  There have been no servers added or removed since the snapshots.  There are two web servers and about 6 application servers that are part of the domain.

When you say that "workstations will have updated their domain passwords" are you talking about the internal password that they maintain in the background to connect to AD?  Would I simply need to remove them from the domain and re-add them?  Will I have any problem removing them through normal means (i.e. set to a workgroup and enter domain admin credentials to allow it to remove) then adding back, all with same name?

Are there any other issues I should be concerned with if I roll both DCs back?  Anything to be concerned about with IIS on the web servers?  It looks like it was actually about 13 days now.
0
 
pcspcsAuthor Commented:
Any other suggestions or answers to the above questions before I give this a try tonight?  I was wondering if it might be helpful to remove the member servers from the domain before taking them down.  That way they won't think they are joined when the two DCs are restored.  Thoughts?
0
 
pcspcsAuthor Commented:
As I think about this more, I have one other idea: what about demoting then removing DC2 from the current domain rather than rolling them both back.  Wouldn't that leave just one server with AD and thus no conflicts?  Then I could add it back?  If this is not a good idea, then I suppose the questions posted above are still applicable?
0
 
pcspcsAuthor Commented:
Everything is back up and running!

Here's what I did:
I started by restoring both DCs to the same point in time from snapshots that were made prior to DFS installation 12 days ago.  This gave me a functioning AD and users could login and authenticate via DC1. I took DC2 down to verify that everything worked with just DC1.  Adding new users to AD worked fine.  I was able to restore data to the data folders from a backup made right before the rollback.

As mentioned, the other servers (non DC) would not authenticate, so I had to remove them from the domain, delete their references in AD, and add them back.  I didn't have workstations on this domain since it's all remote access, so I didn't have to worry about those.

The part that was still not quite right though was AD synchronization between the DCs.  Objects added at DC1 would show up in DC2, but not visa versa.  DCPROMO /Q showed replication errors and referenced invalid rollback - UCN and noted in the article I linked to earlier.

Since DC2 didn't have much on it and was primarily just a secondary AD and DNS server, it was a lot easier to just remove and rebuild this one.  DCPROMO failed to demote it, so I used the manual method then manual metadata cleanup of sites and services, DNS, etc. Then I added the server back to the domain.  The issue persisted, so I decided to just decommission that VM and server name and install a new one, DC3, which was quick and easy since these are just VMs.  This time, using DCPROMO to demote DC2 worked fine.  I think I still found some references in Sites and Services and DNS, so I cleaned those up.  

With DC2 gone, DC3 easily replaced it and replication of AD is working beautifully with user object showing up on both and DNS replicating.  I installed DFS on DC1 and DC3 and now have successful replication there too.

All is well...details are provided here for any help they may provide to others in similar situation.
0

Featured Post

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

  • 8
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now