SOLVED

Understanding of custom policies / oma-uri / registry

Steel Contributor
Hi,
 
i would like to understand the whole topic belonging custom policies / OMA-URI / registry a little deeper.

I hope that some of you guys would like to join the disscussion to gain some new knowledge together.
The first goals should be:
  • Configuring some basic "onboard" registry values
  • Implementation of some Group Policy Objects through Intune Config
Let me outline one or two examples:
  1. I would like to create / edit a registry value at a specific path. (e.g. HKCU\Software\sample\subfolder)
  2. I would like to take an existing GPO and move this one completely to Intune management (e.g. User Configuration \ Preferences \ Folder Options -> hide known file extensions:false)
My thoughts on this:
  1. This should be possible, right? :D
  2. I already used "admx ingesting" before e.g. for use with Google Chrome ADMX / Google Update ADMX, which worked fine after understanding it. ;)
    Is it possible to use all the other gpo related settings within intune, when they' aren't present in the "administrative templates profile", yet? If yes, how?
Any participation in discussion is highly appreciated.
 
Regards
Patrick
5 Replies

Hi @PatrickF11,

 

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:

 

clipboard_image_0.png

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.

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. :)

best response confirmed by PatrickF11 (Steel Contributor)
Solution

Hi @PatrickF11,

 

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:

 

Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Part 2, Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps

 

best,

Oliver

Hi @Oliver Kieselbach 

 

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.

@PatrickF11 

Hey Patrick,

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

 

1 best response

Accepted Solutions
best response confirmed by PatrickF11 (Steel Contributor)
Solution

Hi @PatrickF11,

 

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:

 

Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Part 2, Deep dive Microsoft Intune Management Extension – PowerShell Scripts

Part 3, Deep dive Microsoft Intune Management Extension – Win32 Apps

 

best,

Oliver

View solution in original post