In this blog will I will show you how to configure the new Intune settings catalog and how to automate it and of course, how to troubleshoot this new feature from the client’s perspective.
It can be great to configure settings by simply selecting them with a GUI instead of manually creating your own custom-made settings (Configuration Service Provider).
1.Manually creating the setting in the new settings catalog
When first writing this blog, I thought a lot of settings were missing that could be configured. I really hoped to see the option to configure AppLocker as you could do with the old-fashioned on-premise GPO.
But instead of the possibility of configuring Applocker (I know it’s hard to convert the CSP to a GUI), the possibility to block certain executables is also available in the settings Catalog GUI (Insider Build)
https://call4cloud.nl/2020/08/blocking-administrative-tools-part-2
For example, we are going to configure which sites are going to be opened when you open the Edge Browser. I will choose this setting because we need to troubleshoot it later on.
Let’s start with configuring the settings Catalog by creating a new device configuration profile in Intune
After we created the profile, we need to choose the settings catalog (preview)
Let’s start searching for the restore url setting we need by clicking on “add settings” and searching for: “Action to take on startup” and after selecting this setting, the “Sites to open when the browser starts”
It’s very easy to configure it, you will only need to switch the button to enabled and enter the site(s) to open.
After you have configured the settings needed you can assign these settings to the devices or users who need them.
2. How to automate the deployment of the settings catalog with PowerShell
If you are reading my blogs often, you will know I want to automate the deployment. The first thing I did, was starting Fiddler to get some more information where the information is stored as the location is not the same as the existing device configuration policies
You can read more about using Fiddler:
https://call4cloud.nl/2020/11/close-encounters-of-fiddler
Before we continue we need to know the difference where the settings are stored:
Settings Picker:
Device Configuration Policies:
As shown above, it almost uses the same URL, automating it should be no problem at all. To be sure I manually created my the Settings Catalog I mentioned earlier:
While saving the policy watch fiddler go.
Now we have the URL and the JSON we can automate it.
https://call4cloud.nl/wp-content/uploads/2021/02/SettingsPicker.zip
The zip file contains the script to deploy the new settings catalog JSON and a folder with the JSON itself. The script also assigns the policy to all devices.
Automating the process is one thing I did but I really wanted to see if there is a difference in how the client sees this new settings catalog. So I waited for my own device to receive this setting after I run the PowerShell script.
It was funny to see that all other devices were receiving this setting but my own device was the latest to receive it… Rebooting/stopping and starting the Intune MGT service / Syncing in the company portal and Intune portal did not help at all.
But after getting myself some coffee….
The settings has been applied
3.How to troubleshoot the settings catalog from the client’s perspective
As mentioned earlier I choose this setting, because I already know it will not work the way you want.
Let’s start with some troubleshooting. First, let’s check the settings Catalog report to determine if the settings are being applied
As shown below…it’s compliant so it worked?
Sometimes you could pick a setting that requires the Insider Build as an example, so please make sure you checked the requirements first. But this time it’s not the case
Now we know Intune reports the setting as compliant, we need to check the device. You can use the MDMDiagReport to determine on the device itself if the new setting is being applied:
You don’t need to export it, if you look closely you will notice the Microsoft edge startup policy has arrived.
Let’s check if it’s working!
I guess not… So what happened?
When you are configuring Edge policies, you can simply enter edge://policy to find all the policies which have been applied
The “RestoreonStartup” policy has been applied successfully. It has the value 4 configured, just like we wanted it to, but are the restoreonstartupURLs empty?
Let’s dig a little bit deeper and take a look at the CSP itself. As Edge is based on chromium it will listen to the same restoreonstartupurls as Chrome. Let’s check the Chrome CSP first.
And the registry value when this policy is set.
When you need to troubleshoot the CSP or the settings Catalog, opening the registry is certainly one of the most important steps.
The first place to look inside the registry would be the Policy manager key.
You will notice the restoreonstartupurl’s have been configured and the value corresponding to the winning provider. Go open the provider to determine if the XML is correct. When working with a CSP instead of the settings catalog you will need to configure this XML manually
That’s odd, let’s compare it with the chrome xml csp
Like I showed earlier the value has to be a number instead of the name. To be sure, open the HKEY_CURRENT_User registry to check out the applied policies
That’s wrong… the value has to be a number! SO let’s change this setting manually and open edge again
It works… even the edge://policy is showing us the correct value now
Conclusion
For now… I will not convert all policies to the new setting Catalog because some of the settings I wanted to configure are missing. Of course, I really like where this is going. When all the settings are configurable from the setting Catalog I will go to use it.
When you need to start troubleshooting, you will need to understand: CSP/Settings Catalog/Group policies are nothing more than some registry settings.
It’s nothing but a combination of ones and zeroes, that’s it.