12-10-2019 05:23 AM
12-10-2019 05:23 AM
12-10-2019 09:55 AM
in regards to question number 1, there is no generic registry functionality to set values like this. For third party settings you can ingest 3rd party admx templates like Google Chrome and then set the values (they represent registry keys). This should not be done for Microsoft admx files as MS is providing for this in a dedicated profile type Administrative template naively in Intune, see here:
If you ingest MS admx files you are running into potential conflict with future MS administrative templates, as MS is regularly updating them. Last additions were Office and Edge settings.
Generic "onboarding" registry keys can be set by PowerShell script for example.
In regards to question number 2 you can't move all GPOs to Intune. MS provides a rich set on settings you can use and you can extend this for 3rd party settings via ADMX ingestion. Other missing pieces should be addressed by PowerShell scripts. Your example hide known file extension can be easily accomplished by a one line PowerShell script e.g.
Set-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced -Name HideFileExt -Value 0 -ErrorAction Stop
MS is constantly expanding settings to provide all necessary settings, but don't expect the "overload" like we had with GPOs. They focus on necessary and important settings. A manageable amount of settings will make sure IT admins have enough control, will not generate conflicts and compatibility issues with further upgrades. IT admins can keep track of their setting and they are actually knowing what they are setting. So, my advice re-think what is really necessary and follow a "light management" strategy. Necessary settings are in general security setting and some things for productivity or corporate branding like common logon background.
12-11-2019 01:02 AM
Hi @Oliver Kieselbach & thank you for your reply.
I already know the administrative templates, but of course many options are not yet implemented.
That's why i'm asking on how to deal with this.
The potential conflicts when using admx ingest seems clear to me, but only hypothetically it is possible to ingest any admx files, not only 3rd Party, right?
Thank you for your powershell example.
At this point i 've avoided using powershell scripts with intune because a) i didn't tested it, yet / b) i didn't know how they work exactly.
Are the scripts only running once? How can i monitor settings i set via script?
Thank you in advance. :)
12-11-2019 01:25 AMSolution
in theory you can ingest every admx file but there are some path in the registry which are black listed (https://docs.microsoft.com/en-us/windows/client-management/mdm/win32-and-centennial-app-policy-confi...).
As already outlined I would focus on what is really necessary then I do not miss so much. Important are especially security settings and they are mostly all available.
For an introduction in Intune PowerShell script processing look at my blog posts here:
12-12-2019 02:06 AM - edited 12-12-2019 02:10 AM
I think i just have to rethink a little my mindset regarding the "GPO-World" :D
Thank you for your ideas belonging this.
I've worked throught your really great blogposts 1&2 and i 'll continue with the 3rd one.
Thank you very much for your wonderful work which is really comprehensible with great examples and samples.
Many kudos to you! You're really a big benefit to the community.
12-15-2019 07:19 PM
I believe the PowerShell scripts operate according to this logic:
If it runs successfully - It will never run again unless the policy is updated (i.e. update script, assignment etc)
If it fails, it will retry a maximum of 2 more times, and will never run again unless the policy is updated (i.e. update script, assignment etc)
You need to use Write-Error or force an exit code of 0 for Intune to detect the script as failed.
At this stage, there is no built in way to monitor the settings you configure with a script. You would need to write multiple scripts to configure individual settings.
The methodology i tend to work with is
1. Use a native configuration profile (Device restrictions etc)
2. If that's not possible, use an Administrative template
3. If it's not available there, can i do it with a custom profile
4. No? or for quick 1-offs - PowerShell Script