Configuring USB Redirection for Azure Virtual Desktop for special devices, including COM/serial devices is very easy.

On the session host, you need this GPO:

Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection.

Do not allow supported Plug and Play device redirectionDo not allow supported Plug and Play device redirection -> set to Disabled

Local device configuration:

Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > RemoteFX USB Device Redirection.

Allow RDP redirection of other supported RemoteFX USB devices from this computerAllow RDP redirection of other supported RemoteFX USB devices from this computer -> Set to Administrators and Users

Be sure the GPO has been applied. To be safe, restart the Session Host and your physical device. After starting the destop, you are able to redirect your devices:

Note: This only works on Windows Pro / Enterprise / Education Clients. Home Edition is not supported, unfortunately.

References:

https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-configure-usb?tabs=intune&pivots=azure-virtual-desktop

If you need a quick and dirty way to give a user the permission to start a VM without giving them access to the Azure Portal, Azure Automation Webhooks might help. You basically create a PowerShell script that starts the VM and then you configure the Webhook. The Webhook contains an URL which triggers the exceution of that script. Note that everyone with the URI is able to start the VM, which is not optimal.

Once you have created the Automation Account (easy), configure a new Runbook that starts the VM:

Disable-AzContextAutosave -Scope Process

$subscriptionID = Get-AutomationVariable -Name 'SubscriptionID'

Connect-AzAccount -Identity

Select-AzSubscription $SubscriptionId

Start-AzVM -ResourceGroupName "rgname" -name "vmname"

Configure the WebHook. You will get an URI. Save that URI somewhere, since you cannot view it after being created.

Afterwards, a user can run this line to start the VM:

Invoke-WebRequest -URI "https://xxxx.webhook.webhook.azure-automation.net/XXX" -Method POST -UseBasicParsing

Note: the automation account needs to have Virtual Machine Contributor rights on the resource group or subscription to start the VM.

References:

https://learnwithlenny.azurewebsites.net/2022/11/04/starting-an-azure-vm-using-webhook-powershell-exe/

Azure VM Sizes are very confusing and there are a lot of them that seem very similar. This website helps you compare VM sizes with each other, showing you price/performance ratio etc.

https://sparecores.com/

If you need to delegate Azure Bastion to a user without assigning too many rights, here are some tips for you:

• User needs to have Virtual Machine login or Virtual Machine Administrator Login on VM or Resource Group where the VM is located
• Read rights are needed on Bastion Resource Group
• Make sure to wait 5-10 mins after applying settings

An Azure Service Principal is a service account created in Azure AD and can be leveraged in PowerShell scripts for automation. It is recommended to use Service Principals for security reasons since they have separate credentials and very constrained rights.

You can either use password-based authentication or certificate-based authentication with Service Principals. In this article, only password-based authentication is covered. Certificate-based authentication is treated in the Microsoft article linked at the end of the page.

First of all, the Az Powershell Module is needed.

Install-Module -Name Az -AllowClobber -Scope Allusers

If you have multiple subscriptions, make sure you have selected the correct one.

Get-AzSubscription

Select-AzSubscription -SubscriptionId xxxxxxxxx

Now create the Principal:

$sp = New-AzADServicePrincipal -DisplayName PowershellAutomation

The $sp object contains a secret parameter (the password), which is not in clear-text and an ApplicationID, that will be used as the username. To decrypt the secret parameter use the following commands:

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.secret)
$UnsecurePassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)

In a script the $UnsecurePassword should not be hardcoded, instead, it should be saved as an encrypted XML file and decrypted when the script is executed. I wrote a post about securing credentials in PowerShell scripts, check it out: https://www.ajni.it/2020/05/powershell-encrypt-and-store-your-credentials-securely/.

Logging in is also straightforward. The Tenant id can be retrieved in the main page of Azure AD.

Connect-AzAccount -ServicePrincipal -Credential $credentials -Tenant xxxxx

When assigning rights, the newly created identity will be listed:

References:

https://docs.microsoft.com/en-us/powershell/azure/create-azure-service-principal-azureps?view=azps-3.8.0