Forum Discussion
MicrosoftNew 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...
MicrosoftHi 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.
- Sahil Arora
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.
It's always a good idea to check scripts downloaded from the internet to get an understanding of what they do :) Anyway, we should already be accustomed to new features coming with a large sense of 'pioneering' when it comes to management. For example, with Groups settings administration you still need to through some hoops to creating/update settings objects, and the new licensing cmdlets in AzureAD - especially when disabling features - are not the most intuitive. A cmdlet/script not only takes away all those details for admins, it also means less opportunities for error.
- Sahil Arora
Here is the download link to the script: Signed by Microsoft:
https://www.microsoft.com/en-us/download/details.aspx?id=55709
- 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!
