| [ Web Proxy ] |
| Viewing: https://devblogs.microsoft.com/azure-vm-runtime/ | [Back] [Original] |
[Microsoft]
Dev Blogs
AI
All .NET posts
.NET MAUI
ASP.NET Core
Blazor
Entity Framework
C++
C#
F#
TypeScript
NuGet
Servicing
.NET Blog in Chinese
Microsoft for Developers
Agent Framework
Develop from the cloud
Xcode
ISE Developer
TypeScript
PowerShell
Python
Java
Java Blog in Chinese
Go
Microsoft Edge Dev
Microsoft 365 Developer
Microsoft Entra Identity Developer
Microsoft Entra PowerShell
Visual Studio
Visual Studio Code
Aspire
All things Azure
Azure SDK
Azure VM Runtime Team
Microsoft Azure
Azure Cosmos DB
Azure DocumentDB
Azure Data Studio
Azure SQL
DevOps
DirectX
Microsoft Foundry
Power Platform
OData
Unified Data Model (IDEAs)
Windows Command Line
#ifdef Windows
Inside MSIX
MIDI and music
React Native
The Old New Thing
Windows Developer
Azure VM Runtime Team
Many of you who have published VM Applications may have come across a difficult conundrum regarding security. To create an application version, you must upload your application package to a Storage blob, then provide the address of that Storage blob for replication to occur. The problem comes to the uri of the package. Until recently, there have been two options. Before I move to the solution, a few quick words about SAS urls. First, user delegated SAS urls are sadly not supported, because the service that manages the replication can't impersonate the user. Second, you may have a question about reuse...
One confusion around all of our extensions is: how are reboots handled? This varies by extension, but only VM Applications provide the option onhow to handle them. It does this via the "scriptBehaviorAfterReboot" property. "resources":[ { "type":"Microsoft.Compute/galleries/applications/versions", "apiVersion": "2024-03-03", "name": "[concat(parameters('galleries_mygallery_name'), '/', parameters('applicationDefinitionName'), '/', parameters('version'))]", "location":"[parameters('resourceLocation')]", "properties":{ ...
One confusing area regarding extensions on Azure VMs is - what happens when the OS disk is swapped out? Well, in that case the extensions will run again. Is this the desired behavior? Well, we don't know. There are many types of extensions. Some handle monitoring and security, so those you'll probably want to keep. Some install applications, like VM Applications. You'll probably want those re-installed. Others run a command, such as RunCommand or CustomScript. Those scripts will be re-run, which may be bad or good. Sometimes, those scripts setup the environment on the machine. In that case, it's good that t...
Today, all scripts run through Managed RunCommand will by default use Powershell 5. What if you have a script that requires Powershell7? This is supported via a new feature, but you will need to specify the different script shell. Here's what you need to do. Ensure your VM has Powershell7 Powershell7 is not installed by default. To ensure it's available on your machine, you have the following options. Here's an example on how to do this: By the time you read this, you'll likely need to update the download of Powershell7, which can be found here. To verify that everything installed,...
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 havetwo keyvaults. Each contains a password, but only one is valid. When a...
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...
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 ...
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...
One of the lesser known differences between RunCommand and CustomScriptExtension is the fact that wedo 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 CSEactually re-run the script? The answer is, itmay 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...
| Web Proxy Viewer | New URL | Original Page |
![[]](https://devblogs.microsoft.com/azure-vm-runtime/wp-content/uploads/sites/77/letter-avatar/cb7c83321aaa479a3d0e64e486589df7.svg){kind=link}