NightWatchman Enterprise
Nomad integration with WakeUp is available if you enable this feature when installing NightWatchman Management Center. You should install ActiveEfficiency Server first and then install NightWatchman Management Center. Both servers require Windows Message Queuing feature (MSMQ) to be enabled.
In summary, you require the following:
- NightWatchman Management Center server
- WakeUp Server installed on each Configuration Manager site server
- ActiveEfficiency Server
- WakeUp client module enabled in the 1E Client on all client computers
- Wake-on-LAN enabled on all client computers.
Please refer to Integrating with WakeUp.
See below for pre-installation checks, architecture and ports.
Tachyon
Nomad Download Pause is available if you implement a Tachyon server infrastructure, including enabling the Tachyon client features in 1E Client in addition to the Nomad client. It also requires Single-site download and ActiveEfficiency.
PXE Everywhere
If you are also implementing a PXE Everywhere solution using Nomad, ensure you meets its prerequisites. Please refer to PXE Everywhere 4.0 - Requirements.
Accounts needed to install Nomad
To install Nomad, you will need:
- Installer account – must be a domain account with local admin rights
The Nomad Dashboard and dynamic pre-cache features require ActiveEfficiency to synchronize with the Configuration Manager database. For standalone primary site environments, permissions are assigned to the ActiveEfficiency service account automatically using the ConfigMgr_DViewAccess localgroup native to Configuration Manager. For a CAS, this group is not created natively therefore additional steps are required to allow access. Please refer to ActiveEfficiency Server 1.10 - Preparation: Granting access to the Configuration Manager site database.
If your set-up is across three distributed servers hosting the ActiveEfficiency service, the database and the Configuration Manager database and you plan to use the Nomad Dashboard or the Nomad pre-cache features (or if you get the Login failed for user NT AUTHORITY\ANONYMOUS LOGON
error message in the ActiveEfficiency service log (located in C:\ProgramData\1E\ActveEfficiency
), please refer to the procedure in ActiveEfficiency Server 1.10 - Preparation: Service Principal Names and Delegation.
Checks prior to installing Nomad
- If you are upgrading, please refer to Upgrading Nomad. You must upgrade in the following order to avoid potential forward compatibility issues:
- Upgrade all site servers and Distribution Points first. Old and new clients can then be sure to connect to the latest version on servers
- Upgrade all Nomad clients running on a single subnet at the same time. This avoids potential issues with older clients attempting to peer connect with new clients on the same subnet, even if the client configuration remains the same
- Ensure DNS is working properly
- Ensure client side firewalls have exceptions in place for
NomadBranch.exe
,NomadPackageLocator.exe
andPackageStatusRequest.exe
Ensure local broadcasts are enabled on each subnet that Nomad operates in
Some wireless access points may be configured to prevent broadcasts, which will prevent Nomad peer-sharing features from working. See the Wireless Access Points prerequisite below for details on WAP configuration.- Ensure the Configuration Manager client is healthy and functioning properly
- The latest version of ActiveEfficiency should be installed to support certain features, please refer to the ActiveEfficiency heading above. Network site information (which subnets are in which sites) must also be added to ActiveEfficiency.
- Nomad clients must have
StatusMsgEvents = 0x1000000064
set in the registry to enable them to send data to the dashboard. Currently the default is 0 and no status messages will be sent. - If you want Nomad integration with WakeUp then you will need the following
- ActiveEfficiency
- The latest version of ActiveEfficiency must be installed and the single-site download feature enabled, as described in ActiveEfficiency Server 1.10 - Configuring the Single-Site Download feature
- NightWatchman Management Center with the WakeUp integration with ActiveEfficiency feature enabled.
- NightWatchman Management Center 7.0 or later must be installed
- WakeUp Server 7.0 or later must be installed
- 1E Agent 7.0 or later (with the WakeUp component enabled and reporting turned on) must be deployed to all the clients on the required subnets
You will need a valid NightWatchman Enterprise license to use these components.
- On Nomad peers:
- ContentRegistration must be enabled on all machines where the WakeUp feature is to be used.
- On Nomad machines requesting the download:
- Enable the 1E Agent WakeUp component
- Enable SSD if site-wide wake-up is required
- On the machines where wake-up is used:
- The BIOS on each client must be configured to support wake from off
- The network adapter on each client must be configured to support wake from sleep (1E Services can help configure this using vendor utilities and scripts)
- ActiveEfficiency
To support enhanced package consistency checking, the Nomad client must be installed on each Configuration Manager DP. This client enables file-level consistency checking by creating a manifest file on the DP for every version of each package created enabling Nomad to verify that each file it downloads is consistent with the version available on the DP.
LSZ generation using HTTP/HTTPS is automatically configured only on DPs that are also Site servers. For standalone DPs (those not on a site server), enable the following on the Nomad client running on the DP either during installation or by updating the Nomad registry:
Installer property Registry value Description SIGSFOLDER SigsFolder Nomad is able to leverage Configuration Manager's binary differential replication (BDR) if the Windows remote differential compression feature is installed on the DP server using the Windows Server Manager. On the Nomad side, set this registry value on the DP to point to the Configuration Manager RDC signatures folder. SPECIALNETSHARE SpecialNetShare The 0x4000 bit must be set to enable the Nomad client to handle LSZ file generation requests coming from HTTP/HTTPS enabled clients. PERMITTEDLSZSHARES PermittedLSZShares When installed on a standalone DP (not on a site server), ensure that this registry value contains the local share names used on the server (e.g. SMSPKGF$
;SMSPKGG$
; etc) to host Configuration Manager packages. The default value satisfies the default locations used by Configuration Manager.- If you are using the BIOS to UEFI feature, ensure you meet its prerequisites described in BIOS to UEFI 1.4 - Prerequisites.
Certificates
You can use digital certificates to certify the identity of entities in your network. We support the use of Public key infrastructure (PKI) based certificates or self-signed certificates. If you are using PKIs to digitally sign entities from the outset, ensure that they are deployed to all agents. Alternatively, you can deploy PKIs post-installation. Things to bear in mind when using the HTTPS protocol:
- Define the certificate type using P2PSSLSETTINGS (0 – self-signed certificates or 1 – PKI certificates). By default self-signed is enabled.
When self-signed is enabled, a self-signed certificate is created by the installer and stored in
MY
store.
Networking
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.
The following are the ports used by Nomad client on clients and on Distribution Points. The table does not include Configuration Manager communications, which can be found here: https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/communications-between-endpoints.
Ports | Notes | Configurable |
---|---|---|
UDP 1779 | Default port Nomad uses for listening to elections to determine the master on a subnet, control traffic and for content transfer if you have Connectionless enabled. A firewall exception must exist for this port. Nomad will create one automatically for Windows firewall, but not for other firewall software. | Yes, during installation. |
TCP 80 (HTTP) | Used when the Nomad master requests LSZ files from Nomad running on the DP and when the Nomad master downloads content using Nomad as provider. Communications depend on how the DP is configured. Configuration Manager is configured to use either HTTP or HTTPS. If Nomad clients and ActiveEfficiency server are configured to use HTTP, Nomad clients using SSD register and query for content. | No, for communications with CM components. Nomad service on startup reads the configured ports from CM client registry and uses the same for LSZ generation. Yes, for communications with ActiveEfficiency using Nomad's PlatformURL setting. |
TCP 443 (HTTPS) | Used when the Nomad master requests LSZ files from Nomad running on the DP and when the Nomad master downloads content using Nomad as provider. Communications depend on how the DP is configured. Configuration Manager is configured to use either HTTP or HTTPS. If Nomad clients and ActiveEfficiency server are configured to use HTTPS, Nomad clients using SSD register and query for content. | No, for communications with CM components. Nomad service on startup reads the configured ports from CM client registry and uses the same for LSZ generation. Yes, for communications with ActiveEfficiency using Nomad's PlatformURL setting. |
TCP 5080 (HTTP) | Default HTTP port to use for peer copy. If you are using a custom port, ensure that all agents use the same custom port. From Nomad 6.2, peer copy can be enabled over HTTP (default 5080) or HTTPS (default 5443). You can customize the ports for this feature in the host registry but a change to the default impacts Nomad's peer backup assistant which is used to capture user data on remote peers during OS deployments. | Yes, during installation. |
TCP 5443 (HTTPS) | Default HTTPS port to use for peer copy. If you are using a custom port, ensure that all agents use the same custom port. From Nomad 6.2, peer copy can be enabled over HTTP (default 5080) or HTTPS (default 5443). You can customize the ports for this feature in the host registry but a change to the default impacts Nomad's peer backup assistant which is used to capture user data on remote peers during OS deployments. | Yes, during installation. |
TCP 139 (SMB) | Required only if SMB is enabled. Used when Nomad master downloads content from DP and for peer-to-peer content transfer between the Nomad master and Nomad peers. Communications depend on how the DP is configured. That is HTTP, HTTPS, SMB or SMB over TCP. For Configuration Manager the default is HTTP or HTTPS. Windows Firewall automatically adds the exception when you enable File and Print Sharing but you may have to do this manually if you are using a different firewall product. | No. SMB ports cannot be configured. |
TCP 445 (SMB over TCP) | Required only if SMB is enabled. Used when Nomad master downloads content from DP and for peer-to-peer content transfer between the Nomad master and Nomad peers. Communications depend on how the DP is configured. That is HTTP, HTTPS, SMB or SMB over TCP. For Configuration Manager the default is HTTP or HTTPS. Windows Firewall automatically adds the exception when you enable File and Print Sharing but you may have to do this manually if you are using a different firewall product. | No. SMB ports cannot be configured. |
TCP 137 (SMB) | Required only if SMB is enabled. Used by SMB for data transfer and related communications. It is used to resolve NetBIOS names during a transfer. UDP NetBIOS name query packets are sent to this port. Windows Firewall automatically adds the exception when you enable File and Print Sharing but you may have to do this manually if you are using a different firewall product. | No. SMB ports cannot be configured. |
TCP 139 (SMB) | Required only if SMB is enabled. Used by SMB for data transfer and related communications. It is used to resolve NetBIOS names during a transfer. UDP NetBIOS datagram packets are exchanged this port. Windows Firewall automatically adds the exception when you enable File and Print Sharing but you may have to do this manually if you are using a different firewall product. | No. SMB ports cannot be configured. |
Nomad can use ephemeral ports (not discussed here). Ephemeral or high ports can either be UDP or TCP depending on the protocols used and are used to send information out. In a typical client-server communication, these are ports opened by the client on its own machine in order to send something to the server and they are closed as soon as the transmission is done, hence the term ephemeral. From a security perspective, it is not an issue.
Most firewalls will allow outgoing communications by default so in all likelihood, you will not need to do any firewall configuration. However, if your firewall blocks these outbound communications, consult the documentation for your firewall on how to enable these types of communications.
Basic Nomad architecture
Ports | Notes |
---|---|
UDP 1779 | Step 1By default, Nomad uses UDP Port 1779 to communicate during the election process for determining the master on a subnet. The Nomad installer will automatically addNomadBranch.exe ,NomadPackageLocator.exe and PackageStatusRequest.exe to the list of excepted programs in the native Windows Firewall.The default value for the port may be changed at install time using the P2PPORT installer property or post-installation by changing the P2P_Port registry value. If you change the default port, you must ensure all Nomad clients communicate using the same port. The Nomad port (by default UPD Port 1779) must be open on all wireless access points to facilitate Nomad peer-to-peer communications. Not all vendors enable this port by default, please refer to the specific device vendor's documentation for details on how to enable ports on each WAP device. |
TCP 80 (HTTP) TCP 443 (HTTPS) | Step 2Nomad Master requests LSZ file from Nomad running on the DP. |
TCP 80 (HTTP) TCP 443 (HTTPS) TCP 139 (SMB) TCP 445 (SMB over TCP) | Step 3Nomad Master downloads content using Nomad as provider. This communication depends on how the DP is configured. It may be one of the following:
For Configuration Manager the default setting is HTTP or HTTPS. |
TCP 139 (SMB) | Step 4Local copies from the Nomad master. The recommended way to facilitate Nomad cache access is to enable Windows File and Print Sharing. If this is not feasible on your network environment you can configure Nomad to use different means to access network shares, see Peer access to the Nomad cache for more details on configuring this option.Connections may use one of the following:
|
Nomad pre-caching architecture and ports
The Nomad pre-caching uses the following ports in its communications. If a site server is configured to use custom ports, pre-caching will use those ports to communicate with a management or distribution points. To ensure high-availability, pre-caching falls back to next available site server if it fails to communicate with a management or distribution point.
Ports | Description |
---|---|
N/A | Step 1Choose a package and run the Nomad pre-caching wizard, selecting the target device collection. This step does not require any port configuration but the Nomad Configuration Manager console extensions must be installed in the Configuration Manager Console. |
TCP 80 (HTTP) TCP 443 (HTTPS) | Step 2The Nomad pre-caching wizard stores the target device and package information in ActiveEfficiency. |
TCP 80 (HTTP) TCP 443 (HTTPS) | Step 3The Nomad clients, where the pre-cache feature has been enabled, poll ActiveEfficiency every 24 hours to see if they need to pre-cache some content. This takes the form of pre-caching notifications that tell the Nomad clients they need to process a download job to fetch the specified content. |
TCP 80 (HTTP) TCP 443 (HTTPS) | Step 4The Nomad clients, with pre-caching notifications, contact the Management Point to locate the Distribution Point that holds the content. This may use HTTP or HTTPS depending on how the Management Point is configured. |
TCP 80 (HTTP) TCP 443 (HTTPS) TCP 139 (SMB) TCP 445 (SMB over TCP) | Step 5A Nomad Master election takes place and the elected master processes the job by downloading the pre-cache content using Nomad as provider. This is then distributed locally to the Nomad peers that also require the pre-cached content. This communication depends on how the DP is configured. It may be one of the following:
For Configuration Manager the default setting is either HTTP or HTTPS. |
Nomad and 1E WakeUp integration architecture and ports
Ports | Description |
---|---|
TCP 80 (HTTP) | Step 1Nomad Master contacts ActiveEfficiency and gets a list of Nomad machines that hold the content it requires. Nomad sends a request to wake the top 5 machines on the list. |
TCP 80 (HTTP) | Step 2Without waiting for any machines to be awoken, the Nomad master starts to download content from the DP. This communication depends on how the DP is configured. It may be one of the following:
For Configuration Manager, the default setting is HTTP or HTTPS. |
TCP 1801 (MSMQ) | Step 3ActiveEfficiency posts the wake message from Nomad to MSMQ for the NightWatchman Management Center to retrieve. |
WMI (DCOM) | Step 4NightWatchman Management Center tells the WakeUp server to wake the requested machines |
TCP 1776 | Step 5WakeUp server signals the WakeUp Agent on the appropriate subnet to wake the requested machines |
UDP 1776 | Step 6The WakeUp agent on the subnet sends a wakeup request to the requested machines |
TCP 139 (SMB) TCP 445 (SMB over TCP) UDP 1779 (connectionless P2P) | Step 7As part of its standard behavior, Nomad holds regular elections (every 5 minutes) to determine the most appropriate master. If a machine is found (i.e. one that has been recently awoken) that holds more of the required content, it stops downloading from the DP and fetches the content from the new machine's cache. This may be via SMB or via connectionless P2P, depending on the configuration of Nomad. |
Nomad SSD architecture and ports
Nomad SSD uses the following ports in its communications:
Ports | Notes |
---|---|
TCP 80 (HTTP) TCP 443 (HTTPS) | Step 1Nomad systems on the branch site register in ActiveEfficiency the content they hold in their shares |
TCP 80 (HTTP) TCP 443 (HTTPS) | Step 2Nomad Masters get information on which Nomad systems hold specific content |
TCP 80 (HTTP) TCP 139 (SMB) TCP 445 (SMB over TCP) | Step 3Nomad Master fetches a package from the registered Nomad share on a neighboring subnet |
We recommend that the latest version of ActiveEfficiency is installed to support this feature, please refer to Prerequisites for more details.
Sizing and deployment considerations
For optimum performance, we recommend the following:
Single-server deployment | Distributed server deployment | ||||||
---|---|---|---|---|---|---|---|
Number of machines | 5,000 | 25,000 | 50,000 | 50,000 | 100,000 | 200,000 | 500,000 |
Benchmark configuration | |||||||
Maximum downloads per hour | 5,000 | 12,500 | 25,000 | 25,000 | 50,000 | 100,000 | 250,000 |
ActiveEfficiency server (total including SQL Server) | ActiveEfficiency Server (total) | ||||||
CPU cores | 2 | 2 | 3 | 1 | 2 | 3 | 6 |
RAM | 4 GB | 6 GB | 8 GB | 4 GB | 4 GB | 4 GB | 4 GB |
ActiveEfficiency Server service | |||||||
CPU cores | 1 | 1 | 1 | 1 | 2 | 3 | 6 |
RAM | 4 GB | 4 GB | 4 GB | 4 GB | 4 GB | 4 GB | 4 GB |
ActiveEfficiency Scout (n/a) | |||||||
ActiveEfficiency database | Database Server (total) | ||||||
CPU cores | 1 | 1 | 2 | 2 | 2 | 3 | 6 |
RAM | 2 GB | 4 GB | 6 GB | 8 GB | 8 GB | 10 GB | |
SQL Server instance max memory | 1 GB | 2 GB | 3 GB | 3 GB | 4 GB | 4 GB | 6 GB |
Disk space required for database | 4.5 GB | 4.5 GB | 4.5 GB | 4.5 GB | 5 GB | 6 GB | 9 GB |
SQL Server HDD requirements | |||||||
ActiveEfficiency database MDF | 4 GB | 4 GB | 4 GB | 4 GB | 4 GB | 4 GB | 8 GB |
ActiveEfficiency database LDF | 50 MB | 50 MB | 50 MB | 50 MB | 250 MB | 500 MB | 1 GB |
TempDB MDF | 50 MB | 100 MB | 200 MB | 200 MB | 400 MB | 1 GB | 1.5 GB |
TempDB LDF | 4 MB | 8 MB | 16 MB | 16 MB | 32 MB | 64 MB | 100 MB |
Benchmarking criteria
- Benchmarked against Windows Server 2012 R2 Hyper-V infrastructure, with database and application server components on separate virtual machines
- CPU – Hyper-V host CPU configuration: 2x Intel Xeon CPU E5-2407 v2 @ 2.40GHz, 10M Cache, 4C, Max Mem 1333MHz
- Networking – virtual machines connected over a 1Gbps link through a 1Gbps physical switch
- Database storage – Samsung 850 EVO solid state drives (SSDs) attached locally to the Hyper-V host with up to 98k/90k IOPS (4K random read/write QD32), and MDF, LDF and TempDB on separate SSDs
Recommendations
- Servers can be deployed either on physical or virtual machines. For deployment on a virtual machine, assign the CPU cores at 100% virtual machine reserve
- Database Server:
- deploy data, logs and TempDB on separate physical disks
- configure SQL Server with maximum server memory limit and not at the defaults to consume unlimited memory
- for sizing the Database server in the recommendations above, up to 4GB RAM has been added for the operating system on top of SQL Server instance RAM requirements.