The easiest way is to install the server manually using the MSI. The server supports silent installation if needed, but typically you only need to run the installation on a single occasion so automation is not usually required.

Pre-Requisites

• • Requires .Net 4.7.2 to be installed on the server.

  • If you want to use the same server to host the dashboards - install IIS as well.

  • If you wish to use a Custom App Pool in IIS – create that beforehand

  • Installation account must have Administrator rights (or run the MSI Installer elevated)

  • Ensure you have the License.cab available for the installer to access.

  • Firewall – open ports 1414 (Client comms) and 9000 (Dashboard comms) Inbound for TCP

    traffic

Configure the StifleR Rules XML

The StifleR client will check through its queue of active downloads (both BITS and DO) and will prioritize them according to a locally held XML configuration file containing a set of rules that are configured centrally by the administrator and automatically distributed to 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. See the StifleR Rules XML Guide for more details on how to create and configure the rules file. The latest version of the StifleRulez.xml file can always be found through the default client download link:

http://2pintsoftware.com/download/stiflerrulez/

The clients will download the rules definition XML at a configurable interval from the configured URL. In order to use a custom file this URL must be created, and for the purposes of testing we will assume that it is on the same server as StifleR itself.

File location

Place the stiflerulez.xml in the following folder on the StifleR server:

C:\ProgramData\2Pint Software\StifleR\Rules

Create a Virtual folder in IIS

From an elevated PowerShell prompt, execute the following command:

New-WebVirtualDirectory -Site "Default Web Site" -Name StiflerRules -PhysicalPath "C:\ProgramData\2Pint Software\StifleR\Rules"

This command will create a virtual folder which you will then use during the StifleR client install to configure the clients to automatically update their rules definition. The URL will be:

​http://yourserverfqdn/StiflerRules/stiflerulez.xml​

Note: If you do not configure your own internal rules definition URL, the clients will use the default client download link (above) and use the one located on the 2Pint website.

We are now ready to install the StifleR server component.

Installation

From an Elevated Command prompt launch StifleR.Installer64.msi

Start the installation by executing the correct installer (x64 for x64 systems). The Welcome dialog will appear

Click the Next button and the End User License Agreement page appears. After you have read through the EULA check the box to indicate that you agree to the terms and conditions.

Next is the Licensing dialogue. Enter the Path or click on the “…” button to browse to the location of the License.cab file. Browse and select a valid License.cab file and click ‘Open’ The path to the license file will now be updated.

NOTE: If you select an old expired license file the installer will continue but the StifleR service may stop soon after starting

WARNING At the present time do not install any Feature as stand alone. At the time of writing there is no automatic method that allows a clean uninstall of these features when installed without the StifleR Server Service.

Next, configure the account under which you would like the StifleR service to run, either LocalSystem, or using a specific domain account. Note that, if use a domain (or local user) account it must have the ‘Logon as a Service’ right.

Next, you can choose a port for the StifleR service. The default is 1414 but you can change that here. Click the ‘Test Port’ button to test that the port is available and working.

This page allows you to configure the installation of the Dashboards onto the IIS Site. You can leave the defaults or configure a Custom App Pool if required.

Server Installation - Post Installation Checks

Next is the Installation Folder location where you want to install the StifleR service files.

Next is an option to allow the installer to configure the Microsoft Firewall to create the required exceptions for SignalR, Web Service and Beacon Server communication

Next you need to enter the Name of the StifleR Administrative Groups You will need to create these groups in AD and add your Global Administrator, Dashboard Access and Global Read Operator accounts accordingly.

We’re now ready to unleash the StifleR magic, so go ahead and click on Install, sit back and enjoy a nice cup of tea, you’ve earned it.

All going well you will see the Finish dialogue and StifleR will be ready to

Post StifleR Dashboards Installation - IIS Configuration

As access to the StifleR dashboards is limited by Windows Group membership there is a requirement to make some security configuration changes on the StifleR Dashboards website within IIS. Specifically, we need to remove Anonymous access, and configure Windows Authentication. Then within Windows Authentication, ensure that the only provider that is enabled is NTLM. You can do this manually within IIS Manager, but the easiest way is to run the following PowerShell snippet:

#--------------------------------
#Configure IIS for Authentication
#--------------------------------
$siteName = "Default Web Site/StifleRDashboard"
Write-Host "Configuring IIS for Windows Authentication"

Set-WebConfigurationProperty -filter /system.webServer/security/authentication/AnonymousAuthentication -name enabled -value false -PSPath IIS:\ -location $siteName

Set-WebConfigurationProperty -filter /system.webServer/security/authentication/WindowsAuthentication -name enabled -value True -PSPath IIS:\ -location $siteName

Write-Host "Configuring Windows Auth Providers"

#First we remove all providers - then re-add NTLM Provider only.

Get-WebConfigurationProperty -Filter system.webServer/security/authentication/WindowsAuthentication `
 -Location $siteName -Name providers.Collection | Select-Object -ExpandProperty Value | ForEach-Object {Remove-WebConfigurationProperty -Filter system.webServer/security/authentication/WindowsAuthentication -Location $SiteName -Name providers.Collection -AtElement @{value=$_}}

Add-WebConfigurationProperty -Filter system.webServer/security/authentication/WindowsAuthentication `
 -Location $siteName -Name providers.Collection -AtIndex 0 -Value "NTLM" 
 

• Check that the service is running - not stopped or in any other state.

• Navigate to the StifleR installation directory.

• Check for the License.nfo files. If this is missing the service may not be licensed properly.

• Open up the configuration file (StifleR.Service.exe.config ) and check that the expected values

  are present. For a detailed description of each value see the StifleR Planning and Deployment Guide.

• Open up the Windows Event Viewer MMC and check that StifleR Server events are being

  logged:

Ensuring WMI is operational

• Open up wbemtest.exe and connect to the Root\StifleR namespace.

• Open up the StifleREngine class:

Note: If you are new to the world of WMI then you may find a third party tool such as WMIExplorer a little more user friendly.

• Ensure you can see the WMI methods:

• Hit the Instances button:

• You should see the default Instance of the StifleREngine with the ID of 1:

• Select this Instance. Scroll down in the properties window. Ensure that LicensedVersion is

  not null and that the other values are similar to those below

Overview

About This Guide

This guide is designed to get you up and running with StifleR in a ’Proof of Concept’ or LAB environment. For full design and implementation guidelines – read the Planning and Deployment Guide.

About StifleR

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.

Pre-Flight Checklist

Working P2P Infrastructure

StifleR requires a functioning Microsoft Peer to Peer (P2P) infrastructure in order to fully optimize your software distributions. Typically this includes BranchCache and/or ConfigMgr Peer Cache and/or Windows 10 Delivery Optimization.

LEDBAT - Low Extra Delay Background Transport

LEDBAT is designed to automatically yield bandwidth to users and applications, while consuming the entire bandwidth available when the network is not in use. It’s a scavenger protocol – it scavenges whatever network bandwidth is available on the network, and uses it. LEDBAT can optimize any TCP sender-side workload. It is enabled on the Content Server side and can be monitored by StifleR.

In order to track LEDBAT enabled downloads, each LEDBAT enabled content server (or SCCM DPs) requires an IIS ‘Response Header’ to be added that will tag LEDBAT traffic so that it can be identified by StifleR Clients. You can use the appcmd.exe command line program for this.

C:\Windows\System32\inetsrv\appcmd.exe set config -section:system.webserver/httpProtocol /+"customHeaders.[name='LEDBAT',value='true']"

StifleR Server

A Suitable Server to act as the StifleR Server – this can be any server for the purposes of testing as the load will be very light.

Client Systems

Windows client systems are required, onto which you will install the StifleR Client software. These should represent your corporate client build (OS revision etc) as closely as possible.

Pre-requisite

• Windows 7 SP1 or later

• Supported are x86 or x64 versions of the operating systems

  • Professional, Enterprise or Ultimate versions

  • Newer Educational SKU is also supported

• Microsoft .Net 4. 7 .2 (or higher) must be installed on the client

• Microsoft .Net 4. 7 .2 (or higher) must be installed on the Server

• Hotfixes for Windows 7 - https://support.microsoft.com/en-us/kb/3036149 (not required but fixes a

  bug within BITS that can cause it to ignore Bandwidth Policy)

Network

For the purposes of testing content delivery to low-bandwidth locations, we recommend that you emulate as closely as possible the WAN configuration of your production setup, sepcifically the available bandwdith. You can do this using NEWT, a VYOS Linux Router, or method of your choice.

Features Overview

StifleR is designed to provide two main enhancements to Enterprise-wide Content Distribution.

• To greatly reduce the volume of WAN traffic transferred from content servers to remote

  client systems by using Microsoft Peer to Peer technology.

• To provide granular monitoring and control over the volume of WAN (and LAN) traffic, and

  provide administrators with the ability to optimize network utilization and effectively control

  bandwidth usage.

Server and Client 2.6.9.0 - 2021-08-23

1. Fixes an issue on the client where the flags for downloads were sometimes not set right.

2. Fixes an issue were small jobs that complete very fast are not counted correctly.

3. Fixes an issue where Beacon measurements are not completed correctly for child locations or well connected locations.

4. Fixes an issue where WMI triggered MaxBandwidth measurements fails for parent locations with no children.

5. Updates for missing jobs in fast scenarios where BC is used & fixes for job sizes having mis-matches between peer bytes and source bytes.

6. Fixes where the type detection sometimes fails.

7. Fixes an issue where the parent location objects LastBandwidthMeasurement property is not updated when being measured.

Server 2.6.6.1 - 2021-04-21

1. Adds new "ExternalAddresses" property for NAT routed locations.

2. Fixes for Virtual MAC addresses generating multiple locations.

3. Adds a new DirectRoute property on locations to indicate directly routed locations.

4. Fixes issues where clients send bad job data. These messages are now rejected.

5. Fixed issues with SQL DB for job history reporting.

Client 2.6.6.0 - 2021-04-21

1. Improved logic to catch small/fast jobs.

2. Fixes issues where jobs sometimes reports wrong job sizes.

Order of Installation

For a typical StifleR implementation the order in which you should deploy and configure each component of the system is as follows:-

Enable and Configure your Microsoft P2P infrastructure

A successful StifleR deployment relies on a correctly installed and configured Microsoft P2P infrastructure. This is beyond the scope of this document but, as usual, there’s a lot of useful information and links on the 2PintSoftware.com website to help in this regard.

Install the StifleR Server

• Deploy Rules for your environment

• Install StifleR on a server and configure dashboards

Deploy StifleR Clients

• Install Client in Service mode

• Check configuration

• Enable debug logging if required

• Plan ongoing configuration

Configure Subnet Parameters

• Configure Target Bandwidth

• Configure Subnet Description

• Configure Delivery Optimization

StifleR Client Installation

Pre-requisite

• Windows 7 SP1 or later

• Supported are x86 or x64 versions of the operating systems

  • Professional, Enterprise or Ultimate versions

  • Newer Educational SKU is also supported

• Microsoft .Net 4.6.2 must be installed on the client

The client is a .Net executable with some C++ helper DLLs. It will run on any operating system that is capable of running .Net 4.6 and BranchCache. This includes most operating systems from Windows 7 SP1 and above with the exceptions of Home and other consumer versions of Windows.

Client Modes

• For the purposes of testing we will be installing the StifleR Client in ’Service Mode’

Automated Installation

You can install the StifleR Client interactively, via the MSI wizard based install. This is described in the StifleR Planning and Deployment guide. For the purposes of expediency and testing however, we will install the client using the MSI command line.

For example:

To install the StifleR Client with default settings, in Windows Service Based Mode with a single StifleR server defined , and the URL for the StifleR rules XML download, run the following command line from an elevated command prompt:

The full table showing the available MSI properties, switches, options and defaults can be found in the Planning and Deployment guide.

Post Installation Checks

Service Driven Mode

• Check that the 2Pint Software StifleR Client Service is Running

• Check that the service is generating Event log entries to the StifleR event log

The following XML can be pasted into a text file and should be named StifleRulez.xml and placed on a server that is accessible to you clients via a virtual folder in IIS.

StifleR 2.6

TL;DR Version

1. Ensure that your P2P environment is working – BITS, BranchCache, DO, LEDBAT enabled

2. Set up your Global Administrator, Dashboard Access and Global Read Operator Groups

3. Install the StifleR Server components – Service, Dashboards and Beacon

4. Install at least three clients on a separate subnet

5. Run some BITS downloads on the clients and/or run Microsoft updates and Install some Store Apps

6. Browse to the StifleR Dashboard website – http://IIS_ServerURL/StifleRDashboard

7. Run the StifleR.ClientApp.exe in interactive mode through the CMD prompt (with the /Service switch) and check out what’s happening on client. (Stop the StifleR Client Service first)

8. Go have a quick look at in this manual for a couple more things to try

9. Enjoy!

Executive Summary

What Does It Do?

StifleR optimises WAN Bandwidth usage and ensures that your Users and Workstations obtain the content that they need from a source local to them in the most efficient way possible, while protecting network bandwidth, prioritizing traffic, and giving real-time visibility and control over your Software Distributions through the StifleR Dashboards.

Why Do You Need It?

‘StifleR – How to be the Network team’s best friend in 5 minutes or less’

Would you get onto an airplane knowing that Air Traffic Control Radar wasn’t working? Of course not! Without StifleR your WAN and LAN traffic is ‘flying blind’ with little control over speed or priority. Without monitoring or control, how do you know if your Users aren’t choking the corporate network, downloading or streaming mundane or personal content and blocking high priority business traffic such as your Point-of-Sale data or critical Windows Updates? StifleR delivers the ability to centrally monitor and dynamically control these data streams.

StifleR-assisted content delivery quickly decreases the bandwidth load on your network. The greater the number of StifleR enabled clients across an enterprise, the more efficient content delivery becomes.

How It Works – The Overview From 10,000 Feet

Microsoft clearly sees P2P as the future of content delivery and so should you!

StifleR has been built around the awesome Microsoft Content Distribution and Peer to Peer Caching technologies that are now an integral part of Microsoft’s preferred delivery solutions. BranchCache is the mature WAN Accelerator that’s been built into the Windows operating systems for over 7 years. In Windows 10, StifleR gives you the power to manage Delivery Optimization (DO) which is now the download and cache engine of choice for that platform and for Microsoft distributed content in general. SifleR also manages and enhances the performance of Microsoft Configuration Manager Client Peer Cache which is the solution specifically designed for CM content delivery. Now with Windows Server 2016, StifleR gives you control and visibility over Microsoft’s latency optimized, network congestion control provider called LEDBAT, which stands for Low Extra Delay Background Transfer. LEDBAT is designed to automatically yield bandwidth to users and applications, but is able to utilise the entire bandwidth available and allocate any extra to background services.

StifleR is built on Microsoft’s SignalR which is a massively scalable lightweight platform for real-time network wide communications which enables up to the moment monitoring and end point control between Servers and consumers.

By uniting and giving you control over these various technologies we built a solution that can pamper, whittle, slice and dice your content delivery from the CEO’s Surface Book all the way to the remotest of remote Locations. You have full control and visibility over Windows Updates, Applications, Office files, CM Content even your users personal content streaming, all in real time.

StifleR is designed to provide several enhancements to Enterprise-wide Content Distribution.

• To greatly reduce the volume of WAN traffic transferred from content servers to remote client systems

• To provide granular monitoring and control over WAN (and LAN) traffic, and to provide administrators with the ability to optimize network utilization, prioritize traffic and effectively control bandwidth usage.

Network Traffic Reduction

Microsoft has embraced Peer to Peer (P2P) technologies as the solution to efficiently disseminate content to millions of managed end points around the globe. As mentioned above, this started with BranchCache. We have since seen the introduction of CM Peer Cache, for the efficient delivery of Configuration Manager content and, most recently, Delivery Optimization (DO) is the default manager for the download and P2P sharing of Windows Updates and Windows Store content between Windows PCs both locally and even on the internet. For more information on these various P2P solutions head over to the 2Pint Software web site and have a dig around. There are all sorts of gems waiting to be uncovered.

StifleR enhances the efficiency of content transfers by utilizing and enhancing this built in Microsoft P2P Service infrastructure including Caching, Data Deduplication and Peer-to-Peer sharing of downloaded content at the local network level. Every endpoint that fetches data from a Peer is saving you WAN link bandwidth and saving you costs both directly in WAN charges and indirectly in workplace efficiency.

StifleR with Microsoft P2P Caching solutions has a profound effect on where users actually source their content and the amount of bandwidth consumed in retrieving that content.

It eliminates unnecessary repeated download of content to many local computers from remote data centres by firstly limiting the number of clients in a remote location that will download required content and secondly by storing an accessible copy of downloaded content in the local computers cache which can then be shared with peer computers immediately or at a later time.

Data-DeDuplication

These caching solutions also work closely with the Data De-duplication feature of Windows Server to ensure that content is only transferred in its Deduplicated form which further greatly reduces the total volume of content that is transferred over your corporate WAN links. Data De-duplication is an extremely powerful Microsoft Server technology that chops up data on a disk into small chunks which can then be compared. If the data contained in a chunk from one file is identical to a chunk in another file then the chunk is only stored once on the disk and the files are now reparse points with metadata and links that point to where the file data is located in the chunk-store. This indexing extends to download data so if a chunk is present in the chunk store it is not downloaded and referenced instead. To give you an idea about how this can help save disk and data traffic, just think about how much data is duplicated across Operating System .wim files! Taking advantage of this technology alone saves Gb’s at a time in disk space and network traffic. StifleR takes advantage of this technology by allowing multilane transfers to take place where the relatively small amount of De-Duplicated data required to complete a download may be allowed, at reduced bandwidth, in the background while another larger download uses the full bandwidth allowance as usual.

Altogether, this results in a significant reduction in bandwidth used allows users to access content much faster than if they were retrieving it from the remote datacentre which means you will have Happy, Productive Users and a Healthy Network.

LEDBAT++

To quench latency and improve the user experience, Windows has implemented a low latency transport protocol called LEDBAT. The LEDBAT algorithm seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. In laymen’s terms, use any available bandwidth without anyone noticing. LEDBAT does this by detecting changes in one-way delay measurements to limit congestion that the calling application itself induces in the network.

Microsoft describes Low Extra Delay Background Transport (LEDBaT).as follows:

" Windows LEDBAT transfers data in the background and does not interfere with other TCP connections. LEDBAT does this by only consuming unused bandwidth. When LEDBAT detects increased latency that indicates other TCP connections are consuming bandwidth it reduces its own consumption to prevent interference. When the latency decreases again LEDBAT ramps up and consumes the unused bandwidth."

LEDBAT has been around for some years now, and most famously used by BitTorrent (in their P2P content transfers) and Apple (in their Software Update infrastructure). Now adopted and enhanced by Microsoft their implementation, LEDBaT++, is a bit of a game changer in the world of Content Delivery and Bandwidth Management. As of Server 2019 this is a fully supported Windows feature and is now also included as a delivery option for Configuration Manager Content. As it is controlled from the delivery side it is not dependent on the client side operating system and is simply enabled on the Distribution Point through a simple check box in much the same was that we saw at the introduction of BranchCache into CM content delivery. It didn’t take long for BranchCache to become automatically enabled for all CM content distribution and we would expect LEDBAT to go the same way.

StifleR has the ability to bandwidth manage LEDBAT aware downloads in much the same way as BITS. For the latest on this technology head on over to the 2Pint Software Support pages or drop us a line directly.

Bandwidth Control

If you can’t control the technology that your Microsoft management infrastructure uses to transfer content around your enterprise, you simply aren’t in control.

StifleR enables easy administration of content transfers to Windows client computers in real time by providing configurable automatic controls over the Microsoft content downloader (BITS/DO etc).

StifleR can automatically pause or re-prioritize content transfer while also dynamically limiting or increasing the amount of Bandwidth used between your content servers and client systems at any Location. This helps to ensure that your business-critical network traffic is not impacted by the dayto-day distribution of the large volume of enterprise content that should ideally move around your network quietly and efficiently every day.

StifleR detects if a client is Roaming, Connected to the corporate network, Connected through VPN, “Well Connected” or simply Home Alone and allows administrators to control settings and maximise bandwidth efficiency in each of these situations.

Stop, Pause, Resume

As StifleR allows for real-time granular control over your downloads, it gives you the ability to immediately STOP, Pause and resume, any or all downloads at the Individual Client, Subnet, Site or Enterprise level through the Dashboards Interface or from the command line. No catches – it is that effective.

At 2Pint Software we noticed that although the various P2P technologies are awesome at what they do, there were some obvious areas for improvement. Firstly, the manner in which the content is downloaded (bandwidth control) and secondly, how many machines actually need to download that content from remote data sources onto the local site or subnet before sharing it at the local level. (Single Site Download)

Bandwidth Control

Microsoft P2P solutions use several delivery protocols which by default are difficult to control at a granular level. Taking BITS (BranchCache) as an example: An Administrator can set maximum bandwidth usage for various BITS job priorities but those priorities can only to be set at a very high level and over a wide variety of distribution types which may not necessarily align with your Network or Management requirements. In the case of User initiated Configuration Manager Jobs, control is virtually removed entirely and these are automatically set to Foreground Priority (use all available bandwidth) which has no respect for Bandwidth Limits and will push other (possibly more important) jobs down the queue. The StifleR client agent returns control and allows an Administrator to set priority levels for content download down to specific job types and delivers the ability to centrally adjust and tweak those settings down to an individual job level.

But Job Priority is just half the challenge. The Job Priority settings only enable an Administrator to set a maximum bandwidth level for a download (which unmanaged clients will use if unchecked). If all clients are trying to download content from a remote data centre over a low bandwidth connection, it doesn’t take long for the expensive WAN link to become congested and for your users to start suffering a loss of production data.

StifleR to the rescue! Not only does StifleR allow you to set the priority, and therefore the bandwidth available to a certain content transfer, it also monitors latency during a download and will dynamically adjust the download transfer rate up or down in order to keep the bandwidth usage within configurable QoS limits and allow business critical data to flow without interruption.

Single Site Download

Controlling the bandwidth consumed by your individual clients when they are downloading content is fine to a point but if there are a large number of clients that all need to download content at same time then the sheer weight of numbers can quickly overwhelm a highly utilised link.

StifleR provides a solution to this problem through the concept of the Red and Blue leaders. There’s a lot more about this later on in this document but, in a nutshell, it works by the most suitable client in a subnet being dynamically appointed to be the only client for that location to download the content from the remote source. This “Leader” client alone is allowed to make full use of the priority bandwidth for the download thus delivering the content to the local network in the quickest time. The other clients will throttle down and wait for the content to be available. Once the content has been downloaded to the “Red Leader” client on the local network, Microsoft P2P bandwidth accelerating caching technologies enable that content to be shared efficiently with other clients on the LAN, leaving the WAN link clear for your business critical production traffic.

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 rebroadcast those messages onto their local network 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 may be downloaded once over the WAN for an entire remote site with that content then shared directly between Peers on the well connected LAN.

BranchCache V2-V1 Auto Detection

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.

Inter VLAN P2P

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.

Command Line Execution

Using the command line execution feature you can easily run commands across many systems at one time.

PowerShell Everywhere!

Same as the Command Line execution, but with PowerShell scripts on Clients instead. Each script is distributed to the client and executed.

Create Your Own BITS Downloads

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

Wake-On-LAN

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.

Server and Client

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.

Bandwidth Measurement - Beacon Server

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.

SignalR Communication

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.

StifleR Rules

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.

Security

Communication Channels

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”

User Administrative Access

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

Visibility and Control Through the StifleR Dashboards

The 2Pint StifleR Dashboards allow you to monitor and control the movement and location of individual data streams, while it is being transferred over the network, in real time.

Without this visibility, you’re flying blind and may be at risk when dealing with zero-day security patches, requests from high profile users, mission-critical fixes, and other high priority content distribution.

The various StifleR Dashboards allow you to drill down through Location and/or Job paths. At each step there is the ability to set various parameters and control distribution through such settings as Bandwidth allowance or job priorities from the Global level, Site/Subnet level, right down to the individual client.

Automation

Once configured with the relevant Network and Location data, StifleR is designed to run on ‘Auto-Pilot’ and will transparently and automatically manage and adjust bandwidth controls across the Enterprise. In cases where there is a need to change settings manually, to expedite certain custom deployments for example, instant configuration changes can be automated and scripted via PowerShell and the 2Pint WMI Provider or can be changed directly through the dashboard GUI interface all at the client, subnet, site or enterprise level.

StifleR and Configuration Manager

StifleR is designed to greatly enhance how all content is delivered including Configuration Manager data. It is awesome at providing up to the second information for small datasets. StifleR gives you full visibility over content delivery with the ability to monitor content in transit and to automatically tune bandwidth usage in real time. StifleR also gives you visibility and control over your Configuration Manager Peer Cache data delivery as well as LEDBAT traffic.

Once you install the StifleR client on some test systems, they will report to the StifleR server, which will start to populate the Location information based on the data sent back from the clients.

Each ’newly discovered’ location/subnet has a set of default parameters, and for the purposes of testing, there are some configuration changes that should be made to enable optimal performance while testing.

Configure Subnet Bandwidth

On the StifleR server – run the following command from an elevated Command prompt

wmic /namespace:\\root\stifler path Subnets.SubnetId="xxx.xxx.xxx.xxx" set TargetBandwidth=xxxx

Where xxx.xxx.xxx.xxx is the subnet ID of your test location and

xxxx is the target bandwidth that you wish to allow for that subnet in Kilobits. So 1024 = 1 Mbit

The Target Bandwidth is the network total bandwidth usage limit that is defined for ALL StifleR clients at that location – so if the limit is set to 4Mbit/s – then the TOTAL bandwidth usage across all clients at that location will not exceed that limit.

Populate Subnet Summary Information

Scripted

The summary information for a subnet provides an easy to read description of the subnet in the StifleR dashboards.

Run the following commands from an elevated Command prompt.

wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set Description=”Test
Location”
wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set Town=”SomeTown”
wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set Country=”USA”

You can of course substitute the entries above with those of you own choosing.

Manually through the Dashboards

From the main StifleR Menu (Top LHS matrix icon) navigate to the dashboard for the particular subnet on which you wish to add some summary information. You may then click on a field and you will be presented with an edit box into which you may enter the required details.

Configure Delivery Optimization

WARNING: It is possible to set your Delivery Optimization Peer Caching boundaries to match your Microsoft Configuration Manager Boundary Group boundaries. It is important that you do not use this method if you are using StifleR to configure Delivery Optimization and vice versa.

If you are using Windows 10 Delivery Optimization, StifleR can ensure correct Peer to Peer boundaries are respected.

To achieve this, you need to set two parameters per subnet, the DODownloadMode and DOGroupID. These settings mirror the Policy settings for Delivery Optimization on the client systems.

The DOGroupID must be a unique GUID. You can generate a GUID using PowerShell (New-GUID command) or you could copy the GUID of the subnet itself and use that.

If you have multiple subnets within a location, and you want all StifleR clients to share content across those subnets, simply set the same Group ID for all subnets at that location.

For example, in order to configure this capability, you could run the following commands from an elevated command prompt on the Stifler Server:

wmic /namespace:\\root\stifler path Subnets.SubnetId=" xxx.xxx.xxx.xxx " set DODownloadMode=”2”
wmic /namespace:\\root\stifler path Subnets.SubnetId=" xxx.xxx.xxx.xxx " set DOGroupID=”99999999-9999-9999-999999999999”

Once the above parameters are set, the Delivery Optimization clients will only share content with other clients that have the same Group ID.

NOTE As the DO group is meant to be well connected and used specifically for P2P file sharing there is no Blue Leader functionality as all members should be local.

PowerShell Snippet

This example loops through all subnets and enables Delivery Optimization Download Mode in ‘Group Mode’ (2)

It then sets the DOGroupID using the GUID for that subnet. This is the most basic configuration and means that DO will only share content with other clients on the same subnet.

$alllocs = @(gwmi -namespace root\StifleR -Query "Select * from Subnets") 
 
foreach ($loc in $alllocs)
{
$DODownloadMode = 2
$DOGroupID = $loc.id
#Set the new subnet DODownload Mode + ID
swmi -path $loc.path -Arguments @{DOGroupID = $DOGroupID; DODownloadMde = $DODownloadMode }
} 

Other Delivery Optimization Settings

In order to get the best performance from Delivery Optimization, 2Pint recommends that you set the following Policy items.

1. Max Cache Age (in seconds) – Set this to zero (0) so that content is not removed from the cache once downloaded. The default is only 3 days.

2. Minimum Peer Caching Content File Size (in MB) – Set this to 1 to make sure that all files over 1MB in size will be shared via P2P. The default for this is 50MB or 100MB (depending on Windows 10 version) which excludes a lot of content.

These are the minimum settings that we recommend for efficient Delivery Optimization Peer Caching. There are many other DO setting available – see this link for more information.

https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization

Content Accelerator

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.

Bandwidth Control

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.

Bandwidth Sharing

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.

Visibility and Control Through the StifleR Dashboards

Real Time Monitoring Reporting and Visibility

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.

Administrative Control via the StifleR Dashboards

Server Configuration

Server settings can be configured through the ‘Server Settings’ dashboard

Subnet Configuration

Subnet level settings can be set via the Subnet dashboard, including TargetBandwidth/Well Connected/Address etc.

Locations Configuration

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

Job Management

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.

Administrators Security

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.

Automation and Efficiency

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.

Change Content Delivery Priorities

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:

1. 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.

2. 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.

Multilane Transfer

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.

Summary

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.

Pause and Resume

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.

Stop and Resume

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:

-ArgumentList "Suspend", False, "*", 0, "ALL" 

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:

-ArgumentList "Suspend", False, "*", 0, "192.168.137.0"

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.

Windows LEDBAT++ Tracking

Track the network usage when using LEDBAT in real-time and verify that the server connection is established using the right TCP Template (Internet Custom) and that the right congestion provider is configured for this template.

Why? 'cause people want to know that LEDBAT is really enabled.

Where? See the connection information (including template info) in the Client Info dashboard. You can also see LEDBAT traffic highlighted in a different colour in the Transfer Overview and Subnet Dashboards

What’s next? The ability to change edit the templates from the dashboards.

Improved Client Info

Why? So it’s easier to find stuff about individual clients, both online and offline.

Where? Search is the easiest way to find a machine. You can search all of the properties using key=value syntax, like ip=192.168.138.6.

What’s next? More buttons to directly view, clear things on the client, like the CCM cache etc. The Shutdown/Disconnect etc buttons will come in first.

Example:

View Network Connections and templates

Why? To make sure the right templates are set when using LEDBAT ++

Where? The connections are visible from the list in the Client Info dashboard, both server and clients show the value. As LEDBAT++ is currently only a server side (sender) feature the StifleR client has to be installed on the server in order to show the connections and templates used.

What’s next? We will expand on showing more information from the templates and also setting these templates (prefix etc.) from within StifleR.

Examples:

Realtime Network Monitoring

Why? Track all network connections in real time. Super useful for security investigations or to diagnose unusual network traffic or usage patterns.

Where? Client Info dashboard

What's Next? More real time monitoring capabilities.

Example:

Improved Client Dashboard

Why? Better tracking of client types and usage over time.

Where? Clients Overview Dashboard

What Next? More historical reporting and real time analysis of Client and Network Health and usage patterns

Client Database

What?The server now stores most static information for clients, which is great as statistics can be pulled regardless of when clients are connected. This is exposed in WMI under the Clients WMI class. The old clients class was a sub class of Connections and is removed. The old parent class Connections still exists and has all the properties that Clients used to have.

Why? So we can send less data and report more when clients are NOT online.

Where? It’s in a ESENT self healing database.

Whats’s next? More reports on what’s in the database and more things to put into the database, things like average WiFi signal strength etc.

Client Network Location Tracking

The new client database tracks when the clients are online, and which network it is available on. This will be used as a foundation for the future Pre-Caching features

Examples:

Show when clients power up/connect throughout the day:

You can also track when clients are disconnected/off, roaming or roaming between different networks:

SRUM (System Resource Utilization Monitor) stats

What? We now query the SRUM database on Windows 10 Clients and this is stored on the server for reporting/analysis.

Where? Resource Usage Dahsboard

Example:

Wi-fi Tracking

What? StifleR now reports and tracks the wifi signal strength when connected to WiFi and sends this back to the server. We can also track the number of clients per WiFi Access Point and make sure that only clients with good signal strength can share content via BranchCache P2P.

Why? So we can know if clients are on bad WiFi networks in order to disable/enable different P2P capabilities in the future.

Where? There are several places to check the average WiFi signal strength. Either per accessing the WMI or using some of our pre-baked reports.

Example:

IPv6 and Direct Access support

StifleR now supports Direct Access VPN .

Local Admin Tracking/Modification

You can now list the members of the local administrators group on StifleR Clients.

Why? So you can see how has admin rights.

Where? If you search for a machine and then hit the “List admins” in the Client Info dashboard

What’s next? Triggers when Admins are added/removed and the ability to remove unwanted administrators.

Local Time zone in Locations

Perfmon Counters (Server)

Why? To enable better monitoring of the StifleR Server health

Where? Windows Performance Monitor

What Next? Dashboards based on this data

Hardware

If the client hardware can run Windows, it can run the StifleR Client. CPU & Memory utilization is very low.

Software Requirements

Pre-requisite

• Windows 7 SP1 or later

• Supported are x86 or x64 versions of the operating systems

  • Professional, Enterprise or Ultimate versions

  • Newer Educational SKU is also supported

• Microsoft .NET 4.7.2 must be installed on the client

The client is a .NET 4.7.2 executable with some C++ helper DLLs. It will run on any operating system that is capable of running .NET 4.7.2 and BranchCache. This includes most operating systems from Windows 7 and above with the exceptions of Home and other consumer versions of Windows.

Hotfixes for Windows 7 - BITS might ignore the throttling policy and consume the WAN circuits in Windows 7 SP1 or Windows Server 2008 R2 SP1 (not required but fixes a bug within BITS that can cause it to ignore Bandwidth Policy)

Mode of Operation

The StifleR Client can be installed in one of three modes:

1. Windows Service Based Mode – always connected to the StifleR Server, running as a Windows Service

2. Event Triggered Mode – only starts & connects when a download job is created and running

3. Read Only Mode

Windows Service Based Mode

The benefit of Service Mode is that the Administrator can send configuration changes to the Client immediately at any time. This does not happen in the Event Driven mode as the client is only active when a download job is run and the client will only receive configuration changes at start up.

When running as a service, the StifleR client runs as a Windows Service and monitors job creation every few seconds according to the configured interval.

Event Triggered Mode (Advanced Only)

The client is not always running in this mode lowering utilization on both client and server. This however means that the server cannot reliably perform certain configuration tasks on the client in real time.

When the StifleR client is event driven it is triggered by the Windows ETW (Event Tracking for Windows) system using a Scheduled Task that launches the StifleR Client on BITS Event ID 3 (BITS Job created). Once all queued BITS jobs have completed, the Client exits out.

The reason that Event Driven mode was first written into the product was to cater for a situation where a customer may deploy your content in ’Maintenance Windows’ within set times during offpeak hours for instance and may not want the service running outside these hours. We have not seen any requirement for this in real world usage and accordingly this mode should be considered for advanced use only.

Read Only Mode

This mode requires separate licensing. It is a limited version only for network monitoring and dashboard visibility.

StifleR Client on Windows Server

The StifleR client can be run on a Windows Server system where, for example, you may want to monitor the Bandwidth performance of an SCCM Pull Distribution Point. In order to do this you must edit the following line into the StifleR.ClientApp.exe.config file and restart the StifleR service:

<add key="UseServerAsClient" value="1" />

Once the Service has been restarted, the server can be monitored like any other client. NB: It will not appear in the ‘Servers’ dashboard.

Manual Server Installation

The easiest way is to install the server manually using the MSI. The server supports silent installation if needed, but typically you only need to run the installation on a single occasion, so automation is not usually required.

Pre-Requisites

• Requires .NET 4.7.2 to be installed on the server

• If you want to use the same server to host the dashboards, install IIS as well

• Installation account must have Administrator rights

• Ensure you have the License.cab available for the installer to access

• Set up the StifleR Administrative Security Groups

• Ensure the needed firewall ports are opened

Installation

From an Elevated Command prompt launch StifleR.Installer64.msi.

Automated Server Installation

If you need to automate the StifleR Server installation then you could run the following example command line from an elevated command prompt:

msiexec /i StifleR.Installer64.msi CABSOURCE=C:\Temp\License.cab /qn

Post StifleR Dashboards Installation – IIS Configuration

As access to the StifleR dashboards is limited by Windows Group membership there is a requirement to make some security configuration changes on the StifleR Dashboards website within IIS.

Specifically, we need to remove Anonymous access, and configure Windows Authentication. Then within Windows Authentication, ensure that the only provider that is enabled is NTLM.

You can do this manually within IIS Manager, but the easiest way is to run the following PowerShell snippet:

Server Installation - Post Installation Checks

• Check that the service running and is not stopped or in any other state

• Manually stop and start the 2Pint Software StifileR Service and ensure that it does so gracefully

• Navigate to the StifleR installation directory

• Check for the License.nfo files. If this is missing the service may not be licensed properly

• Open up the configuration file (StifleR.Service.exe.config ) and check that any expected custom installation values are present other than default

• Open up the Windows Event Viewer MMC and check that StifleR Server events are being logged:

Ensuring WMI Is Operational

• Open up wbemtest.exe and connect to the Root\StifleR namespace

• Open up the StifleREngine class:

• Ensure you can see the WMI methods:

• Hit the Instances button:

• You should see the default Instance of the StifleREngine with the ID of 1:

• Select this Instance. Scroll down in the properties window. Ensure that LicensedVersion is not null and that the other values are similar to those below

StifleR controls access to the two main server components, i.e the SignalR Hub and the Web service. This control applies to both users (which required access to StifleR Dashboards) and StifleR Clients (who need to access the SignalR Hub).

User Access Control

Access to the StifleR Dashboards and WMI objects are controlled by Domain Group membership and StifleR Configuration file settings. These are described below:

If the AllowAnonymousRead is enabled (value of “1”) in the StifleR Configuration file, we allow all read operations and the following options are not in play.

Full Administrative Access to StifleR Server is restricted to Accounts that are members of a Global Administrators Group. This group is defined during the installation of the StifleR Server. These Global Administrators can then grant specific rights (read/write) over individual resources to Delegated Administrators. Delegated Administrators can only see and administer those Sites and Subnets over which they have been granted control. See table below for full details.

*StifleR Configuration file setting name

StifleR Client Access Control

No Authentication

If the AllowAnonymousSignalRConnections value is set to “1” – then any StifleR client can connect. This is default currently, as older StifleR Clients (pre- 1.9.7.4) are not capable of ANY authentication and would be rejected if this were set to “0”. This can be disabled by setting the ConnectionSendCredentials option to “0” in the configuration file of the client.

Group Membership

The StifleR client runs as Local System (NT AUTHORITY\System)

If the client and the server are both in the same domain (or trusted), then the Local System account uses the computer account (hostname followed by a $ character, i.e. computer1$) to login on the remote computer. This can then be checked on the server side for limiting access, i.e. verify that the machines account (computer1$) is part of a specific group that gives the right access.

This is configured using the following settings

RequireAgentGroupMembership=”1”

If the above is set, a second setting, AgentGroupMembership is then used to define the RequiredGroup. e.g. AgentGroupMembership=”2PINT\StifleRClientAccess”

Certificates

If the client population is spread across a number of different domains, or are not domain joined, you can use certificates to control access.

If RequireAgentClientCertificate=”1” is set in the StifleR Config file, the client is required to attach a client certificate to the SignalR connection. This requires the CertificateClientThumbprint and CertificateRootThumbprint values to be configured (added) with a thumbprint of a local certificate which is then present in the personal (MY) store in the local machine store location of the client. The first certificate in the store chain from that thumbprint is used.

The server will then verify the certificate. Failing to verify the certificates will return a 403 error to the requesting client.

Client Token

There is a further (less secure) method that can be used if you are unable to use Group membership of Client Certificates. This requires a client ‘token’ value to be configured on the server and client. The value for the Server Configuration is RequestAgentToken which should be configured with a string that will then be used by clients to connect (and should be treated like a password).

Test Function

You can test access to StifleR using the following URL – which will list the group membership and access rights of the current user. The url should be as follows:

http(s)://FQDN.OF.STIFLER.SERVER:9000/api/test

Order of Installation

For a typical StifleR implementation the order in which you should deploy and configure each component of the system is as follows:-

Enable and Configure your Microsoft P2P Infrastructure

A successful StifleR deployment relies on a correctly installed and configured Microsoft P2P infrastructure. This is beyond the scope of this document but, as usual, there’s a lot of useful information and links on the 2PintSoftware.com website to help in this regard.

Set Up User Accounts and Groups

During the installation of the StifleR Server you must enter the name of the several Global Security Groups as shown in the Security Section previous. These groups should be set up prior to installation. The most important at this stage is the Administrators group (“Domain\StifleR Global Admins” by default). Access to StifleR configuration options is limited to members of this group which may be either Local or Domain based and you should have set your main administrator account as a member of this group for post installation administration.

Configure the StifleR Rules XML

The StifleR client will check through its queue of active downloads (both BITS and DO) and will prioritize them according to a locally held XML configuration file containing a set of rules that are configured centrally by the administrator and automatically distributed to 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. See the StifleR rules definition guide for more details on how to create and configure the rules file.

The clients will download the rules definition XML from a configured URL. This URL must be created, and for the purposes of this guide we will assume that it is on the same server as StifleR itself.

1. Place your customized stiflerulez.xml in a folder on the StifleR server e.g.: C:\ProgramData\2Pint Software\StifleR\Rules

2. Create a Virtual folder in IIS as follows:-

From an elevated PowerShell prompt, execute the following command:

New-WebVirtualDirectory -Site "Default Web Site" -Name StiflerRules  - PhysicalPath “C:\ProgramData\2Pint Software\StifleR\Rules”

This command will create a virtual folder which you will then use during the StifleR client install to configure the clients to automatically update their rules definition. The URL will be:

http://yourserverfqdn/StiflerRules/stiflerulez.xml

Install StifleR Server(s)

• Install StifleR on servers and configure monitoring

• Monitor load during StifleR client deployment

• Deploy Rules for your environment

Install StifleR Beacon Servers

• Installed onto stable known end points in your data centres

Deploy StifleR Clients

• Deploy in stages

• Monitor

• Plan ongoing configuration

Troubleshooting

2Pint Support KB and Other 2Pint Website Resources

Lots of answers can be found here and you can even ask us questions via the support portal. Don’t be shy we love this stuff and are happy to help.

Debug Logging Levels

For both Client and Server, Debug Logging has 6 levels

1 = Errors Only

2 = Warning

3 = OK

4 = Informative

5 = Debug

6 = Super Verbose

This is set via the Configuration value:

<add key="EnableDebugLog" value="n"/>

StifleR Server

1. Logs – there are many!

   1. Enable at installation using DEBUGLOG=n .msi switch (n Debug levels 1-6 available)

   2. Enable after installation by editing the StifleR.Service.exe.config file – <add key="EnableDebugLog" value="n"/> (n Debug levels 1-6 available) Service restart not required

2. StifleR Service events are logged in the Windows Event Log at Event Viewer > Applications and Services Logs > StifleR

3. Verbose logging can be viewed (for a short time only!) through a command window by running the executable directly in Interactive Mode. You must stop the Service first! TIP – If you have an installation that does not complete or a service that refuses to start. Fire up the executable in interactive mode and check any error messages that appear.

4. WMI See this guide and the 2Pint KB

5. Dashboards – Lots of information in the Dashboards to help with troubleshooting. The Performance Dashboard in particular gives you some at a glance Server health information

6. Power Shell troubleshooting script (contact 2Pint Support for the latest)

Dashboards and Access Check

You can test access to StifleR using the following URLs –

http(s)://FQDN.OF.STIFLER.SERVER:9000/api/test

Which will list the group membership and access rights of the current user

http(s)://FQDN.OF.STIFLER.SERVER /stiflerdashboard/ce.png

Which, if working correctly, will show the .png 2Pint Software Logo image from the dashboard folder.

StifleR Client

1. Client.log

   1. Enable at installation using DEBUGLOG=n .msi switch (n Debug levels 1-6 available)

   2. Enable after installation by editing the StifleR.ClientApp.exe.config file – <add key="EnableDebugLog" value="n"/> (n Debug levels 1-6 available) Service restart not required

2. StifleR Service events are logged in the Windows Event Log at Event Viewer > Applications and Services Logs > StifleR

BITS

Command Line tool >BITSADMIN

BranchCache etc

1. CMD Line >netsh br show status all – will get you started

2. Microsoft P2P Reporting – see 2Pint KB for how to enable this feature on your test servers

3. 2Pint Reporting Tools – particularly the BITSBCReporter Command Line Tool

4. PowerShell

5. Windows Performance Monitor

6. 2Pint Software Web site – all manner of tips and tricks

The following is a suggested list of actions for testing purposes for you to observe the installation of the Server and Client, investigate the software installed and observe StifleR in action. (For details on ”Interactive Mode” please visit the 2Pint Knowledge base and search for “StifleR Troubleshooting using interactive mode”)

1. Set up the Administrative Security Groups

2. Install StifleR Service, Dashboards and Beacon servers

   • Check that WMI and other bits are working

   • Stop the service

   • Start it in interactive mode (Testing only)

   • Check that the firewall ports are open for client connection

3. Check the Dashboards

   • Get IIS up and running

   • Launch your favourite browser and connect to the SifleRDashboard URL

4. Install StifleR Client

   • Stop the service

   • Start in interactive mode

   • The client should start and connect

5. Review the client connection

   • On the server choose option 5 (from Interactive Mode Menu)

   • Type in the subnet id (Subnet IP address) of the client and hit enter

   • View the stats

   • Exit Interactive mode and start the service

6. Start a BITS job on the client

   • Switch to the server and see the up to date information

7. Add another client

   • Repeat steps 3, 4 and 5

8. View the server again, see that the StifleR Red Leader is downloading data

9. Start the dashboard on the overview page

10. Drill into the subnet to view subnet info

Planning for integrating StifleR into your Content Distribution System is simple. Like most technical projects however, preparation and attention to details pays dividends.

Server

Location

Location of the StifleR server should be considered although it is not too critical unless you have multiple geographical locations etc. in which case you may consider having multiple StifleR servers at key hub locations. More important is the spec of the server and its Network connectivity. Bear in mind that the server will have incoming and outgoing connections to all StifleR clients – sometimes all at once during a large scheduled deployment.

Hardware

The following table can be used as a summarized view of the hardware requirements.

CPU

StifleR is CPU intensive. Since StifleR does not use that many threads, a higher frequency (Ghz) is recommended. We recommend at least a 2.4Ghz processor with 8 cores. Don’t forget that most CPU’s must also handle some of the Network connectivity management.

Memory

StifleR writes a lot of historical data to databases, as well as maintaining in-RAM memory objects. Since each connection and all connection data is stored in RAM a decent size of RAM is recommended but 32GB should be plenty for most installations.

Disk

StifleR saves a lot of information to ESENT databases, especially with the System Resource Tracking features enabled. Fast SSD disks are preferred for housing these Databases.

Network Connectivity

Each client has a non-managed SignalR client connection (web sockets) to the server, so if you want to run 100k clients to a single server you need to beef up the network connectivity.

If you are supporting a large number of clients, you probably want dual or quad 10Gb/s NIC’s for your StifleR server. This will ensure that the NIC’s have enough power to manage the large number of connections.

Software

StifleR server requires Windows Server 2012 with Microsoft .NET version 4.7.2 or higher. If you wish to run StifleR on Windows server 2008 contact us first for a chat.

There are also requirements around IIS settings. Please refer to the Dashboard installation section for important information in this regard.

Redundancy

Multiple StifleR servers can be configured for larger enterprises so that clients can fail-over to a second server should the primary server become unavailable.

Large Enterprise Considerations

For larger installations we recommend splitting the load across several StifleR servers. For example one server per geographical region.

Beacon Server

The server-side component (iperf3.exe) can run on any Windows OS (talk to us if you want to run it on Linux) It acts as the end point to which the StifleR Client Red Leaders send test packets. This allows the Red Leaders to accurately measure the maximum bandwidth available between the a Subnet/Location and the content source. Typically, you will install this component on a server in a central location (such as an SCCM Distribution Point) from which your clients obtain the bulk of their content. If you have a central datacenter for instance you can simply install the StifleR Beacon service onto any server at that location. The StifleR Beacon Service may be installed on the StifleR Server if required but there is no dependency on this configuration.

HTTP v HTTPS

We recommend that http communication channels only be used in your initial high level testing. In a production environment we strongly recommend that you configure StifleR communication to be secured over https. For more information on SSL configuration, and all things certificate related, please refer to the companion document “Securing StifleR operations using SSL” which gives an overview of not only the StifleR and SignalR configuration but also how to set up the underlying Configuration Manager security environment to get you started.

StifleRulez.xml

The StifleR client will check through its queue of active downloads (both BITS and DO) and will prioritize them according to a locally held XML configuration file containing a set of rules that are configured centrally by the administrator and automatically distributed to 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. The “StifleR Rules XML Guide” is available for download from 2Pint website on the StifleR Product Page which gives details on how to create and configure the rules file. There is a default rules file copied into the ProgramData location as part of the Client installation but this is static and should only be used for initial basic testing purposes.

The clients will download the rules definition XML from a configured URL. If you wish to configure your own rules definition file or your client do not have internet access then you need to create this URL on your internal IIS server. If not then the clients will default to use one which is stored on the 2Pint website.

IIS and Browser Requirements

SignalR can be used in a variety of client platforms. This section describes the system requirements for using SignalR in web browsers, Windows desktop applications, Silverlight applications, and mobile devices.

Supported Server IIS Versions

When StifleR’s SignalR driven Dashboards are hosted in IIS, the following versions and configurations are supported.

• IIS 10

• IIS 8, 8.5 or IIS 8 Express

• IIS 7 and 7.5. Support for extensionless URLs is required

• IIS must be running in integrated mode; classic mode is not supported. Message delays of up to 30 seconds may be experienced if IIS is run in classic mode using the Server-Sent Events transport

• The hosting application must be running in full trust mode

Web Browsers

SignalR can be used in a variety of web browsers, but typically, only the most recent two versions are supported.

Applications that use SignalR in browsers must use jQuery version 1.6.4 or major later versions (such as 1.7.2, 1.8.2, or 1.9.1).

SignalR can be used in the following browsers:

• Microsoft Internet Explorer versions 8, 9, 10, and 11. Modern, Desktop, and Mobile versions are supported

• Microsoft Edge

• Mozilla Firefox: current version - 1, both Windows and Mac versions

• Google Chrome: current version - 1, both Windows and Mac versions

• Safari: current version - 1, both Mac and iOS versions

• Opera: current version - 1, Windows only

• Android browser

In addition to requiring certain browsers, the various transports that SignalR uses have requirements of their own. The following transports are supported under the following configurations:

Web Browser Transport Requirements

*: 6+ required for full functionality.

Unsupported Browsers

While SignalR may run without major issues in older browser versions, we do not actively test SignalR in them and generally will not fix bugs that may appear in them.

Roaming Clients

StifleR uses the concept of 'Roaming Clients' and enables the ability to set bandwidth according to the client location and connectivity. A roaming client (in StifleR terms) is one that is not connected to the corporate network i.e. a known location/subnet or is non-domain joined and/or authenticated.

In these cases there are a couple of choices as to how these clients can be configured. These are determined by the StifleR Server setting DefaultRoamingBandwidth.

The default setting is 0 (disabled) which means that by default a StifleR client that roams will have all Bandwidth policies removed.

If, however, that parameter is set to anything other than zero Roaming policy will be applied (split between Delivery Optimization and BITS)

i.e. If a Default RoamingBandwidth of 50Mbs (51200) is set then the clients would get 25Mbs for BITS and 25Mbs for Delivery Optimization

There are two types of Roaming Client – Roaming and connected to a StifleR server: (possible if the client still has a route to the StifleR Server – via Azure for instance) and - Roaming but not connected to a StifleR server.

Well Connected Networks

Well Connected locations are networks where the bandwidth available to clients is fairly generous (>100Mb/s). In this scenario StifleR can still assist with improving Peer-to-Peer and caching efficiencies, which help to offload both network and memory/CPU load from source servers (Distribution Points etc.)

How it Works:

Instead of setting a 'Target Bandwidth', you can set the location to 'WellConnected' and then set DO and BITS (BranchCache) Bandwidth limits. A Red Leader will still be selected, but the bandwidth allocated to 'Non-Red Leaders' is the same. This allows for faster P2P transfers and faster deployments in general.

The Default Setting is False - (Not Well Connected)

StifleR Ports

The following (client) ports are used for the InterVLAN feature (see later). An asterisk (*) indicates a dynamic Port number. BranchCache tries to use a random port among the dynamic port range (49152-65535) as specified in RFC6335 section 6. Port Number Ranges:

Server – Client Communication

• Source – dynamic

• Destination – Port 1414 TCP/IP & Port 1414 UDP for Web Sockets

Web Server - Dashboards

• Source - dynamic

• Port 9000 is used by server to host the dashboard/data API. Dashboard uses it to connect to the REST API to get data

• Port 80 - dashboards

Beacon Server Port

• For clients to send iperf packets – Server TCP 5201

One Red Leader is assigned for each subnet unless StifleR Enterprise is used in which case each subnet is also assigned a Blue Leader which extends P2P functionality across subnet boundaries. It’s a 100% dynamic, automatic process which may change at any time during a download in order to optimize performance.

The figure below shows a StifleR Enterprise environment of 3 subnets, grouped into a Location, each with Leaders assigned.

Red Leader Assignment

The Red Leader assignment is completely dynamic and may switch several times during downloads in order to ensure the most efficient usage of WAN and LAN infrastructure.

Typically, the first machine in a subnet that connects to the StifleR Server will be assigned as the Red Leader. That Red Leader then remains as Red Leader until a more suitable candidate connects in which case the new Red Leader is assigned and the old Red Leader gracefully retires into network obscurity.

Red Leader Traffic Flow

The following visualization depicts the flow between Server and Client.

When Is a New Red Leader Re-assigned?

StifleR checks and compares the following for each client as part of the assignment process:

• If the current Red Leader has not responded to the Server within the configured threshold value

  • This typically occurs where there is a communication breakdown between a nominated Red Leader and the StifleR Server. The Server sends a message to appoint the Red Leader and the Red Leader must confirm the appointment within the threshold time. In the case a client cannot be assigned for a Location a Warning will be recorded in the Windows Event Log and the Server will move on to the next best nominee

• If the Current Red Leader has been marked with the “NotLeaderMaterial” flag set to true

  • It may be undesirable for certain clients to become Red Leaders and in such cases this can be configured on the client (by setting the NotLeaderMaterial setting value to 1 (in the StifleR.ClientApp.exe.config file) or scripted on the Server by setting the NotLeaderMaterial WMI property on the Client instance

• A Client with a higher priority job starts

  • The higher priority job Client will become Red Leader

• A Client with the same priority but a higher BranchCache version connects to the Server

  • Higher BranchCache version Clients will be a preferred Red Leader as a V2 capable system Is able to utilize Deduplication during the download and can also provide a V1 hash to Windows 7 clients.(StifleR Enterprise feature only)

• If a client connects that has downloaded more than the other clients over a configured threshold (10% more)

  • If the newly connected client holds more than 10% of the download in it’s cache than the current Red Leader it will become the preferred nominee and be appointed Red Leader

• If we have more data transferred (10% more) and priority is same or higher and BranchCache version is same or higher but uptime is higher

  • As most machines at the start of a job ends up within the same range, this is the most common rule that applies. Most Red Leaders have a high uptime

Generic Red Leader Selection Example

1. Machine1 connects and the StifleR server detects that no other clients are online for that segment. The client is not marked with NotLeaderMaterial so it will be selected as Red Leader. Machine1 is not currently transferring any active jobs. (Windows Service Mode)

2. Machine4 connects on the same segment. It is transferring a Low priority job and will be assigned as Red Leader. Server Assigns Machine4 to be Leader and retires Machine1

3. Machine5 connects and is transferring the same job as Machine4. Machine5 has a higher uptime, which will rank it higher than Machine4, but it has also transferred more or less as much as Machine4. Machine4 stays as Red Leader but Machine5 gets a BITS policy that stops it from actively transferring any large amount of data. Machine4 gets the high bandwidth transfer throttle value defined for that subnet

4. Machine6 comes online and is transferring a high priority job. Machine6 becomes the new Red Leader and the downloads for Machine4 and 5 is then stopped as both receive a low BITS policy value

5. Machine7 comes online and is a higher BranchCache version (Windows 10=V2) than the others (Windows 7=V1). As Machine7 is also downloading this high priority job, even though it has transferred less than Machine6 it is assigned Red Leader

6. After Machine6 and 7 complete their downloads Machine 5 becomes Red Leader

7. As soon as Machine4 and 5 complete their downloads Machine7 becomes the Red Leader as it has the highest BranchCache version

8. No client is actively transferring any data and Machine7 stays the Red Leader

Red Leader Selection Process High Level – Visualized

The following section shows a high level overview of how a Red Leader is used to transfer data and bandwidth throttling.

First off, for example a BITS job is started:

When the BITS job starts the StifleR clients send up statistics to the StifleR server. This provides the server with the information needed to select the best candidate to be Red Leader. In this case Client 1. As Client 1 downloads it will share content with the peer clients on the LAN. At the same time the peer clients 2 and 3 are automatically configured to throttle down their WAN BITS download speed leaving maximum bandwidth to the Content Server available for the Red Leader.

Once a Leader has been selected the StifleR server starts to send regular configuration messages to the Leader every x (configurable) seconds. The new leader uses these messages to set the (centrally configured) maximum bandwidth through an installed (Microsoft signed) filter driver. The message also includes flags that change other features such as InterVLAN transfers, BranchCache V1 content generation etc.

Each Leader reports up to the StifleR server at a regular interval (tracked as LastCheckIn Value). In the event that this communication stops for a period the StifleR server will automatically mark the failed Red Leader as NotLeaderMaterial and assign a new Red Leader to take over the WAN download.

Seamlessly the other peers will swap sources to continue the download from the new Red Leader.

If you either did not have IIS installed onto your StifleR server when you installed the Service Component or you are using a separate IIS server, you may need to install the Dashboard Feature on its own.

Manual Installation

The Dashboard Feature can be installed manually through the interactive MSI by simply selecting the ”Install StifleR Dashboards (IIS Required)” checkbox at the ”Select Operation Mode and Parameters” step of the installation. Run this on the IIS server that is to host the Dashboards website.

Automatic Installation

WARNING Do not use the ADDLOCAL=DashboardFeature switch. At the time of writing there is no automatic method to uninstall a standalone dashboard installation.

On the IIS Server that is to host the Dashboard website, from an elevated command prompt, run the following command line (Case Sensitive):

msiexec /i StifleR.Installer64.msi CABSOURCE=C:\Temp\License.cab /qn ADDLOCAL=DashboardFeature

Beacon Server Installation

Similar to the Dashboard installation. Command Line install (Case Sensitive):

msiexec /i StifleR.Installer64.msi CABSOURCE=C:\Temp\License.cab /qn ADDLOCAL=BeaconFeature

StifleR Client Installation

Pre-requisites

• Windows 7 SP1 or later

• Supported are x86 or x64 versions of the operating systems

  • Professional, Enterprise or Ultimate versions

  • Newer Educational SKU is also supported

• Microsoft .NET 4.6.2 must be installed on the client

The client is a .NET 4.6.2 executable with some C++ helper DLLs. It will run on any operating system that is capable of running .NET 4.6.2 . This includes most operating systems from Windows 7 and above with the exceptions of Home and other consumer versions of Windows.

Client Modes

As explained in the ”Planning your StifleR implementation” section, the StifleR Client can be installed in one of two modes;

• Windows Service Based Mode – always connected to the StifleR Server, running as a Windows Service - Recommended

• Read Only – Reporting only

StifleRulez.xml File Update

As a part of the Server installation you may have set up a virtual directory so that the clients can download the rules definition XML from a configured internal URL. If you leave the default setting and the clients will default to use the StifleRulex.xml file which is stored on the 2Pint website. In this case they would require internet access.

In all cases you will still need to configure the UpdateRulesTimerInSec value as this is set to “0” (disabled) by default.

Manual Installation

From an elevated command prompt launch the client installation .MSI.

Automated Installation

Installation is preferably performed using the MSI file with command line parameters.

For example:

To install the StifleR Client with default settings, in Windows Service Based Mode with a single StifleR server defined , and the URL for the StifleR rules XML download you would run the following command line from an elevated command prompt:

The following table shows the available MSI properties, switches, options and defaults.

Default Basic Automation

StifleR automatically ‘learns’ about networks as the StifleR clients connect and report data to the server. The Server builds up a list of subnets with a default bandwidth limit set for each new one that is discovered. This information is stored in the StifleR Database file which is stored in the StifleR Server program data folder.

Manual Configuration

To manually “pre-configure” the StifleR Network Infrastructure you can load all of your network information into StifleR prior to deploying any clients. This can be achieved via automation through PowerShell/WMI scripting etc,.

Intelligent Automation of Location and Subnet Configuration

As mentioned above, in the default process, when a StifleR Client reports in from a subnet that does not exist, a new subnet is automatically created with default parameters applied.

There is however a much more intelligent method that uses PowerShell scripting to Generate and then Modify settings for these newly discovered locations. This feature is enabled within the StifleR.Service.exe.config file using the following parameters:

Generate New Location with PowerShell

• Enable key

<add key="GenerateNewLocationsWithPowerShell" value="0"/>

• Default path to the script for PS Generation of Sites

This first option is the most commonly used, as it allows you to set a default ‘template’ for a new subnet according to your preferences. For instance, the overall default Target Bandwidth for a new location may be 1024Mb/s, and you may want to set this to be higher (or lower).

PowerShell can generate any parameter for a new subnet and logic can be used to determine different settings depending on the incoming criteria (subnet, IP Address Range, Physical Location, Computer Name etc)

If the GenerateNewLocationsWithPowerShell setting is enabled, the script identified in the PowerShellExtensionLocationCreateScriptPath is executed as soon as a Client reports in a new subnet.

A basic script is as follows:

Once this data is returned you can then write some new data back to the new subnet

The new subnet must have a unique GUID

Once you have a way to identify the subnet you can edit configuration options. In the following snippet we set a Target Bandwidth of 4096 and setup the Delivery Optimization policy so that the clients in that subnet will only Peer within that subnet.

Finally, we write the new subnet – job done!

return $Location

Modify New Location with Powershell

• Enable Key:

• Default path to script for PS modification

This option is similar to the Generate function but allows you to Modify a subnet once is has been created. This enables you to have your Generate script set some defaults for new subnets and then let the Modify script change some further parameters depending on other criteria.

If the ModifyNewLocationsWithPowerShell setting is enabled, the script identified in PowerShellExtensionLocationModifyScriptPath is executed as soon as a new subnet has been created

A basic script is as follows:

Once we have the new location we can do some lookups, for example examine the IPAddress and set a new target bandwidth based on the Address Range – being in PowerShell land the sky is the limit! Here’s some pseudo code to give you an idea:

If subnet starts with 192 – then target bandwidth should be 10Mb

If subnet starts with 10 – then target bandwidth should be 2Mb

Locations

Once subnets are known to StifleR you can then group local subnets together in Parent/Child relationships to form Locations. You can then use these Locations to control Bandwidth usage for the multiple subnets or VLANs as a single administrative unit. As part of your StifleR infrastructure planning you should gather as much information as you can regarding your geographic locations and associated WAN/LAN configurations, speed etc and then group your subnets into StifleR Locations as required. Please feel free to contact us for recommendations in this regard. This process can be automated as above.

Subnets

A subnet is an IPv4 network range that is calculated by the client using the IP Gateway and Subnet information from the network interface used to access the source data.

The correct adapter and path to use are calculated using the Windows API’s. StifleR is able to identify which gateway is the best one to use in order to access the data. StifleR is then able to calculate the subnet based on the first IP address configured on the adapter which is in the same network segment as the gateway that the client is configured to use. The reason for this complexity is that Issues arise as a NIC can have multiple IP addresses on different subnets. Confused? The following may help:

Consider a client machine that has both a Wireless 3G Card and a Cable plugged into a physical Ethernet Port. StifleR provides Windows with the IP address of the source host, and Windows returns the best interface to access the data. An inquiry is then made on that interface which is the best route (gateway) to the source. The best gateway that should be used to access the source data is then returned,. We then iterate through all the available IP Addresses on that interface and identify the first one that has the gateway set to the same as that previously identified. This is then used to calculate the network ID using the IP address and the subnet information. This is the network segment ID that is then send up to the StifleR Server. This should be the correct network ID to use, unless the network segment is broken and clients have switched over to 3G connections or other data networks.

Locations

A Location in StifleR management and configuration terms is a physical site that consists of two or more subnets that should be managed as a single entity for the purpose of bandwidth control. These subnets can be defined in many different ways, as VLAN tagging or just a different subnet network IDs. The concept of a Location is then used to group together those subnets into a single management unit. Typical use case would be a remote Location that has several network segments that are logically best managed together due to the fact that they share the same WAN connectivity back to the main Location where the source servers are located.

Creating a Location is as simple as linking together two or more network segments (subnets). This creates a Parent-Child relationship where the Parent subnet string is the identifying item for the Location.

A Location can be used as an administrative container to set a bandwidth limit for an entire remote site. Rather than having to set limits per subnet you can set a limit for all segments that share the same network infrastructure and WAN connection. These settings are configured via the ParentLocation class in WMI. StifleR will calculate the portion of bandwidth for each active Red Leader to use at any time according to the number of active Red Leaders in each Location. For example, if you have 3 network segments at a location but only 2 are actively downloading, the total allowed bandwidth for the Location will be split 50/50 between the two active segments. If another segment becomes active then each would receive 1/3 of the configured bandwidth for that location.

Without Locations configured the Server effectively treats each subnet as a Location which leads to each separate Red Leader trying to use the full link bandwidth.

StifleR Enterprise Locations

In StifleR Enterprise each subnet not only has a Red leader assigned for each subnet, but StifleR also assigns a Blue Leader for each subnet. The Blue Leaders are able to facilitate BranchCache data to be shared across segment boundaries which further greatly reduces WAN traffic.

Delivery Optimization Groups

DO groups are set up through WMI by grouping clients together using the DO Group ID. You can set this using a generated GUID (PowerShell can do this for you) or you could use the Location IDs that you are already using in StifleR (these will be unique in your environment). StifleR will check to see if the client is DO capable (Windows Build 14393/Version 1607 and above), DO enabled (Download mode is not set to ”0”) and then check if a DO Group ID is present in the LocationData.xml file. Once StifleR has all of this information DO group membership can be ascertained and the DO group is then managed in the same manner as a location. Note that as the DO group is meant to be well connected and used specifically for P2P file sharing there is no Blue Leader functionality as all members should be local.

Parent/Child and Location/Subnet Structure

As mentioned in the Location segment above, several subnets can be bundled together into a single Location. This creates a many to one relationship between the Child subnet(s) and the Parent subnet. A Parent Location cannot (currently) be set to be a Child of another Location, which logically means that a Child cannot be made Parent for another Location. The “Parent” is simply used for management identification purposes. The Parent subnet is treated equally in all respects to any Child subnets at the Location.

It is suggested for logical tracking purposes that the lowest network ID be set as the Parent network ID. For instance: 10.1.1.0 should be configured as the Parent for 10.1.2.0 and 10.1.3.0.

As an example, we have three network segments, each a standard C class network with a 24 bit subnet mask:

Subnet A: 192.168.1.0/24

Subnet B: 192.168.2.0/24

Subnet C: 192.168.3.0/24

Once you configure Network A to be the Parent of Network B and C the following Location structure would be created:

• Parent: Subnet A – 192.168.1.0

  • Child: Subnet B – 192.168.2.0

  • Child: Subnet C – 192.168.3.0

Typically, most configuration is still performed on a per subnet basis, and only a few changes are performed on the Location level, primarily the Target Bandwidth setting for the location. In the example above you would set a Target Bandwidth limit of 4096Kbits/s for the Location by setting the a limit on Subnet A (the Parent Subnet and therefore the Location Identifier for management purposes) StifleR will then dynamically apportion the bandwidth for each active Red Leader. If there is an active download current in each Subnet the StifleR Server service would automatically calculate and set a Target Bandwidth of 1365 (4096 / 3) for each of the Red Leaders at that location.

Overview

To support BranchCache across subnets, StifleR is using the Blue Leader feature that is enabled by default when connecting multiple subnets together to form a location. Here are some troubleshooting tips.

Note: For the Blue Leader threads to start, you need to have at least 2 subnets linked in a location, and you need to have at least two active clients on each subnet. The subnets also have to be configured for Low Bandwidth, subnets set to Well Connected are not supported for the Blue Leader feature. Until these requirements are met, there is no visibility in the Blue Leader logs.

Blue Leader Troubleshooting Checklist

1. Make sure the Blue Leader firewall ports are opened. If you are using TCP 1337 for BranchCache, the Blue Leader port will be TCP 1338. You also need UDP 3703-3705 open in addition to the default UDP 3702 port for BranchCache

2. Make sure the subnets are configured for Low Bandwidth, and linked together via the Location feature in StifleR.

3. Make sure there are at least two active clients on each subnet.

4. For BranchCache OSD support across subnets, the WinPE Firewall must be disabled after the BCEnabler action has run. Add a run command line action that runs: wpeutil disablefirewall

Intra-VLAN Transfer Logs and flow

The same flow can go bi-directional at any given time, i.e. the diagram below show traffic that is requested in Subnet A from Subnet B, but at the same time Subnet B can be requesting the same (or other traffic from Subnet A).

Verification methods

Verify that the clients are working, on the blue leaders, verify that the ports have been bound OK by running the following command:

Netstat -aon | findstr / ":3703"

That should return a line with the PID as the last entry. Then that PID entry can be used to verify the rest of the ports:

The value of 8824 indicates the PID in this example, so we can use that query all the ports used with the following, similar command:

You can also query the other ports as per the first way:

Then we want to make sure that the port used to proxy the HTTP traffic is bound OK by the HTTP.SYS, in order to do this we need to run the following command:

Netstat -aon | findstr / ":1338"

Where 1338 is the default port used to bridge BranchCache traffic in StifleR.

The following result indicates that the HTTP server has crashed and not recovered, as no port is bound:

This can be the case, even though the UDP ports are bound. StifleR client 1.9.8 and upwards deals with this in a better way and this scenario should not happen.

The result should look like this:

Detection of traffic

It can be hard to troubleshoot this, but on the client that requests the data, you should see connections to Blue Leader that is in the same subnet as the requesting client, the following command will list all connections if run on the requesting client:

Netstat -aon | findstr / ":1338"

The should then return one or several entries pointing to the Blue Leader.

Which port is BranchCache operating on?

You need to both set the URL acl as well as set the right registry value.

netsh http show urlacl | findstr /i "0131501b-d67f-491b-9a40-c4bf27bcb4d4"

Hosted Cache mode settings

Set in the following location: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerDist\HostedCache\Connection

Reg_Dword ConnectPort and ListenToPort

This section explains the configuration options available for Bandwidth monitoring and how the limits set are then used to adjust parameters for maximum download performance. With each of these detection methods, when an override happens, a warning will be written to the Event Log.

Bandwidth Tuning is turned on and overall site settings configured on the Server through the StifelR.Service.exe.config file. This file also contains the parameters that govern the various site wide settings that control the monitoring intervals and the tuning adjustment values. Please refer to the StifleR Server Settings Knowledge Base article for a full explanation of the settings available in this file.

StifleR can manage the bandwidth usage based on throughput, either too little or too much being used and adjust settings accordingly.

These are enabled on a Location (WMI) by setting the BandwidthTuning property, which sets what is to be monitored, the Latency Threshold value which sets when Tuning should be used and the TargetBandwidth value which is the sweet spot for the link.

The following BandwidthTuning options are available:

• Latency

• LowBandwidth

• HighBandwidth

• LEDBAT

• MeasureBandwidth

StifleR can monitor and adjust a number of bandwidth related metrics. The bandwidth management system uses a bit flag system so multiple detectors can be used at the same time. i.e. a value of BandwidthTuning that equals 5 enables 1 and 4 but disables item 2 (see below). The server has flags defined it the actual code of the product as follows:

Latency = 1, 
LowBandwidth = 2, 
HighBandwidth = 4, 
LEDBAT = 8  
Measure Bandwidth = 16 

Therefore the value of 7 in the Server StifleRService.exe.config file:

<add key="BandwidthTuning" value="7" />

Enables the following tuning capabilities on the server (site wide): Latency (1) + LowBandwidth (2) + HighBandwidth (4) = 1+ 2+ 4 = 7.

If you wanted to only use Latency and HighBandwidth monitoring for the site you would set 1+4 = 5.

The same values are used to enable these settings per subnet and are set on the subnets object.

Latency Detection (BandwidthTuning = 1)

This configuration determines latency to the target server using a simple ICMP Ping. The round trip time is recorded and stored which can then be used to calculate the average latency for ongoing comparison.

To use the feature it must be enabled on the Server in the StifleRService.exe.config file (On by default) and then set the Bandwidth tuning Detection flag and LatencyThreshold value for each Subnet that you want to control.

Low Bandwidth Usage Detection (BandwidthTuning = 2)

This detects if the bandwidth being used is lower than a set value

To use the feature it must be enabled on the Server in the StifleRService.exe.config file (On by default) and then set the Bandwidth tuning Detection flag and LowBandwidthThreshold value for a Location that you want to control.

If this occurs without the latency detection being triggered, it’s most likely a configuration issue, server throttling or other QoS policy in place that artificially limits the allowed bandwidth.

BITS has a tendency to be overly cautious on how much bandwidth can be consumed. Please note that it is recommended that this feature be fully tested before use in production as it can consume excess bandwidth unless tightly monitored and controlled.

High Bandwidth Usage Detection (BandwidthTuning = 4)

This feature allows you to detect if the bandwidth being used by BITS is greater than the configured values. The reason for this violation would typically be due to a failure in assigning the desired BITS policy, or an issue with the BITS policy on its own. This may happen for a number of reasons.

• Conflicting GPO settings e.g. Active Directory/Policy differences

• Invalid security settings (StifleR client not running as Admin or System)

• BITS policy corruption

• BITS bugs due to inconsistent hotfixes

To use the feature it must be enabled on the server in the StifleRService.exe.config file (On by default) and then set the Bandwidth tuning Detection flag and HighBandwidthThreshold value for the Locations at which you want to use the feature.

LEDBAT (BandwidthTuning=8)

Low Extra Delay Background Transport (LEDBaT) is a way to transfer data in the background quickly, and without clogging the network. In order to control LEDBAT settings through StifleR you need to set this flag on the server and then make the configuration changes covered in the next section.

StifleR LEDBAT Configuration

StifleR lets you set a higher/different TargetBandwidth policy when LEDBAT is in play. LEDBAT itself ensures that only available bandwidth is used and if other traffic comes along BITS will automatically back off. True auto-throttling in action!

Setting up LEDBAT++ with Content Distribution

1. Enable LEDBAT++ on the content server that will be serving the BITS content (SCCM Distribution Point for example)

2. Set up the LEDBATTargetBandwidth (WMI) for a location/subnet in StifleR (This can be set in the Location Details dashboard or via WMI/PowerShell) swmi -path 'root\Stifler:Subnets.subnetID="192.168.4.0"' -Arguments @{LEDBATTargetBandwidth = 20480}

3. Set an IIS custom header to “LEDBAT:true” on the LEDBAT enabled Content Server. (see How to add a custom HTTP response header to a Web site that is hosted by IIS ) The custom header is picked up by StifleR on the client

4. If LEDBAT is detected on the client, then StifleR will use LEDBATTargetBandwidth value for that location that has been set on the Server

5. The higher LEDBATTargetBandwidth value is then set as that job has the LEDBAT: true header

6. If a different (non-LEDBAT aware) job starts, then StifleR will set the regular TargetBandwidth for the location

7. LEDBAT then takes care of the Throttling, and BITS runs at MAX of LEDBATTargetBandwidth

Bandwidth Measurement – Beacon Server (BandwidthTuning=16)

With this bit set it is possible to specify a Percentage of Maximum Bandwidth for a location/subnet as opposed to a hard limit (Target Bandwidth). It is important to note that this is a percentage of the Maximum measured download Bandwidth for that location. This value is automatically calculated by the StifleR client agent or may be set manually if required. (MaxBandwidthDownstream)

Once this value is set, a second value, PercentOfMaxDownstream is used to set limits for the Red Leader of that subnet/location.

How is it calculated?

The best (and most accurate) way of working out the bandwidth between two points is to send some content up to a location and record how long it takes. This involves some fancy footwork on the client-side which communicates with the StifleR Beacon Server component. In order to achieve this measurement we use the Open Source iperf tool - https://iperf.fr/ - which is ideally suited for this measurement.

Beacon Server Component

The server-side component (iperf3.exe) can run on any (modern) Windows OS (talk to us if you want to run it on Linux) It acts as the end point to which the StifleR Client Red Leaders send test packets. This allows the Red Leaders to determine the maximum bandwidth available between the a Subnet/Location and the content source. Typically, you will install this component on a server in a central location (such as an SCCM Distribution Point) from which your clients obtain the bulk of their content. If you have a central data center for instance you can simply install the StifleR Beacon service onto any server at that location. The StifleR Beacon Service may be installed on the StifleR Server if required but there is no dependency on this configuration.

Client Component

The client initiates the transfer of known chunks of content up to the StifleR Beacon Server and back again. This enables StifleR to build up an accurate picture of the maximum bandwidth (both up and down) that is available at that location. That data is then stored with the subnet information on the server.

• This function only runs on the Red Leader at a location

• It is run at service startup on the first Red Leader at a new location

• It is then run periodically to test and update the setting at various times on a schedule (every six days subject to some other conditions)

Only increases in bandwidth are reported as it’s the Maximum Download Bandwidth that needs to be determined. i.e if the first client at a location measures that bandwidth to be 5Mbit then that will be set as the Maximum Download Bandwidth. If the client then runs a new test and determines that the bandwidth available is now 10Mbit then the Maximum Download Bandwidth will be increased to that value. If a third test is performed at that location and returns a bandwidth of only 8Mbit (the network may be busy for instance), nothing will change.

Once the Maximum Download Bandwidth is determined and set for that subnet, the second property comes into play – namely the PercentOfMaxDownstream parameter. For example, if the Maximum Download Bandwidth is calculated to be 10Mbs and the PercentOfMaxDownstream parameter is set at 50%, then the Target Bandwidth for that subnet is adjusted to 5Mbs.

Beacon Server Setup and Configuration

Client

The client needs to be configured with the Beacon Server address and and optional custom port number (port number only needed when using a different port than default). The Beacon Server Address is simply the FQDN or IP Address of the Beacon server to which the StifleR Client will connect.

The client gets the beacon server configuration from it's subnet, and this is set per subnet using the BeaconAddress parameter in WMI. The beacon address can be hostname:port or just hostname, in which case the default port of 5201 is used. The beacon address can be set via WMIC or PowerShell on the subnet(s).

Configure the Beacon Server for a single subnet using WMIC:

wmic /namespace:\\root\stifler path Subnets.SubnetId="w.x.y.z" set BeaconAddress="BeaconServerFQDN"

Configure the Beacon Server for a single subnet using PowerShell:

$BeaconAddress = "BeaconServerFQDN"
$Subnet = Get-WmiObject -namespace root\StifleR -Class "Subnets" -Filter "SubnetID='x.w.y.z'"
Set-WmiInstance -Path $Subnet.path -Arguments @{BeaconAddress=$BeaconAddress} 

Configure the Beacon Server for all subnets using PowerShell:

$alllocs = @(Get-WmiObject -Namespace root\StifleR -Query "Select * from Subnets") 
foreach ($loc in $alllocs)
{
$BeaconAddress = "BeaconServerFQDN"
Set-WmiInstance -Path $loc.path -Arguments @{BeaconAddress=$BeaconAddress} 
}

Forcing a Beacon measurement

For testing purposes you can use the UpdateMaxBandwidth WMI method to force a client to update the MaxBandwidthDownStream property, which in will turn update the target bandwidth for that subnet.

Forcing an update using WMIC:

wmic /namespace:\\root\stifler path Subnets.SubnetId="w.x.y.z" call UpdateMaxbandwidth

Forcing an update using PowerShell:

$Subnet = Get-WmiObject -namespace root\StifleR -Class "Subnets" -Filter "SubnetID='192.168.26.0'"
Invoke-WmiMethod -Path $Subnet.__PATH -Name UpdateMaxBandwidth

Server Configuration

The fifth bit must be set (16 (Decimal) = EstimateMaxBandwidth) in the StifleR.Service.exe.config file on the server. If you are already using other Bandwidth Tuning methods (and you wish to keep using them) then you must add this value to the existing setting.

<add key="BandwidthTuning" value="16"/>

Set using WMIC for a single subnet:

wmic /namespace:\\root\stifler path Subnets.SubnetId="w.x.y.z" set BandwidthTuning="16"

Or PowerShell (this example sets the BandwidthTuning bitflag for all locations)

$alllocs = @(gwmi -namespace root\StifleR -Query "Select * from Subnets")
foreach ($loc in $alllocs)
{
$BandwidthTuning = 16
swmi -path $loc.path -Arguments @{BandwidthTuning=$BandwidthTuning}
}

Logging

In order to enable Beacon Server Service logging set the following key to a value of “1” in the StifleR.Service.Beacon.exe.config file:

<add key="EnableDebugLog" value="1" />

The Service Logs are written by default to “%PROGRAMDATA%\2Pint Software\StifleR\BeaconLogs”

The iPerf executable logs to the “%PROGRAMDATA%\2Pint Software\StifleR” folder.

NOTES:

• Does not run at ‘Well Connected’ locations

• Does not run at VPN locations

• Does not run on Roaming Clients

Latency Auto-Tuning Management (No Beacon Server)

StifleR can be configured to auto adjust the download speed depending on latency from the Client to the StifleR server OR the download source. If the source is Internal (i.e. on a private network) the source will be used for latency calculations. If the source is External, i.e. the Internet, the StifleR server will be used for Latency calculations.

Sample WMI Commands to Enable Auto Latency Tuning

The following WMI Command will set the TargetBandwidth to 700 Kbit/s, enable the Latency monitoring flag in BandwidthTuning and set the latency threshold to 70 milliseconds for the subnet 192.168.138.0.

wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set TargetBandwidth=700 wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set BandwidthTuning=1 wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set LatencyThreshold=70

The above commands will achieve the following;

• Set a TargetBandwidth of 700

  • Typically, all subnets have a TargetBandwidth value set as this is how StifleR knows how much bandwidth each Subnet or Location is allowed to use

• Enable the first option of bandwidth management

  • The BandwidthTuning is a bit flag. Setting it to 1 enables the first option, Latency. Setting it to 3 would enable the first (1) and the second (2) options etc. Setting the first and third options would be done by setting the value to 5 (1 + 4). Note, this doesn’t actually turn on the tuning itself, as we need a value to tune against first

• The last action is to set the value to tune against

  • In this case it is set to 70msec. If the latency to this Location exceeds 70msec StifleR will lower the bandwidth or if it drops below this threshold then StifleR will try to increase usage

Bandwidth Tuning Adjustment options

The information above is mainly related to how to actually turn on the various Bandwidth Tuning options and set the target counters to maximize network performance. The StifleRService.exe.config file also contains a number of configuration options to control how aggressively the tuning is controlled and changes to bandwidth usage applied.

There is a full list of the options with notes available on the 2Pint Support Knowledge Base - StifleR Server Settings – but for this section we shall discuss one example – Latency.

<add key="LatencyWarningDecreaseDuration" value="10000" />
How long before we lower the bandwidth
10000 will lower the bandwidth if latency is over Threshold for this period.  
Default 10sec = 10000 msec

<add key="LatencyWarningDecreaseFactor" value="1.4" />
When we lower bandwidth, how much do we lower it by? 
TargetBandwidth / 1.4 = 40% decrease per interation.

<add key="LatencyWarningIncreaseDuration" value="10000" /> 
If we are below the level, how long before we increase BW again.  
Default 10sec = 10000 msec.

<add key="LatencyWarningIncreaseFactor" value="5" />
When we increase BW, how aggressive are we?
TunedBandwidth = TunedBandwidth + (TargetBandwidth / LatencyWarningIncreaseFactor)

Therefore, if the Tuned Bandwidth is 500 Kbit/s and the target Bandwidth is 2000 Kbit/s StifleR would increase the Bandwidth by 2000 / 5 = 400, so the new TunedBandwidth figure would be 900Kbit/s with a new increase each 10sec by default

Latency will be measured and adjustment made every 10 second period by default. Should the Latency fall below or above the target level set for the Location, Bandwidth usage will be adjusted up or down according to the Increase/Decrease factors in order to bring things back into tolerance.

WMI Events on Thresholds

StifleR Creates events in WMI for the following items:

1. Latency Threshold Exceeded

2. Latency Threshold Resumed

3. High Bandwidth Threshold Exceeded

4. Low Bandwidth Threshold Exceeded

The StifleR Server(s) needs regular maintenance like any other critical infrastructure to function effectively and continuously. In this section you find an operations guide that the sysadmin or operations team can follow to maintain a StifleR Environment. The guide is divided in to daily, weekly, monthly, and quarterly operation tasks.

In general the tasks described in these documents should be implemented into whatever ticketing system that is being used, such as Service Now, Remedy or Zendesk.

Daily Maintenance Tasks

1. Verify that the nightly backup was successful

2. Check free disk space on all volumes on the StifleR Server (s)

3. Review the StifleR Server Event log

4. Review the StifleR Resource Manager log (if implemented)

Weekly Maintenance Tasks

1. Review all daily tasks

2. Review and disk space usage on the StifleR Server(s), and compare to previous week to see trends etc.

3. Verify that networks haven’t changed (boundaries etc.)

Monthly Maintenance Tasks

To be added, but these are for preparing for upgrades, and to establish long term trends. Usually scheduled meetings with workplace managers and other team members.

Quarterly to semi-annual Maintenance Tasks

1. Review the security plan for any needed changes

2. Change accounts and passwords if necessary according to your security plan

3. Review the maintenance schedule for upgrades to the StifleR platform

4. Check StifleR performance to ensure changes have not been made that affect operations

5. Review the disaster recovery plan for any needed changes

6. Perform a site recovery according to the disaster recovery plan in a test lab

There are several versions of StifleR, building up additional capabilities with each more advanced edition.

At present the following editions exists;

• StifleR Visualizer (Read Only)

• StifleR Standard

• StifleR Enterprise

Read more about the different capabilities below.

StifleR Standard Features

• Data Visualization – Dashboards! which give you a rich source of live data from the Enterprise level overview down to an individual machine

• Administrative Security through the Global Administrators, Global Dashboard Administrators and Read Only Administrators groups

• GUI management controls within the Dashboards

• Scripting with WMI – Power at your fingertips

• Windows Event log logging - Use Event logging to trigger PowerShell scripts to automate your control

• WMI Events – Event Logs not doing it for you? Take things to the next level and unleash the power

• Multi Servers – Redundancy and disaster recovery

• Server Client Reconnect Instruction – Your clients can be pointed at a new StifleR server in an instance

• BITS Control – Centrally Configure and Automate BITS job control. StifleR clients will automatically classify each job in accordance with your centrally set policies and then apply the appropriate BITS Job Priority to each job as required

• BITS Job Management – Suspend, Resume, Cancel and Complete jobs as needed

• Delivery Optimization (DO) Job Control

• Notification System – Send pop up messages to your users – old school!

• Multi-Lane Downloads – Don’t stop – just slow down!

• Red Leader Selection – You don’t want certain machines to become Leader machines – identify them as such and they will remain unassigned

Data Visualization

Data is gathered from StifleR clients and the information presented to Administrators in a number of dashboards which allow drill down from an Enterprise overview to the individual Client or Job.

Please note that it is not difficult to create custom dashboards and link to other Dashboards however instruction for this is beyond the scope of this current document. If you are interested in dashboards customization then please contact support@2pintsoftware.com and we will be happy to give you advice in this regard.

A drop down navigation list is accessed through the matrix button on the top left hand side.

From here you can access the many other dashboards which give you full visibility over your network from various high level views with granular drill down to locations, subnets and individual clients.

Main Statistics Dashboard

Here, by way of example, is a screen shot of the Main Statistics Dashboard giving you an instant overview of what’s been happening in your Enterprise over the past 15mins, Hour and day.

Dashboards Main Menu Overview

Briefly, the menu items link to the following high level pages. Most high level overview page allows drill down for further information, investigation and analysis.

Scripting with WMI

StifleR allows for great scripting capabilities. Use PowerShell or WMIC to connect to the Root\StifleR WMI namespace.

As an example – Here’s how to check the WMI Provider with PowerShell:Invoke-WmiMethod -Namespace root\StifleR -Path StifleREngine -Name TestFunction

Windows Event log Logging

StifleR reports crucial events as Windows Event log items. You may use these to trigger scripts for certain actions.

WMI Events

WMI Events are triggered for certain events. You can use these triggers for active scripting rather than Event log items as the performance scope is greater.

Multi Servers

StifleR supports a multi StifleR server environment to provide failover backup. The multiple Servers details are entered during the StifleR client installation and appear in the StifleR.ClientApp.exe.config file under the StifleRServers string. They are processed sequentially.

This feature can be used in a maintenance scenario where you can switch clients over to the next configured Server and functionality will continue uninterrupted.

Server Client Reconnect Instruction

The Server can instruct the Clients to connect to an alternate server if required.

BITS Control - StifleRulez.xml

Auto Adjustment of BITS Jobs

StifleR uses the StifleRulez.xml to determine the priority of the BITS jobs. This determination is made locally on the Client without any involvement from the StifleR server. The StifleR server can be used to send out a new version of the StifleRulez.xml file with updated parameters and rules which sets new priorities according to enterprise demands. Each client holds a copy of this XML file which is embedded in the client installation MSI.

Administrators can define and configure their own rules according to the following structure.

A rule is matched to the job that you want to control using different matching verbs. Once a download has been matched, it is then linked to a StifleR download type. The processing order is:

• The BITS job name is matched and assigned a Job type

• The Job type is then associated with a Download Type, against which the BITS priority is set

Rules are processed in the top down order of the <TypeData> TypeID nodes and stops at the first match that evaluates to true according to the matching rules. The TypeID is then matched in the top <DownloadTypes> section and the Download Priority set accordingly.

A sample basic StifleRulez.xml rule file is shown below.

Figure 16 A sample default StifleRulez.xml rule file

Example: A job with the display name of “SkypeUpdate” will be linked to the Download Priority TypeID of 3, which sets the BITS job to “3”- low priority.

You can have as many rules as you want, matching as many Download Types as you need, but keep in mind that the first matching hit will be used. In order to test and track this ensure that debug logging is enabled on the clients during your testing.

StifleR BITS Priority Values

The following BITS Priority values are applied according to the Download Priority values shown above:

These priority values also appear in the dashboards.

Auto BITS Job Classification

Issues can arise where, for instance, some BITS jobs are created using only a GUID ID as the name, making it hard for an administrator to classify the job. StifleR solves this by looking at the URL of the files in the Job. It can also apply rules according to the BITS Job name, descriptions, URL or other BITS job information. With Windows 10 the PID (Process ID) creating the job is also tracked, providing additional capabilities to classify the download.

StifleR Rules Match Parameters

The following syntax can be used with the rules file, the DisplayName of the job is used on some matching and some of them uses the URL of the current file. Other rules uses the jobs progress data. No rule is case sensitive.

AutoUpdating StifleR Prioritization Rules

The Server can instruct Clients to download a new version of the StifleRulez file. This can also be done on a scheduled timer, creating a BITS job to download the source of the rules from either Internet or a corporate URL.

The client tries to update the file on simple schedule controlled by the UpdateRulesTimerInSec key value in the StifleR.ClientApp.exe.config file. By default this is set to a value of 604800 which is once a week. Set this to 0 to disable this feature.

BITS Job Management

The StifleR Server can instruct clients to Resume, Suspend, Cancel, Complete BITS jobs. You can filter jobs on Names or StifleR priority classifications defined in the StifleR rules file.

The job modification is achieved through calling the ModifyJobs method on the StifleREngine class :wmic /namespace:\\root\stifler path StifleREngine call ModifyJobs /? Call

The “action” parameter can be configured as one of the following (same as BITS) values: Suspend, Resume, Cancel or Complete.

Action

The action parameter determines what we want to do with the job.

Action: SUSPEND - Suspends the Job

Suspends a job, i.e. Stops it until RESUME action is received. If a resume command is not received for a manually suspended job then the job will remain suspended until it is cancelled after 90 days (default JobInactivityTimeout Group Policy). New jobs, jobs that are in error, and jobs that have finished transferring files are automatically suspended. The state of the job cannot be

BG_JOB_STATE_CANCELLED or BG_JOB_STATE_ACKNOWLEDGED

Action: RESUME - Resumes the Job

Activates a new job or restarts a job that has been suspended.

When you create a job, the job is initially suspended. If you are using StifleR to create jobs, they are auto resumed after creation. That does not mean transfer starts though, as their might be other jobs in the queue. After calling Resume BITS moves the job from the suspended state to the queued state. The job stays in the queued state until the scheduler determines it is the job's turn to transfer files. Note that the job must contain one or more files before calling this Method.

If a job that is in the BG_JOB_STATE_TRANSIENT_ERROR or BG_JOB_STATE_ERROR state, call the Resume Method to restart the job after you fix the error.

Action: CANCEL - Cancels the Job

Deletes the job from the transfer queue and removes related temporary files from the client (downloads) and server (uploads).

You can cancel a job at any time; however, the job cannot be recovered after it is canceled.

For upload jobs, if the server is unavailable, there may be a delay before BITS deletes the job from the queue. BITS periodically sends a cancel request to the BITS server for up to 24 hours. If the server does not respond within the 24-hour period, BITS removes the job from the queue. If the no-progress time-out period is less than 24 hours, BITS uses the no-progress time-out period to limit the retries.

Action: COMPLETE - Completes the Job

Ends the job and saves the transferred files on the client. Important: If you are not using the default command line of the job, and using an override command line the job must complete before the files are available for use.

Download files are not available until you call the COMPLETE Method. Call the COMPLETE Method after BITS successfully transfers the files. The Method renames the temporary download files to their final destination names and removes the job from the queue. Note that BITS renames the temporary upload file when the server receives the last fragment, which is why download jobs require network connectivity and upload jobs do not.

All of the files have been successfully transferred if the job's state is BG_JOB_STATE_TRANSFERRED.

If you do not call the COMPLETE Method or the CANCEL Method within 90 days (default JobInactivityTimeout Group Policy), the service cancels the job. If the service cancels the job, the downloaded files and the reply file are not available to the client; job cancellation does not affect files that have been successfully uploaded.

BITS removes the job from the transfer queue if the HRESULT is S_OK or BG_S_PARTIAL_COMPLETE. The job remains in the transfer queue if BITS was unable to rename all of the temporary files. Files that were renamed successfully are available to the user. The job remains in the queue (the state is BG_JOB_STATE_TRANSFERRED) until the application is able to fix the problem and calls either the COMPLETE Method again or the CANCEL Method to cancel the job. To determine which files were not renamed for download jobs, run BITSAdmin or PowerShell on the affected client.

For download jobs, you can call the COMPLETE Method at any time during the transfer process; however, only files that were successfully transferred to the client before calling this Method are saved. For example, if you call the COMPLETE Method while BITS is processing the third of five files, only the first two files are saved.

For upload jobs, you can call the COMPLETE Method only when the job's state is BG_JOB_STATE_TRANSFERRED.

BITS does not guarantee the integrity of the transferred files against third-party intrusions. Clients can implement integrity checks to validate transferred files after calling the COMPLETE Method.

The owner of the file is the user who made the call. For example, if an administrator completes someone else's job, the administrator—not the owner of the job—owns the file.

Force

The force flag can be set to $true to take ownership of the job if it is not owned by StifleR. Typically, this does not need to be used.

Name

The name parameter can be used to determine the name of the job to stop.

Apart from the actual name you can also use parameters like:

Global Wildcard

If the name is set to * all jobs are modified.

Name Matching

If you use %myString% as the name it will stop any job that contains the “myString” string in the displayname.

Example:

Then we run the following command to Cancel all jobs containing the string "bepa":

Then we see the log entry that the client has removed the job.

If we then try to list it:

StifleRType

In the StifleRulez.xml file, BITS job Names are associated with a Job Type. Therefore this switch allows control over jobs according to this association. Use the name from the 'DownloadTypes' section of the Rules file for example:(Case sensitive)

<Download TypeID="213" StifleRPriority="2000" Name="CM Available Package" />

So the following PowerShell command will suspend ALL clients with a job type of CM Available Package

Invoke-WmiMethod -Namespace root\StifleR -Path StifleREngine.Id=1 -Name ModifyJobs -ArgumentList "Suspend", $true, *, "CM Available Package", "All"

Target

Which machines should run this?

ALL = All connected machines.

IPSubnet = All machines within a network segment.

GUID = The connection ID of an individual machine.

Notification System

StifleR can be used to notify any connected Client using Windows built in Notification system. This requires Client OS to be Windows 8 or later.

Multi-Lane Downloads

StifleR allows multiple downloads to happen at the same time. This is by default and is used since BranchCache can potentially transfer the entire job without affecting the WAN usage.

There is no server configuration item for this feature as it is controlled by the StifleRulez.config file on the client. Jobs with the same priority will run side by side.

Red Leader Selection

The only configuration that can be done here is to set the NotLeaderMaterial setting on clients that you don’t want to become Red Leaders. This can be scripted and used in combination of Client data like uptime etc.

Windows Management Instrumentation (WMI) is a Command and Control (C&C) infrastructure that is integrated within Windows. It provides three primary capabilities:

• Exposing state information regarding a configurable entity

• Invoking control methods on a configurable entity

• Publishing events from a configurable entity

These facilities are a complete instrumentation solution for any Windows application, and multiple system components expose information through the use of WMI providers. This information can be consumed from a multitude of languages and technologies by WMI consumers, using a standard query language (WQL).

The StifleR server interface for automation is a WMI Provider In practical terms this means the administrator uses a WMI interface to communicate and control the StifleR server component.

The primary advantage to using WMI in favour of other communication technologies that abound is that WMI is a standardized C&C mechanism which can be consumed by numerous existing C&C frameworks. Most Windows components expose C&C information using WMI, and it is preferable that a single C&C framework is used instead of reinventing a C&C framework for each individual component. This makes a single C&C tool suitable for a variety of configurable and controllable entities.

Most automation of StifleR is done through the StifleR WMI Provider. This is present under the \\ROOT\StifleR WMI namespace on the StifleR server itself.

Updating Values

StifleR is a multithreaded asynchronous service, which means that the changes done through WMI cannot be guaranteed. A change might return the original value and not the changed value, so keep this in mind when scripting against StifleR. If the returned value does not match the value that you are attempting to write it has not been successful and will have to be retried.

After creating or making configuration changes, you should check to ensure that the value you to set has been changed to what is actually running. Some values are checked as part of the function to ensure that the change was successful and will return a failure if not. But some simple value changes have to be verified, as the underlying code runs asynchronously and on multiple threads in order to maximize performance.

The reason StifleR has been designed to work this way is because the internal workings are running on multiple threads asynchronously which may or may not have write access to the internal data structures at any given time. Rather than waiting for a lock to be lifted, using precious resources, the data is flushed to free resources. This allows StifleR to support an extreme large number of simultaneous connections.

For example, if you are trying to set the TargetBandwidth for a Location, make sure that there is a check for the running value after the Set command and make sure that the value has in fact been updated.

Listing Method and Instance Parameters

Using WMI with the CALL and GET /? parameters will give the following outputs:
C:\>wmic /namespace:\\root\stifler path StifleREngine CALL /?
Method execution operations.
USAGE:
CALL <method name> [<actual paramlist>]
NOTE: <actual paramlist> ::= <actual param> | <actual param>,  <actual paramlist> 
The following verb(s)/method(s) are available:

C:\Windows\system32>wmic /namespace:\root\stifler path StifleREngine GET /?
 Property get operations. 
USAGE: 
GET [<property list>] [<get switches>]
NOTE: <property list> ::= <property name> | <property name>,  <property list> 
The following properties are available:

Some properties will be listed as Operation “Write” which means you can use the SET verb to write to them. To find all items that allows Write, replace GET /? with SET /?.

An example how to use the SET operator

wmic /namespace:\\root\stifler path Subnets.SubnetID="192.168.90.44" SET Description=Test

Further Reading

There used to be a large section in this document devoted to WMI with screen shots and tables explaining each setting in detail. The good news is that this information still exists on the 2Pint Support KB site which you can view if you search for ”StifleR WMIC Command Line Tool”

The Blue Leader is a feature of StifleR Enterprise. On each Subnet the Red Leader is responsible for downloading the content across the WAN. On that and all the other subnets at the Location, Blue Leaders are automatically assigned. These Blue leaders are able to communicate with the other Leaders at the Location to facilitate the sharing of cached content between Peers across subnet boundaries at the local level.

A Blue Leader is basically a Red Leader (Assigned using the same selection process) but stripped of allowed WAN bandwidth consumption.

This feature requires Port 3703 (UDP) to be open for Multicast communication from Blue Leaders to

Clients on the local network segment. All leaders communicate with other leaders on ports 3704 and 3705 (UDP). Also check that the Microsoft BranchCache port is reachable and also the Blue Leader BranchCache port, which is typically assigned to the port one above the Microsoft BranchCache port number.

Blue Leaders do not generate V1 Content, only the Red Leaders make these hash calculations.

This document guides you through a backup and recovery of a StifleR Server.

Note: This document replaces the old we have in our knowledge base area.

Backup Operations

StifleR have several components that needs to be backed up in order to do a successful recovery if something happens to the server. The components are:

• StifleR Databases

• StifleR Configuration File

• StifleR License File

• StifleR Rules File

• Extra scripts

StifleR Databases

Backup of the five StifleR databases can be done either online or offline. The benefit of the online method is that you don’t have to stop the StifleR Server service during backup, but the downside is that it forces you to run a repair job of the database before they can be used in a restore. The offline backup method means stopping the StifleR service during backup, and then start it again after backup has completed. Benefits with this method is that you don’t have to repair the database before a restore.

The StifleR databases are using the Extensible Storage Engine (ESE) runtime in Windows (ESENT), and as such are often called ESENT databases. In addition to the core database files, the EDB files, ESE is also using recovery logs which are in the same folder as each database file.

By default, the databases are stored in C:\ProgramData\2Pint Software\StifleR\Server\Databases , and while the StifleR databases are not very big, we recommend storing them on data volume rather than the OS volume.

StifleR Configuration File

The StifleR Configuration File (StifleR.Service.exe.config) is located in the StifleR Server installation directory.

StifleR Rules File

The StifleR Rules File is often added to the C:\ProgramData\2Pint Software\StifleR\Rules folder, but can be in any folder as long as the IIS virtual directory knows where it is.

Extra Scripts

Additional custom scripts, like maintenance scripts, utility scripts, and generate location scripts should also be included in the daily backup.

Backup Maintenance Task

Backup Archiving

In addition to daily snapshots of the StifleR VM, or traditional daily file-level backup via your regular backup software, we recommend archiving at least a week worth of backup sets on a different server. The StifleR backups sets are quite small, rarely over 10 GB even in larger environments.

Client Behavior during Backup and Recovery

If the client cannot connect to server, due to networking roaming or other issues, the client will try to connect to the next server in the list. Failing to connect to a valid server eventually causes the client go into a disconnected state during which the bandwidth configure for disconnected mode will be applied. Once the StifleR Server has been restored, clients will automatically check in again, and go back to normal operations.

Recovery Operations

Restoring a StifleR Server is straight forward. If you have been using the offline backup, the restore process is a follow:

1. Make sure to install a new VM with the same server name, disk layout, and OS version

2. Install the version of StifleR you had before.

3. Stop the StifleR service, delete the empty databases, and restore the ones you have in your backup.

4. Restore the Configuration File

5. Restore the Rules file, and recreate the IIS virtual directory

6. Restore any additional scripts, and re-create scheduled tasks etc.

7. Start the StifleR service

For an online backup the process is quite similar

1. Make sure to install a new VM with the same server name, disk layout, and OS version

2. Install the version of StifleR you had before.

3. Stop the StifleR service, delete the empty databases, and restore the ones you have in your backup.

4. Repair the StifleR databases using esentutl /p

5. Restore the Configuration File

6. Restore the Rules file, and recreate the IIS virtual directory

7. Restore any additional scripts, and re-create scheduled tasks etc.

8. Start the StifleR service

Summary

The 2Pint StifleR Server, by default, stores its databases in the %ProgramData% folder which is typically located on the C: drive. In some cases, an admin might want to move the databases to another drive. The steps below describes the process of migrating the StifleR databases to another folder on the same server.

Procedure

1. On the server hosting the StifleR server, create a new folder where you would like to store the databases. In this example, the folder will be D:\StifleRDBs.

2. Stop the "2Pint Software StifleR Server" service.

3. Copy the folder structure from C:\ProgramData\2Pint Software\StifleR\Server\Databases to the folder created in step 1, Ex: D:\StifleRDBs.

4. To modify the configuration, you will need to edit the StifleR.Service.exe.config file. It is recommended to make a backup copy of the file before proceeding. The file is located in the installation directory in which StifleR was installed.

5. Open a text editor as administrator and edit the StifleR.Service.exe.config file.

6. In the .config file, under the <AppSettings> line, add the following:

7. Save the .config file and start the "2Pint Software StifleR Server" service.

8. Check the Event Viewer - Applications and Services Logs - StifleR and check for errors.

Verification

1. Open the StifleR Dashboard and verify that you can logon and verify that the data is available as expected, specifically your Networks.

2. If all looks well, feel free to delete the Databases folder under: C:\ProgramData\2Pint Software\StifleR\Server. If not, see the next section to Backout of the change.

Backout

1. If an error occurred and you need to restore the previous configuration. Stop the 2Pint Software StifleR Server service.

2. Restore the backup copy of the StifleR.Service.exe.config and start the 2Pint Software StifleR Server service.

In the last incarnation this document had swelled to a mighty tome and we had to slim it down. For that reason we have moved a lot of information over to the 2Pint Support pages. Head over to the KB page and search for the titles below for greater technical understanding of how it all works, best practices and product configuration options. No more Slow!

• Securing StifleR Operations using SSL

Essential best practice companion document that explains in detail how to secure communication channels in StifleR or, more specifically SignalR

• Securing StifleR Operations using SSL

Essential best practice companion document that explains in detail how to secure communication channels in StifleR or, more specifically SignalR.

• SignalR and Connection Management

All communication between clients/servers and dashboards are done via SignalR. Understanding SignalR is therefore key in understanding how StifleR works.

• StifleR Active Bandwidth Management Philosophy

This document gives some background on the thinking behind the StifleR solution and why it’s better than the other solutions that are out there, some of which what we’ve been involved with previously.

• StifleR Client Settings

A run through of available StifleR Client configuration settings with defaults and options.

• StifleR Server Settings

A run through of available StifleR Server configuration settings with defaults and options.

• StifleR Disaster Recovery

Some best practice for DR

• StifleR WMIC Command Line Tool

WMIC screenshots, dumps, examples and explanations. Unleash the power!

Introduction

The StifleR client prioritizes BITS and Windows 10 Delivery Optimization (DO) downloads by checking through its queue of active jobs and matching them against a locally held XML configuration file. This file contains a set of Administrator configured rules that define various download types and the priority that should be assigned to each.

It is also possible to assign ‘Auxiliary Bandwidth’ to a certain type (or types) of content which is in addition to the Target Bandwidth that is assigned to a subnet/location.

This allows you to configure the download priority, i.e. which type of download goes first, second, third etc. in the download queue, according to download type, as well as how much bandwidth is assigned to each of these specific download types. This allows the Administrator highly granular control over all content transfers.

The actual XML file is named StifleRulez.xml and is installed to:

%PROGRAMDATA%\2Pint Software\StifleR\Client

Process

A rule is matched to the download job that you want to control using different matching verbs. Once a download has been matched, it is then linked to a StifleR “download type”. The processing order is:

* The BITS/DO job name is matched and assigned a Job type.

* The Job type is then associated with a Download Type, against which the BITS/DO priority is set.

The StifleR client first needs to determine the ‘Type’ of download according to the rules within the XML. It starts at the top of the first section and works through the rules until it either has a match for the download type, or there are no matching criteria, in which case the download will be classed as ‘Unknown’.

Once a download type is found, (even if that type is ‘Unknown’), the client looks at the second section of the XML to find a match for that type of download which defines the settings for that transfer.

The first section of the file contains some version information. This can be useful if you are maintaining your own custom rules definitions, or in checking that you have the latest 2Pint version.

<StifleRData xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <VersionInfo>
    <Issuer>2Pint Software</Issuer>
    <Version>2.2.0.0</Version>
    <Date>07-06-2019</Date>
  </VersionInfo>

Match=

Next the <TypeData> section of the file is parsed, starting from the top. If there is a match, the search stops, so therefore it is important to enter the TypeData rules in the correct order. The rules need to identify a BITS Job by a certain attribute of that job, be it title, download URL or some other marker.

The XML file contains a number of ways to determine the type of download as follows:

Equals

These entries attempt to exactly match the title of a BITS/DO download. The comparison string in contained within the > <

<Type TypeID="215" Match="Equals" CCMDTSType="0">CCMDTS Job</Type>

In the example above, we know that all Microsoft ConfigMgr content downloads have a BITS job title of “CCMDTS Job”. More on ConfigMgr specifics later in this document.

Contains

If you only know part of the Job title you can use the ‘Contains’ verb to obtain a match.

<Type TypeID="109" Match="Contains">Microsoft Outlook Offline Address Book</Type>

This means that if the Job title includes the string contained within the > < (which in the case above is “Microsoft Outlook Offline Address Book”) a match will be made.

StartsWith

This checks if the display name of the job starts with the defined Value.

<Type TypeID="6" Match="StartsWith">Microsoft Outlook</Type>

The above rule would match “Microsoft Outlook Offline Address Book” but could also match “Microsoft Outlook Some other download” – which is why it is important to order your TypeID rules correctly.

Matching specific Configuration Manager download types can be a little complicated. We shall use the following XML file line as an example:

<Type TypeID="256" Match="Equals" WellConnected="0" UserInitiated="1" CCMDTSType="4" WinPE="1">CCMDTS Job</Type> <!--Task Sequence in WinPE : User Initiated Low Bandwidth -->

WellConnected="1"/”0”

Used to match for Well Connected sites

In our example WellConnected="0" is a match for a normal StifleR bandwidth-controlled site,

CCMDTSType=

Used to identify a specific type of ConfigMgr deployment

0 = Package/Program

4 = Task Sequence

5 = Software Update

8 = Application

In our example CCMDTSType="4" matches a ConfigMgr Task Sequence download.

UserInitiated="1"/”0”

Specifies whether the download job was started by a user (“1”) or not (“0”)

In the example UserInitiated="1" would only match ConfigMgr downloads which were triggered by the user.

WinPE="1"/”0”

Specifies if the download is coming from WinPE.

In our example WinPE="1" will only match if the download is running in WinPE

Putting all three of the above rules together we can see that this line will match to Task Sequence Download, initiated by the user, running in WinPE.

DownloadOnDemand="1"/”0”

Identifies Task Sequence download behavior

<Type TypeID="209" Match="Equals" DownloadOnDemand="1" CCMDTSType="4">CCMDTS Job</Type> <!--Task Sequence in Full OS : Required Deployment : Download on Demand -->

This rule will apply for a TS which has been set to Download Content as required rather than before execution of the Task Sequence ( CCMDTSType="4" )

Issues can arise where, for instance, some jobs are created using only a GUID ID as the name, making it hard for an administrator to classify the job. StifleR solves this by looking at the URL of the files within the job.

URLContains

This checks if the URL of the active file being downloaded contains the Value contained within the > < . Use this to track hostnames or even ConfigMgr package ID’s etc.

<Type TypeID="204" Match="URLContains">sms_pol</Type>

The above rule is used to match all ConfigMgr Policy Traffic as the URL always contains “sms_pol”

Internet="1"/”0”

This can be used to match a download whose source is a public IP address. StifleR Classes 192/172 and 10 subnets as internal and anything else as external.

“0” equates to a non-internet download.

<Type TypeID="303" Match="URLContains" Internet="1">adobe.com</Type>

This line will match any download with a URL containing “adobe.com” that originates from an external address.

BranchCache="1"/”0”

Used to distinguish BranchCache Enabled downloads from non-BranchCache jobs.

<Type TypeID="904" BranchCache="1" Internet="1" />

This would match a job that was BranchCache aware, AND came from an external URL. You might use this type of rule as a ‘Catch-All’ rule further down the TypeID section to match any other job types.

SmallerThan/LargerThan

Catch-all values that simply compare the size of the download file with the value between the > < and match accordingly.

Identifying Microsoft Configuration Manager Job Types

Because ConfigMgr assigns the same name to ALL content downloads, i.e. “CCMDTS Job”, this can make it impossible to identify the job any further. To provide more granularity with these ConfigMgr jobs, the StifleR Client can identify a certain type of download, and this is expressed within the rules. You can also identify and differentiate a job that is a ‘Required’ installation from an ‘Available’ installation performed by the user within ConfigMgr Software Center or Company Portal, along with Jobs that are running within WinPE. This can be extremely useful in allocating priority and/or bandwidth to differing types of ConfigMgr download.

Once the download has been matched to a TypeData and assigned a TypeID the next section of the XML is parsed to set the StifleRPriority. This can then be used to give a recognizable description to the download, allocate a priority to the job, and even to allocate specific bandwidth to a certain download type.

Assigning Priority and Description

StifleRPriority= and Name=

The StifleRPriority value is simply the priority given to a particular job in relation to other jobs. The lower the StifleRPriority value, the higher the priority.

<Download TypeID="209" StifleRPriority="1000" Name="CM Required TS"/>

Using our previous example, the download matched TypeID=”209” which, we can see above, is assigned StifleRPriority="1000". There is also the option to set a Name for the job, which will be displayed in the StifleR Dashboard, in this case "CM Required TS"

Looking further down the list we can see:

<Download TypeID="213" StifleRPriority="2000" Name="CM Required Application" />

As you can note from Name="CM Required Application this is a Configuration Manager Required Application which in the default StifleRulez.xml file it will be configured with StifleRPriority="2000" meaning that it has a lower priority than the Name="CM Required TS" and will throttle down until the other completes.

Assigning Auxiliary Bandwidth – Bandwidth=

StifleR can assign bandwidth to clients that are NOT Red Leader, based on the StifleR rules. This can be useful, for instance, if you wish to allow certain download types to use more than the default NonRedLeader Bandwidth amount.

Important: The Red Leader for a subnet will always use the Target Bandwidth amount for that subnet. The Auxiliary Bandwidth should be used carefully as it contributes to bandwidth use, over and above, the target bandwidth.

Use Case:

Auxiliary Bandwidth can be used to ‘boost’ certain types of download so that a particular download type does not become ‘stuck’ in a queue behind a Red Leader download. A prime candidate for this would be ‘User Initiated’ downloads where the user expects to see progress in the UI. Using the Auxiliary Bandwidth then allows the download to proceed alongside the Red Leader download bandwidth.

Usage:

A user-initiated download is matched as follows to TypeID="212"

<Type TypeID="212" Match="Equals" UserInitiated="1" CCMDTSType="8">CCMDTS Job</Type> <!--Application/Virtual in Full OS : User Initiated -->

This TypeID has been assigned a Priority, Name AND Bandwidth as follows

<Download TypeID="212" StifleRPriority="1000" Name="CM Available Application" Bandwidth="512" />

This is an example where a Download Type has been allocated 512Kbs bandwidth – even if the system is not a Red Leader.

Tip: If you think that there will be a lot of these types of download, you may wish to reduce the Target Bandwidth for that location accordingly so that the cumulative Auxiliary Bandwidth does not impact adversely on network performance.

Windows 10 Delivery Optimization download jobs are tracked by StifleR. Currently the only types of DO content that can be prioritized are Windows Store and Windows Update DO jobs, but we expect this to change, and will add new rules as and when DO functionality changes.

As well as the Standard Edition features, the following additional features are included in the StifleR Enterprise Edition:

• Wake-On-LAN, uses WOL to wake machines in remote Locations that might have cached content that other clients need to download

• BranchCache V2->V1 Auto Detection

• Multi-VLAN detection. Allows Locations with multiple VLANs to share one Red Leader instead of having one per Subnet. This eliminates the need to do custom multicast network configuration to allow WS-Discovery traffic to span multiple subnets

• Command Line Execution. Allows you to execute command line on Clients

• PowerShell execution. Execute PowerShell scripts on Clients

• BITS Job Creation. Allows you to create BITS jobs with a completion command line. Effectively allows you to distribute software or command line changes when required

StifleR and Wake-On-LAN (WOL)

StifleR advance includes the ability to use WOL to wake up machines that might have the content that you are interested in.

This can be used with or without custom scripting. You can use the auto feature that talks to the BranchCache Reporting DB (ConfigMgr if that is used) or custom script this yourselves.

The WOL feature only works effectively if you are using the Windows Service Based mode of the StifleR clients. Under the Service Based mode clients are running all the time and are thus available on a network segment to broadcast the Magic Packet.

When waking a machine you need to know the Subnet segment of the actual device as well as the MAC. If you only know then computer name, you can use a WMI query and ask for the IP and MAC of the computer you are interested in.

The StifleR server will then contact the Red Leader on that segment and instruct it to send a Magic Packet onto the network. If the target client is connected and WOL enabled on the NIC, it will power on and be available for BranchCache sharing.

BranchCache V2->V1 Auto Generation

This feature detects if you have a mixture of BranchCache V2 and V1 computers in your environment and prefers V2 machines to become Red Leaders. V2 machines are able to create hash data for the V1 clients as well as V2. Given the fact that V2 machines are able to utilize Deduplication to download the data from the source, this greatly speeds up the transfer time for the V1 clients.

If a single Windows 7 machine (V1) starts a download of its own, no V2 hash is required. The feature comes into play when targeting V2 to a Location that needs to then generate legacy V1 content. The V2 Red Leaders will automatically generate V1content if configured to do so which allows V1 machines to join at the same time or after the V2 Red Leader has generated the content.

If one or many V1 clients start a download, one of them will be selected to be Red Leader and will perform the download until such time that a V2 client starts a download. At that time the V2 client will be selected Red Leader and start the V2 download from the beginning as it cannot use the already cached V1 data. Once it has caught up with the V1 clients download the V1 clients will start sourcing V1 content that is generated from the V2 Red Leader.

If the download has already happened, the V2 Red Leaders BranchCache will continue to serve V1 clients even if they are not Red Leaders any more, given that they are connected to the network.

To enable the feature, ensure that the GenerateV1Content property (in the WMI Subnet Class) is set to 1 (1=enabled, 0=disabled) for the network segments that require this functionality and from that point on V2 Red Leaders will generate both versions of hashed content.

Inter-VLAN BranchCache Transfers

StifleR Enterprise can enable BranchCache traffic to span over multiple subnets, in a well-connected physical location, by utilizing the feature of bonding subnets into a single entity (a StifleR Location).

This function works in the following way:

1. The requesting client sends out a BranchCache Multicast WS-Discovery (Web Services Dynamic Discovery) probe with a target port of 3702

2. This is picked up by the Blue Leader in the same subnet, hereafter referred to as “Leader”

   1. This Leader then forwards the multicast discovery request as unicast UDP to each leader in every other subnet for that Location. NOTE The server provides each Leader with every other Leaders details each time they contact the Leader with bandwidth assignment configuration

   2. The Unicast message is then resent as multicast by the leaders on the other subnets. This communication is sent from port 3703 to 3702 in order to differentiate from the port that BranchCache normally operates on

3. Clients that hold the data in their cache respond with a Probe Match to the Leader in the segment

4. The Leader receiving the Probe Match sends this over to the Leader local to the requesting client. This Leader then resends the Probe Match to the requesting client

5. The requesting client then does a PCCRR request to get the data from the local Leader, which re-routes the message to the original client that responded with a Probe Match

6. The data stream is then forwarded to the requesting client via the leader which acts as a proxy

Data Visualization of Blue Leader and InterVLAN Communication

This sections uses graphical elements to describe the process of InterVLAN transfers. First step is the transmitting and forwarding of the WS-Discovery probe (What BranchCache uses to find peers with data).

Once the forwarding of the WSD probe has been made, it is then time to forward the reply. This is also handled by the Blue Leaders which forward the requests and replies.

After the client has been made aware that data is available, it can then choose to get the data from the Blue Leader #1 or from any other client in the subnet. Keep in mind that all client requests will be forwarded by the Blue Leader #1 so it’s likely that another machine will respond and provide the data to the requesting client. As BranchCache is requesting data per segment not every request probe that received a response will be used to actually get data.

If the client should choose to get data from the client in Subnet #3 it would forward the request to Blue Leader#1 which passes this through to the Client in Subnet #3. If the client still has the data available at this time the data is then streamed directly back to the requesting client. In the case of the data not being available the client will send an empty response and BranchCache will then retransmit the data discovery request.

Please note that the Blue Leaders role is to facilitate the communication of Discovery date. If the data is available it is then directly streamed from the Client in Subnet #3 to the Client in Subnet #1.