Chrome Configuration in App Cat Rule works until Web Filter is applied

Chrome Configuration in App Cat Rule works until Web Filter is applied

I am adding an Application Catalog Rule for Google Chrome and in the Advanced tab I am configuring the Home Page and a managed book mark. It works without issue. 

I also have a Profile Configuration Payload for Webfilter - The web filter blocks * (all sites) and allows the end user URL only. 

Depending on which element gets assigned last is what works. It appears the two cancle each other out. 

 

For example if Chrome is updated by Google Play the settings work but then as soon as the web filter is applied the home page and managed bookmark are gone but the web filter works. 

If the web filter is applied first, it works great and all sites are blocked but as soon as google play applies the chrome with config the web filter stops working and you can brows anywhere. 

 

4 Answers

Order By:   Standard | Newest | Votes
Matt Dermody | posted this 04 December 2020

Fascinating! I would have thought one would take priority over the other but it seems to be more based on the sequence based on your testing. 

Is there a Web Filter option within the Managed Configuration option exposed by the App Catalog rule? Perhaps you could put all of the configurations in one place. 

  • 0
  • 0
Lewis Hutcheons | posted this 05 December 2020

In the config section of Chrome for the app rule there is a section for blocking URLs and allowing URLs. It says to follow the format on this page - https://www.chromium.org/administrators/url-blacklist-filter-format  so i used "*" in the block section and "http://URL" in the allow section but it does not work...not sure what the proper format is supposed to be. 


Edit

 

I just figured it out i needed to use ["*"] and ["Http://URL"]

 

Edit #2

PS, Thanks for the advice!

  • 0
  • 0
Raymond Chan | posted this 05 December 2020

The importance of policy conflict resolution is often overlooked.  A general rule of thumb of profile configuration payload is to manually avoid policy conflicts as much as possible. 

 

Just imagine you have profile 1 having a feature control payload that disables camera, and another profile 2 having a feature control payload that allow camera.  It is possible to deploy both profiles to the same device.  In such case, is the camera allowed or disabled?  Relying on the device/MDM firmware to resolve policy conflict is not recommended, as I could only find incomplete and vague conflict resolution guidelines for MDM developers from Apple and Google. What resolution algorithm/strategy should be used actaully depends on the nature of the policy- sometimes the most logical approach seems to be logically-AND, sometimes logically-OR, sometimes First-Come-First-Serve, and sometimes using the latest configuration, etc.

 

In MobiControl, some form of resolution at the profile payload level is that SOME payload types can only have one instance deployed on a device, and any subsequent attempt to deploy a second instance will fail.  Things get even more complicated when some MDM policies can get overridden with script commands, configurations from AppConfig/OEMConfig framework, etc.   In particular, AppConfig/OEMConfig compliant options set in the advanced tab of an Managed-Google-Play app in an AE App-Catalog rule are dynamically re-deployed as soon as there is any change, not just once after the app binary installation.  Also, script command configuring policy can be sent to the device anytime to override what has previously been set by a profile.  Taking all of the above into consideration, using the latest configuration (deployed from whatever means) seems to be the predominant resolution. 

 

One has to have a big picture of all of the above, and hopefully learn the knowhow to avoid incorrect policy set-up due to conflict(s) from his/her configuration practices.

 

  • 1
  • 1
Raymond Chan | posted this 05 December 2020

The importance of policy conflict resolution is often overlooked.  A general rule of thumb of profile configuration payload is to manually avoid policy conflicts as much as possible. 

 

Just imagine you have profile 1 having a feature control payload that disables camera, and another profile 2 having a feature control payload that allow camera.  It is possible to deploy both profiles to the same device.  In such case, is the camera allowed or disabled?  Relying on the device/MDM firmware to resolve policy conflict is not recommended, as I could only find incomplete and vague conflict resolution guidelines for MDM developers from Apple and Google. What resolution algorithm/strategy should be used actaully depends on the nature of the policy- sometimes the most logical approach seems to be logically-AND, sometimes logically-OR, sometimes First-Come-First-Serve, and sometimes using the latest configuration, etc.

 

In MobiControl, some form of resolution at the profile payload level is that SOME payload types can only have one instance deployed on a device, and any subsequent attempt to deploy a second instance will fail.  Things get even more complicated when some MDM policies can get overridden with script commands, configurations from AppConfig/OEMConfig framework, etc.   In particular, AppConfig/OEMConfig compliant options set in the advanced tab of an Managed-Google-Play app in an AE App-Catalog rule are dynamically re-deployed as soon as there is any change, not just once after the app binary installation.  Also, script command configuring policy can be sent to the device anytime to override what has previously been set by a profile.  Taking all of the above into consideration, using the latest configuration (deployed from whatever means) seems to be the predominant resolution. 

 

One has to have a big picture of all of the above, and hopefully learn the knowhow to avoid incorrect policy set-up due to conflict(s) from his/her configuration practices.

 

  • 1
  • 1

Give us your feedback
Give us your feedback
Feedback