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.
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.
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”
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.
14) 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.
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.