Friday, July 13, 2018

Removing a Forest from Azure AD Connect


In an organization with multiple Active Directory forests, you may want to sync objects from trusted forests. Adding trusted forests to Azure AD Sync is a simple process that I will likely cover in a future article. The focus of this post is the not-so-obvious process of removing a forest from Azure AD Connect. This can be a daunting and somewhat scary thing to do. Not fully understanding the process or having someone to guide you can leave you with thoughts like “what happens when I remove the forest from Azure AD Sync? Do on-premises objects get deleted? Are cloud objects deleted?”. I will try to answer these questions to the best of my ability and hopefully make the process simple and stress-free for you.

To get started, we first need to open PowerShell and disable the AD Sync scheduler. You can do this by running the “Set-ADSyncScheduler” cmdlet:




This cmdlet is included in the ADSync PowerShell module. You may need to load the module prior to using the cmdlet (Import-Module ADSync).

The next step is to open FIM (miisclient) located in the install directory of Microsoft Azure AD Sync. By default, this is C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe. Once you have FIM open, click on the Connectors tab, then right click on the connector for the forest that you want to delete, and click “Delete”.




You will then be prompted, asking if you want to just delete the Connector Space, or delete the Connector and the Connector Space. The former open removes all data, but keeps the configuration in case you want to use it again later. The latter option deleted the data and the configuration. This open should only be used if you don’t plan on syncing the forest again.




The connector for the forest is now deleted, but what actually happens? Your on-premises objects do not get removed for the forest, and cloud objects are removed. Simple enough, right?


Now you just need to re-enable the AD Sync Scheduler with this cmdlet: 
Set-ADSyncScheduler -SyncCycleEnabled $true

One last thing to mention… You may receive an email from the Microsoft Online Services Team stating that the identity synchronization failed due to a deletion threshold being met. By default, Azure AD Connect will not allow you to delete more than 500 objects in your cloud directory. This is to protect you from making a careless (potentially resume generating) mistake. The email will look something like this:



If you are certain that you want to proceed with deleting the objects, here are the steps:

1 1) Disable the deletion threshold protection. Open PowerShell on your Azure AD Sync server and type   in this cmdlet: Disable-ADSyncExportDeletionThreshold. You will be prompted for credentials,   sign-in with an Azure AD Global Admin account.
2 2) Open FIM (miisclient), and click on the “Connectors” button at the top of the window. Right click   on the connector of type “Windows Azure Active Directory”, and select “Run…”.





3) Next, click Export and then click Ok. 



1      4) Allow the connector to run. This will take a few minutes. You can monitor the progress by clicking the Operations button.
2      
5   5) Once this completes, you need to re-enable the deletion threshold. You can do this by running this cmdlet: Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500. You will be prompted for credentials again. Just type in your Azure AD Global Admin creds. You can even lower the threshold if you’d like. I set mine to 100.

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.

 

Follow by Email

Search This Blog