Nomad Client Health integrated product pack

Integrated Product Pack used to create the Nomad Client Health instruction set and Nomad Client Health policy.

For more information please refer to Nomad Client Health Policy.

Nomad is included as part of the 1E Client, and as part of that integration, we offer a Nomad client health compliance policy in Endpoint Automation. This verifies common Nomad requirements such as ACP registration, disk availability, firewall exceptions, crash notifications and cache monitoring.

The Nomad client health policy replaces the client health tile in the Nomad dashboard plus additional remediation steps:

Keeps content distribution services up and running on Nomad clients, so that users are secure and productive
Ensures Alternative Content Provider (ACP) registration configuration is set
Maintains optimal disk availability and monitors cache size for storage capacity planning
Enforces Firewall exceptions.

Note

This policy is intended for deployment to Windows devices only.

Instructions

The following table shows the instructions included in the Integrated Product Pack. Unless already uploaded, the following instructions are added to an Instruction set named: Nomad Client Health.

Readable Payload	Type	Description	Name	Version
P2P election weight vs criticality	Question	Returns the Nomad peer-to-peer election weight and the criticality of the device. This instruction is useful if you use - and want to correlate - the Nomad feature Sensitive server weighting and the 1E Platform feature Using Device Criticality. The P2PElectionWeight registry entry does not exist unless it is explicitly set - for example by a Configuration Manager baseline or Tachyon instruction. If the registry entry does not exist, the response will be Not set. Similarly, the default criticality value assigned to a device is Undefined. The following is an extract from Election weighting in Download once to branch: Click here to expand... Nomad performs automatic weighting depending on its situation, according to the criteria listed below, and stores the value in memory (not registry). The higher the value, the greater the probability of winning the election. 61 – the agent is running on a server OS and it is not a domain controller (DC) 40 – the agent is running on a laptop 30 – the agent is running on a wireless network 10 – the agent is running on WinPE 50 – default If necessary, you can use the P2PElectionWeight registry setting to increase or decrease a Nomad client's probability of being elected a master. The range for this registry value must be between 0 and 99 inclusive. If not set, Nomad uses the values listed above. The registry key is located at: `HKLM\software\1e\NomadBranch\P2PElectionWeight` To take effect after setting the registry value, the client service must be restarted. This method is not recommended because Nomad is already quite efficient in the way it elects a master and needs very little intervention in this process. However, you may want to reduce the chance of computers with low processing power, or prevent critical servers, becoming a master. You should also consider the following points before you influence the weighting: Use this technique in exceptional circumstances and only after testing has shown that you need to make a particular computer more or less likely to be elected as a master for specific operational reasons. Choose the simplest weighting strategy possible - for example, set servers at 90, laptops at 10 and workstations at 50. The weighting does not guarantee that the more heavily weighted computers will win the election – they may be turned off or another local peer may have already cached more of the requested content. The final weighting value used by the computer during an election may differ from the registry value as Nomad will automatically adjust it depending on the chassis and the network connection used. In the event you no longer need the values to be set, you should remove it and restart the service to resume dynamic election weighting. Setting to 0 is a special case called Sensitive server weighting designed for use on critical servers. The 0 value prevents Nomad from acting as master, and devices with this value will not respond to election requests.	1E-Explorer-NomadClientHealth-ElectionWeightVsCriticality	3

Readable Payload

Type

Description

Name

Version

P2P election weight vs criticality

Question

Returns the Nomad peer-to-peer election weight and the criticality of the device.

This instruction is useful if you use - and want to correlate - the Nomad feature Sensitive server weighting and the 1E Platform feature Using Device Criticality.

The P2PElectionWeight registry entry does not exist unless it is explicitly set - for example by a Configuration Manager baseline or Tachyon instruction. If the registry entry does not exist, the response will be Not set. Similarly, the default criticality value assigned to a device is Undefined.

The following is an extract from Election weighting in Download once to branch:

Click here to expand...

Nomad performs automatic weighting depending on its situation, according to the criteria listed below, and stores the value in memory (not registry). The higher the value, the greater the probability of winning the election.

61 – the agent is running on a server OS and it is not a domain controller (DC)
40 – the agent is running on a laptop
30 – the agent is running on a wireless network
10 – the agent is running on WinPE
50 – default

If necessary, you can use the P2PElectionWeight registry setting to increase or decrease a Nomad client's probability of being elected a master. The range for this registry value must be between 0 and 99 inclusive. If not set, Nomad uses the values listed above.

The registry key is located at: HKLM\software\1e\NomadBranch\P2PElectionWeight

To take effect after setting the registry value, the client service must be restarted.

This method is not recommended because Nomad is already quite efficient in the way it elects a master and needs very little intervention in this process. However, you may want to reduce the chance of computers with low processing power, or prevent critical servers, becoming a master.

You should also consider the following points before you influence the weighting:

Use this technique in exceptional circumstances and only after testing has shown that you need to make a particular computer more or less likely to be elected as a master for specific operational reasons.
Choose the simplest weighting strategy possible - for example, set servers at 90, laptops at 10 and workstations at 50.
The weighting does not guarantee that the more heavily weighted computers will win the election – they may be turned off or another local peer may have already cached more of the requested content.
The final weighting value used by the computer during an election may differ from the registry value as Nomad will automatically adjust it depending on the chassis and the network connection used.
In the event you no longer need the values to be set, you should remove it and restart the service to resume dynamic election weighting.

Setting to 0 is a special case called Sensitive server weighting designed for use on critical servers. The 0 value prevents Nomad from acting as master, and devices with this value will not respond to election requests.

1E-Explorer-NomadClientHealth-ElectionWeightVsCriticality

Policies

The following table shows the policies included in the Nomad Client Health Integrated Product Pack:

Name	Description
Nomad Client Health	The Nomad Client Health policy ensures that the health of the Nomad client is compliant with a reference baseline.

Rules

The following table shows the rules included in the Nomad Client Health Integrated Product Pack:

Note

Any parameter values shown in the table below are specifically set in the rules when the pack is uploaded. These may be different from the default values shown in the Fragments and Trigger templates tables. You can modify these if required.

Name	Type	Description	Check and Fix fragments	Triggers	Precondition fragment
Check Nomad ActiveEfficiency connectivity status	Check	Checks the Nomad agent connectivity to ActiveEfficiency.	1E-GuaranteedState-Nomad-Check-AEConnectivity No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\ActiveEfficiency` Include Sub keys=0 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad can communicate through the Windows Firewall	Check	Check that there are Windows Firewall program exceptions for Nomad and its related executables.	1E-GuaranteedState-Nomad-Check-FirewallExceptions No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Ensure Nomad can communicate through the Windows Firewall	Fix	Ensures there are Windows Firewall program exceptions for Nomad and its related executables.	1E-GuaranteedState-Nomad-Check-FirewallExceptions No parameters 1E-GuaranteedState-Nomad-Fix-FirewallExceptions No parameters	TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad can generate LSZ files on ConfigMgr distribution points	Check	Check that LSZ generation is enabled on ConfigMgr distribution points.	1E-GuaranteedState-Nomad-Check-DpLszEnabled No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=1 smbEnabled=0
Check Nomad can hash content	Check	Checks Nomad content hashing is enabled.	1E-GuaranteedState-Nomad-Check-HashingEnabled No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad crash dumps status	Check	Checks whether Nomad has generated any crash dump in the last seven days.	1E-GuaranteedState-Nomad-Check-CrashDumps No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad does not have its content indexed by ConfigMgr software inventory checks	Check	Checks whether skpswi.dat exists in the Nomad cache directory.	1E-GuaranteedState-Nomad-Check-SkpSwiDat No parameters	TriggerTemplate-FileChange File Name=C:\ProgramData\1E\NomadBranch\skpswi.dat TriggerTemplate-IntervalHours intervalHours=1 Warning Do NOT use this Check if you have changed your cache location.	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Ensure Nomad does not have its content indexed by ConfigMgr software inventory checks	Fix	Ensures that skpswi.dat exists in the Nomad cache directory.	1E-GuaranteedState-Nomad-Check-SkpSwiDat No parameters 1E-GuaranteedState-Nomad-Fix-SkpSwiDat No parameters	TriggerTemplate-FileChange File Name=C:\ProgramData\1E\NomadBranch\skpswi.dat TriggerTemplate-IntervalHours intervalHours=1 Warning Do NOT use this Fix if you have changed your cache location.	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad has a virtual directory on ConfigMgr distribution points to perform LSZ generation	Check	Check that an LSZFILES virtual directory has been created on a ConfigMgr distribution point.	1E-GuaranteedState-Nomad-Check-DpLszVirtualDirectory No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=1 smbEnabled=0
Ensure Nomad has a virtual directory on ConfigMgr distribution points to perform LSZ generation	Fix	Ensure that an LSZFILES virtual directory has been created on a ConfigMgr distribution point.	1E-GuaranteedState-Nomad-Check-DpLszVirtualDirectory No parameters 1E-GuaranteedState-Nomad-Fix-DpLszVirtualDirectory No parameters	TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=1 smbEnabled=0
Check Nomad has sufficient disk space to download content	Check	Check the drive that Nomad is using for content download has sufficient disk space.	1E-GuaranteedState-Nomad-Check-DiskAvailablility No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad is not using the Windows temp directory for caching	Check	Checks that Nomad is not configured to use the Windows temporary directory for caching.	1E-GuaranteedState-Nomad-Check-CacheInTemp No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad is registered as an Alternate Content Provider with ConfigMgr	Check	Check that Nomad is correctly registered as an Alternate Content Provider with ConfigMgr.	1E-GuaranteedState-Nomad-Check-AlternateContentProvider No parameters	TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=1 sccmDp=0 smbEnabled=0
Ensure Nomad is registered as an Alternate Content Provider with ConfigMgr	Fix	Ensure Nomad is registered as an Alternate Content Provider with ConfigMgr, registering it if necessary.	1E-GuaranteedState-Nomad-Check-AlternateContentProvider No parameters 1E-GuaranteedState-Nomad-Fix-AlternateContentProvider No parameters	TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=1 sccmDp=0 smbEnabled=0
Check Nomad run status	Check	Checks that the Nomad service is running.	1E-GuaranteedState-Nomad-Check-StartService No parameters	TriggerTemplate-IntervalHours intervalHours=1 TriggerTemplate-ServiceStatusChange ServiceName=`NomadBranch`	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Ensure Nomad is running	Fix	Ensure the Nomad service is running, starting the service if required.	1E-GuaranteedState-Nomad-Check-StartService No parameters 1E-GuaranteedState-Nomad-Fix-StartService No parameters	TriggerTemplate-IntervalHours intervalHours=1 TriggerTemplate-ServiceStatusChange ServiceName=`NomadBranch`	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad variant status	Check	Checks whether the running Nomad service was one supplied with the 1E Client.	1E-GuaranteedState-Nomad-Check-Variant No parameters	TriggerTemplate-IntervalHours intervalHours=1 TriggerTemplate-ServiceStatusChange ServiceName=`NomadBranch`	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=0
Check Nomad's share directory is accessible	Check	Check whether Nomad needs a share, and if it does that it would be accessible to other devices.	1E-GuaranteedState-Nomad-Check-Share No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=1
Ensure Nomad's share directory is accessible	Fix	Ensures that Nomad's share is accessible if it is configured to require a share.	1E-GuaranteedState-Nomad-Check-Share No parameters 1E-GuaranteedState-Nomad-Fix-Share No parameters	TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=1
Check Nomad's share is accessible by specific accounts	Check	Checks that the correct accounts are able to access Nomad's share.	1E-GuaranteedState-Nomad-Check-ShareAccount No parameters	TriggerTemplate-WindowsRegistryChange Hive=`HKLM` `Subkey=Software\1E\NomadBranch\NomadBranch` Include Sub keys=1 TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=1
Ensure Nomad's share is accessible by specific accounts	Fix	Ensures that the correct accounts are able to access Nomad's share.	1E-GuaranteedState-Nomad-Check-ShareAccount No parameters 1E-GuaranteedState-Nomad-Fix-ShareAccount No parameters	TriggerTemplate-IntervalHours intervalHours=1	1E-GuaranteedState-Nomad-PreCondition-MultiTests hasCmClient=0 sccmDp=0 smbEnabled=1

Fragments

The following table shows the fragments included in the Nomad Client Health Integrated Product Pack:

Note

The Parameters column in the following table shows the ranges and default values for the parameters. The default values are used when you create custom rules using these fragments, unless you select alternative values.

Name	Type	Readable Payload and summary	Parameters
1E-GuaranteedState-Nomad-PreCondition-MultiTests	Precondition	Check if standard conditions apply for Nomad plus optionally: is a ConfigMgr DP (<sccmDp>); has a ConfigMgr client (<hasCmClient>); SMB sharing is enabled (<smbEnabled>) The precondition passes for all of the following standard tests: The device is running a version of Windows - Nomad is only supported on Windows operating systems The device is not running Windows XP - which is no longer supported by Nomad The `NomadBranch` service is installed, although not necessarily running. The precondition also tests for each of the following if it is enabled by changing its parameter from 0 to 1: hasCmClient : The ConfigMgr client is installed sccmDp : The device is a ConfigMgr Distribution Point (DP) smbEnabled : SMB sharing of Nomad's cache is enabled. If smbEnabled test is set in the rule precondition then an additonal test is made to see if the device is a Domain Controller (DC). When installed on a DC Nomad must use its computer account instead of SMSNomadP2P& in order to share its cache. This requires registry value `HKLM\SOFTWARE\1E\NomadBranch\SpecialNetShare` to have its 0x80 bit set. If not set then Nomad does not share its cache on a DC and does not respond to elections. For early adopters, the readable payload of this precondition was: Carries out the specified checks; if any fail (i.e. they are logically AND-ed) then the preconditions fails.	hasCmClient sccmDp smbEnabled Range 0 or 1, defaults=0
1E-GuaranteedState-Nomad-Check-AEConnectivity	Check	Check whether there is a working connection to ActiveEfficiency Tests whether the URL given by registry value `HKLM\SOFTWARE\1E\NomadBranch\ActiveEfficiency\PlatformUrl,` if it is not empty, is contactable and returns a 200 code.	None
1E-GuaranteedState-Nomad-Check-AlternateContentProvider	Check	Check whether Nomad is correctly registered within Microsoft ConfigMgr Check that the ConfigMgr client's list of ACPs includes an object for Nomad in WMI class `ROOT\ccm\Policy\Machine\RequestedConfig\CCM_DownloadProvider`, with `CLSID` "`25A6160D-4543-495F-975E-32CFBD6F70E0`", `LogicalName` "`NomadBranch`", `V4CompatibleHash` is set, and just "`<Data></Data>`" in `GlobalSettings`.	None
1E-GuaranteedState-Nomad-Fix-AlternateContentProvider	Fix	Ensures Nomad is correctly registered within Microsoft ConfigMgr If the same checks as 1E-GuaranteedState-Nomad-Check-AlternateContentProvider are not satisfied, restarts the `NomadBranch` service, waits 10 seconds for Nomad to establish itself as an ACP, then carries out the checks again.	None
1E-GuaranteedState-Nomad-Check-CacheInTemp	Check	Check whether Nomad's cache is not in a temporary directory The Nomad cache can sometimes be configured to be in the Windows `Temp` directory (usually `C:\Windows\Temp`) or one of its subdirectories. Since all the contents of the Windows `Temp` directory are considered to be transient and could be deleted at any time, this is not suitable for Nomad's cache which should be a permanent location. The check examines Nomad's `HKLM\SOFTWARE\1E\NomadBranch\LocalCachePath` registry value and verifies that the specified location actually exists. It then gets the `TEMP` environment variable, which, because both the `1E Client` and `NomadBranch` services run as `Local System`, is usually the WIndows `TEMP` directory. If the `LocalCachePath` value is the same as the `TEMP` environment variable, or `LocalCachePath` specifies a subdirectory within it, the check fails.	None
1E-GuaranteedState-Nomad-Check-CrashDumps	Check	Check whether there have been any crashdump files created by Nomad in last 7 days Nomad dump files are saved in the same directory as the log file, the parent directory of the `HKLM\SOFTWARE\1E\NomadBranch\LogFileName` registry value. The check looks in here for any files with a "`.dmp`" suffix (ignoring case), and if it finds any examines the modification time (not creation time!) of each, reporting as a failed check any that were modified in the last 7 days. So the check passes if there are no "`.dmp`" files or they are all older than 7 days.	None
1E-GuaranteedState-Nomad-Check-DiskAvailablility	Check	Checks whether there is sufficient disk space for Nomad This examines Nomad's `HKLM\SOFTWARE\1E\NomadBranch\PercentAvailableDisk` registry value. (It ignores the older MaxCacheSizeMB value which has been superseded by `PercentAvailableDisk`.) If the value is greater than or equal to 80, the check fails because the setting is too high. It then compares the size of the contents of the folder given by `HKLM\SOFTWARE\1E\NomadBranch\LocalCachePath` in the registry, i.e. Nomad's cache, with the free space of the drive on which the folder resides, as reported by WMI's `root\cimv\Win32_LogicalDisk`. The check fails if the percentage of free space on the drive is less than or equal too `PercentAvailableDisk`.	None
1E-GuaranteedState-Nomad-Check-DpLszEnabled	Check	Check whether web LSZ generation is correctly configured on standalone distribution points Nomad automatically sets up LSZ file generation on DPs that are ConfigMgr site servers, but extra configuration is required for standalone DPs. The device is a standalone DP if, under registry key `HKLM\SOFTWARE\Microsoft\SMS\Operations Management\SMS Server Role`, the subkey `SMS Distribution Point` exists but `SMS Site Server` does not. If the device is a standalone DP, registry value `HKLM\SOFTWARE\1E\\NomadBranch\SpecialNetShare` should have its 16384/0x4000 bit set to turn on web LSZ generation for HTTP/HTTPS enabled clients; if not, the check fails.	None
1E-GuaranteedState-Nomad-Check-DpLszVirtualDirectory	Check	Check whether the LSZ directory is correctly configured on distribution points At time of writing there is a bug such that the overall check status is usually "Passed" even when individually reported checks fail. If the device is a standalone DP, the check first verifes that registry value `HKLM\SOFTWARE\1E\\NomadBranch\SpecialNetShare` has its 16384/0x4000 bit set. (This bit is not required for a DP on a site server.) Then the `LSZFILES` web site is examined to verify that all these conditions are satisfied: Anonymous authentication is enabled Windows authentication is enabled No SSL Default document is enabled Directory browsing is enabled, with Date, Time, Size, Extension and LongDate all available Content indexing is disabled.	None
1E-GuaranteedState-Nomad-Fix-DpLszVirtualDirectory	Fix	Ensure that the LSZ directory is correctly configured on distribution points At time of writing there is a bug such that the overall check status is usually "Passed" even when individually reported checks fail. If any of the conditions described above for the corresponding check fragment is not true, the LSZFILES website is reconfigured to set that condition.	None
1E-GuaranteedState-Nomad-Check-FirewallExceptions	Check	Checks whether firewall exceptions exist for Nomad First is a check that at least one Windows firewall profile is enabled and that the firewall itself is enabled with either `HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile\EnableFirewall` set to 1 or `HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\StandardProfile\EnableFirewall` set to 1 in the registry. If no firewall and no firewall profile is enabled then no firewall exceptions are necessary and so there is nothing more to do. Otherwise,the Nomad-related firewall rules are examined. These are the rules named: `NomadBranch.exe` `NomadPackageLocatorTcp` `NomadPackageLocatorUdp` `PackageStatusRequestTcp` `PackageStatusRequestUdp` `NomadBranchPeerHttp` `NomadBranchPeerHttps` Using the `NomadBranch` service's path of `NomadBranch.exe`, the paths of `NomadPackageLocator.exe` and `PackageStatusRequest.exe` are deduced. Using the `HKLM\SOFTWARE\1E\NomadBranch\P2PEnabled` , `P2P_Port` , `P2PHttpPort` , and `P2PHttpsPort` settings in the registry, the fragment works out which Nomad features are enabled and hence which firewall rules are required. The firewall rule checks involve: Whether the rule even exists That the rule is enabled and not blocked The local port (which may be a specific one or all) Which protocol (TCP or UDP) is involved The path to the associated executable Rulesfor `NomadBranch.exe` , `NomadPackageLocatorTcp` , `NomadPackageLocatorUdp` , `PackageStatusRequestTcp` and `PackageStatusRequestUdp` must always be correctly defined. `NomadBranchPeerHttp` is only required if the 0x20 bit of `P2P_Enabled` is set, and likewise the 0x40 bit requires `NomadBranchPeerHttps`.	None
1E-GuaranteedState-Nomad-Fix-FirewallExceptions	Fix	Ensures the required firewall exceptions exist for Nomad This carries out all the checks as described above for 1E-GuaranteedState-Nomad-Check-FirewallExceptions then, for each absent or incorrectly configured rule that is required to support the `P2PEnabled` registry setting,configures that rule.	None
1E-GuaranteedState-Nomad-Check-HashingEnabled	Check	Check whether hashing is enabled in Nomad This examines the `HKLM\SOFTWARE\1E\NomadBranch\CompatibilityFlags` registry value. If the host is a ConfigMgr DP the 0x80000 bit should be set ("enable full hash generation for SIS content when an LsZ file is generated on a DP"), otherwise the 0x100000 bit ("abort download on the Nomad client if an LsZ hash mismatch is detected").	None
1E-GuaranteedState-Nomad-Check-Share	Check	Checks whether the Nomad share is available This first checks the firewall settings. If the firewall is enabled then "`File and Printer Sharing`" (i.e. SMB) cannot be disabled. Next the 0x10 bit of registry value `HKLM\SOFTWARE\1E\\NomadBranch\SpecialNetShare` is examined to see if the share name is the default "`NomadSHR`" or the hidden "`NomadSHR$`". The share's security descriptor is read and check made that the local "`SMSNomadP2P&`" account has read permission. The share's properties are then verified as follows: The shared directory is that named by registry value `HKLM\SOFTWARE\1E\NomadBranch\LocalCachePath`. The shared directory also matches the `Path` from WMI's `root\cimv2\Win32_Share` object for the share. The `Status` of the `root\cimv2\Win32_Share` object is "`OK`". These additional checks are not carried out if the host is a server or a custom share is involved: The maximum number of connections specified by the upper word of `SpecialNetShare` does not exceed the `MaximumAllowed` value of the WMI object. The `Data` value reported back by the check contains the results of the individual checks.	None
1E-GuaranteedState-Nomad-Fix-Share	Fix	Ensures the Nomad share is available This carries out the checks as in 1E-GuaranteedState-Nomad-Check-Share above, then if any of them fails it restarts the `NomadBranch` service which should recreate the share correctly.	None
1E-GuaranteedState-Nomad-Check-ShareAccount	Check	Checks whether the Nomad share account is correctly configured If the machine account is used rather than the default "`SMSNomadP2P&`", as specified by bit 0x80 in registry value `HKLM\SOFTWARE\1E\\NomadBranch\SpecialNetShare` , no checks are carried out. A WMI `root\cimv2\Win32_UserAccount` object for the local `SMSNomadP2P&` account must exist and the account cannot be disabled.	None
1E-GuaranteedState-Nomad-Fix-ShareAccount	Fix	Ensures the Nomad share account is correctly configured If the checks as described above for 1E-GuaranteedState-Nomad-Check-ShareAccount do not pass, the `NomadBranch` service is restarted to create a local `SMSNomadP2P&` account.	None
1E-GuaranteedState-Nomad-Check-SkpSwiDat	Check	Check whether skpswi.dat exists on disk A `skpswi.dat` file in a directory prevents ConfigMgr from falsely detecting that software is installed there during a Software Inventory scan, so Nomad requires one in its cache. Such a file must exist in the directory named by the `HKLM\SOFTWARE\1E\NomadBranch\LocalCachePath` registry value, and it must also be a hidden file.	None
1E-GuaranteedState-Nomad-Fix-SkpSwiDat	Fix	Ensure skpswi.dat exists on disk If the directory named by the `HKLM\SOFTWARE\1E\NomadBranch\LocalCachePath` registry value does not contain a "`skpswi.dat`" file, such a file is created and its hidden attribute set.	None
1E-GuaranteedState-Nomad-Check-StartService	Check	Checks that Nomad is running The `NomadBranch` service must be in "`Running`" or "`Starting`" state and be configured to start automatically.	None
1E-GuaranteedState-Nomad-Fix-StartService	Fix	Ensures that Nomad is running If the `NomadBranch` service is not in "`Running`" or "`Starting`" state and configured to start automatically, it is started and configured to be so.	None
1E-GuaranteedState-Nomad-Check-Variant	Check	Check whether the correct variant of Nomad (that supplied with the 1E Client, not standalone Nomad) is used for the service This verifies that the parent directory of the executable that the Service Control Manager uses to run the `NomadBranch` service is the `Extensibility` directory of the 1E Client, and hence not, for example, an older standalone version of Nomad.	None

Trigger templates

The following table shows the trigger templates included in the Nomad Client Health Integrated Product Pack.

Note

The Parameters column in the following table shows the ranges and default values for the parameters. The default values are used when you create custom rules using these templates, unless you select alternative values.

Name	Readable Payload and summary	Parameters
TriggerTemplate-FileChange	On change of file "<fileName>" When a file changes (Windows only)	File Name File path of file to be monitored, default is null.
TriggerTemplate-IntervalHours	Every <intervalHours> hours Periodic (hours)	Interval Hours 0 to 999 hours (approximately 42 days), default interval is 12 hours.
TriggerTemplate-IntervalMinutes	Every <intervalMinutes> minutes Periodic (minutes)	Interval Minutes 0 to 99,999 minutes (approximately 69 days), default interval is 30 minutes.
TriggerTemplate-IntervalSeconds	Every <intervalSeconds> seconds Periodic (seconds)	Interval Seconds 0 to 999,999 seconds (approximately 11 days), default interval is 3600 seconds (1 hour).
TriggerTemplate-ServiceStatusChange	On change of running state of the "<serviceName>" service When the state of the named Windows service changes Note You can determine the short name of a service using the PowerShell cmdlet `get-service -DisplayName "Network Location Awareness"` This will return NlaSvc in the above example. It is this short name you specify in the <ServiceName> parameter.	Service Name Short name of service - for example NomadBranch.
TriggerTemplate-WindowsRegistryChange	On change of registry values in "<hive>\<subkey>" (include subkeys=<includeSubkeys>) When the value of a Windows registry key changes.	Hive, which must be one of: HKLM (default) HKCR Subkey : free text string, default empty. Include Sub Keys : 1/0 default 0.

Name

Readable Payload and summary

Parameters

TriggerTemplate-FileChange

On change of file "<fileName>"

When a file changes (Windows only)

File Name

File path of file to be monitored, default is null.

TriggerTemplate-IntervalHours

Every <intervalHours> hours

Periodic (hours)

Interval Hours

0 to 999 hours (approximately 42 days), default interval is 12 hours.

TriggerTemplate-IntervalMinutes

Every <intervalMinutes> minutes

Periodic (minutes)

Interval Minutes

0 to 99,999 minutes (approximately 69 days), default interval is 30 minutes.

TriggerTemplate-IntervalSeconds

Every <intervalSeconds> seconds

Periodic (seconds)

Interval Seconds

0 to 999,999 seconds (approximately 11 days), default interval is 3600 seconds (1 hour).

TriggerTemplate-ServiceStatusChange

On change of running state of the "<serviceName>" service

When the state of the named Windows service changes

Note

You can determine the short name of a service using the PowerShell cmdlet

get-service -DisplayName "Network Location Awareness"

This will return NlaSvc in the above example. It is this short name you specify in the <ServiceName> parameter.

Service Name

Short name of service - for example NomadBranch.

TriggerTemplate-WindowsRegistryChange

On change of registry values in "<hive>\<subkey>" (include subkeys=<includeSubkeys>)

When the value of a Windows registry key changes.

Hive, which must be one of:

HKLM (default)
HKCR

Subkey : free text string, default empty.

Include Sub Keys : 1/0 default 0.