VM's deployed from image no longer joining AAD?

AdamHarrison-6604 1 Reputation point

I am deploying an Azure Virtual Desktops pool and so far my testing has been fine, I have been deploying the VM's from an image which has been working - up until yesterday. Now, the machines are not joining AAD (whereas they were before), and therefore not showing as Session Hosts.

When I try to manually deploy a VM from the image, I see the message "This image does not support Login with Azure AD."


While I have been updating the image as I have been going along, the last change before this image was setting a local policy to map a network drive. That's it.

Anyone able to help me out here? I can't figure out what has gone wrong and how to fix it, and this needs to be up and running by Monday morning!!

Azure Virtual Desktop
Azure Virtual Desktop
A Microsoft desktop and app virtualization service that runs on Azure. Previously known as Windows Virtual Desktop.
1,387 questions
{count} votes

2 answers

Sort by: Most helpful
  1. Ravi Kanth Koppala 3,231 Reputation points Microsoft Employee

    @AdamHarrison-6604 ,
    Thank you for reaching out to the Microsoft Q&A platform. Happy to answer your question.

    Can you please confirm if you are using Azure AD, not Azure AD DS managed domain? If you are using Azure AD Ds, Did you create a testing base VM, did you select the checkbox “Login with Azure AD”? If that is correct, then the extension to Login with Azure AD joins the VM to Azure AD to enable another type of login but can cause conflicts if you need to join the VM to the Azure AD DS managed domain.

    If the above statements are true, please deleted everything that you previously created, Created a new VM, leave that check box unchecked, created an image, etc.

    If my understanding is not correct, can you please share more details so that I can help you? Thanks.

  2. srbhatta-MSFT 8,546 Reputation points Microsoft Employee

    Hello @AdamHarrison-6604 ,
    Thanks for reaching out on Microsoft QnA and for explaining your scenario.

    To answer what you asked above in the comments, no, creating an image from a VM that is already a AVD session host (part of a hostpool) should ideally not cause this.
    Looking at your scenario, as you have mentioned, you have a requirement of continually updating the image. So, I assume you have followed the process to first update the VM (that is the AVD session host) by making changes on it at the OS level. Then, you will have to generalize (sysprep) the VM at the OS level. After the sysprep is complete, you will have to remove the VM from the hostpool by clicking on the Remove option available for the session host.
    Then, you will have navigate to Virtual machines, from there go to the VM that you have just generalized, and select on Capture, which will create an image for you (Remember to take snapshots for rollbacks prior the sysprep). You can use this image to deploy an AVD session host in your desired hostpool. For convenience, you can also store the images in a Shared Image Gallery, where you can add the latest tag for the last updated image.

    You can refer to the below two videos, which will walk you through the steps in great details.
    Update session hosts from latest image - AVD
    Image Management - AVD

    Now, coming to the initial issue that you faced, you said after the most recent update of the image, where you had set a local policy to map a network drive, post which when you provisioned a new session host from updated image, you got the warning that "This image does not support login with Azure AD". Now, to understand why this happened, the issue needs to be reproduced and logs will need to be checked to understand the cause behind it. However, the 'upgrading' process is basically the AVD agent is updating/upgrading itself with the latest stable version. The session host might be stuck in the 'upgrading' state for 2-3 minutes, which is normal. However if it is stuck in the same state for quite a while, then it means that there might be issues with the installation of the AVD agent, and you can refer to this document to further understand the reason behind it. The 'upgrading' state means that connections to the AVD session host at that moment will not go through because the agent itself is upgrading, and you might face connectivity issues at that time. But, it does not have anything to do with image.

    In this case, I think the issue was with the latest updates/changes performed on the image, and to understand what were those changes, we would need to reproduce the situation, and maybe in this case support team will be able to help you to investigate on this step by step if you wish to repro the issue.

    Let me know if this helps.


    Please don't forget to 179759-accept.png and 179670-upvote.png if you think my response was helpful, so that it can help others in the community looking for help on similar issues. Thanks for helping improve Microsoft QnA.

    0 comments No comments