Contents
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. |
Using Nomad pre-caching
Viewing pre-cached jobs
If you are not a full administrator, you can only view pre-cached jobs provided you have Read permissions on the collection as well as the content.
To view pre-cached jobs:
Deleting pre-cached jobs
You can only delete pre-cached jobs if you have permissions for a particular content type. If you are not a full administrator, you will need:
- Read permissions on collections (through a security role)
- Access to the pre-cached job (i.e. content and the device collection)
To delete a pre-cached job:
- In Configuration Manager, choose Monitoring.
- Expand the Overview tree and choose Nomad Pre-cache jobs.
- In the Nomad Pre-caching jobs list, right-click the pre-cached you want and from the context menu, choose Delete.
Managing pre-cached jobs with Powershell cmdlets
You can also manage pre-cached jobs by using PowerShell cmdlets.
To get all pre-cached jobs from ActiveEfficiency, run:
Get-PreCachingJobs [-ActiveEfficiencyUrl <String>] [<CommonParameters>]
To remove pre-cached jobs from ActiveEfficiency run:
Remove-PreCachingJobs [-Id] <String> [-ActiveEfficiencyUrl <String>] [-Confirm [<SwitchParameter>]] [<CommonParameters>]
Remove-PreCachingJobs -Before <String> [-ActiveEfficiencyUrl <String>] [-Confirm [<SwitchParameter>]] [<CommonParameters>]
Remove-PreCachingJobs -AgeInDays <UInt32> [-ActiveEfficiencyUrl <String>] [-Confirm [<SwitchParameter>]] [<CommonParameters>]
Remove-PreCachingJobs -All [<SwitchParameter>] [-ActiveEfficiencyUrl <String>] [-Confirm [<SwitchParameter>]] [<CommonParameters>]
The parameters are:
Parameter | Optionality | Notes |
---|---|---|
-Id | Mandatory | ID for the job to delete. |
-ActiveEfficiencyURL <string> | Optional | Location of ActiveEfficiency. If not provided, it is retrieved from the NomadAdminUI registry value. |
-Confirm | Optional | Suppresses the confirmation prompt for the deletion. |
-Before | Mandatory | Delete jobs before a particular date and time where the notation is yyyyMMddHHmmss . |
-AgeInDays | Mandatory | Delete jobs older than a particular number of days. |
-All | Mandatory | Delete all jobs. Exercise caution if you use this. |
<CommonParameters> | Values are: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer, PipelineVariable and OutVariable |
There is more information about CommonParameters
at http://go.microsoft.com/fwlink/?LinkID=113216
Dynamic pre-caching
If the content or membership of a targeted collection changes after a pre-cached job is created, ActiveEfficiency is updated to keep in sync with Configuration Manager. It does this by polling the Configuration Manager database at regular intervals to fetch updated content.
These intervals (you would have defined the intervals when you installed ActiveEfficiency) have the following characteristics:
- The range for the interval is between 5 minutes and 1440 minutes (1 day). By default, ActiveEfficiency synchronizes with the Configuration Database every 30 minutes. If the values are outside the range, for example if the interval is less than 5, it will default to the minimum which is 5 minutes. Similarly, if the interval is greater than 1440, it defaults to the maximum which is 1440 minutes.
- If a synchronization fails, it is rescheduled to run again in 15 minutes
Each synchronization task fetches the following:
- Pre-caching data (device collections and contents).
- Dashboard data (status messages).
Pre-cached jobs are affected when these events take place in Configuration Manager, and on the next synchronization with ActiveEfficiency:
Configuration Manager events | Next ActiveEfficiency synchronization cycle | |
---|---|---|
Device collections |
|
|
Packages |
|
|
Applications |
|
|
Task sequences | If you chose to automatically pre-cache references (as well as those added later) | ActiveEfficiency is updated:
Applications and packages that will be installed using a dynamic variable list will not be automatically pre-cached. Also be aware that any other dynamic content will not be pre-cached, for example drivers deployed using Modern Driver Management (http://www.scconfigmgr.com/modern-driver-management/). Dynamic content needs to be pre-cached independently as separate jobs. |
If you chose to selectively pre-cache references: |
|
Manually forcing a synchronization from ActiveEfficiency
You can force a synchronization to occur outside its normal cycle. To do this:
- Navigate to your ActiveEfficiency installation directory.
- Start a command-line prompt.
- If you want to refresh all data, run
ServiceHost.exe -NomadSyncAll
. - If you only want to refresh existing data, run
ServiceHost.exe -NomadSync
- Check
C:\ProgramData\1E\ActiveEfficiency\service.log
for details. All synchronisation activities are logged in ActiveEfficiency's service logC:\ProgramData\1E\ActiveEfficiency\service.log
by default.
Disabling synchronization
There may be instances, such as carrying out maintenance on the Configuration Manager server or the SQL Server instance, where you have to disable synchronization. To do this:
- Open
ServiceHost.exe.config
located in the service installation folder, typical inC:\Pogram Files (x86)\1E\ActiveEfficiency\Service
by default. Set
EnableNomadSync
to false under the AppSettings element. For example:<appSettings> ... <add key="EnableNomadSync " value="false"/> ...... </appSettings>
Hash validation
Hash validation is used when content is downloaded for pre-cached jobs and for LSZgen requests for these jobs. When a pre-cached job is created:
- For task sequences, hashes for all referenced packages and applications are posted to ActiveEfficiency
- For applications, hashes for all its child deployment types are posted to ActiveEfficiency
On the client side:
- Where a job is queued, the client queries the management point for content locations. The management point returns a hash for application content types only. If it does not return a hash, the client retrieves it from ActiveEfficiency. Hashes from management points take priority over Active Efficiency.
- For the ActiveEfficiency server, the client fetches the hash during the pre-cache cycle for that particular content
Nomad clients polling ActiveEfficiency
After running the wizard, Nomad clients that are registered with ActiveEfficiency and that were included in the selected device collection will get a pre-cache notification within 24 hours. This notification tells Nomad that it has to process a download job on the content to be cached. The default number of notifications a client processes in one pre-cache poll cycle is 20 but you can modify this by updating the PrecachePollBatchSize registry value.
When is polling disabled?
Nomad clients normally start their polling cycle when the service starts, with a random delay to minimize the possibility of multiple simultaneous polls from different clients. However, polling will not start if any of the following is true:
- The ActiveEfficiency URL is not set in the Nomad registry.
- Nomad is running on a machine using the Win PE operating system.
- The Configuration Manager client is not installed on the machine – in order to download pre-cached content, the Nomad service needs to contact the management point and this is only possible if the client is installed locally.
To explicitly turn polling off for a Nomad client set the PrecachePollMinutes registry value to 0.
Nomad pre-caching RBAC support
Nomad pre-caching is tightly integrated into Configuration Manager and honors the permissions and restrictions enforced by role-based access control (RBAC). The following rules are used to determine whether a particular user is allowed to pre-cache a particular content on a particular collection or not:
- A user is only allowed to pre-cache a content item if they have the RBAC permissions to deploy it via Configuration Manager.
- A user is only allowed to pre-cache to a device collection if they have the RBAC permissions to access that collection.
If an administrator does not have the necessary RBAC permissions, they will not be able to see or access any of the Nomad pre-cache features in the Configuration Manager Admin console. Similarly, if they do not have the right permissions to a device collection, that collection will not be available to them in the Targeting screen of the pre-cache wizard.
However, full administrators will see:
The following table provides an overview of the availability of Nomad pre-caching for the built-in Configuration Manager security roles:
Nomad pre-caching support based on the Configuration Manager security role | ||||||
Built-in Configuration Manager Security Roles | SOFTWARE LIBRARY | |||||
APPLICATION MANAGEMENT | Operating System | |||||
Applications | Packages | Driver Packages | Operating System Images | Boot Images | Task Sequences | |
Nomad pre-caching Wizard | ||||||
Application Administrator | Pre-caching available (Access to Collection required) | Not available | ||||
Application Author | Pre-caching Not available (Access to Application Management only) | Not available | ||||
Application Deployment Manager | Pre-caching available (Access to Collection required) | Not available | ||||
Asset Manager | No access to Software Library | |||||
Company Resource Access Manager | ||||||
Compliance Settings Manager | Pre-caching Not Applicable for Software Updates (No Access to Application Management & Operating System, Only Software Updates under Software Library available) | |||||
Endpoint Protection Manager | No Access to Software Library | |||||
Full Administrator | Pre-caching available (Access to Collection required) | |||||
Infrastructure Administrator | Pre-caching not available (Access only to Windows Sideloading Keys in Application Management under Software Library) | |||||
Operating System Deployment Manager | Pre-caching not available | Pre-caching available If Package/Application is part of a task sequence, pre-caching does not happen | ||||
Operations Administrator | Pre-caching available (Access to Collection required) | |||||
Read-only Analyst | Pre-caching not available (SCCM Console is in Read-Only mode) | |||||
Remote Tools Operator | No access to Software Library | |||||
Security Administrator | ||||||
Software Update Manager | Pre-caching not applicable for Software Updates (No access to Application Management & Operating System, Only Software Updates under Software Library available) |
Limitations
The following limitations are part of the current implementation of the Nomad pre-caching feature:
- The Pre-caching (monitoring) screen will only display the job ID and its creation date if you are not running ActiveEfficiency 1.9.100.xx or later.
- The creation date for pre-cached jobs may be incorrect if they were created using older versions of ActiveEfficiency.
- Pre-cached jobs created with older versions of ActiveEfficiency are only visible to full administrators.
- Software Updates are not supported by Nomad Pre-caching. Instead, make use of the available and mandatory advertisement dates.
- Disabling Nomad Content Registration with ActiveEfficiency prevents Nomad clients from fetching further pre-caching notifications after the first batch of 20.
- The Nomad Pre-caching Wizard allows packages that do not have content to be selected for pre-caching.
- Delays may be seen when processing Pre-caching notifications for devices with many notifications. By default, Nomad clients will poll ActiveEfficiency once a day. Each time a client polls it will fetch a batch of 20 notifications to process, so for a client with 100 outstanding pre-caching notifications, it will take 5 days for all the notifications to be processed. The time between polls depends on the PrecachePollMinutes setting which can be reduced if there are a large number of pre-caching jobs, though the 24-hour default is recommended.
- Pre-caching jobs do not support Nomad additional settings (such as those configurable in the Nomad tab in the Package or Task Sequence properties).
- Nomad won't re-download a pre-caching job with updated data format (that is compressed/encrypted), if the content has previously downloaded to the cache. The conversion will happen when ACP triggers the same content.
- ActiveEfficiency synchronization may cause issues if there is any replication issues between the central administration site and primary site.
- Workgroup member clients may not be able to use the Nomad Pre-Caching feature, as it requires ActiveEfficiency registration using their FQDN.
Limitations addressed in Nomad 6.3
- The Nomad Pre-caching feature is now able to work when Windows Authentication has been configured for ActiveEfficiency.
Using network access accounts
Prior to this release, when a download is initiated, Nomad only used the credentials from the first Configuration Manager network access account it found to authenticate, and if that failed, the download stopped. From this release, Nomad cycles through all native Configuration Manager network access accounts to authenticate, thereby reducing the risk of failure.
Nomad won't use network access accounts for SMB downloads from Distribution share. It uses the SYSTEM$ account to connect to the package share location.