Active Directory Replication: The active Directory property cannot be found in the cache

Last night I came across a problem with AD that I have never seen before. Normally, Active Directory Domain Services is an extremely robust application that will continue to work, regardless of not implementing best practices, or misconfiguration. However, I promoted a new domain controller and was surprised to see that it was not able to replicate with any other DCs.

Everything appeared to be configured properly. This seemed like the millionth domain controller I’ve created throughout my career, so I was accustomed to the process.

When clicking “Check Replication Topology” within Sites and Services, I received this error:

The active Directory property cannot be found in the cache

 

The problem was caused by a missing cname record in the _msdcs.<domain name>.<tld> forward lookup zone:



 

When a domain controller registers its name with another DNS server, it needs to create a CNAME record in this zone, which is then used by other domain controllers to locate replication partners. This is what the zone looks like normally:



 

There should be a CNAME record for each domain controller, mapping the DSA GUID to the FQDN of the domain controller. The newly promoted domain controller did not automatically create this CNAME record. After manually creating it, and waiting a little while, I was able to replicate all partitions throughout the domain.

 

To create this record, first obtain the DSA Guid. Open a cmd prompt on the problematic domain controller and type in:

Repadmin /showrepl



 

 

Then open DNS on another (working) domain controller and create a CNAME record in the _msdcs.<domain name>.<tld> forward lookup zone.



 

Also verify that the new domain controller is listed as a name server for the zone.



 

Just wait a little while, and then try to replicate all partitions.

 

Azure AD Connect: Health service data is not up to date

Noticed this error earlier today in the Azure Portal. This happened after renaming the server over the weekend. It looks like the Agent on the server uses a certificate to authenticate with Azure. Since the server name changed, the certificate is no longer valid.



I ran the "test-azureAdConnectHealthConnectivity" cmdlet as suggested, and got these results:



It was pretty obvious what the problem/solution was after seeing the "Invalid Credentials" response from the server. I wasn't sure how to update the certificates without completely re-installing Azure AD Connect, and couldn't find anything on Google that would help. But after poking through the Azure AD Connect Powershell module, I found this cmdlet: Register-AzureAdConnectHealthSyncAgent.



After running this cmdlet, and restarting the Azure AD Connect services, the error message was resolved in the Portal. Hope this helps anyone experiencing this issue.

Remove Stubborn PSC or vCenter Appliance from an SSO Domain

While attempting to decommission one of our vCenter sites, I ran into an issue removing one of the PSCs. This site consisted of two PSCs and one vCenter appliance. I removed the first PSC from the SSO domain successfully, and then removed the vCenter appliance. Things became a little tricky during the removal of the final PSC. This PSC did not get removed even after running the cmsso-util command. This article will detail the steps I took in decommissioning the site, as well as removing the stubborn PSC.

First, we need to check if vCenter is currently using the PSC we plan on decommissioning. If it is, we need to use the cmsso-util command to redirect vCenter to a different PSC. Instructions for redirecting vCenter can be found here: https://kb.vmware.com/s/article/2113917?language=en_US

To check what PSC your vCSA is currently pointing to, browse to the Advanced Settings for the vCSA in the vSphere Web Client. Filter by this key: config.vpxd.sso.admin.uri

To remove a PSC or vCSA from an SSO domain, connect to a PSC via SSH and run these commands:

To remove a PSC from the vSphere SSO domain:

cmsso-util unregister --node-pnid psc01.ad.vcplab.local --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password

To remove a vCSA from the vSphere SSO domain:

cmsso-util unregister --node-pnid vcsa.ad.vcplab.local --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password

After running these commands, delete the virtual appliances. You can also verify the appliances have been removed by browsing to Administration > System Configuration > Nodes in the vSphere Web Client.

If cmsso-util fails to remove any of the nodes, you can use this command to force the removal:

vdcleavefed -h vcsa.ad.vcplab.local -u Administrator -w Passw0rd!

Upon successful completion, you should see something like this:

/usr/lib/vmware-vmdir/bin/vdcleavefed -h vcsa.ad.vcplab.local -u administrator
password:
vdcleavefd offline for server vcsa.ad.vcplab.local
Leave federation cleanup done

When specifying the username, use the SSO admin (administrator). However, do not use the full UPN (administrator@vsphere.local). Doing so will cause the command to fail.

Exchange 2016 Hybrid Deploy Check - Username or Password Invalid

These days, it seems every Microsoft product comes with its own unique set of head scratchers. Microsoft Exchange Server is no exception to this. I was installing Exchange 2016 earlier today, to be used as a hybrid configuration server for Office 365 (no local mailboxes). I downloaded the self depackaging executable from Microsoft, and attempted to install it. If you currently have a hybrid configuration (which we did, with Exchange 2010), the Exchange 2016 installer will detect this and run some tests to verify that the Office 365 tenant is ready for Exchange 2016 (more info here: https://technet.microsoft.com/en-us/library/ms.exch.setup.hybridconfigurationstatuspage(v=exchg.160).aspx). You’ll be prompted for Office 365 credentials (the user must have the Organization Management role). Seems simple enough, right? Wrong.

After typing in the username and pasting the password into the password field, setup came back with an error message stating the username or password was wrong. I then clicked the back button, and it crashed. I ran through this process a few more times, all with the same outcome. I even rebooted the server, which (in my opinion) should never be the resolution to a software problem. I looked through setup logs and found no indication of what the problem could be…



It was on the fourth try that I typed in the password, and this seemed to work. I didn’t receive any error messages about the credentials being wrong. The Exchange setup seemed to continue on successfully. However, it then failed with a different error:



I again looked through the setup logs and found that this error happened anytime setup tried to run the “Get-OrganizationConfig” cmdlet. After troubleshooting for a little while, and no resolution in sight, I turned to Google. One of the posts I came across said that this is a bug in the Exchange installer, and to try and use the Cumulative Update installer instead. Apparently, with Exchange 2016, the Cumulative Update installer’s include all of the Exchange binaries, not just the updated binaries. I downloaded the installer for CU7 (all 6 gigabytes of it…) and successfully installed Exchange 2016. Hope this helps anyone out there struggling with this.