Thursday, March 15, 2018

Incorrect Function When Bringing Disk Online in Disk Manager

I was configuring new storage for a Veeam Proxy server, and was surprised to find that I couldn’t bring the volume online. This was a freshly provisioned Fibre Channel LUN on a Nimble AF5000 array. The particular Veeam Proxy in question is a Cisco UCS B200 M3 blade. I created the LUN on the AF5000 and created the initiators. I then configured Fibre Channel zoning on the Nexus switches, went back to Windows and rescanned the storage. The new LUNs appeared in Disk Management, but when attempting to bring them online I received this message:



After some quick troubleshooting, I found that the SAN policy for the Virtual Disk Manager is set to “Offline Shared” by default. The SAN policy controls how SAN LUNs are mounted on a Windows Server. This can be confirmed using DiskPart.

Open a cmd prompt as admin and type in “diskpart”. Then type in “san”. This will show you the current SAN policy.



To resolve this, you need to change the SAN Policy to “Online All”. This can be done with a simple command. Back in the diskpart window, type in “san policy=onlineall” :



Now, go back to disk management (or you can just use diskpart) and bring the volume online, then initialize it.

 

Tuesday, November 28, 2017

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.

 

Monday, November 13, 2017

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.