Azure AD PowerShell module version 2.0.1.6 released

Another minor version of the Azure AD PowerShell module released at the end of last week, namely 2.0.1.6. The modules doesn’t bring anything that interesting, which seems to be the trend lately. Only the following new cmdlets have been introduced:

Get-AzureADMSDeletedGroup
Get-AzureADMSDeletedDirectoryObject
Remove-AzureADMSDeletedDirectoryObject
Restore-AzureADMSDeletedDirectoryObject

All of these were available as part of the AzureADPreview module, which did NOT receive a newer version this time around. In other news, it seems that both modules are now renamed to feature “for Graph” in their designation:

Azure Active Directory PowerShell for Graph – General Availability Release 2.0.1.6

and

Azure Active Directory PowerShell for Graph – Public Preview Release 2.0.1.2

This entry was posted in Azure AD, Office 365, PowerShell. Bookmark the permalink.

6 Responses to Azure AD PowerShell module version 2.0.1.6 released

  1. Dave green says:

    Hi Vasil,

    Many thanks for the information on your blog – it’s very helpful! 🙂

    Do you know why the Get-AzureADMS* cmdlets seem to generate a second authentication prompt (over and above running Connect-AzureAD), asking for a password?

    I’m trying to figure out a way to get around this since I have some processes that (ideally) would rely on these commands that i’d like to run unattended but cannot at the moment because of this prompt.

    Thanks,
    Dave Green

    • Vasil Michev says:

      I cannot reproduce this, which version of the module are you using? Older version of the AzureAD module did not have this cmdlet, so if you have both the AzureAD and the AzureADPreview module on the same machine, PowerShell might be auto-loading the Preview one. But it should still not prompt you for credentials.

      • Dave green says:

        Aha, It turns out I just needed someone to say ‘That doesn’t happen for me, are you sure?’ for me to figure out where and how (if not why) it was happening 🙂

        Thank you for making me think about it a bit more. I specifically went and cleared up any traces of AzureADPreview and I think I’ve figured out the problem with a small reproduction that i’ll probably submit to the AzureAD github sometime soon.

        Essentially, I am developing an addition to my original script (which connects to AzureAD and runs some pester tests) in an separate script file to test the Get-AzureADMS* commands.

        I think the only reason I noticed it is because I’m passing in a credential object to connect (like in the example shown below, which reproduces my issue). When I do it this way, I get the second authentication box on the Get-AzureADMS* command. When running interactively, there’s no issue. I’m not 100% sure whether it’s reproducible by others as I don’t have any colleagues to bounce this off of working in this area, but I run into this on multiple machines. I was using 2.0.1.3, but this seems to exist with 2.0.1.6 too.

        # This example should show the issue from any standard PowerShell host with the AzureAD module installed.
        $cred = (Get-Credential)
        $null = Connect-AzureAD -Credential $cred
        Get-AzureADApplication # Works
        Get-AzureADMSDeletedGroup # Generates second credential box for password?

        • Vasil Michev says:

          Is this perhaps an MFA-protected account, or do you have any Conditional access policy that enforces MFA? What I’ve noticed lately is that some parts of O365 now require you to pass “strong” credential (as in 2FA) before they allow access. So even when you use some mechanism to bypass MFA, you might still get prompted. Still, sound very strange to me, and I’m definitely not able to reproduce it with your example.

          Are you sure it’s not just a byproduct of you loading another file in the script? Is your function running in a Global context?

          • Dave green says:

            I had initially dismissed the MFA piece, as the account is MFA enrolled, but not MFA enforced, so it’s not used. There are also no conditional access policies, but that may be it, I’ll go away and test :).

            I initially thought the context thing as well but it’s definitely not that as I can reproduce it in a fresh PowerShell host window by copy/pasting the commands and filling out the credential the first time. Again, I think there’s a bit more testing in my future to really narrow this down.

            Thank you very much for the great blog and going over and above by giving me a bit of help in the comments, it’s very much appreciated!

          • Vasil Michev says:

            Well I can tell you for certain that copy/pasting the cmdlets does NOT reproduce it on my machine 🙂 Hope you get to the bottom of it.

Leave a Reply

Your email address will not be published. Required fields are marked *