Slow Exchange Server Boot In Azure VM


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-2Exch-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.

 

Exch-2 Powered On At 09:41

Now it has entered a running state.  We should be able to connect to this after a couple of minutes?

Exch-2 Powered On And Now Runing

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.

 

A Whole Lot of ICMP Request Timed Out

 

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.

Event Log Showing StartUp Time

In the Event Logs we see errors where the Exchange services are not starting up as expected:

ADTopology StartUp Errors

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

OS Shutdown Time

 

OS StartUp Time

 

Cheers,

Rhoderick

Comments (10)

  1. P_rashant says:

    thanks for your articles.

    Thanks

  2. As I see the VMs are basic, did you tried the same with virtual machines having premium storage?

    1. Yes – I have other labs with premium storage, and same issue. That is not the issue with this Charles.

      Cheers,
      Rhoderick

      1. Are you trying to say one should not put Exchange VM in de-allocated state or there is a problem in azure VM booting after powering ON from deallocate state?

        1. The latter – It will take a while to come back up from the deallocated state — unless you do the workaround mentioned here and in the comments.

          Cheers,
          Rhoderick

  3. Great Informative article..

  4. Bryon Brewer says:

    I have experienced the same issue for the past 2 years… since using Exchange 2013. We use the environment for training classes, and it basically takes Exchange server 45 minutes to become available from a stopped state. I don’t really understand why this is happening. The logs show that it cannot find the LDAP / AD server. However, all other machines find it just fine. We’ve rebuilt the machine a couple times and still same issue. I’m not really sure why just Exchange servers have this issue. We have custom DNS set in Azure on the VM pointing to the AD server in the same environment.

  5. Dima says:

    Hi, Rhoderick! Thanks for the great blog 😉
    From my field experience, I just setup all services to delayed start- so, VM booting very fast, lower than five minutes. And then all services just starting automatically, so after 10 minutes max I had the server working properly.

    1. Good point! I resorted to my old Exchange 5 habits– a batch file to start and stop the Exchange services. NT did not feature such advanced logic as delayed start 🙂

      Cheers,
      Rhoderick

Skip to main content