Azure AD Sync - Set-MsolDirSyncEnabled : You cannot turn off Active Directory synchronization.

 I recently ran into a situation in my lab environment that required I resync all (2000+) user accounts to Azure AD. Though this sounds complex and daunting, its actually quite simple. T

he basic steps involve disabling sync, and then removing the user objects. This can all be done with two PowerShell commands:

1) Set-MsolDirSyncEnabled -EnableDirSync $false

    

2) Get-MsolUser -All | Remove-MsolUser -force

    

The account that you are currently running the commands as will not be removed. 

To enable Azure AD Sync, you simply reverse the boolean operation on the Set-MsolDirSyncEnabled cmdlet above. However, I ran into an issue when trying to enable Azure AD Sync. 

After some research, it turns out you must wait a period of time (up to 12 hours in some cases) before you can make a second change to the Azure AD Sync status. This error simply means that we made a recent change to Azure AD Sync, and we must wait before making another change. To prove this, there is a "DirectorySynchronizationStatus" member for the Get-MsolCompanyInformation cmdlet. If we take a look at this member, we can see the status is "PendingDisabled". 

Check the status of this periodically over the next 12 hours or so, and once it says "Enabled" or "Disabled", you should be able to change the state once more. 

Azure VM Scale Set - Get Instance IP Address

 

If you are using VM Scale Sets in Azure, you know how important it can be to quickly obtain an instance IP address. This can of course be done using the Azure Portal. However, I am often working in a shell or VSCode, and I do not want to leave the comfort of my shell to login to the portal.

There are a few options we have for retrieving information about a VMSS and its instances without using the Azure Portal. We can use PowerShell or the Azure CLI. Being that I am constantly flipping between Windows and Linux, I will detail both here.

 

You will need to have the AZ module installed. To install this module, simple open PowerShell (as admin) and type in “Install-Module -Name az”. To get the IP address of the instances within a scale set, use the following script:

https://github.com/rnemeth90/Get-VmssInstanceIpAddress

You can also use the Azure CLI to obtain individual instance IP addresses. This method is much simpler than PowerShell, and only requires one line of code:

az vmss nic list --resource-group myResourceGroup  --vmss-name myVmss | grep -w "privateIpAddress"

 

Azure Policy - Allowed Locations for Resource Deployment

 

Azure Policy allows us to control what actions users can perform regarding creating and managing resources in Azure. We can define policies for naming standards, require that certain extensions be installed on virtual machines, audit various resources for certain configurations… the possibilities are endless.

In this article, well focus on defining what locations users can deploy resources in. To get started, login to the Azure Portal and search for “Policy”.

 

 

Click on “Definitions”. Here you will find several built-in definitions that can be applied to your resources. Definitions are a json template containing the logic for what you want to accomplish. It is worth investing some time to look through these built-in definitions.

In the “search” field, type in “location”. Then, click on the “Allowed Locations” definition.

Here you can see the json content of the definition. The “policyRule” section is the bread and butter of the definition. In this particular example, the policyRule states that if the location that the user is deploying a resource to is NOT a) in the list of allowed locations, b) global, or c) a b2c directory, then deny the deployment.

Next, click on “Assign”.

 

You can assign the policy to a subscription or resource group. You can also create exclusions in this same window, and enable or disable the policy.

Click “Next”, and on the Parameters page, choose the allowed locations from the drop down menu. Then click next.

Azure Policy has the capability to remediate non-compliant resources. An example would be having a policy that requires anti-virus be installed on all servers. If Azure Policy detected a server that did NOT have anti-virus installed, it would use a managed identity to install AV software on the server. This particular policy does not need a remediation action, so we will just click “Next” here.

On the Review + Create window, review the resource and then click “Create”.

Back on the Azure Policy blade, select “Assignments”. We can now see that our new policy is assigned.

 

Back on the “Overview” page, you can track compliance for the policy. We can see here that compliance for the “Allowed Locations” policy assignment has not yet been started. This typically takes an hour or so before the compliance state is updated.

Click on the Policy to get a more detailed view of compliance, view the definition, edit the assignment, and even create exemptions.

Replicate an Azure VM Image Between Regions

 

Let’s say you have a VM in Azure North Central. You created this VM from a custom image that you maintain in an Azure image repository. Now, what if you wanted to create that same VM in Azure South Central, and use the same reference image? A standard image repository is limited to the region that it exists in. The answer here is to create a Shared Image Library, add the image to it, and then configure the image to replicate to other Azure regions.

This article assumes you already have an image.

First, create a Shared Image Gallery in Azure. Browse to the Azure portal (https://portal.azure.com), and (from the home page) click “create a resource”. 

 

Search for “Shared Image Gallery” and then click “Create”.

Configure a subscription, resource group, and then name the Shared Image Gallery and configure what region you want it to live in. You will want to create it in the same region as your standard image repository.

If you want to assign some tags to this new resource, continue to the next page. Otherwise, click “Review + Create”.

On the final page, if the validation is successful, click “Create”.

It should take less than a minute to create the shared image gallery. Once its created, click “Go to resource”. 

 

In the shared image gallery blade, click “Add new image definition”.

 

On the next page, select the region where your existing image repository lives, give the image definition a name, and then fill out the rest of the information as needed. The publisher will typically be the name of your company/organization. The offer will typically be set to the name of the overall application, being that servers typically host one piece of an application (example: database servers vs. application servers). The SKU will typically be set to the name of the component within the application (for example, a web server or database server).

Next, configure an image version. This should use the typical semantic format used in software development (major version, minor version, patch level). I will typically substitute the patch level with the date the image was captured. Probably not a best practice, but something that has served me well in the past.

Next, select the source image. This will be the image that you are copying from your standard image repository. You can also configure an end of life date for the image version here if you wish. In the “Target Regions” section at the bottom, select the region where you plan to create the new VM. Also select the target storage account type.

You can configure some publishing options and tags on the following pages. Though, it is not required. Click “Review + create”.   After the validation passes, click “Create”.

This process will take a few minutes to complete. Once its finished, click on “go to resource”. You now have an image that is available to be deployed in the north central region or the south central region.