Office 365: Some quick notes on the end of support for Dirsync and Azure AD Sync

Earlier this week Microsoft announced the end of support for the legacy Microsoft Dirsync and Microsoft Azure AD Sync tools. Millions of customers out there use one of those two tools, or the new Microsoft Azure AD Connect, to sync their users, groups, passwords, etc, from their On-Premises Active Directory to the Azure AD.

After quite a few name changes, it looks like the Azure AD Connect major version is here to stay, and now it’s time to end support to the two older major versions, and make sure that all of them are updated and replaced with the AD Connect.

If you haven’t done it already, it’s time to read the Microsoft announcement, and to start planning that upgrade.

Now let’s take the key points of the Microsoft announcement:

  • In April 13th 2016 Microsoft announced the deprecation of both Dirsync and Azure AD Sync
  • The end of support for both versions of the sync tool was planned to be April 13th 2017. That date is now official with the announcement this week and in that day the official support to those tools is gone
  • Azure AD will stop accepting connections from both tools in December 31st 2017

The most relevant thing to take into account is that, either you upgrade those instances, or they will stop working by the end of this year.

Now that you are probably more than convinced to update your instance(s) for your customers or your infrastructure, let’s bullet point some thoughts to have into account when planning the upgrade:

  • Make sure you read the official Microsoft document to upgrade Dirsync to Azure AD Connect
  • Or make sure you read the official Microsoft document to upgrade Azure AD Sync to Azure AD Connect
  • You can only do in place upgrade from Azure AD Sync to AD Connect or from an old to a more recent version of AD Connect. In place upgrades from Dirsync are not supported
  • Microsoft describes the migration done with a parallel server, to replace the existing, as “Swing migration”
  • On a standard Dirsync or AD Sync instance, there’s nothing that you need to backup and restore in the new version. The new Azure AD Connect instance will do a fresh full sync after the installation. That full sync will bring all data from the local and the Azure AD. Replacing a Dirsync or an AD Sync instance should not require restoring data
  • The only exception to the above statement is when you have some type of filtering. Filtering can be done at the AD OU, Domain or attribute level. In those cases you need to make sure you replicate the filtering you have in place, into the new instance.
  • To learn more about Dirsync filtering click here.
  • To learn more about AD Sync and AD Connect filtering click here.
  • If you are not doing an in place upgrade, you need to be aware that the “downtime” on your sync instance has impact in creating new account and replicating changes to the existing ones (that includes password changes, if you have password sync enabled)

And that’s it. As simple as that. Start downloading the AD Connect version and it’s upgrade time! ­čÖé

Let me know if you have questions.

Set-AzureStaticVNetIP Error: The static address doesn’t belong to the address space defined by the role┬┤s subnet

Quick blog post on a simple and logic error that you might get when you┬┤re trying to set a static IP on your Microsoft Azure VM.

1

So as you can see above, when you try and run:

Get-AzureVM -ServiceName MYMSEXCHANGE -Name TestVNetVM |Set-AzureStaticVNetIP -IPAddress 192.168.0.150 |Update-AzureVM

You get the error:

“Update-AzureVM : BadRequest : The static address 192.168.0.150 doesn’t belong to the address space defined by the┬árole’s subnets.”

The reason behind this error is simple: You are trying to set a static IP for your VM that does not belong to the subnet where the VM is. So let’s have a quick look on how to see which subnet does your VM belongs to. From the azure PowerShell run:

$MyVM = Get-AzureVM -ServiceName MYMSEXCHANGE -Name TestVNetVM

Get-AzureSubnet -VM $MyVM

2

The output will show you the Subnet of your VM.

You can also see the network where your VM is on by running:

Get-AzureVM |fl Name, VirtualNetworkName

4

Now that you know what network and subnet your VM is on, you can go to the Azure Portal > Networks, and on the Configure tab of the network you can see the range of IP addresses from the subnet of your VM:

3

In my case the VM is on the subnet-2, with a range of Ip’s of 192.168.1.0/24 and i was trying to set up an IP address on the 192.168.0.0/24 range.

Let’s try with a valid IP now on the 192.168.1.0/24 network:

5

No error, job done, and as simple as it gets! ­čÖé

Microsoft Azure Tip: How to assign a static IP address to your Azure VM

This blog post will quickly show you how you can assign a static IP address to one of yours Microsoft Azure Virtual Machines, using the Microsoft Azure Powershell.

Assuming that you have already created at least one virtual machine, on your Azure subscription, the first thing you need to know and do is, how to install and configure the Azure Powershell.

On the article from the above link, you can follow the instructions to install the Microsoft Azure Powershell and to connect it to your Azure subscription.

Now let’s login to the Microsoft Azure Management Portal, and start by looking at the Virtual Networks.

Network-VM-1

I created a virtual network on my subscription, named “vlan192”, and as you can see the virtual machine “DC01” got the IP address 192.168.0.4 assigned, which is part of a sub. Now I will change that IP address to one of my choosing.

Network-Subnets-2

Above you can see the virtual network in more detail. Before assigning a static IP address to your virtual machine, make sure the address you choose is within the usable address range of one of the subnets of your virtual network. My virtual network has two subnets.

One other thing that you need to take into account, is that when you create the Vitual Machine, you need to make sure that you assign the correct virtual network and subnet to it, as shown below:

Network-createVM-3

You can always go to the Dashboard of the virtual network, and make sure that the Virtual Machine you created is listed there, and what subnet is the virtual machine using.

We can now connect to the Microsoft Azure Powershell and set the static IP. Let’s start by running the following cmdlet to see the details of the existing virtual machines:

Get-AzureVM

The cmdlet above will give you the servicename and the virtual machine name that you need to run the cmdlet that sets the static IP:

Get-AzureVM -ServiceName <ServiceName> -Name <VMName>  | Set-AzureStaticVNetIP -IPAddress <StaticIP> | Update-AzureVM

Below you can see the output of the cmdlet.

Network-changeIP-4

And finally if you go to the properties of the virtual machine, on the Azure Management Portal, you can see that the static IP is set.

Network-checkIP-5

IMPORTANT NOTE:

You need to be aware is that the IP above is assigned to the specific VM. A reservation is made and therefore that will be the IP of the virtual machine as long as the reservation is kept. This does not change the network properties at the OS level. It doesn┬┤t set the static IP there. You should┬ánow login to the virtual machine and set the static IP to match the reservation, as you are now sure that it won’t cause any IP address conflict.