When connection to Exchange Online PowerShell using the command Connect-ExchangeOnline nothing special happens. But when executing a PowerShell command like Get-Mailbox you get the following warning:
PS C:\WINDOWS\system32> $mailboxes = Get-mailbox -ResultSize unlimited
Attention!
You are currently using an older version of the Exchange Online PowerShell module which uses RPS. RPS deprecation has been announced and you will need to move to the latest V3 module by June 2023. Read more here: https://aka.ms/RPSDeprecation
Please install our new REST-based PS V3 module downloadable from https://www.powershellgallery.com/packages/ExchangeOnlineManagement/, which is more secure and reliable.
Please note that you will no longer be able to use -UseRPSSession after June 2023.
Microsoft has introduced a new Exchange Online PowerShell module (v3) and the previous modules will be deprecated in the (near) future.
To update the PowerShell module, the old module needs to be uninstalled first before you can install the latest version. To uninstall the old v2 module, execute the following command:
Uninstall-Module ExchangeOnlineManagement
And to install the new v3 module, execute the following command:
The last in most interesting part (in my opinion) is installing an Exchange 2019 server in Azure. This can be your last Exchange server for management purposes, or maybe an Exchange server still hosting (some) mailboxes or performing SMTP Relay. It can be quite expensive to host mailboxes on an Exchange server in Azure, moving Mailboxes to Exchange Online is much cheaper. But then…. If you are already decommissioning your own datacenter… All business requirements are different of course 🙂
Exchange in Azure Setup
Currently Exchange server are located on-premises in a hybrid scenario. There’s already a Domain Controller in Azure, and the Azure AD Connect is running in Azure too. Now I want to install an Exchange 2019 server in Azure and run the Hybrid Configuration Wizard to create a hybrid configuration with the Exchange 2019 server in Azure. Webmail and Autodiscover will point to the Exchange server in Azure as well. In short, the configuration will look something like this:
Inbound mail will be sent to Exchange Online Protection and delivered to mailboxes in Exchange Online. When a mailbox is located on-premises, it will be routed to the Exchange server in Azure and when needed, routed to the Exchange server on-premises.
But first we have to think about sizing the Exchange server in Azure.
Sizing Exchange in Azure
The first question about Exchange server in Azure is sizing the Exchange server. First of all, deploying Exchange on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage (please see the Exchange Server Virtualization article on Microsoft Learn.
When you are planning to host active mailboxes on the Exchange server running in Azure then you should use the Exchange 2019 storage requirements calculator to figure out the correct size for the Exchange server. You can find the storage calculator on the Exchange 2019 ISO images in the \Support directory.
If you are planning to install an Exchange server in Azure just for management purposes, or for lab purposes, I would recommend using a ‘Standard d8s v3’ VM. This is a VM with 8 vCPU, 32 GB memory and a maximum of 16 additional disks. When you create a new VM in the Azure Portal and select ‘see all sizes’ it will show a list of most used virtual machines by Azure users as shown below:
For my own lab environment I selected the DS3_V2 VM. Not the fastest VM, but for my own test- and management purposes it is sufficient, but your mileage may vary of course. Attached to my VM are two SSD disks of each 1TB. Be aware that the disks can be a costly thing, especially in a lab environment! The network interface is connected to the internal VNET that was created earlier, and it is connected to the Microsoft network using a public IP address. I also created a DNS name (exchlabsnl.westeurope.cloudapp.azure.com which can be used as a CNAME record for some other DNS name) but that’s not really needed since I can use the public IP address in a regular DNS A record.
Installing and Configuring Exchange in Azure
When you have the VM up and running in Azure and you have configured the storage as required, you can install the Exchange server. This is not different from a regular Exchange server. Install the prerequisite software, patch the machine, install the latest Exchange 2019 Cumulative Update and install the latest security update for this CU.
Configuring the Exchange server in Azure is similar to configuring the Exchange server on-premises. Install a proper certificate, configure the virtual directories (hopefully needless to say, but use a different FQDN in Azure since it is a different site in Active Directory) and configure the transport database on a different disk.
Configure the Network Security Group (NSG) to allow access on port 443 and port 25 from the Internet. Depending on your security requirements, you can configure the NSG of the Exchange server with the IP ranges of Exchange Online (https://learn.microsoft.com/en-gb/microsoft-365/enterprise/urls-and-ip-address-ranges) so only Microsoft can fully access your Exchange server in Azure. If you have clients that need to connect to the Exchange server, they can use a VPN connection (that’s what I typically recommend to customers these days, and what I do in my lab environment).
If you are planning an Exchange server just for management purposes, I would recommend not using a public IP at all and only connect to the Exchange server using the private Vnet. In this scenario there’s no need to publish the Exchange server to the Internet, and all changes to recipients are replicated to Exchange Online using Azure AD Connect. No Internet connection is less prone to external attacks of course. And another interesting thing when using a management server only, you can turn it off when not in use. This can save you quite some money.
The next step is to run the Hybrid Configuration Wizard which you can download from https://aka.ms/hybridwizard. When going through the wizard, select the Exchange server in Azure for the Receive Connector configuration and for the Send Connector configuration.
When finished, add the public IP address of your Exchange server in Azure to your SPF record for outbound mail, or configure the SMTP connector to Exchange Online to route all outbound mail via Exchange Online, that’s up to your requirements of course.
What happened in my scenario, my public IP address was assigned by Microsoft and you never know what happened previously with this IP address, but I had to delist it from SpamHaus before I was able to send out email from my Exchange server.
Then move your resources from the on-premises Exchange server to the Exchange server in Azure and decommission your Exchange server on-premises when needed.
Summary
In the past three blogpost I explained what it takes to install an Exchange server in Microsoft Azure and it contains of the following steps:
Create a site-to-site connection between your on-premises network and a Vnet in Azure.
Install a Domain Controller in Azure, connected to the Vnet. Optionally you can install an Azure AD Connect server in Azure as well.
Install and configure an Exchange server in Azure, connected to the Vnet (and to the Internet when needed)
An Exchange server in Azure is fully supported, as long as the Mailbox database and transaction logfiles are located on premium storage, that should be no problem.
Sizing your Exchange server in Azure is like an on-premises Exchange server. Use the storage calculator to determine the size of your Exchange server, and look for a VM that matches these requirements.
When installing an Exchange server in Azure just for management purposes it’s much easier. You can use a relatively lightweight Exchange server, there’s no need to publish it to the Internet (much safer) and you can turn it off when not in use.
In my previous blog I wrote about creating a virtual network in Microsoft Azure and a site-to-site VPN connection to connect your on-premises network to the virtual network in Azure. The next step is to create a Domain Controller and (optional) an Azure AD Connect server in Microsoft Azure.
On a Domain Controller on-premises, create a new site in Active Directory and a new subnet and assign it to the new site. In my environment, the new site is called ‘Azure’ and the new subnet is ‘172.16.1.0/24’ as shown in the following screenshot:
Adding a new VM to Azure is not too difficult, but you must be careful with change the network properties. Do not change the DNS setting on the NIC inside the VM, but change it on the properties of the networking interface object in Azure.
Open the properties of the Virtual Machine in Azure, scroll down to Networking (under Settings) and click on the Network Interface. Select DNS Servers (under Settings) and add the (AD Integrated) DNS server on-premises shown in the following screenshot:
It takes some time before the new settings are active. Once active, you should be able to resolve other machines on the on-premises network and more important, join the new VM to Active Directory. And once joined, install the ADDS components on the new VM and promote it to a new Domain Controller, running in Azure.
Another thing I have changed in Azure is the DNS setting of the virtual network. Open the virtual network properties and scroll down to DNS Servers (again under settings). Open the DNS servers properties, select the ‘custom’ radio button and add the IP address of the new Domain Controller (with Integrated DNS of course). All VM’s on this virtual network now use the new Domain Controller for name resolution.
For external recurring DNS queries, and the Azure forwarder with IP address 168.63.129.16 on the forwarders tab of the DNS server as shown in the following screenshot:
The next step is to create a VM that will host the Azure AD Connect server. It still is my test environment so VMs don’t have to be that big, so for the Azure AD Connect server I’m using the Standard DS1 v2 (1 vcpu, 3.5 GiB memory) as well. You can also install Azure AD Connect on the Domain Controller in Azure, but personally I’m not a big fan of installing other services on Domain Controllers.
Make sure the new VM is connected to the Virtual Network that was created earlier, it will automatically get an IP address in the correct range.
Once installed, logon to the new server, join it to the domain and reboot again, just you would do with a server on-premises. Since we are working post migration to Exchange Online we do have an Azure AD Connect server running on-premises. Moving this server to Azure is just like upgrading an Azure AD Connect server. Export the configuration of the existing server to a JSON file, and import this JSON file using the Azure AD Connect setup application. I have blogged about this process in an earlier upgrade blog: https://jaapwesselius.com/2021/12/24/upgrade-azure-ad-connect-from-1-x-to-2-x/ but it’s similar to moving to Azure.
When using this method, the new server will automatically be in ‘staging mode’, so it will fill its database with information, but it won’t sync anything with Azure AD. When you are ready, set the old server in staging mode and get the new server out of staging mode. At this point you are synchronizing using Azure AD Connect in Azure instead of on-premises.
As an Exchange consultant I still do a lot of work with Exchange server on-premises, like migrations to Exchange 2019 and hybrid migrations to Exchange Online. In a typical Exchange hybrid environment 99% of all mailboxes are in Exchange Online, and only a handful of mailboxes are in Exchange on-premises. As a result, only one or two Exchange servers are left on-premises; for management purposes, for SMTP routing purposes and host these leftover mailboxes. A logical follow-up question is “why not put them in Azure?”.
Placing the last Exchange server in Azure can be costly, but a lot of customers are working hard to decommission their on-premises server room, so from that point of view it’s a valid question.
Before going into detail about this Exchange server in Azure, a couple of other things need to be in place:
Site-to-Site VPN connection between on-premises and Azure.
Domain Controller in Azure (optional: Azure AD Connect in Azure).
Exchange server in Azure.
These make a couple of interesting blogs 🙂
Site-to-Site VPN with Ubiquity EdgeRouter
The first step is to create a site-to-site VPN connection between the internal network and Microsoft Azure, and we begin with a virtual network in Microsoft Azure.
The internal network is 10.83.4.0/24 and the Azure Virtual Network is 172.16.0.0/22, separated in a gateway subnet (172.16.0.0/24) and a server network (172.16.1.0/24).
My configuration looks like this (but my external IP addresses are different):
These are the steps I executed in the Microsoft Azure Portal:
Create a new Azure Virtual Network:
Name: ServerNetwork
Address Space: 172.16.0.0/22
Subnet name: Default
Subnet Address Space: 172.16.1.0/24
Resource Group: MyTestRG
Create a Gateway Subnet (under Virtual Networks, select Subnets and click +Gateway Subnet. The properties of the Gateway Subnet are automatically populated.
Public IP Address: Create new during creation of VirtualGateway
Public IP Name: ..cloudapp.azure.com
Public IP Address SKU (dynamic)
The creation of the VirtualGateway can take quite some time, so be patient…
Create a local network gateway
Name: LocalGateway
IP Address:
Address Space: 10.83.4.0/24 (your own internal IP address space)
Create the VPN Connection (under VirtualGateway Connections)
Name: IPsecER
Connection type: Site-to-Site (IPSec)
Virtual Network Gateway: VirtualGateway
Local Network Gateway: LocalGateway
Shared Key: <secret>
For testing purposes, I created a new Virtual Machine in Azure (Standard DS1 v2 (1 vcpu, 3.5 GiB memory). This is automatically connected to the newly created Virtual Network. Using the external IP address, you can use RDP for the initial connection. For security purposes, use the Network Security Group (NSG) to restrict RDP only to your own IP address. After connecting, enable the ‘File and Printer Shared (Echo request – ICMPv4-In) Inbound Rule in Windows Defender Firewall. This makes connectivity testing a lot easier.
The Ubiquite EdgeRouter supports site-to-site VPN solutions, including site-to-site to Microsoft Azure which is documented in the EdgeRouter Route Based Site-to-Site VPN to Azure article. Not all devices are supported by Microsoft as documented in the Microsoft article About VPN devices and IPsec/IKE parameters for Site-to-Site VPN Gateway connections. Keep in mind though that not tested by Microsoft means ‘not supported by Microsoft’ but that does not automatically include ‘does not work’. If the vendor (Ubiquity in my case) supports it, you’re good to go.
When the router is configured correctly the site-to-site connection is automatically setup and the VPN Connection status should change to ‘Connected’ as shown in the following screenshot:
At this point you should be able to ping the VM in Azure (that’s connected to the virtual network that we created earlier) from a machine in your local network and vice versa.
In my next blog I will discuss installing a Domain Controller in Azure.
I was under the impression I blogged about this years ago (while working on an Exchange 2010 –> 2016 migration) but I couldn’t find my own blog, so here it goes (again).
The Active Directory Recycle Bin saved my life a couple of times, not only my life but also my customer’s life. With the Active Directory Recycle Bin you can restore deleted object from Active Directory, and when using Azure AD Connect also automatically restore object in Azure Active Directory (assuming the deleted object was synchronized before the actual deletion of course).
Too bad that’s it disabled by default, but enabling the Active Directory Recycle Bin to just a matter of start the Active Directory Administrative Center, select and right-click your root domain and select ‘Enable Recycle Bin…” as shown in the following screenshot:
Of course, it is also possible to enable this using PowerShell, just execute the following commands:
PS C:\> Import-Module ActiveDirectory
PS C:\> Enable-ADOptionalFeature "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "ProExchangeAdmin.com"
WARNING: Enabling 'Recycle Bin Feature' on 'CN=Partitions,CN=Configuration,DC=ProExchangeAdmin,DC=com' is an irreversible action! You will not be able to disable 'Recycle Bin Feature' on 'CN=Partitions,CN=Configuration,DC=ProExchangeAdmin,DC=com' if you proceed.
Confirm
Are you sure you want to perform this action?
Performing the operation "Enable" on target "Recycle Bin Feature".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
PS C:\>
Wait until all Domain Controllers have replicated this change and you are all set.
But how does this work under the hood? Deleted object don’t stay in the recycle bin forever. By default, a deleted object continues to exist in Active Directory for 180 days, which is set on the msDS-deletedObjectLifetime attribute of the Directory Service object. On the object that is deleted, the isDeleted and isRecycled property come into play.
When a user object is deleted, the isDeleted property on the user is set to True. At this point it is logically deleted, but physically still available in Active Directory (in the Deleted Items container) and it can be restored. When the deleted object lifetime has passed, the isRecycled property is set to True and the Active Directory garbage collector knows it can remove this object from Active Directory (physically removed from the database).
This is graphically shown in the following figure.
It is possible to increase the deleted object lifetime by stamping a higher value on the msDS-DeletedObjectLifetime property. For example, to increase the default lifetime of 180 days to 2 years (=730 days) you can use the following PowerShell command:
Restoring a deleted object from the recycle bin is easy. Open Active Directory Administrative Center, navigate to your domain and select deleted objects. Select and right-click the object and select Restore as shown in the following figure:
It is also possible to use PowerShell to restore a deleted object. For example, to find the user in the previous example we can use the following Powershell command:
PS C:\> Get-ADObject -Filter 'samaccountname -eq "Johns"' -IncludeDeletedObjects
Deleted : True
DistinguishedName : CN=Labs | John Smith\0ADEL:7ee41efd-0034-46d7-9313-62360fff43fb,CN=Deleted Objects,DC=labs,DC=local
Name : Labs | John Smith
DEL:7ee41efd-0034-46d7-9313-62360fff43fb
ObjectClass : user
ObjectGUID : 7ee41efd-0034-46d7-9313-62360fff43fb
PS C:\>
Pipe this output to the Restore-ADObject command and the deleted user will be restored. Very simple and very useful, I always recommend enabling this.
Jaap Wesselius 
You must be logged in to post a comment.