Forum Discussion
New Feature Announcement: PowerShell support of Allow/Block guest access based on Domain list
Not to be disrespectful here, I really appreciate the update. But how about providing UI settings, or at least a "regular people" version of the cmdlets? I mean sersiously, have you received at least one positive feedback item on the usability of these cmdlets? It takes a 300 pages script to just change a setting, cmon.
And why are half the settings controlled via "settings" and the other half via "policies"? The same thing that's used for token expiration settings, that will surely help reduce confusion...
To be fair to Microsoft, this step:
- Moves block/allow lists into an AAD policy rather than introducing a dependency on a base workload (like SharePoint or Exchange).
- Uses a policy that is available to all group-enabled applications - which is why it is right to use a separate policy rather than adding it to the Groups AAD policy. That's in line with creating a common external access mechanism for all Office 365 apps (as I argue for in https://www.petri.com/common-external-access-office-365).
Also, if you strip things away, you can get to
Update an existing policy:
New-AzureADPolicy -Definition $policyValue -DisplayName B2BManagementPolicy -Type B2BManagementPolicy -IsOrganizationDefault $true -InformationAction Ignore | Out-Null
Create a new policy:
Set-AzureADPolicy -Definition $policyValue -Id $currentpolicy.Id | Out-Null
Most of the code in the script is error handling or software setup, which is what you'd expect in any utility written by Microsoft... Now, my scripts would be a lot simpler, but they'd have no error handling!
Hi Vasil,
1. UI support is in the pipeline and we are targeting to have that soon.
2. I hope you have seen the script here but to clarify we understand Azure Policy JSON argument can be difficult for normal people but if you see the script, the script does the job of converting the parameters as JSON, you just need to pass parameters, also this script works as a cmdlet if you run in a session, so in a way its very easy to run this script, if you save the script locally and run as cmdlet.
For the second message, I will definitely pass the feedback to update the set-azure policy.
Yes, but you do realize that many organizations have strict policies around running scripts, unsigned at that? Heck, I've even seen complaints about having to download the AzureAD module from "non-MS" source such as the PowerShell Gallery, but that's another story. In any case, I need to go over all the 300+ lines of the script to make sure I understand what it does, before I run it. And I'm pretty much forced to do that, because the only examples I can find on how to actually run the cmdlet and which parameters to use are in that script.
Don't get me wrong, I really appreciate you providing a solution to this problem. My main complaint is usability, you could've easily made a cmdlet available that accepts the allow/block domain parameter and handles the JSON conversion internally. And that's a general complaint about pretty much every operation handled by the AzureAD module. Forcing us to work with ObjectIDs, JSON and whatnot is simply not cool. You should not be providing a solution that's convenient to you as programmers, but to the end users. If it's not in UI form, at least make it as easy as passing a simple parameter.
Thanks for your feedback! This is a representative script for IT admins to use as a reference while crafting their own based on their organization requirements. It is not a downloadable script. The downloadable link will be provided to you in few days, which will be signed by Microsoft.
- BTW, is there any reason why the script is not signed by Microsoft? Running unverified scripts is not a habit that we should encourage, even if the script comes from Microsoft...
- BTW, I agree with Vasil that if you provide a PowerShell cmdlet to update policies etc., please hide all the JSON formatting crap behind the scenes so that "normal people" (let's define these folk as people who don't have the time or the inclination to mess around with JSON when they just want to update a setting - life is too short). Parameters like this should be simple strings like a list of domain names. For some unfathomable reason, Microsoft engineers working on Office 365 seem to love obfuscating simple things with JSON and GUIDs... Very strange!
At the very least, can you please update the New/Set-AzureADPolicy cmdlet help to include examples on how to configure this. Perhaps also referencing the JSON helper functions from the example script, so that normal people can work with it.
