Login to Windows virtual machine in Azure using Azure AD authentication (and the pitfalls)!
Dear Microsoft Azure Friends, This article is about the login to Windows virtual machine in Azure using Azure Active Directory authentication and what needs to be considered in the process. This article describes the procedure. So far, everything is actually in perfect order. https://docs.microsoft.com/en-us/azure/active-directory/devices/howto-vm-sign-in-azure-ad-windows So I have worked through the steps and now I want to log on to the virtual machine with an Azure Active Directory account. Why does this error message appear now? Have I done something wrong? I am going through all the steps again. No fits. So I take another close look at the article and discover the following: But that's exactly not the case with me. I want to connect from my local system which is not registered or joined in Azure. Let's take it one step at a time. First of all, I create a group in Azure Active Directory. This will contain the account I will use later for the login. ATTENTION: Use the appropriate Windows OS => Windows Server 2019 Datacenter edition and later or Windows 10 1809 and later Next I create a new virtual machine with the default settings (including a public IP address and yes this is not good, but this demo absolutely OK). Except for Management I set the following settings. If you want to work with an existing virtual machine you need to install the extension. You can do this with the Azure Cloud Shell, in a Bash terminal. az vm extension set \ --publisher Microsoft.Azure.ActiveDirectory \ --name AADLoginForWindows \ --resource-group YourResourceGroup \ --vm-name YourVM After the virtual machine is created we need to work with Role based Access Control RBAC. There are two roles that can be used. Virtual Machine Administrator Login or Virtual Machine User Login If you need local admin rights you need the first role. If you want to log in as a standard user, you can work with the second role. Now we connect to the virtual machine using RDP, but ATTENTION, I use the account I created when I created the virtual machine (not an Azure AD account). In the virtual machine I start the command prompt and use dsregcmd /status. The machine is Azure AD Joined. In the virtual machine, navigate to Start and invoke "run". Type sysdm.cpl and navigate to the Remote tab. Remove the "Allow connections..." option and click "Select Users". When you click on "Locations" you will immediately see that you cannot select an account from Azure AD. We need the command prompt for this. Start the command prompt with elevated privileges and enter the following (customized with your information, of course). net localgroup "remote desktop users" /add "AzureAD\Email address removed" Go back to the Azure Portal to your virtual machine. Download the RDP connection file. Open this RDP file with an editor and add the following lines. enablecredsspsupport:i:0 authentication level:i:2 Now double click on the RDP connection file and now use the Azure account for login. AND BINGO, we can now log in to our virtual machine using the Azure Active Directory account! Cool! I hope this article was useful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerCreate a snapshot of a VM with PowerShell in Azure
Hi Azure friends, I used the PowerShell ISE for this configuration. But you are also very welcome to use Visual Studio Code, just as you wish. Please start with the following steps to begin the deployment (the Hashtags are comments): #The first two lines have nothing to do with the configuration, but make some space below in the blue part of the ISE Set-Location C:\Temp Clear-Host #So that you can carry out the configuration, you need the necessary cmdlets, these are contained in the module Az (is the higher-level module from a number of submodules) Install-Module -Name Az -Force -AllowClobber -Verbose #Log into Azure Connect-AzAccount #Select the correct subscription Get-AzContext Get-AzSubscription Get-AzSubscription -SubscriptionName "your subscription name" | Select-AzSubscription #Set some parameters $resourceGroupName = 'tw-rg01' $location = 'westeurope' $vmName = 'tw-winsrv' $snapshotName = 'mySnapshot' #Get the VM $vm = Get-AzVM -ResourceGroupName $resourceGroupName -Name $vmName #Create the snapshot configuration $snapshot = New-AzSnapshotConfig -SourceUri $vm.StorageProfile.OsDisk.ManagedDisk.Id -Location $location -CreateOption copy #Take the snapshot New-AzSnapshot -Snapshot $snapshot -SnapshotName $snapshotName -ResourceGroupName $resourceGroupName #Next steps in the Azure Portal #Create a virtual machine from a snapshot by creating a managed disk #from a snapshot and then attaching the new managed disk as the OS disk Now you have used the PowerShell to create a snapshot of virtual machine! Congratulations! I hope this article was useful. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerPersistent Virtual Machines provisioningState "Updating"
Hi, I'm trying to use Ansible to manage my Virtual Machine state via Ansible and some unexpected behaviour popped up. The Azure VM provisioningState never changed from "Updating" to "Succeeded" while the VM is running and available. I've validated this by querying the API using the Azure-CLI tool and checking : > az vm show -g cloudVMrg -n cloudVM |jq '.provisioningState' "Updating" After some searching it seems that this state is represented as is registered in Azure for the Virtual Machine. The state value "Updating" seems to me as an intermediate state whereafter Completed should be set. It seems that this doesn't or didn't happen in my case. The VM is started and available (I can SSH on to the machine) but its provisioningState is still "Updating". On Azure (see attached images) the changes logged on the VM confirm that the value was changed from "Succeeded" to "Updating" when the VM was changed from deallocated powerState. Is this a bug? What is a valid less intrusive and sustainable (automatable) workflow to resolve this issue? What is an effective (stateless) way to monitor this? I've followed this instruction however it doesn't exactly match my case, but it fixed the provisioningState; command ran like 10 minutes. Resolution - https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/vm-stuck-in-failed-state?tabs=cli
NV Series - WDDM vs TCC
According to the Azure GPU VM size guide (https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-gpu): NC, NCv2, and ND sizes are optimized for compute-intensive and network-intensive applications and algorithms, including CUDA- and OpenCL-based applications and simulations, AI, and Deep Learning. NV sizes are optimized and designed for remote visualization, streaming, gaming, encoding, and VDI scenarios utilizing frameworks such as OpenGL and DirectX. When I deploy a NV instance, the M60 GPU defaults to TCC mode when I think that it should be in WDDM mode: TCC being useful for compute workloads (NC or ND size) vs WDDM being appropriate for graphics workloads (NV size). In my experience, when the GPU is in TCC mode, RDP sessions are not able to leverage the GPU. Using the nvidia-smi tool to change the mode to WDDM: nvidia-smi -g {GPU_ID} -dm 0 and then rebooting the VM allows the RDP session to leverage the GPU. However, this setting does not persist. If the VM is shutdown/de-provisioned, when it is next started, the GPU is back in TCC mode and has to be switched to WDDM mode again. My research suggests that this is due to a setting stored in the EEPROM of the GPU. Am I missing something from a configuration standpoint to either get an RDP session to use the GPU in TCC mode or to always start the VM in WDDM mode?Upgrade Windows Datacenter Server from 2019 to 2022
Microsoft have just released Windows Server 2022 for Azure. Is it possible to update an existing Windows Server 2019 Datacenter to 2022? If so, how do you do it? One could, of course, build another server, but I should like to update the existing one. What are the cost implications if any? I realise a standalone server can be updated, but doing it under Azure may have other implications.
