Solved

Corrupt AD database

Posted on 2014-10-06
5
104 Views
Last Modified: 2014-10-06
Ok so here's the deal. We have a corrupt DC, but I cannot simply demote it because a previous admin put Exchange on it. I've worked with Microsoft and the safest method to resolve this is to move Exchange to a new VM. This is not an easy process since we don't run a DAG, but is in the planning process.

In the mean time here is my issue, any new user added can access OWA and email, but no other network resources such as terminal servers or network drives. My hunch is that it is because the corrupt DC is handling the authentication request and since the DC's aren't replicating it doesn't see the user as valid, but the good DC is handling the OWA request. So how can I force the authentication to look at the working DC? I've made sure all FSMO roles are with the good DC, but it still didn't work. Obviously the fix is to move exchange and kill the bad DC, but until then I need a workaround.

They are both Windows Server 2008 (one of them being R2).

Thoughs?
0
Comment
Question by:bhieb
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
5 Comments
 
LVL 16

Expert Comment

by:Joshua Grantom
ID: 40364063
Option 1
Is the good DC also running the DHCP and DNS server? If not, it needs to, then you can disable the DNS Server role on the exchange DC.

Option 2
You can also look at the DHCP scopes and remove the bad dc from being a DNS server at all. Then it will not service any requests
0
 

Author Comment

by:bhieb
ID: 40364067
Yes it is, there is no DHCP or DNS on the bad one.
0
 
LVL 26

Assisted Solution

by:DrDave242
DrDave242 earned 250 total points
ID: 40364227
Make the good DC a global catalog and remove the GC from the bad DC. I'm not certain that'll help, but it's worth a shot.
0
 
LVL 9

Accepted Solution

by:
stu29 earned 250 total points
ID: 40364329
There is no simple way to do this, and even the workarounds usually dont guarantee the auth request will hit the desired DC.
1.  Configure the LdapSrvPriority registry setting on your domain controllers so that the good DC has the highest priority. For more info about this setting, see here:

http://technet.microsoft.com/library/cc957290

In addition you can configure the LdapSrvWeight registry setting on domain controllers to assign a weighted priority for each one:

http://technet.microsoft.com/en-us/library/cc957291

Of course, this will mean that all client computers  will prefer the good DC for logons, and it doesn't actually guarantee the good DC will be used because if the good DC is unavailable then domain controllers with lower weighted priority will be tried in order.

2. If you get more desperate .... Create a new site in Active Directory and move both the workstations and the good DC to the new site. Of course you would probably only want to do this in a test environment, so if you're in a production environment you will have to use another method.

These options will only give you breathing space.  The auth process is very fickle and more complex than this, but it may help.
0
 

Author Comment

by:bhieb
ID: 40364506
Not sure what method did the trick. I noticed on the technet links that it was reg settings to the netlogon service. So I just stopped that service on the bad DC. That then broke the OWA login, so I restarted it, and now the other DC is servicing the terminal login requests and the OWA is working. That was my primary goal, I also did the GC change so not sure what did it but I'll split the points.

I'm sure it isn't going to be a perfect fix, but it will at least hold together for a week or so. Also I had a thought that I could just block the LDAP ports on the bad box, making any query failover to the good one.
0

Featured Post

Does Powershell have you tied up in knots?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Uncontrolled local administrators groups within any organization pose a huge security risk. Because these groups are locally managed it becomes difficult to audit and maintain them.
This article provides a convenient collection of links to Microsoft provided Security Patches for operating systems that have reached their End of Life support cycle. Included operating systems covered by this article are Windows XP,  Windows Server…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…

695 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question