Windows RMM and UEM tools

On Windows everything SafeToOpen needs is a handful of registry values under HKLM\SOFTWARE\Policies (guide 3). Any tool that can run PowerShell as SYSTEM on a schedule, or import a registry file, can deploy it. This guide gives, for each common tool, where to put the script and what to schedule. The script itself is the one from guide 2 section 3; the console generates it with your key filled in (Settings → Unattended enrolment → “Intune script (Windows)”).

One change for non-Intune tools#

The Intune version takes the user’s UPN from the Intune enrolment. On devices that are not Intune-enrolled that key is empty and the script falls back to Win32_ComputerSystem.UserName, which is DOMAIN\login (or AzureAD\Name on Entra-joined devices without Intune). Either set the email domain in Settings → Unattended enrolment so the backend can complete the address, or replace that line with your tool’s own variable for the user’s email where it offers one (noted per tool below).

1. NinjaOne#

1. Administration → Library → Automation → Add → New Script. Language PowerShell, OS Windows, Architecture 64-bit. Paste the script; set your key.
2. Administration → Policies → the workstation policy → Scheduled Scripts → Add. Run daily, as System. This covers new devices and user changes.
3. Optional: add a Script Result Condition that alerts when HKLM:\SOFTWARE\Policies\Microsoft\Edge\3rdparty\extensions\bbgoikmidjfiaaadlgkpdlppilhkjfke\policy\enrol_key is missing.

NinjaOne on macOS and mobile#

• macOS: the same Library → Automation entry accepts a Shell script; paste the root script from guide 4 section 2 and schedule it daily through the Mac policy. Deliver the force-install profile with Administration → Apple → Configuration Profiles (custom .mobileconfig).
• NinjaOne MDM (iOS, Android): push the SafeToOpen iOS app as a managed App Store app with the four keys in its app configuration (enrol_key, user_name, asset_name, domain_name); use NinjaOne’s device-name and user-email placeholders where the app-config editor offers them. On Android push Edge from managed Google Play; the extension and the activation link remain the user’s step (guide 7).

2. Datto RMM#

1. Automation → Components → New → Script Component, PowerShell. Add a variable EnrolKey and read it in the script as $env:EnrolKey so the key is not hard-coded.
2. Store the workspace per site as a site UDF and read it as $env:UDF_1 for $ws.
3. Create a Scheduled Job on the sites, daily, or attach the component to a Monitor that runs when the registry value is absent.

3. ConnectWise Automate#

1. Automation → Scripts → New Script. Add a step “Execute Script” (PowerShell), paste the script. The agent runs it as SYSTEM.
2. Put the key in a client-level EDF and reference it with %ClientEDF:SafeToOpenKey% (or your naming), so one script serves every client.
3. Schedule from the client’s Scripts tab, daily.

4. Kaseya VSA#

1. Agent Procedures → Schedule / Create → New Procedure. Step: Execute PowerShell (64-bit), run as System, paste the script.
2. Schedule on the machine group, recurring daily.

5. Atera, Action1, PDQ#

• Atera: Admin → Scripts → Create Script; assign in an Automation Profile that runs daily on the customer’s folder.
• Action1: Script Library → Add; Automations → New → Run Script, schedule daily on the endpoint group.
• PDQ Deploy: New Package → PowerShell step, paste the script; deploy with an Auto Deployment to the target collection. PDQ Connect: Packages → New → Script step, schedule.

6. ManageEngine Endpoint Central#

1. For the force-install and static values a Registry configuration is enough: Configurations → Add → Windows → Computer → Registry → Write value, the keys from guide 3 section 2c.
2. For the per-device values use Configurations → Computer → Custom Script with the PowerShell script, run at startup and repeat daily.

7. MECM (SCCM)#

1. Assets and Compliance → Compliance Settings → Configuration Items → Create. Type Windows Desktops and Servers, setting type Script. Discovery script: return Compliant when enrol_key exists under both 3rdparty policy keys; remediation script: the deployment script. Tick “Run scripts by using the logged on user credentials”: No.
2. Add the CI to a Configuration Baseline, deploy to the device collection with remediation enabled and a daily evaluation schedule.
3. Alternatively Software Library → Scripts → Create Script, approve, and run on the collection once; use the baseline for drift.

8. Omnissa Workspace ONE UEM#

1. Profile route (no script): Resources → Profiles → Add → Windows → Windows Desktop → Device → Custom Settings. Paste SyncML that writes the registry through the Registry CSP, using lookup values {EmailAddress} for user_name and {DeviceName} for asset_name. Publish to the smart group.
2. Script route: Resources → Scripts → Add → Windows, PowerShell, execution context System, trigger Login plus a daily schedule. Paste the script.
3. Force-install: the same Custom Settings profile can carry the ExtensionInstallForcelist values, or use the built-in Edge and Chrome policy templates under Profiles → Windows → Device → Microsoft Edge / Chrome.

<Replace>
  <CmdID>1</CmdID>
  <Item>
    <Target><LocURI>./Device/Vendor/MSFT/Registry/HKLM/SOFTWARE/Policies/Microsoft/Edge/3rdparty/extensions/bbgoikmidjfiaaadlgkpdlppilhkjfke/policy/user_name</LocURI></Target>
    <Meta><Format xmlns="syncml:metinf">chr</Format></Meta>
    <Data>{EmailAddress}</Data>
  </Item>
</Replace>

9. Verify and maintain#

1. edge://policy and chrome://policy on a device list the force-install entry and the four values under the extension ID.
2. Console → Settings → Unattended enrolment → Enrolled devices fills in as devices start their browsers.
3. When you rotate the key, update the script or profile variable; devices retry within 6 hours, or immediately when the policy value changes.
4. When someone leaves, remove the device from the schedule or wipe it; removing the person in the console revokes access, but a device that still carries the policy re-enrols them at next start.