Azure VM Runtime Team
Azure VM Runtime Team
Latest posts
Properly cycling domain passwords with the JSonADDomain extension
For those familiar with the JsonAdDomain extension, it provides an easy way to join VMs to your domain. However, one aspect that customers have been less crazy about is that the domain password must be shared in the protected settings (where it is at least encrypted) and, more importantly, the functionality of the extension doesn't work well with standard security practices. There are several basic security practices involving something like a domain password: The standard procedure for cycling passwords is to actually have two keyvaults. Each contains a password, but only one is valid. When a...
So how many replicas should my VM Application use?
One great advantage of VM Applications is the ability to specify how many replicas you want for each VM Application version. While documentation exists on how to specify replicas, we don't really provide advice on determining how many replicas to use. The goal of this post is to rectify that gap. First, the basics. When you specify a replica count, we create one storage account behind the scenes for each replica. These are shared across versions of the same application. So, if you have version 1, 2, and 3, and each has 3 replicas, then they'll all use the same storage account underneath. Different applications...
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...