One of the great uses of Azure is to host VMs which can address a number of business requirements. While we can install Exchange 2013 on an Azure VM, this is generally not the most cost effect way to have mailboxes running in a cloud. Office 365 is the recommended option to leverage cloud mailboxes since it has pricing and feature advantages. Some customers may still wish to do deploy Azure Exchange VMs since the cost may be cheaper than breaking ground on a new datacentre. Alternatively you can also host your Exchange test lab on Azure VMs.
One thing that you might notice is when powering the Exchange VM on from a deallocated state, the boot process takes an extended amount of time.
Start Me Up
In the below 2013 lab, there are two Exchange 2013 servers named Exch-1 and Exch-2. Exch-2 is currently in a deallocated state. Let’s power on Exch-2 and see how long before we can connect to it.
Exch-2 was powered on at 09:41 Eastern, which you can see below. The VM successfully transitioned from a deallocated state to a running state.
Now it has entered a running state. We should be able to connect to this after a couple of minutes?
Nope that is not happening. We are unable to RDP to the VM.
Start Me Up – Slowly
What about internal connectivity? Is the issue just for RDP connections?
Logging on to the other Exchange server in this test lab (Exch-1) we will use Get-Date to show the time and try to ping the server which we powered on (Exch-2). While the times are shown as UTC, this does not matter. Note the duration. Even after 20 minutes the server is not responding.
Since I bore easily, certainly not going to keep manually trying to ping the box. We can use something like this batch file to log ping failures. The server Exch-2 started to respond to pings at this time:
Thu 04/21/2016 14:26:09.49 - [ Lost = 1 (100% loss)]
Thu 04/21/2016 14:26:14.47 - [ Lost = 1 (100% loss)]
This is ~30 minutes after the transition from being deallocated.
Looking in the system event log now that the machine is running we can see when it started up. Remember that the time is in UTC.
In the Event Logs we see errors where the Exchange services are not starting up as expected:
Exchange requires the AD Topology service, so if this service is not starting then the other services will certainly have serious issues.
Working Around Start Up Issues
To work around this we can set the Exchange services to manual, and once the OS has started then Exchange can be brought online. As a quick example, the AD Topology service was disabled and the VM machine was powered off to a deallocated state. It took 10 minutes to regain network connectivity. The same time was noted in my testing when setting all Exchange services to manual. You could set them manually one, by one or use something like the below PowerShell command:
Get-Service | where {$_.DisplayName -like "Microsoft Exchange*"} | Set-Service -StartupType Manual
To start the services after the machine is running there are several approaches. The Test-ServiceHealth cmdlet could be used:
Test-ServiceHealth | Select ServicesNotRunning -Expand servicesNotrunning | Start-Service
Exchange labs in Azure are the most likely to experience this issue, as they are often powered off either because they are not being used or to save costs.
For more examples on starting services, please see this post.
Bootnote
Yes that pun was intended…
Note that the issue above is noted on a power-on event from a deallocated state. When the server is restarted, the reboot is quick. The below entries for lost pings are less than a minute in duration
Thu 04/21/2016 14:42:21.18 - [ Lost = 1 (100% loss)]
Thu 04/21/2016 14:42:25.95 - [ Lost = 1 (100% loss)]
Thu 04/21/2016 14:42:30.97 - [ Lost = 1 (100% loss)]
The machine rebooted at 14:42:17. This is the first event shown below, and the machine then continues to boot at 14:42:25
Cheers,
Rhoderick