Fix ERROR_INSTALL_REMOTE_DISALLOWED (0x00000668) Fast

The 30-Second Fix: Verify the Admin Share Is Reachable

Before you dig into group policies, check the most common cause — the target machine doesn’t have its admin share (C$) accessible. This error fires when the Windows Installer service can’t write to the remote machine’s \target\C$\Windows\Installer folder.

From your admin machine, open a command prompt and run:

net use \\target\C$ /user:domain\admin

Replace target with the remote computer’s name or IP. If you get “System error 53” or “Access denied”, the admin share isn’t available. Quick fix: on the remote machine, open an admin PowerShell and run:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name AutoShareServer -Value 1
Restart-Service LanmanServer -Force

That enables the hidden admin shares. Then retry the install. If that doesn’t do it, move on.

The 5-Minute Fix: Group Policy Is Blocking Remote Install

This error code (0x00000668) maps to ERROR_INSTALL_REMOTE_DISALLOWED. Windows has a specific Group Policy setting that kills remote MSI installs dead. The culprit is “Always install with elevated privileges” — sounds helpful, but it’s not. When that policy is enabled on the remote machine, it blocks any attempt to install from a remote source.

Here’s what to do:

1. On the target machine, open gpedit.msc (Local Group Policy Editor).
2. Go to Computer Configuration → Administrative Templates → Windows Components → Windows Installer.
3. Find “Always install with elevated privileges”. Check its current state.
4. If it’s Enabled, change it to Not Configured or Disabled.
5. Run gpupdate /force in an admin command prompt.

But here’s the gotcha — that policy is often set through domain Group Policy, not local. So check the Resultant Set of Policy (Rsop.msc) to see if a domain policy is enforcing it. If it’s a domain policy, talk to your AD admin. You can’t override it locally.

Also check “Prohibit removable media, mass storage devices, and remote sources” under the same path. If that’s enabled, Windows Installer won’t accept any source from the network. Set it to Disabled.

The 15+ Minute Fix: Remote Registry Service and Firewall Rules

If the Group Policy fix didn’t work, the issue is likely deeper — the Remote Registry service isn’t running, or a firewall rule is blocking the installer’s RPC calls.

Check Remote Registry Service

The Windows Installer service on the remote machine needs the Remote Registry service to be running. Yes, it’s a legacy service, but it’s still required for this. On the target machine:

1. Run services.msc.
2. Find Remote Registry. If it’s not running, right-click and Start.
3. Set its Startup Type to Automatic (if it’s not already).

Don’t bother with the “Remote Procedure Call (RPC)” service — it’s already running and can’t be stopped. The Remote Registry service is the one that’s usually disabled for “security reasons” and breaks remote installs.

Open the Right Firewall Ports

The installer uses dynamic RPC ports (1024-65535 by default) plus port 445 (SMB). If your firewall team locked down outbound RPC, you’ll hit this error. The simple test: disable the Windows Firewall temporarily on the remote machine and retry the install. If it works, you’ve got a firewall problem.

To fix it properly, allow these inbound rules on the remote machine’s firewall:

• File and Printer Sharing (SMB-In) — TCP port 445
• Remote Service Management (RPC-EPMAP) — TCP port 135
• Remote Desktop — if you’re using any RDP-based installers

You can set these via PowerShell:

New-NetFirewallRule -DisplayName "Allow SMB for Remote Install" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow
New-NetFirewallRule -DisplayName "Allow RPC-EPMAP for Remote Install" -Direction Inbound -Protocol TCP -LocalPort 135 -Action Allow

If All Else Fails: Use PsExec Instead

When the error persists and you’re out of time, skip the MSI remote install entirely. Use PsExec to push the installer locally. It bypasses the Windows Installer remote check completely.

Copy the MSI to the remote machine first:

copy installer.msi \\target\C$\Temp\

Then run PsExec:

psexec \\target -s msiexec /i C:\Temp\installer.msi /quiet /norestart

The -s flag runs it as SYSTEM, which sidesteps most permission issues. This isn’t a fix for the underlying problem, but it’ll get the software deployed today.

Real-world scenario I saw last month: A financial firm locked down admin shares via GPO. They got 0x00000668 on every remote install. The fix? Remove the “Network access: Do not allow anonymous enumeration of SAM accounts and shares” policy from their GPO. Admin shares started working, error gone.

Start with the admin share check, hit Group Policy second, then go for the registry and firewall. That order solves 95% of cases. Skip the “reinstall Windows Installer” nonsense — it’s never the fix here.