Issues Starting UEM Services

The most common cause for UEM Services not starting on a Closed Network is because UEM Services are not able to perform CRL check to digicert. See the pre-reqs below:

Port Protocol Source Destination Service Description
Console and Device Services Server g1.crl
Supports code-signing verification of Workspace ONE UEM code post-installation.
Console and Device Services Server g1.crl
Supports code-signing verification of Workspace ONE UEM code post-installation.

Since VMware signs all the WS1 DLLs & .Exes to comply with Microsoft Security Practices, UEM services will perform periodic validation by online certificate status protocol (CRL Verification). Hence, the servers will need outbound access to the CRL endpoint.

On a closed network, to reach CRL endpoint is not possible since the server has no internet access. Hence, below is the workaround to bypass the CRL check.

  1. Update the Registry Settings
  2. Create an host file to point the destinations above to a local server.

Update the Registry Settings

1. Determine the SID for user running the service. Typically, the user will be local system (administrator).

Run the following command on cmd to get list  of users and SID:

WMIC useraccount get name,sid

2. Open the registry editor and navigate to:

HKEY_USERS/{SID you obtained earlier}/SOFTWARE/Microsoft/Windows/CurrentVersion/WinTrust/Trust Providers/Software Publishing

3. Change value of “State” key to 0x00023e00. 

Note, if this key doesn’t resolve the issue. You can also try “0x000002c9”. This is applicable for GPO Managed Servers.

4. Restart all UEM Services. Quick way to do this is run the following command on Powershell:

 Get-service -displayname airwatch* | restart-service

5. Perform IIS reset

If Services still don't start, try the following:

Uncheck Certificate Revocation under IE Seetings

Go Internet Explorer / Internet Options / Advanced and Uncheck the following:

  1. Check for publisher’s certificate revocation
  2. Check for server certificate revocation*

Changing the Service startup timeout

To increase the service startup time yourself, create the following registry entry:


Name: ServicesPipeTimeout
Data: The number of milliseconds that you want to give the services to start in.

To create this registry entry, follow these steps:

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following registry subkey:
  3. Right-click Control, point to New, and then click DWORD Value.
  4. In the New Value #1 box, type ServicesPipeTimeout, and then press ENTER.
  5. Right-click ServicesPipeTimeout, and then click Modify.
  6. Click Decimal, type the number of milliseconds that you want to wait until the service times out, and then click OK.
    We want to set to 3 minutes so we will enter “180000”
  7. Quit Registry Editor, and then restart the computer.

Technical Details

Resource: PDFShareForms

1. What is “WinTrust?”
2. What does “Software Publishing” provider do?
3. What does my current value of “State” registry key mean?
4. And what does magic value “0x00023e00” mean?

WinTrust is a name (and DLL) of Microsoft Trust verification services, which provide a common API for determining whether a specific subject can be trusted.

For example, when using Workspace ONE UEM, the service application needs to answer the following question: Is (this embedded in Workspace ONE UEM code) trusted (to be labeled as provided by a trusted software publisher) according to the (Software Publisher Trust Hierarchy and System Settings)?

The answer to the question depends on the several factors:

1. Type of information being verified for trust;

2. The Trust Administrator’s local system policy regarding who and what to trust;

3. The Trusted Authority who produced the subject.

Trust verification services are implemented by trust providers. There is a built-in trust provider: Software Publishing. The Software Publishing trust provider allows a calling application to determine whether a software component contains digital signatures that identify it as being authentic software released by a publisher that is trusted on the local user’s system.

Software Publishing trust provider uses registry key (on per user basis) to specify trust policy flags. The policy flags are defined as enumeration of WintrustGetRegPolicyFlags – see link below for details:

The WintrustGetRegPolicyFlags can have the following combination of bitwise values:






Trust any test certificate.



Check any test certificate for validity.



Use expiration date.



Do revocation check.



If the source is offline, trust any individual certificates



If the source is offline, trust any commercial certificates



If the source is offline, trust any individual certificates. Do not use the user interface (UI).



If the source is offline, trust any commercial certificates. Do not use the checking UI.



Turn off verification of version 1.0 certificates.



Ignore time stamp revocation checks.



Allow only items in personal trust database.

The most common value is ‘0x00023c00’. If we use the table above, we can see that such value is a bitwise combination of the following flags:


In order to change ‘State’ value from ‘0x00023c00’ to the magic value ‘0x00023e00’, we need to add flag WTPF_IGNOREREVOKATION. This flag will set policy for trust provider to ignore revocation check.