Tuesday, August 21, 2018

Active Directory Migration Toolkit - The RPC Server is Unavailable (hr=0x800706ba)

When migrating computer objects using the Active Directory Migration Tool, you may encounter the following error:

In addition, the Migration Log may show the following error:

This is typically caused by a host-side firewall. To resolve this, deploy a GPO to disable the Windows firewall prior to migrating the computer account. I like to create a special OU for computers (I typically name it “PreMigration”) that I will move computer objects to prior to migrating them. This OU will have two policies applied. One to disable the Windows Firewall and another to start the Remote Registry service. Both are required for the computer object to successfully migrate.

Azure Site Recovery - VMware-to-Azure: Wrong IP address discovered for VM

When replicating virtual machines from VMware to Azure using Site Recovery, you may encounter an issue where the Configuration server discovers the wrong IP address for a VM. This can be caused by stale entries within the infrastructurevms MySQL table that is used by ASR to track VM attributes. 

To resolve this issue, you first need to disable replication for the VM in the Azure Portal.

Next, login to your ASR Configuration Server and open a CMD prompt as administrator. Browse to the bin directory for your ASR installation. For example, in my case ASR is installed on the E: partition under the following directory:

E:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\bin

Type in this command to remove the VM from the ASR database (replace IP address with the IP of your VM):

perl Unregister-ASRComponent.pl -IPAddress -Component Source

That’s it. You should now be able to reconfigure replication for the VM, and ASR will discover the correct info about the VM.

Thursday, July 26, 2018

Azure AD Connect No-Start-Connection

This morning, I ran into an issue with Azure AD Connect that I had never seen before. I received an email alert from Azure AD stating that Password Synchronization was not working for my forest, and the suggested fix was to restart the ADSync service on the server. I restarted the service and then forced a sync to verify it was working.

After forcing the sync, I opened miisclient and noticed some strange errors. We sync multiple on-prem AD forests to Azure AD, and the status for one of them was “no-start-connection”. That error in itself does not seem significant to me. However, after clicking on the “failed-connection” link in the Connection Status pane, things became much more clear.

The domain controllers for the forest in question are in a datacenter that is geographically separated from the datacenter that our Azure AD Sync server lives in. The two sites are connected via a S2S VPN.

There was obviously some type of connection issue between our two datacenters. In my case, the issue was transient, and resolved itself after a few minutes. But if you’re experiencing this error message, check your L2/L3 connection. Also, verify DNS is working and someone didn’t make changes to your firewall(s). Just walk up or down the OSI model and you’ll eventually find the problem.

Wednesday, July 18, 2018

Azure AD Connect Health: Latest Data is not Available in Azure Portal

I recently had to create a new Azure AD Connect server, and found that it was not able to report health status in the Azure Portal. After some troubleshooting/research, I was able to get the health status report working by registering the health agent on the server with Azure AD Health Services. Doing this involves running one PowerShell cmdlet on your AD Connect server and providing global administrator credentials.  

First, let’s test the status of the agent communication:

If you do not receive any errors, that means the Azure AD Connect Health agent on your server is able to successfully communicate with the cloud service. Now, let’s register the agent:

You will be prompted for credentials. The credentials you provide need to be a global administrator account in your Azure AD tenant.

You should receive some output stating that the registration is successful (or it failed).

 Now, just go back to the Azure Portal and refresh the page. The message stating that the
"latest data is not available" should be gone.

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.
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.


Follow by Email

Search This Blog