Symptom, cause, fix · As of September 2026 (Server 1.0.31, Agent 1.0.36)

Known Issues

Each section describes one issue the way an administrator sees it, names the cause, and the fix. The issues are unrelated to each other; read only the section whose symptom you are seeing.

1. The browser asks for a password, or access is denied despite having permission

Usually there is nothing to do here. Kerberos signs domain users in automatically through the server's computer account; the SPN for the server's own name already exists. Something needs setting up only if the portal must also be reachable under a different name, for example behind a Network Load Balancer (NLB) with one shared address for several nodes. We advise against that: ZeroPortal needs no load balancer for high availability, the agent switches to the next reachable node on its own (see Setting up high availability). An SPN on a shared alias is exactly the source of error this section describes — for the same reason, many vendors avoid NLB in front of Kerberos-secured services.

1.1 Symptom

• A login window appears when opening the portal; after entering domain credentials, everything works. Cancelling shows the "Sign in required" page instead.
• Or: the header shows the account, but the portal says "no access", even though the user is in the right AD group.

1.2 Cause

The portal signs domain users in silently through Windows authentication (Negotiate: Kerberos or NTLM). Browsers only send the Windows account to sites in the Local Intranet zone; if that zone entry is missing, the login window appears (401). "No access" (403), on the other hand, is a permissions question: the group is not assigned to a portal group, or the ticket predates the group change. NTLM instead of Kerberos happens with an alias name that has no SPN, or when accessing by IP address; the permissions in the portal are the same either way.

1.3 Fix

1. Add the portal URL to the intranet zone, by group policy for every user: User Configuration → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page → Site to Zone Assignment List, portal URL (e.g. https://zeroportal.firma.local or *.firma.local) with value 1; the same setting also exists under Computer Configuration. To test on a single machine: Internet Options → Security → Local Intranet → Sites → Advanced.

2. For Edge and Chrome, alternatively: the browser policy AuthServerAllowlist with the portal name (several separated by commas). Firefox: network.negotiate-auth.trusted-uris.

3. SPN only for an alias. The SPN already exists for the server's own name. If the portal is reached under a DNS alias (e.g. zeroportal.firma.local pointing at ZPSRV01), register it on the server's computer account:

powershell setspn -Q HTTP/zeroportal.firma.local # is the name already taken? setspn -S HTTP/zeroportal.firma.local ZPSRV01$ setspn -L ZPSRV01$ # check

An SPN may only sit on one account; no portal restart is needed; there is no SPN for an IP address. Load balancer in front of several nodes: NTLM, or a shared gMSA.

4. On "no access": check permissions in the portal (see Users, permissions, licences and logs); sign out and back in on the Windows client after a group change.

1.4 Check

Open the portal from a client: no login window should appear, and the header shows account and method (Username: DOMAIN\user Auth: Kerberos).

On the client, klist shows the ticket HTTP/zeroportal.firma.local, whoami /groups the groups in the token. In the portal log C:\ProgramData\NickIT\ZPServer\Logs\ZeroPortalLogs.log, every rejected action is logged as a warning Access denied (403): user '…' tried …; a login window (401) is not logged. A browser on the portal server itself usually shows NTLM; that is not an error.

2. Installing an MSIX package takes minutes on devices without internet

Some devices have no internet access for good reason: manufacturing networks, point-of-sale systems, classified or otherwise isolated networks, or a proxy that only lets signed-in users through and shuts out the system account. But Windows checks a package's signature online by default — without a connection, every check runs into a timeout before the install continues. This section shortens the wait without turning the check off.

2.1 Symptom

• MSIX and App Attach packages take one to several minutes per package on devices without internet, or behind a proxy, while others take only seconds; the package itself has long since finished transferring. The Windows App Installer shows the same thing on a double-click.
• In the agent's tray menu, Deployment times shows a long package deployment.
• The agent log carries warning 3410 as soon as a deployment has taken longer than 30 seconds (threshold Agent/SlowDeployWarnSeconds, default 30, 0 = off). It names the missing intermediate certificate or the unreachable revocation-list addresses.

2.2 Cause

Before installing, Windows checks the signature of every package and, to do so, wants to fetch the intermediate certificate from the internet (if it is missing locally) and check the revocation list (CRL) or an OCSP response. Without internet, every lookup runs into a timeout: 15 seconds per address by default, and up to 20 seconds per check; a package is checked more than once, so this adds up to minutes. Deployment runs under the system account; a proxy set up only for signed-in users does not help it (netsh winhttp show proxy).

2.3 Fix

Every step needs administrator rights; none of them turns off signature checking. Steps 1 and 2 are safe on any device, step 3 only for devices without internet.

1. Add the intermediate certificate to the computer store. On a machine with internet: right-click the package → Properties → Digital Signatures → Details → View Certificate → Certification Path, select the certificate between issuer and root, View Certificate → Details → Copy to File (DER, .cer). On the device, import it into the local computer's Intermediate Certification Authorities store:

powershell Import-Certificate -FilePath .\Intermediate-CA.cer -CertStoreLocation Cert:\LocalMachine\CA

Centrally: Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Intermediate Certification Authorities. Trust is still decided by the root authority.

2. Limit the wait for certificate lookups. Revocation checking stays on, but without internet it now fails after seconds instead of a quarter minute per address:

powershell $key = 'HKLM:\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config' New-Item -Path $key -Force | Out-Null New-ItemProperty -Path $key -Name ChainUrlRetrievalTimeoutMilliseconds -Value 3000 -PropertyType DWord -Force | Out-Null New-ItemProperty -Path $key -Name ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds -Value 6000 -PropertyType DWord -Force | Out-Null

Centrally: the same values as a registry item (Computer Configuration → Preferences → Windows Settings → Registry) or the policy Public Key Policies → Certificate Path Validation Settings, Network Retrieval tab, both timeouts in seconds.

Consequence: signature checking itself is not turned off, it just gives up sooner when an address does not answer. On devices with an occasionally slow or unstable network, this can make the revocation check end more often in "could not be determined" instead of "valid" — Windows still allows the install in that case, but the revocation list was not checked in full. Do not set these values on devices with reliable internet.

3. Turn off the Defender cloud query (devices without internet only). Real-time protection stays on:

powershell Set-MpPreference -MAPSReporting Disabled -SubmitSamplesConsent NeverSend -DisableBlockAtFirstSeen $true

Centrally: Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → MAPS. Leave out on devices with occasional internet.

4. Restart the deployment service. The certificate takes effect right away, but the timeout values only reliably apply after restarting the AppXSvc service or the device:

powershell Restart-Service AppXSvc -Force

The restart aborts any deployment in progress; do not run it during a sync. When rolled out by group policy, the device's next restart is enough.

5. Make the revocation-list addresses reachable (recommended). If devices can reach the CRL and OCSP addresses (a proxy or firewall exception, an internal mirror), the check is fast and complete. The addresses appear in warning 3410 and in the output of certutil -verify -urlfetch (section 2.4).

Only as a last resort: the options Check for server certificate revocation and Check for publisher's certificate revocation (Internet Options, Advanced) apply only to the user account, are not reliable for the system account, and a revoked certificate is no longer detected. To undo: delete the registry values.

2.4 Check

Measure before and after (clear the cache first, so the measurement is honest):

certutil -urlcache * delete
Measure-Command { Get-AuthenticodeSignature 'C:\Path\App.msix' }

Under a second: fine. Two-digit seconds or more: the device is affected.

Check the chain and each address (shows, per address, whether the lookup succeeded):

$sig = Get-AuthenticodeSignature 'C:\Path\App.msix'
[IO.File]::WriteAllBytes("$env:TEMP\signer.cer", $sig.SignerCertificate.Export('Cert'))
certutil -verify -urlfetch "$env:TEMP\signer.cer"

Agent log: C:\ProgramData\NickIT\ZeroPortalAgent\Logs\agent-<date>.log, the line with [3410]. "Certificate chain INCOMPLETE … '' is not in the local store": the intermediate certificate is missing (step 1). "Certificate chain is complete locally … revocation checking (CRL/OCSP) … Endpoints: …": revocation-list lookups (steps 2 and 5).

Appendix: registry (local computer)

Registry (per user account, not recommended)