DNS Records Not Updating

I’m going to stray off of the beaten path and post a blog regarding an Active Directory DNS issue that I experienced.  Although it’s not Exchange server related, I thought this would be worth publishing as I’m sure others have encountered this issue.

We noticed that client DNS records were not getting updated in a timely manner.  More specifically, this was occurring primarily with clients that were connecting remotely to the internal network via VPN.

Suspecting that this was a client issue, one of the first measures we took was to give the DHCP servers the authority to update DNS on behalf of clients.  This seemed to alleviate the issue somewhat, however it completely resolved the problem.  Another step we took wected as to lower the DNS scavenging, where stale records would deleted sooner.  This workaround did not help matters alot either.

As I stated previously, this issue was primarily occurring with clients that connected through VPN sessions.  When client machines connect via VPN, the VPN appliance acts as the DHCP server and issues an IP address from its address pool.  There is an option within the VPN appliance to allow the internal DHCP servers to assign IP addresses, however this is probably a less secure configuration.  Once the client receives its IP address from the VPN DHCP server, the client will update its record in DNS.  Herein lies the problem.

When VPN clients update their records in DNS, they then take ownership of the records.  A look at the properties of a VPN client’s DNS record would show the client as the record owner.  When users that previously connected via VPN returned to the office, the internal DHCP servers were unable to update DNS despite having authority to do so.  The DHCP servers would need to be given permissions to overwrite records and take ownership.  This was done by adding them to the DNS Admins security group.  Afterwards, the DHCP servers were now able to update DNS records that were owned by clients that previously connected via VPN.

Standard

Exchange 2010 DAG Unavailable

I had a situation where my test environment DAG was offline and not detected.  I’m not sure what caused this issue, however the mailbox databases were dismounted and the Content Indexes were in a failed state.  This environment has two sites with a single DAG expanding across the sites.  One site is active with a single Mailbox server and one CAS/HUB multi-role server.  The passive site has the same configuration.

The following was returned when I executed a Get-MailboxDatabaseCopyStatus |FL:

copy status

Attempting to mount the databases doesn’t work.  I attempt to start the DAG and get the following error:

start DAG

The errors associated with the Cluster API in the above figure show that the Cluster service is not in a healthy state.  Furthermore, I was not able to determine which data center was the cluster owner as seen below:

cluster owner

After checking the cluster service in Services, I see that it’s not only disabled but greyed out as well.  Therefore, I’m unable to start it.  Next, I proceed to the Failover Cluster Manager snap-in and notice that none of the DAG nodes are listed.  This article by Tim McMichael was helpful in resolving this issue by providing the following steps in restoring the cluster.

Since this server is running on Windows 2008 R2, I run this command:  Import-Module FailoverClusters

Next, I cleanup the cluster by running:  Clear-ClusterNode -Force -Verbose -Confirm:$FALSE

Now I have to reset the DAG Cluster Name Object (CNO) in Active Directory.  Once the object is located, you simply right click on the CNO and select reset.  After this is complete the CNO has to be disabled.  If it’s still enabled, you will not be able to recreate the Cluster using the existing name as Failover Cluster Manager will think it’s being used.

Finally, I’m able to recreate the Cluster in Failover Cluster Manager, I was able to restore the DAG and bring the mailbox databases back online.

In this blog, I covered the steps I used to recover from a scenario where the DAG in my Exchange 2010 test environment was offline.

 

 

 

 

Standard