StifleR consists of two main parts. The StifleR server component and the StifleR clients.
Each StifleR client makes a lightweight connection to the StifleR server and sends up information about the current content download queue. This information is evaluated and the server (dynamically) assigns the most suitable system per Location to be the “Red Leader”. The Red Leader system is then responsible for downloading content and obeying the defined network bandwidth limits for that Location. Other clients at that same Location, that would otherwise also download the content from the remote source, will not download from the remote location but instead will throttle down, wait, and then copy the data locally from the Red Leader and other Peers using Microsoft P2P transfer functions. The end result is that rather than all clients downloading remote content, WAN traffic is limited to between the single Red Leader and the remote content server. Should the current Red Leader system become unavailable, a new Red Leader is automatically selected, which results in uninterrupted, efficient and dynamic workflow.
This functionality also extends to Windows 10 Delivery Optimization groups and respects the Bandwidth administrative settings present under any DO control policy that may be in place.
In StifleR Enterprise, this concept is further enhanced and expanded to the Site level with the introduction of Blue Leaders. Blue Leaders communicate with each other over Subnet boundaries. They pick up local broadcast discovery requests and pass these on to other Blue Leaders which can then broadcast these messages onto their local segment thus allowing the sharing of content with and between all the clients at a multi subnet location. The end result of this infrastructure is that content is downloaded only once over the WAN for an entire remote site with that content then shared directly between Peers on the well connected LAN.
The StifleR Beacon Server component is installed at your file server locations. These then act as known end points to allow the StifleR clients to benchmark bandwidth parameters and set and tune limits accordingly.
StifleR is a typical Client – Server application that uses bi-directional communication channels. The Server hosts an OWIN (Open Web Interface for .NET) implementation of Microsoft SignalR. All communication is based on the Microsoft the Microsoft SignalR protocol, a web-sockets based protocol that runs over UDP, initiated first through an HTTP connection which then steps things up to web sockets. StifleR server also uses SignalR to communicate with the endpoint clients and any connected dashboards. Understanding how SignalR works is not mandatory to use StifleR but is required if custom scripting or advanced configuration of StifleR is to be undertaken. Please refer to the 2PintSoftware Website for advanced information on the Microsoft SignalR platform including “SignalR and Connection Management” on the Knowledge Base and the companion document to this guide “Securing StifleR Operations Using SSL” which includes SignalR configuration.
The StifleR client checks through its queue of active downloads (both BITS and DO) and then prioritizes them according to a locally held XML configuration file (StifleRulez.xml) which contains a set of rules that are configured centrally by the administrator and automatically downloaded by the clients.
This file contains a simple rule set that defines the content download jobs and the priority that the administrator has assigned to each job type.
As an example, Microsoft Maps sync could be set to a low priority, while Windows Update patches would be set to high. Using this rule set, you can effectively control which downloads should be completed ahead of others. All of these configuration settings can be changed centrally at any time with any such changes automatically replicated to your clients in seconds.
In order to secure the SignalR communication channels in StifleR we recommend that you use SSL. A full explanation of this can be found in the companion document “Securing StifleR Operations Using SSL”
StifleR uses a delegated security model in both WMI and the Web portal. There are several basic security levels:
Global Administrators (Mandatory)
Access to all locations and WMI regardless of location rights
Only Global Administrators have rights and visibility over roaming clients
Delegated Access
Granted by a Global Administrator on the individual Subnet level. Rights to WMI methods only on the allowed subnet or clients in that subnet
Global Read
Gives read only rights to ALL locations and statistics. Including WMI
Dashboard Access
Access to Dashboard and overview statistics only
Anonymous Read
Allows anonymous access. Should be disabled in all but a test environment
StifleR is able to detect that you have a mixture of BranchCache V2 and V1 computers in your environment and automatically assign the V2 machines to become Red Leaders. V2 computers are able to generate hashed data for both V1 and V2 clients. Unlike V1 machines however, V2 machines are able to utilize deduplication on the download side which greatly speeds up the overall transfer time for the V1 clients. For more information on BranchCache version interoperation please visit the 2Pint website.
At Locations with multiple VLANs or Subnets StifleR Blue Leaders are assigned. These clients are able to act as BranchCache communication proxies and allow P2P traffic to cross network boundaries. In larger locations with limited WAN connectivity back to the data centre this feature is invaluable in order to limit WAN usage as far as possible.
Using the command line execution feature you can easily run commands across many systems at one time.
Same as the Command Line execution, but with PowerShell scripts on Clients instead. Each script is distributed to the client and executed.
StifleR not only monitors BITS downloads, it can create them too. Here’s a couple of suggestions for usage of this feature:–
Download the ‘top 10’ most accessed files from your corporate intranet into the BranchCache cache overnight
Seed (pre stage) certain key systems in remote Locations with Software Updates that can then be shared via BranchCache
StifleR has Wake-on-LAN technology built in which may be used to power on systems in a Location that hold cached content that are needed by Peer clients. This saves bandwidth and time as the transfer becomes P2P instead of WAN based.
StifleR accelerates content transfers by utilizing the various Microsoft P2P services, enabling caching, Deduplication and Peer-to-Peer distribution of content on local networks. By utilizing and improving the Microsoft P2P functionality, StifleR has a profound effect on where users actually source their content, the network bandwidth consumed in retrieving that content and the speed with which the content is delivered to consumers.
StifleR gives you control over content transfers to Windows client computers by enabling granular configuration of the Background Intelligent Transfer (BITS) and/or Delivery Optimization (DO). Services not natively available.
As the Red Leaders are continuously communicating download details back to the StifleR Server, the Server is aware of how many active subnets transferring data there are at any moment in time. At a remote location the allowed Bandwidth between the Location and the Datacentre is dynamically apportioned between the number of active Red Leaders (Subnets) at that Location allowing maximum bandwidth to be assigned to each at all times.
NOTE: We strongly advise to view the Dashboards only on administrative workstations rather than directly on a Server. Servers are generally not built with graphical applications in mind.
Using StifleR you have complete visibility over WAN and LAN transfers globally through the Dashboards. The Dashboards update several times per second thus giving an up to the second view of content transfers. The SignalR architecture also allows you to have as many dashboards open as you like without putting a strain on the server infrastructure.
The dashboards allow real time monitoring of all content transfers within the enterprise, all from a single view. From the main dashboard you can then drill down from a multi subnet Site through individual subnets right down to single client data.
StifleR tracks all content being downloaded on the clients and reports this data back to the StifleR server. All this data is then made available for reporting on the StifleR server directly in WMI or graphically through the Dashboards interface. StifleR will give you a view of all active and queued downloads at a given Location. A BITS client only supports a single active download at a time and therefore it is on this that StifleR reports and sends data.
Server settings can be configured through the ‘Server Settings’ dashboard
Subnet level settings can be set via the Subnet dashboard, including TargetBandwidth/Well Connected/Address etc.
Further to the Subnet settings above, you can also set Delivery Optimization parameters such as GroupID and Download mode, LEDBAT Target Bandwidth and Well Connected Bandwidth limits
Within the BITS and DO job dashboards, StifleR gives you the ability to Stop, Start, Pause or change the priority of individual job downloads with a simple click of the mouse. These controls are instant and can be used to control traffic at all levels of the infrastructure.
Global Administrators have the ability to grant granular administrative control to Delegated Administrators over StifleR resources all through the Dashboard interface. A Deputy Administrator can be granted the ability to monitor and set controls for particular subnets only. They are granted security access to the WMI methods and controls for the subnet.
While the Dashboard interface can be used for small scale manual configuration and control, for serious, Enterprise wide automated administration StifleR can be configured via Microsoft PowerShell or WMIC scripting which interacts with the StifleR Windows Management Instrumentation (WMI) Namespace. There are limitless possibilities in this regard. For some examples and inspiration to get you started head over to the 2Pint Software KB site "StifleR - WMI, Scripts And Commands".
We also recommend that you read through the StifleRServerScriptingGuidance.ps1 script in the StifleR Server Installation folder which contains numerous handy code snippets to help with various administrative tasks.
StifleR is designed to enable configuration and control over the static priority of different content types and allows you to change the priority of a job immediately using WMI. You can change the job priority in several different ways, depending on what you want to achieve:
Pause a running higher priority job in order to allow the next job in line to start. The original job can then be resumed once the other has completed.
Make changes centrally to the StifleR download job definition file (stiflerulez.xml) and push this to clients instantly via StifleR. e.g. change one type of BITS job to a higher priority to get certain content distributed ahead of existing traffic.
Changes to the bandwidth and priorities directly using WMI (or through the Dashboard) replicates settings within seconds, regardless of how many Locations you have targeted.
Intelligent Bandwidth Sharing between active Devices
StifleR also allows for multilane transfers, i.e. multiple transfers at the same time. Using a combination of the locally cached BranchCache content and Data Deduplication, transfers can be allowed that put none, or very little, traffic on the WAN as most of the content is actually present already and it is only the balance of content that needs transferring. Here’s a scenario to help your understanding of how this works in the real world: -
A client at a remote location starts to download content. At the same time another peer at that same remote Location needs to download & install an updated version of the same content. Because of Windows Deduplication, a large percentage of the content is not required to be transferred over the WAN. Instead of waiting for the complete local data to become available the StifleR client on the second Peer will allow the download to go ahead, at the same priority as the existing download but at reduced bandwidth. This allows the peer to slowly download the content, which, due to De-Dupe, may be enough to get the installation started faster as most of the content will be sourced from the local caches and only a trivial amount coming over the WAN.
StifleR empowers you to re-prioritize content delivery quickly and non-destructively (without killing jobs). When you change content priorities, any paused content automatically resumes after the new higher priority content transfer completes, without retransmitting data already downloaded. You can specify job priority and also allow jobs to run side by side while using appropriate bandwidth in proportion to the job needs. StifleR also has the ability to monitor and adjust bandwidth usage up or down according to set limits. StifleR makes it easy to view, configure and manage all content priority changes and to monitor content transfer in real time.
An important function utilized by StifleR, which should already be healthy in your Software Distribution solution, is automatic pause and resume. This is the control that sets the ability to move something to the top of the queue, causing the currently active item to pause immediately. Later, when the urgent content finishes downloading, BITS will resume the interrupted download exactly where it left off without missing a byte and without re-transmitting data already downloaded. The healthy state of this function in the enterprise should be considered a pre-requisite for StifleR operation.
In some exceptional circumstances you may need to completely stop traffic from transmitting over the WAN.
Stopping every BITS job in the entire Enterprise is as easy as a click in the Dashboard or a single WMI command line:
StifleR uses the default BITS API commands so an administrator can just as easily Suspend, Resume, Cancel or Complete jobs.
By changing the argument list around a little, you can do some powerful stuff. If we change the “ALL” to an IP Network ID we can target resources in a more granular manner:
If true pause/resume is important to your organization, then it’s important to understand why this is unique. You can instantly pause content transfer non-destructively (without killing jobs) anywhere in your enterprise, and later resume exactly where it left off. There is no limit to the scope:
For delivery of a single piece of content
For all content delivery to a single Location or subnet
For all content delivery globally
By using PowerShell or any other WMI aware scripting language you can easily pipe objects to each other. For example, you can select a Location where bandwidth usage is too high and then suspend all jobs temporarily as required. Once again, refer to the scripting guide for examples and ideas in this regard.
