Skip to main content

How to create a Free Azure Log Analytics Workspace using PowerShell

· 2 min read

When you create a Log Analytics workspace using the Azure Portal, you only get the Pricing or 'Pay-as-you-go' tiers to select.

You used to create a 'Free' tier using the Azure Portal; however, since 2018; they removed it with a change in plans and it became a legacy offering.

However, using PowerShell, you can still create a Log Analytics Free SKU!

The Free pricing tier is a legacy pricing tier that is available for trying Azure Log Analytics. It has a data cap of 500 MB/day and only 7 days of data retention, so it is intended only for testing and is not to be used for production deployments.

You can change a Free Tier Log Analytics workspace to a Pay-as-you-go or commitment tier later.

You cannot change a Log Analytics workspace created on a higher tier back to Free, even using PowerShell, due to adjustments in 2018 around the Log Analytics billing and plans.

Azure Log Analytics - Free

Create a 'Free Tier' Log Analytics using PowerShell

Change the script's variables below to suit your environment, connect to Azure and run the script to create your Log Analytics workspace.

Note: I tested this script on an MSDN subscription, which I've had for a few years and a recent one created a few months back (2021), but there may be limitations on other subscription types that I haven't tested - see blurb below the script.

#Connect to Azure
Connect-AzAccount

#Set Variables
$ResourceGroup = 'aad_mgmt'
$Location = 'australiaeast'
$LogAnalyticsName = 'la-free'
$SKU = 'Free'

#Creates Log Analytics Workspace
New-AzOperationalInsightsWorkspace -Location $Location -Name $LogAnalyticsName -Sku $SKU -ResourceGroupName $ResourceGroup

If you get an error: Error Message: Pricing tier doesn't match the subscription's billing model. Read http://aka.ms/PricingTierWarning for more details, unfortunately it means that your Subscription is under a different Billing model, and may have been created recently are you are unable to use the 'Free' tier, instead you may have to create it using 'standard' instead.

Azure Log Analytics - Free

How to set a Log Analytics Daily Data Cap

· One min read

This is just an additional configuration that may help with sizing and pricing Log Analytics, you can set a 'Daily cap' for the amount of Data you ingest per day, to help restrict cost.

The downside of this is if you reach the cap, you will no longer collect any data, until the following day, meaning you may miss key events or issues.

This is something that I would recommend ONLY to do if you run into any financial constraints, giving you more time time to work through, of course, situation depending.

This is a pretty quick 'How To' so let's get straight into it:

  1. Log in to the Azure Portal
  2. Search for your Log Analytics Workspace
  3. Select Usage and estimated costs
  4. Click on Daily Cap
  5. Set your cap in GB (I put 0.166 as my thinking was 5GB per free each month, so 166MB a day, should cap my Log Analytics workspace, although useful for this demo/lab, it's not a number I would recommend for Production)
  6. Click Ok

Log Analytics - Set Daily Cap

Create Custom Roles for Microsoft Azure

· 12 min read

Microsoft Azure uses Role's to define who can access what - Role-Based Access Control (RBAC).

You may be familiar with some of the more common ones, such as:

  • Owner
  • Contributor
  • Reader

Behind the scenes, each role is a separate grouping of permissions that determine what level of permissions someone or something has in Azure; these permissions are usually in the form of:

  • Read
  • Write
  • Delete
  • Action

Each role can be assigned to a specific Resource, Subscription, Management Group or Resource Group through an 'Assignment' (you assign a role if you give someone Contributor rights to a Resource Group, for example).

These permissions can be manipulated and custom roles created.

Why would you use custom roles you ask? As usual - it depends!

Custom Roles can give people or objects JUST the right amount of permissions to do what they need to do, nothing more and nothing less, an example of this is maybe you are onboarding a support partner, if they are will only be supporting your Logic Apps, WebApps and Backups, you may not want them to be able to log support cases for your Azure resources; instead of attempting to mash several roles together that may give more or fewer rights than you need, you can create a custom role that specifically gives them what they need, you can then increase or decrease the permissions as needed, however, if a built-in role already exists for what you want. There is no need to reinvent the wheel, so use it!

I will run through a few things to help arm you understand and build your own Custom Roles, primarily using PowerShell.

Install the Azure PowerShell Modules

As a pre-requisite for the following, you need to install the Azure (Az) PowerShell Module. You can skip this section if you already have the PowerShell modules installed.

  1. Open Windows PowerShell

  2. Type in:

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
    Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
  3. If you have issues installing the Azure PowerShell module - see the Microsoft documentation directly: Install the Azure Az PowerShell module.

  4. Once you have the Azure PowerShell module installed, you can connect to your Azure subscription using the little snippet below:

    #Prompts for Azure credentials 
    Connect-AzAccount
    #Prompts Window allowing you to select which Azure Subscription to connect to
    $subscriptionName = (Get-AzSubscription) | Out-GridView -Title 'Select Azure Subscription' -PassThru | Set-AzContext -SubscriptionName $subscriptionName

Export Built-in Azure Roles

One of the best ways to learn about how an Azure Role is put together is to look at the currently existing roles.

  1. The following PowerShell command will list all current Azure roles:

    Get-AzRoleDefinition
  2. For a more human-readable view that lists the Built-in Azure roles and their descriptions, you can filter it by:

    Get-AzRoleDefinition | Select-Object Name, Description
  3. As you can see in the screenshot below, there are many various roles, from EventGrid Contributor to AgFood Platform Service and more! At the time of this article, there were 276 built-in roles.

  4. Azure Builtin Roles

  5. Now that we have successfully been able to pull a list of the existing roles, we will now export them as JSON files to take a proper look at them.

  6. The PowerShell script below will create a few folders on your computer as a base to work from (feel free to change the folders to suit your folder structure or access rights).

    • c:\Temp
    • c:\Temp\AzureRoles
    • C:\Temp\AzureRoles\BuiltinExports\
    • C:\Temp\AzureRoles\CustomRoles
  7. Once the folders have been created, it will Get the Azure Role definitions and export them into JSON into the BuiltinExports folder to be reviewed.

    New-Item -ItemType Directory -Path c:\Temp -Force
    New-Item -ItemType Directory -Path c:\Temp\AzureRoles -Force
    New-Item -ItemType Directory -Path c:\Temp\AzureRoles\BuiltInExports -Force
    New-Item -ItemType Directory -Path c:\Temp\AzureRoles\CustomRoles -Force

    $a = Get-AzRoleDefinition

    Foreach ($role in $a)
    {
    $name = $role.Name
    Get-AzRoleDefinition -Name ($role).Name | ConvertTo-Json | Out-File c:\Temp\AzureRoles\BuiltInExports\$name.json
    }
  8. Once completed, you should now see the JSON files below:

  9. Azure Role - JSON files

Although you can use Notepad, I recommend using Visual Studio Codeto read these files. This is because Visual Studio Code will help with the syntax as well.

Review Built-in Azure Roles

If you open one of the roles, I will open the Azure Digital Twins Data Owner role; however, it doesn't matter.

You should see the following fields:

  • Name
  • Id
  • IsCustom
  • Description
  • Actions
  • NotActions
  • DataActions
  • NotDataActions
  • AssignableScopes

These fields make up your Role.

Azure Role - JSON

  • The Name field is pretty self-explanatory - this is the name of the Azure Role and what you see in the Azure Portal, under Access control (IAM).

  • Azure Portal - Role

  • The same is true for the: Description field.

    These are essential fields as they should tell the users what resource or resources the role is for and what type of access is granted.

  • The IsCustom field is used to determine if the Azure Role is a custom made policy or not; any user-created Role will be set to True, while any In-Built role will be False.

  • The Actions field is used to determine what management operations can be performed. However, the Azure Digital Twins role doesn't have any (as it is mainly Data Action based) if we look at another Role such as the: Azure Kubernetes Service RBAC Admin role:

    • ""Microsoft.Authorization/*/read",
    • "Microsoft.Insights/alertRules/*",
    • "Microsoft.Resources/deployments/write",

    You can see that it has the rights to Read the permissions, create and delete any Alert rules and update resources.

  • The NotActions field is used to exclude anything from the Allowed actions

  • The DataActions field allows you to determine what data operations can be performed. Usually, these are sub-resource tasks, where management or higher-level operations are performed in the Actions field, more specific resource actions are performed in the DataActions field.

    The NotDataActions field is used to exclude anything from the Allowed actions in the DataActions

To help get a feel of the differences with the Actions, here is a list of Actions and DataActions for the Azure Kubernetes Service RBAC Admin role:

  • Azure Custom Role - JSON
  • And finally, the AssignableScopes is used to specify where the role will be available for assignment, whether it can be assigned at a subscription or resource group or management group level. You will notice that most if not all built-in Azure Roles have an Assignable scope of "/" - this means that it can be assigned everywhere (Subscriptions, Resource Groups, Management Groups etc.).

Review Azure Provider Namespaces

You may have noticed that each Action has a provider. In the example of a Virtual Machine, the provider is Microsoft.Compute.

  1. To get a list of all current Providers, run the following command:

    Get-AzProviderOperation | Select-Object ProviderNamespace -Unique

    At the time of writing, there are 198 current Providers! So that's 198 providers or overall buckets of resources that has permissions over.

  2. We can drill into a provider a bit further to check out current Operations:

    Get-AzProviderOperation -Name Microsoft.Compute/*
  3. This displays a list of all providers within the Microsoft.Compute namespace, such as (but definitely not limited to):

    1. Virtual machines
    2. Virtual Machine Scale Sets
    3. Locations
    4. Disks
    5. Cloud Services
  4. If we wanted to drill into the Virtual Machines providers a bit more, we could filter it like:

    Get-AzProviderOperation -Name Microsoft.Compute/virtualMachines/*
  5. Here we can finally see the available actions, and for example, the following Action will allow you to Read the VM sizes available to a Virtual Machine:

  • Operation: Microsoft.Compute/virtualMachines/vmSizes/read
  • operation name: Lists Available Virtual Machine Sizes
  • ProviderNamespace: Microsoft Compute
  • ResourceName: Virtual Machine Size
  • Description: Lists available sizes the virtual machine can be updated to
  • IsDataAction : False
  1. You can use the PowerShell script below to export all the Providers and their Operations to a CSV for review:

    $Providers = Get-AzProviderOperation

    $results = @()

    ForEach ($Provider in $Providers) {



    $results += [pscustomobject]@{
    'Provider NameSpace' = $Provider.ProviderNamespace
    Description = $Provider.Description
    'Operation Name' = $Provider.OperationName
    Operation = $Provider.Operation
    ResourceName = $Provider.ResourceName


    }

    }

    $results | Export-csv c:\temp\AzureRBACPermissions.csv -NoTypeInformation

Using the namespace, providers and actions, you should now be able to see the power behind Role-based access control and how granular you can get.

Add a Custom Role using PowerShell

Now that we understand how to navigate the Namespaces and Built-In Roles available in Microsoft Azure using PowerShell, now we will create one.

I have created a base template to help you start.

This base template has the following fields that the majority of most custom roles will use:

  • Name
  • IsCustom
  • Description
  • Actions
  • AssignableScopes (make sure you put in the of your Azure subscription, you are assigning the role to.)
  1. Edit these fields (apart from IsCustom, which you should leave as True) as you need.
CustomRoleTemplate.json

{
"properties": {
"roleName": "Custom Role - Template",
"IsCustom": true,
"description": "This is a Template for creating Custom Roles.",
"assignableScopes": [
"/subscriptions/<SubscriptionID>"
],
"permissions": [
{
"actions": [
"Microsoft.Support/register/action",
"Microsoft.Support/checkNameAvailability/action",
"Microsoft.Support/operationresults/read",
"Microsoft.Support/operationsstatus/read",
"Microsoft.Support/operations/read",
"Microsoft.Support/services/read",
"Microsoft.Support/services/problemClassifications/read",
"Microsoft.Support/supportTickets/read",
"Microsoft.Support/supportTickets/write",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Resources/subscriptions/resourcegroups/resources/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
]
}
}

This Custom Role - Template allows you to read the name of all Resource Groups in a subscription and open a Microsoft Support case.

In my example, I am going to add a new role called:

  • LukeGeek-WebApp Deployment-RW

This role will allow users to Deploy and modify Azure WebApps, among other things!

LukeGeekWebDeployment-RW.json

{
"properties": {
"roleName": "Custom Role - Template",
"description": "This is a Template for creating Custom Roles.",
"IsCustom": true,
"assignableScopes": [
"/subscriptions/<SubscriptionID>"
],
"permissions": [
{
"actions": [
"Microsoft.Support/register/action",
"Microsoft.Support/checkNameAvailability/action",
"Microsoft.Support/operationresults/read",
"Microsoft.Support/operationsstatus/read",
"Microsoft.Support/operations/read",
"Microsoft.Support/services/read",
"Microsoft.Support/services/problemClassifications/read",
"Microsoft.Support/supportTickets/read",
"Microsoft.Support/supportTickets/write",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Resources/subscriptions/resourcegroups/resources/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
]
}
}

  1. To add the Custom Role to Azure, I will run the following PowerShell command:

    New-AzRoleDefinition -InputFile "C:\\temp\\AzureRoles\\CustomRoles\\LukeGeek-WebApp Deployment-RW.json" -Verbose

Your new Custom Role has now been uploaded to Azure and can be selected for an assignment.

Add a Custom Role using the Azure Portal

Now that we have been through and investigated the Azure roles and their providers and actions, instead of using PowerShell to look through and create manually, you can use the Azure Portal!

Gasp! Why didn't you tell me earlier about this, Luke?

Well, fellow Azure administrator, I found it easier to look at PowerShell and JSON to explain how the Custom Roles were made, vs staring at the Azure Portal and to be honest, really just because! Like most things in IT there are multiple ways something can be done!

  1. Log in to the Azure Portal
  2. Navigate to your Subscription
  3. Click on Access Control (IAM) on the left-hand side blade
  4. Click on Add
  5. Click on Add Custom Role
  6. Type in the Role Name, for example, WebAdmin-RO
  7. Type in a clear description so that you can remember what this role is used for in a year!
  8. For Baseline permissions, select: Start from Scratch
  9. Click Next
  10. Click Add Permissions
  11. If you want, you can select: Download all permissions to review the providers and actions (very similar to the Get-AzProviderOperation PowerShell command).Azure Portal - Create Custom Role
  12. As you should see, all the Namespace providers are listed with the Actions/Permissions that you can do.
  13. In my example, I am going to search for Microsoft Web Apps
  14. Select all 'Read' operations (remember to look at Data Actions as well, there may be resource level actions you might want to allow or exclude)
  15. Click Add
  16. Azure Portal - Create Custom Role
  17. Review the permissions and click Next
  18. Select your assignable scope (where the Role will be allowed so that you can assign it)
  19. Click Next
  20. You can review and download the JSON for backup later (this is handy if you are going to Automate the creation of roles in the future and want a base to start from)
  21. Click Next
  22. Click Create to create your Custom Role!
  23. Azure Portal - Create Custom Role

Assign a Custom Role using the Azure Portal

Now that you have created your Custom Role - it is time to assign it! So it is actually in use.

  1. Log in to the Azure Portal
  2. Navigate to your Subscription or Resource Group you want to delegate this role to
  3. Click on Access Control (IAM)
  4. Click Add
  5. Click on Role Assignment
  6. Under the 'Role' dropdown, select your Custom Role.
  7. Azure Portal - Add Role Assignments
  8. Now you can select the Azure AD Group/User or Service Principal you want to assign the role to and click Save.
  9. Congratulations, you have now assigned your Custom role!

Assign a Custom Role using PowerShell

You can assign Custom Role's using PowerShell. To do this, you need a few things such as the Object ID, Assignable Scope IDs etc., instead of rehashing it, this Microsoft article does an excellent job of running through the process.

Add a shortcut to the Azure Virtual Desktop Web Client to the Microsoft 365 waffle

· 3 min read

If you are like me, you use the application launchers in the Microsoft 365 waffle daily, if not hourly! Then having it as a single pane of glass to access all your applications is a no-brainer!

That includes access to the Azure Virtual Desktop Web client! In addition, Microsoft has given us the ability to add Custom App Launchers for applications that are accessible to a URL to the Launchers in the waffle!

Create custom tiles that will appear in the All apps section of the Office 365 app launcher for all of your users. Users can pin the custom tiles directly to their app launcher for quick access.

You can add much more than the Azure Virtual Desktop web client to help improve your user's experience, but this quick guide will focus on adding the Azure Virtual Desktop Web Client.

M365 Waffle

  1. Open the Microsoft 365 Admin Panel
  2. Expand Settings
  3. Click on Org Settings
  4. Select Organisation Profile
  5. Click on Custom app launcher tiles

M365 - Organisation Profile

  1. Click + Add a custom title.
  2. Please type in the name of your Desktop; in my example, it is Contoso Desktop.
  3. For the URL of the website, type in: https://rdweb.wvd.microsoft.com/arm/webclient/index.html
  4. Type in a URL of the icon you want the App Launcher to have (Make sure this is a location that you have access to and can manage (i.e. even sitting on your website or Azure Storage account as long as it's publically available)).
  5. Add a description (such as Contoso Desktop, used for Line of Business Applications)
  6. M365 - Custom App Launcher
  7. Click Save
  8. M365 - Custom App Launcher
  9. Log out of your Admin account and log into an account with an Exchange license attached to it. It may take some time for the Custom App Launcher to display.
  10. Once the Custom App Launcher has displayed, your users can pin it to the launcher, so it is always right on top.
  11. Click on your Azure Virtual Desktop launcher, and you should be redirected to the Azure Virtual Desktop Web client!
  12. M365 Waffle - App Launcher

Just some notes on additional testing:

  • I attempted copying the Azure Virtual Desktop RDP file (C:\Users\%UserAccount%\AppData\Local\rdclientwpf) to my website to access directly however received an error, even opening up the RDP file directly failed, to test the Remote Desktop client.
  • I had some success opening that RDP up with the Remote Desktop application directly using 'Open With' C:\Users\%UserAccount%\AppData\Local\Apps\Remote Desktop\msrdcw.exe, instead of the default Remote Desktop Connection client locally.
  • This will add it for all M365 users, if you want to restrict it to Users/Groups, I would look at testing and creating an App Registration.

At this stage, having a launcher to the Web Client is the best bet vs a shortcut directly to the RDP file as you don't have to worry about users having the Remote Desktop agent installed when working remotely.

Start VM on Connect for Azure Virtual Desktop

· 7 min read

One of the models of Cloud governance and cost in Microsoft Azure is 'Pay As You Go', ie. Pay for what you need when you need it.

The Azure Resource Manager fabrics allow you to scale up and down resources when you need it, whether built-in to the Azure portal or through various other automation mechanisms.

For Azure Virtual Desktop, this means ensuring that session hosts (Virtual Machines) are available for users to connect to consume their services when they need it the most, whether first thing in the morning or late hours of the evening.

One of the technologies that can help with this is: Start VM on Connect(Start VM on Connect allows users to start the virtual machine from a deallocated state).

You no longer need to create a Custom Role for Start VM on Connect - a built-in role now exists named: Desktop Virtualization Power On Contributor - once that role is assigned to the Azure Virtual Desktop application, you can skip straight to Configure

  • Imagine a 9 AM -> 5 PM Monday to Friday business; during the day, Azure Virtual Desktop is available, however anything out of these hours (through Scheduled Shutdowns or Azure Automation Runbooks etc.), the session hosts are shut down to reduce operational costs.
  • A business user gets some urgent work on Saturday morning and then tries to connect to Azure Virtual Desktop resources to complete the work; because they were turned off outside of business hours, they can't connect and then have to ring IT support to get resources started (the alternative would be to leave Virtual Machines running, which may or may not be needed).
  • Using 'Start Virtual Machine on Connect', the moment that the user attempts to connect a Virtual Machine is started.
  • Then it allows the users to log in and do their work without a call to IT, overall saving money, as the hosts are only started when they are first needed. The feature will also only turn on additional VMs (if available) when the first VM reaches the session limit.

This is a host-level setting, so setting 'Start VM on Connect' will affect all session hosts in the host pool. Therefore, you cannot target specific Virtual Machines in a session host at this stage. This is now supported for both Personal and Pooled session hosts!

As of 03/07/21 (NZ date format - DD/MM/YY): The Start VM on Connect feature is currently in public preview. This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

Follow the guide below to implement; the Microsoft documentation is pretty good but hoping this might fill in a few gaps for people.

Create a Custom Role for "Windows Virtual Desktop"

For the "Windows Virtual Desktop" service principal (this should already exist, it is an inbuilt SPN created by the Azure infrastructure, it is currently called Windows Virtual Desktop but expect this name to be updated in the future) to have the ability to Start a Virtual Machine, we first need to give it rights. You could give it Contributor or Virtual Machine Contributor rights but want to go with the least privileged to create a custom role.

  1. Log in to the Azure Portal
  2. Navigate to the Subscription (you can only currently create custom roles at a subscription level) that your session hosts exist in
  3. Look for the Subscription ID (copy this, we will need it later on, usually found on the Overview window of the Subscription)
  4. Download the AVD-StartVMOnConnect JSON file below and save it to a location you can edit.
AVD-StartVMOnConnect.json
{
"properties": {
"roleName": "AVD-StartVMOnConnect",
"description": "Custom role, designed to allow 'Windows/Azure Virtual Desktop' rights to Start session hosts.",
"assignableScopes": [
"/subscriptions/<SubscriptionID>"
],
"permissions": [
{
"actions": [
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
]
}
}

  1. Open up the JSON file (this is the Custom Role we are creating, as you can see, we are only allowing the ability to Read a Virtual Machine and Start it)

  2. Replace the: with your subscription ID, created earlier and save the JSON file.

  3. AVD-StartVMOnConnect Custom Role.

  4. Click on Access Control (IAM) on the left-hand side blade

  5. Click Add

  6. Click Add Custom Role

  7. AVD-StartVMOnConnect Custom Role

  8. Name your Custom Role Name something meaningful, for example, AVD-StartVMOnConnect.

  9. Add a meaningful Description; for example, mine is:

    Created: 03/07/21

    Created by: Luke Murray

    Created for: Custom role, designed to allow 'Windows/Azure Virtual Desktop' rights to Start session hosts.

  10. For: Baseline permissions, select Start from JSON

    Select the JSON file you downloaded and edited earlier

  11. AVD-StartVMOnConnect Custom Role

  12. Click on Next

  13. Verify the permissions are as below (if they aren't, you may need the redownload or check the JSON file for syntax issues - I recommend downloading Visual Studio Code):

  14. AVD-StartVMOnConnect Custom Role

  15. Click Next

  16. We used the subscription property to select the assignable scope (i.e. the scope is where this role will be available for you to assign access to), but now using the Azure Portal, we can select a specific Resource Group to limit the roles access, please be careful with doing this, especially if you are planning on expanding out your Azure Virtual Desktop infrastructure in the future as you may forget that this role may not be available in other resource groups. I am going to leave mine at the Subscription level and click Next

  17. Here we can verify and save the changed JSON file (if you want for future reference) and click Next to review your configuration.

  18. Click Create to create your Custom Role!

  19. AVD-StartVMOnConnect Custom Role

Assign your Custom Role

Now that you have created your custom role for Azure Virtual Desktop, it is now time to assign it, and this is where you can assign and lock down the role; in my case, I only have one Resource Group where my session hosts sit in, so going to assign it a Resource Group level, but feel free to assign this at a subscription level.

  1. Log in to the Azure Portal
  2. Navigate to the Resource Group (or Subscription) that has your Azure Virtual Desktop session hosts
  3. Click on Access Control (IAM) in the left-hand side blade
  4. Click on + Add
  5. Click on Add role assignment
  6. Select the Role you created earlier (i.e. AVD-StartVMOnConnect)
  7. Specify the 'Windows Virtual Desktop' service principal and select Save
  8. AVD-StartVMOnConnect Custom Role
  9. If you want, you can click on Role Assignments to verify your role has been assigned:
  10. AVD-StartVMOnConnect Custom Role

Configure Start VM on Connect

  1. Log in to the Azure Portal
  2. Navigate to your Host Pool
  3. Click on Properties
  4. Select 'Yes' to Start VM on Connect
  5. Click Save
  6. Azure Virtual Desktop - Start VM on Connect
  7. Congratulations, you have now set up Azure Virtual Desktop - Start VM on Connect; next time someone connects to a turned-off Azure Virtual Desktop session host, the Virtual Machines will now automatically start the users will get a prompt like below:
  8. Azure Virtual Desktop - Start VM on Connect
  9. Azure Virtual Desktop - Start VM on Connect
  10. Before finally prompting for their login credentials!