7/14/2023 0 Comments Giant machines 2017 first mission![]() Settings will remain on the device, they are tattooed! There are just a few profiles currently, which are removed after the assignment is removed or the profile is deleted. The setting stays there until it is configured to a different value, even after removing the assignment of the policy. If we compare this with GPOs, we would call this tattooing. Removing the assignment of the policy from the user or device does not revert the setting automatically to the default value (see Update below on this!). If a setting should be the default value again the setting must be configured to the default value again. If the policy changes on the MDM server, the updated policy is pushed down to the device and the setting is set to the new value or the old value is enforced. Let’s have a look into that in the next section. The architecture behind the MDM stack and configuration profiles (settings) in Windows 10 should be clear now, but what about the actual processing of the configuration settings. There are a lot of pitfalls in the process (false OMA-URI construction, case-sensitive URI’s, wrong value referenced, etc). One advice here: ADMX ingestion is not very easy and intended for third party ADMX ingestion. For custom ADMX ingestion read carefully this article Win32 and Desktop Bridge app policy configuration. To dive into that topic I really recommend to carefully read the article here Understanding ADMX-backed policies, which provides great details on the whole process. Especially for ingested policies we need to be careful about the OMA-URI’s. During usage of ADMX-backed policies we need to take special care about the configured values, they follow a specific notation. This allows us and Microsoft to easily make policies available for MDM configuration. In addition to that, it is even allowed to ingest new policies and compile them to new MDM policies (e.g. This is a clever move to make important policies shipped with Windows 10 accessible by compiling them into MDM policies during OS-build time. ![]() In addition to native CSP implementations in Windows 10, Microsoft uses a technique called ADMX-backed policies. The nice thing about the ability to configure custom OMA-URI’s is, that we are able to control settings as soon as they are introduced on the client side (Windows 10) and we do not need to wait for Intune to build an UI explicitly for it. In the modern MDM stack, this input was standardized (XML) and the instructions are built up in a tree structure. The input files on a domain client may be different depending on the CSE. You can think of the MDM stack as a logical evolution of the domain group policy processing. So, this is basically the same approach but with MDM it is standardized and designed to work perfectly over the air. The Windows client had so called Client Side Extensions (CSE’s) (compare: CSP) to process the input files and finally do the configuration. On the client side we had the group policy service (compare: MDM client) which simply used a SMB connection (compare: HTTPS) to get the files from the sysvol folders (okay there was a little bit more involved in that process like authentication, GPC lookup, etc, but for this comparison I simplify it a little bit). ![]() There was the domain controller (DC) (compare: MDM server) and the DC provided the sysvol folders with policy files. Yeah, right as it is basically the same architecture as we had in an on-premises domain. These components are responsible to read, set, modify, or delete configuration settings on the device. On the client side there are so called Configuration Service Providers (CSP’s). This builds the architecture to transfer instructions in a standardized way to the endpoints. This is vendor independent and is used for Android and iOS management as well. This is a common defined standard and uses a XML-based SyncML format to push the information to the client. The MDM system and the MDM client are working together to exchange data based on the Open Mobile Alliance Device Management ( OMA-DM) protocol (more from Microsoft here). Today Microsoft provides us the MDM client also on Windows 10. The roots of the MDM client are based on Windows Mobile. There is the MDM system (Intune) and the MDM client on the Windows 10 OS. To better understand the processing, we first need to understand the components involved in the process. I cover the current technology and what has changed with Windows 10 version 1903. We will have a look at the architecture, the settings, and the actual processing including the refresh behavior. Intune is an MDM system and has the ability to deploy so called device configuration profiles to managed Windows 10 endpoints. In this post I will dive into the Intune policy processing on a MDM managed Windows 10 client. ![]()
0 Comments
Leave a Reply. |