While I work on the next part of my Identity Governance series, I’ve got a configuration gem to share.
As a firm believer in leaving servers as a footnote in our tech history, I often guide my clients on their journey to a cloud-only environment. A top priority in this journey? Migrating endpoints out of the on-prem domain—because, frankly, there’s rarely a need to keep endpoints tethered to a traditional domain anymore. This transition also tightens security, enabling server isolation and reducing our attack surface.
Table of content
The Mission Brief: Streamlining Intune Registry Configuration
Recently, I was tasked with helping a client move their endpoints from a domain-joined setup to an Entra-joined configuration. This involved combing through their existing Group Policy Objects (GPOs) to ensure a smooth migration.
This client had a long history with GPOs, resulting in a tangled web of settings: many GPOs clashed, became obsolete, or were simply inefficient for the task at hand. While I was able to discard about 90% of these GPOs—either because they weren’t needed for the Entra Joined clients or were better handled in Intune—one stubborn legacy app required extra attention. This app, an Outlook add-in for email archiving, relies on a registry setting in the HKCU hive to determine specific archive locations. Previously, each location was managed by a GPO, with each GPO scoped to a different user group.
Simply lifting these GPOs into Intune would have been a headache both for management and performance. Plus, it risked performance slowdowns and management complexity if a user were ever added to multiple groups.
The Question
Due to the above, the question I was trying to get a handle on ended up as such:
How do I manage dynamic changing registry key / values in the HKCU hive based on Entra ID Group Memberships?
Answer Unlocked
As a rule, I don’t port GPOs to Intune—I start fresh whenever possible. So I got to thinking: how could I implement a cleaner solution?
After talking through the case with some of my knowledgeable colleagues, sketching out potential workflows, and testing several ideas, I finally landed on a solution worth sharing.
The Powershell Script solution
Both scripts used for this solution are available on my GitHub
Required Permissions
To run these scripts, you’ll need an App Registration in Entra ID with the following API permissions:
User.Read.All
Group.Read.All
Installation Script
This script uses the Microsoft Graph API to retrieve the currently logged-in user’s group memberships within Microsoft Entra ID and configures registry settings accordingly, in the HKU Hive. The script dynamically retrieves the user’s SID, saving it for detection, and applies a set of static registry values for all users.
NOTE: The script is build around PSAppDeploymentToolkit, as it reuses some of the functions and methods from the toolkit.
Detection Script
The detection script verifies that the registry settings match the expected configuration based on group memberships. It fetches group memberships from Entra ID and checks the FilePath registry value for each user profile, dynamically retrieving the user’s SID to access their registry hive if needed. Static registry values are also checked across users.
NOTE: As this is not a RunOnce scenario, it bypasses the Active Setup registry key and instead targets the HKU Hive for registry modifications, setting values directly for the user.
Deployment Options
Deploying this script can be handled in multiple ways, specifically through:
Platform Script – This would let the script run once, which doesn’t work for this solution.
Remediation Script – This could work as it allows the script to run at regular intervals (as often as hourly) and verifies that the current registry key aligns with the Entra group membership. Strong contender however as I reuse logic from PSADT, which isn't a possibility for Remediation Scripts.
Win32 Application – Deploying the script as a Win32 application means it runs during synchronization, which happens every 8 hours by default, but can be enforced either locally or via Intune. This approach offers full Win32 capabilities, including requirements, detection, supersedence, and dependencies, and is the only option possible for this script solution.
When packaging the script using PSAppDeploymentToolkit (PSADT), you have the option to embed the script within the main Deploy-Application.ps1 file or place it in the Files folder and call it from there.
Below is an example of how to reference the script in PSADT by adding a line to the installation phase of Deploy-Application.ps1:
Once packaged with PSADT, the app needs to be converted to an .intunewin file using the Microsoft Win32 Content Prep Tool, readying it for Intune deployment.
Deploying via Intune: Step-by-Step
Step 1: Open Intune.microsoft.com and navigate to Apps > Windows.
Step 2: Click “+ Add” and select “Windows app (Win32)” on the next blade.
Step 3: Select your .intunewin file for the application.
Step 4: Configure a meaningful app name and description. Including the app version is useful for testing as it updates in the company portal when a sync is run, making it easy to ensure testing with the newest version deployed.
Side 5: Set your install and uninstall commands. For this app, we don’t need the uninstall command.
Step 6: Configure any necessary requirements based on your environment.
Step 7: Choose a custom detection script and add the provided detection script.
Step 8 (Optional): Configure supersedence or dependencies as needed.
Step 9: Assign the app to the intended scope. In this case, I deployed it to all users, scoped to Entra-joined devices via a device filter.
Once deployed, the app will start setting registry keys based on the user’s group memberships in Entra ID.
Conclusion: A Fresh Take on Registry Changes
What We’ve Learned
Implementing dynamic registry changes based on Entra ID group memberships in a cloud-only environment isn’t always straightforward. Traditional GPO methods don’t translate seamlessly to the cloud, and this process illustrates the complexity involved. However, with a bit of PowerShell wizardry and creativity, it’s absolutely doable. This solution offers a flexible, scalable approach for managing registry changes dynamically—without the headaches of legacy GPOs
And now for a quick laugh, or at least a puff of air, here's another bad joke
How does a computer get drunk?
It takes screenshots! 😎
Try It Out!
If you’re in the process of moving away from legacy setups, this approach could save you hours of manual configuration and troubleshooting. Give it a shot in your environment, and see if it simplifies your migration process.
Stay Connected!
If you found this guide helpful, explore the rest of my blog for more insights and tutorials on cloud management and identity governance. Bookmark this page and check back often—I’m regularly sharing tips and solutions for navigating the challenges of modern IT. Got questions or suggestions? Reach out or leave a comment! Let’s make the cloud migration journey easier, one post at a time.
Comments