Error 1923 during service installation gives misleading "insufficient privileges" message when service account does not exist

[DataTraveler1]

Update 2026-03-13: Full analysis and tested fix posted in the comments further below 👇

Description of Issue

---

Summary

When the SERVICEACCOUNT property is set to an account that does not exist on the target machine, the installer fails with Error 1923 and the message:

"Service 'PowerShell Universal' (PowerShellUniversal) could not be installed. Verify that you have sufficient privileges to install system services."

This message is incorrect and misleading. The install is running fully elevated (Privileged = 1, MsiRunningElevated = 1). The actual cause is that the Windows Service Control Manager (SCM) could not resolve the supplied account name and returned a failure to CreateService, which Windows Installer surfaces generically as Error 1923 regardless of the underlying reason.

---

Product

PowerShell Universal
Version: 26.1.3
Manufacturer: Devolutions, Inc.
Package: Devolutions.PowerShellUniversal.2026.1.3.0.msi

---

Steps to Reproduce

1. Launch the MSI installer interactively (double-click or msiexec /i).
2. Proceed through the wizard until the service account input screen.
3. Enter a service account that does not exist on the machine or domain (e.g. contoso\psu_service where the account is absent).
4. Enter any password and click Next / Install.
5. Observe the failure dialog at the service installation step.

Note: A verbose log was captured in parallel using:

msiexec /i Devolutions.PowerShellUniversal.2026.1.3.0.msi /l*v install-failed.log

The /l*v flag does not affect installer behavior — it was added solely for diagnostics.

---

Expected Behavior

The installer should detect that the supplied service account cannot be resolved before attempting service creation, and present a clear, actionable message such as:

"The service account 'nonexistent-domain\psu_service' could not be found. Please verify the account name and try again."

The user should be returned to the setup dialog without a full rollback.

---

Actual Behavior

• Installation proceeds through all file copy and custom actions successfully.
• At the InstallServices action, CreateService is called with StartName=nonexistent-domain\psu_service.
• The SCM rejects the account and returns a failure.
• Windows Installer wraps this as Error 1923 with a misleading privileges message.
• A full rollback is triggered, removing all previously copied files.
• Exit code: 1603

Relevant log extract:

Executing op: ServiceInstall(Name=PowerShellUniversal, ..., StartName=contoso\psu_service, ...)
Error 1923. Service 'PowerShell Universal' (PowerShellUniversal) could not be installed.
  Verify that you have sufficient privileges to install system services.
Action ended: InstallFinalize. Return value 3.
MainEngineThread is returning 1603

---

Impact

• The misleading message causes users and IT admins to investigate elevation/UAC issues that are not present.
• The full rollback means all installer progress is lost; the user must re-run from scratch after fixing the account.
• Silent installs (/qn) in enterprise/pipeline deployments produce only the cryptic 1923 in the MSI log with no indication that the account name is wrong.

---

Suggested Fix

Option A — Improve the Error 1923 message (low effort)

Override row 1923 in the MSI Error table with a more accurate message that mentions account validity as a possible cause alongside privileges.

Option B — Pre-flight validation CA in InstallUISequence (recommended for interactive installs)

Add an immediate C# DTF custom action scheduled just before ExecuteAction that calls:

new NTAccount(serviceAccount).Translate(typeof(SecurityIdentifier));

If IdentityNotMappedException is thrown, surface a clear error and return the user to the dialog with no rollback required.

Option C — Deferred validation CA in InstallExecuteSequence (recommended for silent/enterprise installs)

Add a deferred C# DTF custom action immediately before InstallServices in InstallExecuteSequence, performing the same NTAccount.Translate() check. This fires regardless of UI level (/qn, SCCM, Intune) and produces a named, descriptive failure in the MSI log.

⚠️ Exact sequence numbers for InstallServices and the correct dialog/control name for Option B wiring are pending confirmation from the MSI database (Orca). Will update before final submission.

Production recommendation: ship Options B + C together.

---

Attachments

• install-failed.log — verbose MSI log of the failing install
• install-succeed.log — verbose MSI log of a successful install using a valid service account

---

Environment

• OS: Windows Server (64-bit)
• Machine role: Domain Controller (WIN-DC-01) — relevant because DC security policy and Group Policy may impose additional constraints on service account rights vs. a standard member server
• Install path: C:\Program Files (x86)\Universal\ — this is a 32-bit MSI running on a 64-bit OS, which is expected; noted here in case it is relevant to path handling
• Install context: elevated (SYSTEM via msiexec service), Privileged = 1, MsiRunningElevated = 1 confirmed in log
• Domain environment: yes
• Failed run service account: contoso\psu_service (account does not exist)
• Successful run service account: contoso3\psu_service (valid account, install succeeds)
• Both runs used the same MSI, same machine, same install options

Version

26.1.3

Severity

Low

Hosting Method

MSI (Windows Service)

Operating System

Windows

Database

SQLite

Licensed

Yes

Features

No response

Additional Environment data

No response

Screenshots/Animations

[DataTraveler1]

Follow-up to original report — full analysis and tested fix

The original report captured the symptom and proposed three fix options with a note that exact MSI database details were pending Orca confirmation. This comment provides all confirmed details and includes working, tested C# code that can be compiled and patched into the MSI without access to the original WiX source.

---

Root Cause (confirmed)

The ServiceInstall table has StartName = [SERVICEACCOUNT]. The property value is passed directly to the Windows SCM CreateService API without any validation. When the account does not exist, the SCM returns an error code that Windows Installer wraps unconditionally as Error 1923 — the same message it uses for actual privilege failures — so users and IT admins invariably chase an elevation issue that does not exist.

Confirmed from ServiceInstall.idt:

ServiceInstall  StartName   [SERVICEACCOUNT]

No existing CA validates the account before InstallServices at sequence 5800.

---

Confirmed MSI Database Details

All values below confirmed from the exported IDT tables.

Item	Value
Service account wizard dialog	SettingsServiceDlg ("PowerShell Universal Service Settings")
Account input control	ServiceAccount
Advance button	Next
Existing NewDialog events on Next	3 rows — all at Ordering = 1
InstallServices sequence	5800
Sequences 5798, 5799	Occupied (SetAPPSETTINGSProperties, APPSETTINGS)
Available slots	5796 (setter CA) and 5797 (deferred CA)
Error table row 1923	Absent — only rows 26253 and 26254 exist

---

Fix

Option A — Improve the error message only (no code, Orca only)

Add row 1923 to the Error table. This row is not present in the current package, so this is a pure add with no risk of changing existing behaviour. The new row overrides the engine's hardcoded string.

Suggested message:

Service '[2]' ([3]) could not be installed. The service account may not exist on this machine or domain, the password may be incorrect, or the account may lack "Log on as a service" rights. Verify the service account name and credentials, then re-run setup.

Pros: No code required; can be applied immediately.
Cons: Only changes the message after the failure — no dialog-level prevention and no improvement for silent installs.

---

Option B — Dialog-level pre-flight check (interactive installs)

Add an immediate DTF custom action to the Next button on SettingsServiceDlg at Ordering = 0 so it fires before the three existing NewDialog ControlEvents at Ordering = 1.

Important implementation notes

1. Do not use session.Message() from this CA. When the CA runs as a remote immediate action (standard sfxca subprocess model), calling session.Message(InstallMessage.Error, ...) causes the proxy to return Failure to the engine, which maps to Error 2896 and raises a FatalError dialog — contrary to the intended behaviour. Call user32.dll MessageBoxW via P/Invoke instead.

2. Always return ActionResult.Success. Returning Failure from a UISequence DoAction CA also triggers Error 2896. Dialog navigation is controlled exclusively by the _SVCACCT_VALID property described below.

3. Gate navigation with a property, not a return value. The three existing NewDialog ControlEvents on SettingsServiceDlg.Next have their Condition column amended to require _SVCACCT_VALID = "1". If the CA leaves the property empty (unresolvable account), none of the NewDialog events fire — the user stays on the dialog with no rollback and no FatalError.

4. Condition is part of the ControlEvent primary key. MSI SQL cannot UPDATE a primary key column; use DELETE + INSERT for each of the three NewDialog condition changes.

MSI database changes (Option B)

Table	Operation	Detail
Binary	Add row	Name=ValidateSvcAcctCA, Data=<DLL>
CustomAction	Add row	Action=ValidateServiceAccountUI, Type=1, Source=ValidateSvcAcctCA, Target=ValidateServiceAccountUI
ControlEvent	Add row	Dialog_=SettingsServiceDlg, Control_=Next, Event=DoAction, Argument=ValidateServiceAccountUI, Condition=1, Ordering=0
ControlEvent	DELETE + INSERT	Argument=SettingsDataDlg — condition: 1 → _SVCACCT_VALID = "1"
ControlEvent	DELETE + INSERT	Argument=SettingsServerDlg — condition: APPSETTINGS = "0" → APPSETTINGS = "0" AND _SVCACCT_VALID = "1"
ControlEvent	DELETE + INSERT	Argument=VerifyReadyDlg — condition: NOT OLDFOUND AND APPSETTINGS = "1" → NOT OLDFOUND AND APPSETTINGS = "1" AND _SVCACCT_VALID = "1"

C# source — ValidateServiceAccountUI (Option B entry point)

using System;
using System.Runtime.InteropServices;
using System.Security.Principal;
using Microsoft.Deployment.WindowsInstaller;

public class CustomActions
{
    [DllImport("user32.dll", CharSet = CharSet.Unicode)]
    private static extern int MessageBoxW(IntPtr hWnd, string text, string caption, uint uType);

    private const uint MB_OK        = 0x00000000;
    private const uint MB_ICONERROR = 0x00000010;

    // Option B: fires on SettingsServiceDlg.Next (DoAction, Ordering=0)
    // Always returns Success — navigation gated by _SVCACCT_VALID property
    [CustomAction]
    public static ActionResult ValidateServiceAccountUI(Session session)
    {
        session["_SVCACCT_VALID"] = "";   // reset on every button click

        string account = session["SERVICEACCOUNT"];

        if (string.IsNullOrWhiteSpace(account)
            || account.Equals("LocalSystem", StringComparison.OrdinalIgnoreCase)
            || account.StartsWith("NT AUTHORITY\\", StringComparison.OrdinalIgnoreCase)
            || account.StartsWith("NT SERVICE\\", StringComparison.OrdinalIgnoreCase))
        {
            session["_SVCACCT_VALID"] = "1";
            return ActionResult.Success;
        }

        try
        {
            new NTAccount(account).Translate(typeof(SecurityIdentifier));
            session["_SVCACCT_VALID"] = "1";
            return ActionResult.Success;
        }
        catch (IdentityNotMappedException)
        {
            // Cannot use session.Message() here — causes Error 2896 from sfxca subprocess.
            MessageBoxW(IntPtr.Zero,
                "Service account '" + account + "' could not be found on this machine or domain.\n\n"
                    + "Please verify the account name and try again.",
                "PowerShell Universal Setup",
                MB_OK | MB_ICONERROR);
            // _SVCACCT_VALID stays empty — NewDialog conditions below block navigation.
            return ActionResult.Success;
        }
    }
}

---

Option C — Execute-sequence guard (silent / enterprise installs)

A deferred CA at sequence 5797 fires regardless of UI level (/qn, SCCM, Intune, pipeline), immediately before InstallServices at 5800. If the account cannot be resolved, the install aborts with a human-readable log line naming the unresolvable account instead of the cryptic Error 1923.

Note: rollback still occurs (the deferred CA runs inside the MSI transaction). The improvement over the current behaviour is error clarity — the log clearly identifies the unresolvable account. Rollback avoidance requires Option B, which fires before ExecuteAction / InstallInitialize, so the transaction never starts.

MSI database changes (Option C)

Table	Operation	Detail
Binary	(same row as Option B — one DLL, two entry points)
CustomAction	Add row	Action=SetValidateServiceAccountData, Type=51, Source=ValidateServiceAccount, Target=SERVICEACCOUNT=[SERVICEACCOUNT]
CustomAction	Add row	Action=ValidateServiceAccount, Type=1025, Source=ValidateSvcAcctCA, Target=ValidateServiceAccount
InstallExecuteSequence	Add row	Action=SetValidateServiceAccountData, Sequence=5796
InstallExecuteSequence	Add row	Action=ValidateServiceAccount, Sequence=5797

Why Type 51 setter CA? Deferred CAs run in a sandboxed server process and cannot read MSI session properties directly. The setter CA (Type 51) writes SERVICEACCOUNT into CustomActionData via an MSI property whose name must match the deferred CA name exactly (ValidateServiceAccount).

C# source — ValidateServiceAccount (Option C entry point, same class / same DLL)

    // Option C: deferred CA in InstallExecuteSequence at seq 5797
    // Covers /qn silent installs, SCCM, Intune, pipeline deployments
    [CustomAction]
    public static ActionResult ValidateServiceAccount(Session session)
    {
        string account = session.CustomActionData["SERVICEACCOUNT"];

        if (string.IsNullOrWhiteSpace(account)
            || account.Equals("LocalSystem", StringComparison.OrdinalIgnoreCase)
            || account.StartsWith("NT AUTHORITY\\", StringComparison.OrdinalIgnoreCase)
            || account.StartsWith("NT SERVICE\\", StringComparison.OrdinalIgnoreCase))
        {
            session.Log("[ValidateServiceAccount] Built-in account, skipping.");
            return ActionResult.Success;
        }

        try
        {
            new NTAccount(account).Translate(typeof(SecurityIdentifier));
            session.Log("[ValidateServiceAccount] PASS: '" + account + "'");
            return ActionResult.Success;
        }
        catch (IdentityNotMappedException)
        {
            session.Log("[ValidateServiceAccount] FAIL: '" + account + "' could not be resolved.");
            var record = new Record(1);
            record[0] = "Service account '[1]' could not be found. Correct the account name and re-run.";
            record[1] = account;
            session.Message(InstallMessage.Error, record);
            return ActionResult.Failure;
        }
    }

---

Build notes

• Target framework: net472 (x86). The package's own LaunchCondition requires .NET 4.7.2+ (registry key 460798), so net472 is the lowest safe target and runs on all supported OS versions (Server 2019 inbox is exactly 4.7.2).
• Reference: Microsoft.Deployment.WindowsInstaller.dll from WiX Toolset v3 SDK.
• Wrap with MakeSfxCA.exe from the WiX SDK. Use absolute paths for all arguments — relative paths cause MakeSfxCA to silently produce a broken 195 KB stub without any diagnostic output. Include a CustomAction.config alongside the managed DLL to force CLR 4.x load; without it, sfxca falls back to the .NET 2.0/3.5 runtime and fails silently on modern OS versions:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
  </startup>
</configuration>

Correct wrapped output size: ~270 KB. MakeSfxCA should report three files packed: ValidateSvcAcctCA.dll, Microsoft.Deployment.WindowsInstaller.dll, CustomAction.config.

---

Test Results

The fix was applied to a copy of Devolutions.PowerShellUniversal.2026.1.3.0.msi and tested on Windows Server 2019 with verbose logs. All tests passed.

Test	Account	Mode	Result
T-01	contoso\psu_service (non-existent)	Interactive	✅ MessageBox shown, stayed on dialog, no Error 2896, no rollback
T-02	devolutions\psu_service (valid domain account)	Interactive	✅ _SVCACCT_VALID="1" set, wizard advanced
T-03	contoso\psu_service (non-existent)	Silent /qn	✅ [ValidateServiceAccount] FAIL: in log, Return value 3, no Error 1923
T-04	devolutions\psu_service (valid domain account)	Silent /qn	✅ Return value 1, install completed

T-01 — screenshot (interactive, non-existent account):

MessageBox shown by Option B when contoso\psu_service cannot be resolved. The user remains on the wizard dialog — no rollback, no FatalError dialog.

T-03 log excerpt (before vs. after):

Before (unpatched):

Error 1923. Service 'PowerShell Universal' (PowerShellUniversal) could not be installed.
  Verify that you have sufficient privileges to install system services.

After (patched):

[ValidateServiceAccount] FAIL: 'contoso\psu_service' could not be resolved.
Action ended ...: ValidateServiceAccount. Return value 3.

---

Recommendation

Implement Options B + C together. Option B prevents the rollback entirely for interactive users. Option C handles the same failure condition in enterprise/silent deployments where dialogs never appear. Both entry points live in the same DLL (ValidateSvcAcctCA) and share the same NTAccount.Translate() resolution logic.

[Omzig]

@DataTraveler1 i smell ai in this one, man this thing is epic

[DataTraveler1]

Yes it was AI but I hand-tested and personally inspected 🔎 everything. We had to go through quite a few iterations to get it right 👍 😁

[MikeShepard]

AI can do a wonderful job of reporting/summarizing. Not a bad thing.

…

On Mon, Mar 16, 2026 at 9:40 AM DataTraveler1 ***@***.***> wrote: *DataTraveler1* left a comment (ironmansoftware/powershell-universal#5592) <#5592 (comment)> Yes it was AI but I hand-tested and personally inspected 🔎 everything. We had to go through quite a few iterations to get it right 👍 😁 — Reply to this email directly, view it on GitHub <#5592 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKI2ITDDXXQHTOXO5WA5YT4RAG5PAVCNFSM6AAAAACWP3VRRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRYGE3DKMRRHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

-- https://powershellstation.com

[DataTraveler1]

I would characterize it as accelerating productivity 🚀