Azure Cloud Service Startup Task that requires reboot

Question

Tried with osFamily 4, osVersion *

Background: we have an app that uses System.Management.Automation.dll (from the GAC, dev box is W10) to work with Powershell in C# code. Specifically, we are using InitialSessionState and the ExecutionPolicy property - which we found out is part of WMF 5 (it errors out with not found exception on type load on the cloud service).

Now, this can be properly fixed by installing WMF 5 (we tried first via Remote Desktop; and no, forcing only the newer smadll into the GAC does not work). Problem is, the installer asks for a reboot - and that I think is a problem with the startup task.

We added the installer to the setup.cmd that we already had:

Win8.1AndW2K12R2-KB3134758-x64.msu /quiet

It indeed automatically reboots the role instance, and runs setup.cmd again (which adds an error entry to the setup event log to the tune that it is already installed).

This reboot does not flag the cloud service deployment as failed. Which we are happy about but, is this really a supported behavior? or accidental?

Is there the supported way to make an installer work that requires a reboot? Or is the behavior we found the "supported" way?

Answer 1

There's not really a "supported" way - how you initialize your cloud service is really up to you. Having said that:

Given that cloud service role instances typically survive reboots, there's nothing wrong with setting something up that requires a reboot. Then it's a matter of dealing with already-installed software when returning from the reboot (eg leaving a breadcrumb file from your .cmd that installed the software initially). This is sometimes the only way you can install software (where reboots are involved), and utilizing a breadcrumb helps cut down on subsequent reboot time (the clock-time required to complete the boot process; not the number of actual reboots).

In this type of scenario, only the initial role instance boot has an additional reboot. (other reboots, from Guest OS and Host OS updates, or failed hardware etc., are separate, of course).