This article is a complete, self-contained deployment path for administrators who roll out Draftable Legal using Microsoft Configuration Manager, still widely known as SCCM. It is one of several ways to deploy Draftable Legal, and it is optional: if you deploy with Microsoft Intune, Group Policy Software Installation, or by running the installer directly, see Enterprise deployment options instead.
Everything here applies equally to any tool that installs Draftable Legal silently in the machine context, including task sequences and third-party deployment frameworks.
Verify the draftable:// URL scheme after deployment. The installer registers it, but a failure to do so does not fail the installation, and a machine-wide installation does not repair itself afterwards. If the registration is missing, the deployment looks completely successful while no user can start a comparison from iManage, SharePoint, NetDocuments, the Office add-ins or File Explorer. Step 2 covers how to verify it and what to do if it is absent.
Before you start
Confirm the machine-wide MSI is the right installer
Decide which features you need
Check for a previous per-user installation
Plan licensing and Citrix or RDS considerations
The product key cannot be passed on the MSI command line. It is deployed through the registry or Group Policy, covered in step 4. If your target machines are Citrix or Remote Desktop hosts, read Deployment advice for Citrix and RDP environments before you deploy, because activation needs to be configured for that environment in advance.
The deployment sequence
A Configuration Manager deployment performs the following in order. The installer handles the shell integration in step 2 itself, so that step is a verification point rather than something you always have to build, but it is the one worth checking on every rollout.
Step 1: Install the MSI
Run the installer silently in the system context. Deploy it as an application with an MSI deployment type, and set the installation behaviour to Install for system.
ADDLOCAL=ALL installs every feature, which is the simplest way to guarantee that the HTTP Listener Service and the add-ins are present. To install a subset instead, name each feature explicitly:
Always include HttpListener. Because ADDLOCAL installs only the features you list, omitting it silently leaves out the HTTP Listener Service. The service allows comparisons to be launched from iManage when Draftable Legal is not already running, is needed on multi-user systems such as Citrix and RDS, and is required by the Draftable Outlook add-in.
Use the default installation location. If you integrate with iManage, a custom INSTALLDIR increases the chance of integration problems. It also means the executable path used in steps 2 and 4 changes, so every command below has to be updated to match.
The /L*V switch writes a verbose installer log, which is worth keeping in a managed deployment. The parent folder must already exist, so use a directory such as C:\Windows\Logs that is always present.
Two behaviours worth knowing when you choose your command. Installing with no ADDLOCAL property at all installs the HTTP Listener Service but not the Office COM add-ins, because the add-in features are not selected by default. And if CreateDesktopShortcut is set to 0 under HKLM\Software\Policies\Draftable\Installer, no desktop shortcut is created even when DesktopShortcut is named in ADDLOCAL.
Step 2: Verify the draftable:// URL scheme
Every comparison started from outside the Draftable window is a draftable:// request. When a user chooses Compare with Draftable in iManage, SharePoint Online or NetDocuments, uses the Office add-ins, or right-clicks a file in File Explorer, that action asks Windows to open a draftable:// link, and Windows passes it to Draftable Legal.
Windows can only do that if the draftable:// URL scheme is registered on the machine.
The installer registers the scheme, but a failure to do so does not fail the installation. Both installers register the scheme as part of installing, including in a silent or scripted installation. If that registration is prevented — most often because something in the environment blocks writing to HKEY_LOCAL_MACHINE\Software\Classes — the installation still completes and reports success.The result is an installation that appears entirely healthy. The application runs, the HTTP Listener Service starts, the Office add-ins load and licensing activates, but no user can start a comparison from iManage, SharePoint Online, NetDocuments, the Office add-ins or File Explorer. Those actions do nothing at all: no error, no prompt, and no entry in the Draftable logs, because Windows has no application associated with draftable:// and discards the request before Draftable is involved.
Machine-wide installations do not repair this by themselves. The per-user installer re-registers the scheme each time Draftable Legal starts, so a per-user installation recovers on its own at the next launch. A machine-wide MSI installation does not re-register at startup, so once the registration is missing it stays missing until an administrator restores it. This is why the problem is normally seen across a managed deployment rather than on a single machine.
Checking whether the scheme is registered
Test the scheme directly
Press Windows + R, enter the following, and select OK:The Draftable New Comparison window should open. If Windows reports that no application is associated with the link, or nothing happens at all, the scheme is not registered. Check the registry
Confirm that HKEY_CLASSES_ROOT\draftable\shell\open\command exists, and that the path it contains points to a DraftableDesktop.exe that is actually present on disk. A path left behind by a previous installation is as broken as no path at all.
Run the built-in system check
In Draftable Legal, open Settings, then Help & Troubleshooting, then Diagnostics, and select Run system check. On versions before 26.6 this is Settings > Troubleshooting > System Verification.The check is named Microsoft Windows: Custom URL scheme supported. If it fails, the scheme is not registered as Draftable expects it. Note that this check does not distinguish between a machine-wide and a per-user registration, so use the registry check above to see which is present.
Restoring the registration
First, repair the installation
Because the installer performs the registration, repairing the installation runs it again. For the machine-wide MSI, re-run the MSI over the existing installation with administrator rights, or use Repair from Programs and Features. This is the quickest fix for one machine, and it is worth trying before making registry changes by hand.
If repairing does not restore it, the write is being blocked
Endpoint protection, an application control policy such as AppLocker or Windows Defender Application Control, or a Default Associations policy can prevent or later remove the registration. Add the Draftable installation folder to your endpoint protection exclusions, and permit the draftable URL scheme in any application control policy, then repair again.
For a managed fleet, create the values from your deployment
Creating the values directly does not depend on the installer action succeeding, so it is the dependable option when you are deploying to many machines or when the cause has not yet been identified. The values are below.
Registry values
These are the values the installer creates. Use HKEY_LOCAL_MACHINE so the scheme applies to every user of the machine, and replace the executable path if you installed to a custom location.
The URL Protocol value and the shell\open\command key are the two that Windows needs in order to open Draftable Legal. The remaining values are part of the registration Draftable Legal creates for itself.
Create all of the values, including the Application ones. Draftable Legal’s own system check expects the complete registration. If you create only URL Protocol and shell\open\command, comparisons will launch correctly but the Custom URL scheme supported check will still report a failure, which is misleading for anyone troubleshooting the machine later.
The default executable path for the machine-wide MSI is:
Creating the values from a script
Run this with administrator or SYSTEM rights after the installer has finished. The commands use reg.exe so they behave identically in PowerShell, in a command prompt, and inside a deployment tool’s script step.
Writing this into a batch file instead? In a .bat or .cmd file the %1 placeholder must be written as %%1, otherwise the command interpreter replaces it with the script’s own first argument. The placeholder is what passes the comparison request through to Draftable, so it must reach the registry exactly as %1.
The scheme is active as soon as the values exist. Neither a restart of Draftable Legal nor a sign-out is required.
Confirm the executable path before you deploy at scale. Every command above depends on it. If you installed to a custom location with INSTALLDIR, use that path instead. On a machine that already has Draftable Legal running, Get-Process DraftableDesktop | Select-Object Path returns the path in use.
Per-user installations need per-user values. The values above are correct for the machine-wide MSI, which installs to Program Files. If the executable is under %LocalAppData%\DraftableDesktop\current\, it was installed with the per-user installer, and a machine-wide value pointing there will not work for anyone else on the device. In that case simply restarting Draftable Legal restores the registration, because the per-user installer re-registers the scheme at every launch.
A leftover per-user registration takes priority. Values under HKEY_CURRENT_USER\Software\Classes\draftable, typically left behind by an earlier per-user installation, override the machine-wide values. Draftable removes a redundant per-user registration automatically only when it points to the same executable as the machine-wide one. If it points somewhere else, delete the HKCU key so the machine-wide registration is used.
Worth building into the deployment for a large rollout. Because the installer’s registration step cannot report a failure back to the installation, creating the values from your deployment as well is a reasonable belt-and-braces measure on a large estate. The values are identical to the ones the installer creates, so applying them a second time is harmless. If you would rather not add the step, use the detection rule further down to surface any machine where the registration is missing.
Step 3: Apply settings with the registry or Group Policy
Draftable Legal reads centrally managed settings from the registry. Values under a \Policies\ path are enforced and cannot be changed by users.
The order of priority is:
For a machine-wide deployment, write to HKLM:\Software\Policies\Draftable\. Note that HKLM:\Software\Draftable\, without Policies, is not read by the application.
Deploying the product key
Commonly deployed settings
For the full set of available settings, including DMS configuration, output types and redline profiles, see Most common Draftable Legal registry configurations and Configuring settings with Group Policy. If you prefer to manage settings through Group Policy rather than in the deployment script, the ADMX and ADML templates are available from Draftable Legal Group Policy Template Files.
Do not copy an entire exported Draftable registry hive between machines. Some values are specific to the machine they were created on, and copying the whole hive to other devices causes integration faults that are difficult to diagnose. Deploy only the specific values you intend to manage.
The right-click Compare in Draftable entries are created by the installer at the same time as the URL scheme, so if that registration was prevented they will be absent too. Repairing the installation restores both. Use the values below if you would rather create them from your deployment, or if the entries are missing on machines where you do not want to repair the installation. They are optional, and their absence does not affect comparisons started from a DMS or the Office add-ins.
Detection method
For an application with an MSI deployment type, Configuration Manager derives a detection rule from the MSI product code automatically, and that is sufficient to detect the application itself.
If you want the deployment to be reported as compliant only when it is fully configured, add a second detection clause for the URL scheme registration:
This is useful because it distinguishes a fully working deployment from one where the MSI installed but the shell registration did not complete. Since that registration cannot fail the installation, a detection rule is the most practical way to find affected machines across an estate rather than discovering them one support ticket at a time.
Using a deployment script wrapper
Many organisations wrap the installation in a PowerShell script, often using a framework such as the PowerShell App Deployment Toolkit. The sequence is the same as above: install the MSI, register the URL scheme, apply the settings, then optionally register the File Explorer menu.
If your framework provides its own registry helper, you can use it in place of the reg add commands. The values to create are identical. For example, a toolkit that exposes a Set-RegistryKey function would create the first URL scheme value as:
Do not treat a script step’s exit code as proof that the URL scheme was registered. Always confirm the registry values exist, or use the validation steps below. An exit code of zero from a wrapper script only means the step ran, not that the scheme is present.
Validating the deployment
Test on a machine that has received the deployment and has had no manual configuration applied, and perform no manual steps before testing.
Confirm the URL scheme responds
Press Windows + R, enter draftable://?source=outlook and select OK. The New Comparison window should open.
Confirm the HTTP Listener Service is running
Press Ctrl + Shift + Esc, open the Services tab, and confirm that Draftable.HttpListener is present and running.
Run the built-in system check
In Draftable Legal, open Settings, then Help & Troubleshooting, then Diagnostics, and select Run system check. On versions before 26.6 this is Settings > Troubleshooting > System Verification. Confirm the Microsoft Windows: Custom URL scheme supported check passes.
Start a comparison from your DMS
From iManage, SharePoint Online or NetDocuments, select two documents and choose the Draftable compare action. The comparison should open in Draftable Legal.
Confirm licensing applied
Open Settings, then Licensing, and confirm the product key has been applied and the licence is active.
Updating an existing deployment
An MSI update does not preserve your previous feature selection. Installing a newer MSI over an existing installation applies only the features named in the new command. Any feature you leave out is removed, including HttpListener and the Office add-ins. Always repeat the full feature list, or use ADDLOCAL=ALL, in every update command. This is the usual explanation for the HTTP Listener Service or an add-in disappearing after an update.
An update re-runs the installer’s shell registration, so it also refreshes the URL scheme. Verify it after updating all the same, and if you build the registry values into your deployment, keep them in the update as well. If the installation path changes between versions, the shell\open\command value has to match the new path, otherwise it points at an executable that no longer exists.
Machine-wide MSI installations do not update themselves, so plan version upgrades as a normal Configuration Manager deployment. For a downgrade, uninstall the current version first: installing an older MSI over a newer one is not supported. See Update procedure and configuration across deployment options.
Troubleshooting
If you need assistance with a Configuration Manager deployment, contact support@draftable.com and include your verbose MSI installer log.