Historically, Nomad content distribution required File and Print services to be enabled in order for it to share the content. From version 4, you could bypass these services and use the connectionless transfer protocol over the User Datagram Protocol (UDP) instead. However, this implementation was not scalable and fully secure. To overcome this limitation, peer-to-peer copy over HTTP is available from version 6.2 where each agent acts as an HTTP server and can serve content from its cache. The election process determines the master and instead of copying content from its file share, peers looking to download content make HTTP requests to the master.

On this page

By default, only SMB and NetLiteralNames are enabled. If you want to enable other protocols such as HTTP or HTTPS, see P2PEnabled.

Registry valueDefault valueNotes

9 (0x9)

Has 2 new bit masks:
  • Bit 5 (0x0020) – enables HTTP
  • Bit 6 (0x0040) – enables HTTPS
P2PHttpPort5080Default HTTP port to use for peer copy. If you are using a custom port, ensure that all agents use the same custom port.
P2PHttpsPort5443Default HTTPS port to use for peer copy. If you are using a custom port, ensure that all agents use the same custom port.

Nomad agents can be configured to use either self-signed certificates or PKIs with the P2PSslSettings registry value. When the service starts, it looks for the certificate that matches this criteria:

  • Store = MY (the default certificate store)
  • Usage = Server Authentication
  • Issuer = CertIssuer
  • Subject/DNS = Host name or FQDN

If there is more than one certificate, the order of precedence for the certificate is:

  • HostName and FQDN
  • HostName
  • FQDN

If it still cannot resolve the precedence, the certificate with the longest validy is used.

  • When using Net literal names (3rd bit in P2PEnabled is set), clients ignores mismatch in host names during the SSL handshake – this is because IP addresses are generally not included in certificates
  • When using self-signed certificates, clients do not validate the certificate issuer since it is issued by NomadBranch and it is not a valid CA
  • Due to the nature of how proxy servers can be implemented, some of which can be quite complex, you may need to consult your networking specialist to see if exceptions need to be added to enable Nomad’s peer-copy over HTTP or HTTPS.

Firewall exceptions

Depending on your preferences (protocols, ports) during installation, the installer will add the exceptions to Windows firewall.

If for some reason these exceptions are removed post-installation, Nomad service will automatically re-add them. You'll just have to restart the service. Nomad service checks and fixes required firewall exceptions whenever it starts.

You can verify these in its Inbound Rules:

  1. For HTTPS (port 5443)
    Verifying inbound rules for port 5443
  2. For HTTP (port 5080) 
    Verifying inbound rules for port 5080

Note that the firewall exceptions are added against the program "system" not NomadBranch.exe. This is because Nomad uses Windows HTTP Server API to create the HTTP server and under this API all requests are handled by Windows kernel's "system" program not by Nomad directly. In some third-party firewalls you may have to use the program name "ntoskrnl.exe", since "system" is actually alias for ntoskrnl.exe.



Authentication happens only once per session and all anonymous requests are met with a HTTP 401 status code. AuthenticatedUsers determines who is granted access to the Nomad cache and any unauthorised requests are met with a HTTP 403 status code.

  • 1 – Any authenticated user (default).
  • 2 – SMSNomadP2P& – the SMSNomadP2P& account is used to authenticate with master's HTTP server. Alternatively, you can use the machine account by setting SpecialNetShare to 0x0080 (decimal 128).

If the master is on a workstation, only 6 peers can concurrently download from it – there is no limitation if the master is on a server. The Fanout feature compensates for this by enabling peers connected to the master to themselves allow connections to other peers requiring the download so that more peers can be updated at the same time.

WinPE support

Nomad in WinPE can download content from others over HTTP/HTTPS, but it will not be able to serve others. Despite not being a HTTP server, it still needs to be configured correctly (port usage and certificate type) or it will not be able to connect peers.

The configuration is in the Install and Configure Nomad in Windows PE task sequence:

Configuring PKI support for WinPE

Using to PKIs post-installation

To use PKIs post-installation:

  1. Deploy the certificate to all agents. Ensure that the certificate's usage is Server Authentication and the subjects are its host name or FQDN.
  2. Enable HTTPs (0x0040) in P2PEnabled.
  3. Update CertIssuer with the name of the certificate authority.
  4. P2PSslSettings set to 1 to enable PKI.
  5. Restart the Nomad service.

Checking the status of your Nomad P2P HTTP server

To check the status of the P2P HTTP server:

  1. Open the Nomad log. 
  2. When the Nomad service starts, it logs a list of URLs it listens to,
    Checking the status of your P2P HTTP server 
  3. Alternatively, run NETSH to check the status of the P2P HTTP server:
    Checking the status of the HTTP server using NETSH 

Checking SSL certificate bindings

To check the bindings of your SSL certificates:

  1. Open the Nomad log.
  2. When the Nomad service starts, it logs the name of the certificate and its issuer.
    Checking the status of your certificate bindings
  3. Alternatively, run NETSH to check the bindings for the certificates. In our example, the bindings for port 5443 are:
    Checking certificate bindings with NETSH

Troubleshooting failures during HTTP/HTTPS downloads

The most likely causes of HTTP/HTTPS download failures occur during a connection to a master. The most common errors are detailed below:

Error codesReason

HTTP/HTTPS is not enabled on the master or HTTP/HTTPS server on the master is listening on different port.

In our example, the log illustrates that HTTPS had not been enabled on the PC1 master.
Protocol not enabled on the master

Possible solution:  Double-check the values of P2PEnabled on both the client and remote peer - they should be the same.


Invalid Certificate on master.

In our example, issues with certificates causes the download to fail with 0x00002f8f (security error) and the logging does not identify the cause of the failure.
Unknown CA for the certificate
Where errors like this occurs, check the following on master:
  • Expiry date
  • Subjects – should contain hostname or its FQDN
  • Issuer must be trusted via the trust chain on the peer machine
  • SSL Binding – ensure it exists for the HTTPS port