Content Distribution FanOut

Windows imposes a limit on the number of concurrent connections on the Content Distribution share. FanOut compensates for this limitation by enabling any peer that has more content than the requester to respond to the FanOut request. It is not limited to peers that have an active connection to the master.

The product formerly referred to as Nomad has been rebranded as Content Distribution. Although the new name is implemented in the majority of documentation and user interfaces, references to Nomad may still appear in specific tools, scripts, or contexts.

How FanOut works

To use FanOut, the Content Distribution SpecialNetShare registry value must be updated to include bit 6 (0x40 or 64 decimal) on all devices hosting Content Distribution.

By default, the Content Distribution cache share NomadSHR is limited to six concurrent connections by Windows. This means that up to six Content Distribution peers (devices that request the download) can obtain content from the master at any given time (the device that wins the election on the subnet and becomes the central source for the download). Under normal circumstances, if a Content Distribution client tries to connect to the master and all six connections are in use, the Content Distribution client retries later.

The FanOut feature compensates for this limitation by enabling the Content Distribution client to ask for an alternative peer on the same subnet that has the content it needs, any other peer on the subnet can respond to this request but will only do so if it meets certain criteria, it must:

  • Have more content than the Content Distribution client requesting it.

  • Have available connections on its own NomanSHR.

  • Not already be connected to a FanOut peer (a device connected to the master share that responds to FanOut requests and allows other devices to connect to it).

Refer to Using FanOut for large subnets for an example scenario about deploying software in a large network and how you can monitor those deployments using the Content Distribution app.The following illustrations demonstrate how FanOut works.

If a Content Distribution peer gets a Maximum connections limit when trying to connect to a master, it broadcasts a request for who has more than a certain percentage of a package with a certain ID.

A device responds to a FanOut request if the following conditions apply:

  • If it is currently active and downloading, or it is idle and has downloaded part or all of the package from the master.

  • It has a larger percentage of the package than the device broadcasting the request.

  • If the broadcast request has not been received over a wireless link.

  • Its version of the package is greater than or equal to the package version held by the device broadcasting the request.

  • It has free connections to its Content Distribution share.

  • Its election weighting is greater than zero – i.e. it is not set as a sensitive server. Refer to Election weighting.

  • It is not a domain controller.

  • It is not part of any inhibited subnets and sites. Refer to Inhibiting subnets and sites.

  • Its NomadSHR exists and P2PEnabled is turned on, it is not set to 0.

The Content Distribution peer will attempt to connect to the first FanOut peer that responds to its request. In this way, rather than limiting the distribution to six Content Distribution peers, many more devices can be accessing the download from the master, exponentially speeding up content deployment on large subnets.

Checking to see if FanOut is working

To observe FanOut on Content Distribution client when the connection to NomadSHR is reached on the elected master:

  1. Open NomadBranch.log on a Nomad client. This client must not be the master.

  2. Notice that the client has failed to connect to the master.

  3. It then polls for a FanOut peer.

  4. It receives a response and starts the download.

Limitations

FanOut cannot currently be used with the following features:

  • Content Distribution is installed in WinPE is not capable of becoming a FanOut peer (i.e. a provider of package content) because file sharing is not supported. However, Content Distribution is capable of requesting content from and connecting to FanOut peers on the local subnet.

  • FanOut is not compatible with Content Distribution multicast, if multicast is enabled for a particular package, FanOut is not used, regardless of the value in SpecialNetShare.

  • FanOut will not be used when Content Distribution is run in standalone mode.

  • FanOut is disabled for computers using wireless connectivity.