We are migrating from R7 to Rhino 8 (8.35 / SR35) across a managed Windows fleet via Intune/SCCM and need to stop specific legacy in-house developed plug-ins from loading.
Questions
- Is there a supported machine-wide (HKLM) way to block a plug-in by GUID from loading in Rhino 8, that overrides the per-user setting?
- Can the Rhino 7 → Rhino 8 plug-in migration be disabled (fully or per-GUID) at first run, via an install switch, config file, or settings scheme we can seed at deployment?
- What is the exact key / value name / type Rhino 8 actually reads for plug-in load state? We want to confirm we targeted the right place.
Context — what I tried, what happened
At my testing deployment, I install rhino silently, and then run a post install action (running as SYSTEM) where I set LoadMode = 0 for the plug-in GUIDs under:
HKEY_LOCAL_MACHINE\SOFTWARE\McNeel\Rhinoceros\8.0\Plug-Ins\5dba7085-b10e-4c5f-b2aa-58339a48cfd1
HKEY_LOCAL_MACHINE\SOFTWARE\McNeel\Rhinoceros\8.0\Plug-Ins\16c726b6-2134-431d-8a12-ec68f667ae1a
Testing empirically, this had no effect:
Plug-ins installed as user for Rhino 7, which register on the user side (HKCU), are still picked up by Rhino 8 on launch, despite the HKLM keys existing and sharing the exact same GUID.
So, the HKLM value we set is clearly not what Rhino consults. We’d like a system-wide solution applied once per machine at deployment. We know we could programmatically walk each user profile and remove the plug-in folders/HKCU entries, but we’re trying to avoid that per-user, profile-iterating approach.
Thanks, happy to share logs or the exact registry state.
