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
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
E:\Program Files (x86)\Microsoft Azure Site
Type in this command to remove the VM from the ASR database
(replace IP address with the IP of your VM):
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.