Single Site Download

The local SSD feature was introduced to supplement site SSD for clients on networks such as wireless where broadcasts are disabled, to prevent each client becoming its own master and downloading direct from the DP. In a SSD enabled environment, a master queries Content Distribution to get a list of devices on other subnets within the site that have content. With local SSD enabled, the master also queries for devices having content within local subnet. If any local peers with content are available, then the master downloads from them, otherwise it attempts to download from Site peers (other subnets in the site), and if the master still cannot find any peers, it downloads the content direct from the DP.

In version 7.0 and later, a master skips using local SSD if it sees broadcast messages from peers. This means clients in mixed network environments can be configured with the same SSDEnabled setting (with Local SSD enabled) and clients can move seamlessly between networks. When on a wireless network (where broadcasts are typically disabled) local SSD can be used. On LAN networks (where broadcasts are typically allowed) local SSD would be skipped because a master is elected and sees broadcast activity from peers.

For details, refer to Nomad SSD architecture and ports

• The information about sites and their associated subnets are stored and maintained in Content Distribution. When a client downloads a package, it registers this information with Content Distribution, enabling it to build a profile of which client holds particular packages and on which subnet.

  

• When a client on a subnet requires a particular package, it first tries to find a copy on the local subnet using the standard method for retrieving cached The Content Registration Sync Cycle is available in Content Distribution 7.0 or later (1E Client 4.1 or later) which registers pending and failed content registrations with Content Distribution files.

  

• If no local copy of the package is found it then tries Content Distribution database to see if any clients on other subnets at the same site hold a copy.

  

• Only when all other avenues have failed will Content Distribution resort to downloading the package from the DP over the WAN.

  

• When the master has a portion of the package it, registers itself with Content Distribution to say that it can provide this package to other subnets if required.

  

Fetching content

When Content Distribution receives a request to download content, an election takes place for a master. The master queries Content Distribution about neighboring subnets (accessible on LAN rather than WAN) so that it can download content from a peer in an adjacent subnet (within the same location) if that content is not available on a peer in its own local subnet. For each subnet, the top 10 clients (in terms of percentage cached by the client) are listed – the subnet containing the master is excluded from the list if no peer has the content. During this process, the percentage specified by the requesting client is ignored. Although neighboring clients may have a lower percentage than the requesting client, they may in fact have gained more since they last communicated with Content Distribution, so they are potentially useful sources for the package, hence the top 10 rule.

The master (now a subnet master) iterates through the list (which is sorted by percentage) and sends a package status request to each client. If it receives a response, the master attempts an SMB peer-to-peer download from that client (the current site master). If the attempt fails (it is not contactable or the limit on the number of concurrent connections is exceeded), it tries the next one in the list. If it fails to get the package from any of them, it downloads from the DP. If the list is empty, the master downloads from the DP. Clients with a lower percentage of the package than the client requesting it will not respond.

If a download is interrupted part way through (i.e. the source becomes unavailable), Content Distribution iterates through the remainder of the list and if it fails to get the package from any of them, it downloads from the DP.

When a download starts, Content Distribution registers the progress with Content Distribution (0% of the content has been downloaded) and when it finishes, the final percentage is also recorded. As long as the content downloaded is greater than 0%, the host becomes a candidate for another client until the package is deleted from its cache. Records with status of 0% downloaded are purged from Content Distribution.

Before enabling clients to use SSD, you need to ensure the following:

• 1E Platform is installed and running successfully.

• The Content Distribution database is populated with information about sites and their associated subnets.

High-level overview of how to enable SSD

The following information applies to both new and existing installations of Content Distribution:

• Make sure that 1E Platform is installed in your environment and is used as a content location metadata repository.

• Within Content Distribution, populate the SSD sites and subnet information. A sample PowerShell script called PostADSitesandSubnets.ps1 is included in the Content Distribution installation files, which reads sites and subnets from AD.

• Content Distribution captures a list of background channels from the 1E Client in the BackgroundChannelUrl and uses the first working URL as the PlatformURL by appending /Proxy/ContentDistribution/ if this PlatformURL is unreachable it attempts to connect to the next BackgroundChannelUrl.

• Enable SSD on all Content Distribution agents, by modifying HKLM\Software\1E\NomadBranch\SSDEnabled to 3, this enables SSD for both "Provide" and "Consume" modes, specifically Content Distribution will provide content to other peers and consume content from other peers.

• If you already have Content Distribution installed and are only now enabling SSD, then ensure HKLM\Software\1E\NomadBranch\Platform\ContentRegistration is set to 1, in other words Content Distribution will register downloaded content, this is automatically enabled for new installations, and SSD.

IPv6 Protocol-Aware Filtering

For Content Distribution and PXE Everywhere:

To minimize WAN bandwidth usage, the client requests a list of peer devices from Content Distribution that already possess the required content or version. This list may include devices with either IPv4 or IPv6 addresses. However, the requesting (source) device might not be able to communicate with some of the returned devices due to protocol stack incompatibilities (e.g. IPv4-only device trying to reach an IPv6-only device).

To address this, two configuration flags are used:

• IPv4IPv6CommunicationSupported: At the subnet level.

• IPv4IPv6CommunicationEnabledForAllSubnets: At the global level.

These flags determine whether devices that support both IPv4 and IPv6 communication should be included in the returned list. By filtering based on protocol compatibility, the system reduces failed connection attempts and improves overall performance.

Building a subnet profile in Content Distribution

To build a subnet profile for SSD and the peer backup assistant feature, Content Distribution must communicate with its web service. When theContent Distribution service starts, it connects and registers the hosting device by name with Content Distribution, which returns a device ID in the form of a GUID that enables it to uniquely identify the client and its default subnet. If it is unable to communicate with Content Distribution, it retries every 5 minutes until it succeeds (as long as SSD is enabled). An attempt to communicate with Content Distribution is also made prior to a package download to register its status. Refer to Enabling SSD in WinPE

Note the following:

• On a multi-NIC host, only one NIC gets registered, and a wired interface takes precedence over a wireless interface during registration.

• If Content Distribution fails initially to register an adapter, it retries every 5 minutes (for as long as SSD is enabled) until it succeeds.

• Wireless adapters can be configured to act as SSD content providers and consumers. Use the ContentProviderOnWifi registry setting to do this.

• If the initial device registration was successful when the Content Distribution service started, but Content Distribution later becomes unavailable, when Content Distribution subsequently downloads and caches a package it will not be able to register the package (see below for details). Content Distribution does not re-attempt package registration, so it will not know that this particular Content Distribution host has the package.

Example PowerShell scripts

You can get information about sites and subnets from AD, or by other means. Example PowerShell scripts can be used for retrieving information about sites and their associated subnets from the AD and updating the Content Distribution database. Refer to Content Distribution Tools for details.

Viewing Nomad sites and subnets in the Nomad app

The sites and subnets stored in Content Distribution are visible in the Nomad Sites page of the Content Distribution app.

• The Nomad Sites page is primarily designed to show how the network is being used for content distribution in different locations. It focuses on the volume of content downloaded from peers vs over the WAN, rather than the status of specific content titles in a given site. You can see what content is available in a given site by looking at the Content tab for that site.

• A Nomad Site corresponds to Nomad Single Site Download (SSD) site. Customers that have implemented SSD and upgrade ActiveEfficiency to the Content Distribution app will see their defined SSD locations displayed as Nomad Sites.

• Any subnets that are not included in a Nomad SSD Site definition will be represented in a site named Unknown. If no SSD sites have been defined, all subnets will be included in the Unknown site.

Uninstallation, reinstallation and reactivation

When you uninstall a client, all its registry values are deleted. However, if you subsequently reinstall it, the device ID returned when Content Distribution next registers is one that is recycled from the database – this is because that is the device registered for the named computer, so it recognizes that the same computer is involved and restores the previous values to the registry.

If a cached package is reactivated, such as after an OSD upgrade or cloning, Content Distribution will register the package. (If this is a re-registration, the Content Distribution record is effectively unchanged).

Improved resilience of content registration

Registrations can fail when Content Distribution or the SQL Server hosting the ContentDistribution database is busy, overloaded or down for maintenance, resulting in content registration mismatch between the clients and Content Distribution.

The following registry setting is used by the Content Registration Sync Cycle feature.

Registry value	Type	Default	Notes	Installer property
CacheStateSyncIntervalMinutes	REG_DWORD	1440 (1day)	Range: from 60 to 525600 (1Year).	MODULE.NOMAD.CACHESTATESYNCINTERVALMINUTES

To enable SSD in WinPE:

1. Edit the task sequence for which you want to use SSD.

2. Enable Single Site Download.

3. In 1E Platform base URL: enter for example, https://<server_FQDN:port/ or http://<server_FQDN:port/ depending on the protocol you are using, where <server_FQDN> is the FQDN of the 1E server or its DNS alias.

4. Click OK.