Azure VM Runtime Team
Azure VM Runtime Team
Latest posts
Introducing Managed RunCommand Artifacts
As most of you may know from the current Managed RunCommand documentation there are multiple ways your script may be specified. However, what if your script uses various artifacts that also must be downloaded to the machine? Well, in the past it was necessary to call RunCommand are use some other technique to get those files on the machine. That process is now simplified. Added to the properties for Managed RunCommand is "artifacts". This is a collection containing artifacts with three properties. artifactUri - The uri from which to download the artifact. As with scriptUri, this may be a SAS ...
Using Managed RunCommand in an ARM Template
Perhaps one of the largest differences between "Action RunCommand" (internally called RunCommand V1) and "Managed RunCommand" (internally called RunCommand V2) is that Managed RunCommands are ARM resources themselves. That means you can use them in ARM templates. Recently, I needed to issue a RunCommand in an ARM template, so I looked around for examples how to do this. Yes, even though we wrote RunCommand, we're just as lazy as anyone else. However, I didn't find anything, so I thought I'd share how this works so others may be lazy where I failed. The following is an example resource for a VM. This is f...
When will CustomScript extension re-execute my script?
One of the lesser known differences between RunCommand and CustomScriptExtension is the fact that we do promise to not re-run your script in RunCommand, but no such promise exists for CustomScript. This is mentioned in the documentation, which isn't often fully understood. However, more than once I've been asked: when does CSE actually re-run the script? The answer is, it may run on a reboot. This can happen if your script never finished running. This is actually by design, since many scripts run by CSE may reboot the machine. So, in that case the scripts runs, installs some stuff, reboots the machine...
The treatFailureAsDeploymentFailure flag
In both VmApplications and RunCommand, we support a property called "treatFailureAsDeploymentFailure". Note that for Managed RunCommand it may not be visible yet in Powershell or CLI, but it is available via ARM. Note that this flag is only available for managed RunCommand. It is not available for action RunCommand. For those unaware, managed RunCommand is the newer version and should be used by default. This flag originated in VmApplications, where the question arose "what if my application should fail to install?" Should this result in a failed deployment? In some cases yes, but in others no. The truth is we...
Working with VM Application Names
I admit that VM Application names can be a bit tricky, or at least non-intuitive. The basic issue is this, you have some binary - let's call it MyApp.exe - and you want to install it on your VM. Therefore, you create a blob with the name MyBlob and set your install script to the following: You then name your VM Application "MyVmApp" and deploy it to a VM. The install will not work. Why? Because when we download your package to your VM, we'll rename it as "MyVmApp" (no extension). Why do we do that? Well, the VM doesn't know what name your package should be called. Therefore, it gives it the best name...
Working with unmanaged storage account quotas in VM Applications
While working with VM Applications, it's possible to receive the following error. Operation could not be completed as it results in exceeding approved UnmanagedStorageAccountCount quota. Additional details - Deployment Model: Resource Manager, Location: northeurope, Current Limit: 64, Current Usage: 64, Additional Required: 1, (Minimum) New Limit Required: 65. Please read more about quota increase at https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits As errors go, this one is well done. It describes the problem, the current quota, and how to go about f...
How to determine if your Runcommand script failed
Today, we're going to cover what can be a maddening issue in just determining whether your script failed. Let's start with a very simple operation. Open a Powershell window and run the following: This shouldn't be rocket science here. It's very clear that "this is an error" is, in fact, an error. So, with this universal fact determined, let's run it on an Azure VM. And now let's see the result. Note that you need to pass in -expand "instanceView" to see the actual error. Without this, you'll receive the following. This leads one to believe everything worked, when it didnt't. So, the first lesson...
Long running RunCommands
Recently, there's been a bit of confusion involving long running RunCommands. For reference, the default wait time for RunCommand has been 90 minutes - the same as all other extensions. But what if you have a script that takes longer? Well, we've added a timeoutInSeconds parameter just for that purpose! The only slight problem is this won't work. If your script runs for more than 90 minutes, you'll see an error like this. Huh? As long as it's within the boundary of your timeout, shouldn't it work? The problem lies with how RunCommand executes. There are two modes - synchronous and asynchronous...
RunCommand vs Custom Script Extension vs VM Applications
I'm sure that many of you would swear that Microsoft loves to confuse you. Currently, there are not three but four ways to run code on your machine. Now, I know what you're saying. "I just want to run this thing on my machine! Which do I choose?" Well, here I hope to clear that up. First, all of the above work on both Windows and Linux. They also work on both Virtual Machines and Virtual Machine Scale Sets. However, their behavior for the latter differs. Let's start out with the simplifying the problem: there is rarely a reason to use Custom Script Extension. Personally, I don't have...