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 Testing Quick Start Guide 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.

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.

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.

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 - 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:

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

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

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

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

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:

#--------------------------------
#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"

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

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)

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:

msiexec /i StifleR.ClientApp.Installer64.msi INSTALLTYPE=2 
STIFLERSERVERS=http://yourserverfqdn:1414 
STIFLERULEZURL="http://yourserverfqdn/StiflerRules/StifleRulez.xml" UPDATERULESTIMERINSEC=”3600” /qn 

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.

Service Driven Mode

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

• Stop and start the Service and check that it does so gracefully without error

• Check that the service is generating Event log entries

Event Driven Mode

Check that the StifleR Scheduled task was created correctly.

Configure Delivery Optimization

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:

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

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.

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.

Other Delivery Optimization Settings

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

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

Bandwidth Policy Configuration for VPN and Roaming Clients

In most Corporate Environments clients will connect in any number of different ways and locations. Bandwidth control must make allowances for these different scenarios with clients Roaming and connecting over VPN. Clients may be on well connected networks or slow links with and without Peers. StifleR must also recognise and cater for situations where the StifleR server cannot be contacted.

The StifleR client can be configured to recognise these different situations and adjust bandwidth allowances accordingly.

The following gives an overview of these various schedule settings:-

Disconnected Policies (Client)

At start up the StifleR client will automatically set the DefaultDisconnected Bandwidth limits (DO and BITS) which are applied in the event that the StifleR client is unable to connect to the StifleR server.

Connected (Client)

If the StifleR Client can contact the StifleR server then it will firstly apply the DefaultNonRedLeader Policies (DO and BITS) values from the local client settings.

The Server will then instruct the client according to its situation:

Roaming (Server)

If the client is roaming, ie. not assigned to a managed subnet, it will set the Server value of DefaultRoamingBandwidth (50/50 DO and BITS)

Not Roaming (Location)

Bandwidth settings are set as follows:

VPN

If the StifleR agent detects that the system is connected via a corporate VPN connection, the client will take the configuration settings for the subnet (as configured on the server) and set:

• TargetBandwidth value / number of active clients

This is updated every 15mins.

For example. If the VPN Subnet is configured with a TargetBandwidth value of 102400 (100Mbs), and there are 5 clients connected via VPN, they will each receive 5/100Mbs – so 20Mbs

This is recalculated every 15 minutes so as clients connect/disconnect via VPN the bandwidth is shared proportionately.

Well Connected Network: (Location)

Well Connected locations are networks where the bandwidth available to clients is generous and no throttling is required. 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:

A Red Leader will still be selected, but the bandwidth allocated to 'Non-Red Leaders' is exactly the same. This allows for faster P2P transfers and faster deployments in general.

The Default Setting is False - (Not Well Connected)

The Client will set:

• WellConnectedBITSBandwidth (for BITS) and WellConnectedDOBandwidth (for Windows 10 Delivery Optimization)

Regular (Managed) Subnet

The client will initially set the Server DefaultNonRedLeader values. A Red Leader is then selected and configured with the TargetBandwidth setting for that subnet.

Red and Blue Leader Assignment

Red /Blue Leaders on Roaming networks are not assigned

Red /Blue Leaders on VPN networks are not assigned

On well connected subnets Red and Blue Leaders are still set but as local policy may be very high this is more to keep the role for other actions such as WOL etc.

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!

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

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.

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.

This requires that the appropriate ports be opened on the clients for this to work. See below.

Each connection generates a new thread on the StifleR Leader (Maximum 8 threads), but as the traffic is never decrypted or analyzed in-depth the CPU and overall system performance hit is very low. Each connection and data transfer handles roughly around 100k of data. Mostly it’s a matter of simply forwarding packets from one port of one client to another port on another client, no deep packet analyses if performed.

As BranchCache traffic is always encrypted on the wire it is not possible for the leader to perform a man in the middle attack or to get access to the encrypted data.

StifleR Client Command Line Execution.

This feature allows an administrator to execute command line on connected Clients. Please note that there is currently no feedback of return codes to the server but this may appear in future editions if requested.

These command lines will be executed under the System context unless otherwise specified. If you specify a separate set of credentials they will be encrypted with AES256/SHA-512 using the client’s connection ID (GUID) as the private key. This GUID is generated by the server at connection time and is unique per connection.

No password is stored on the server side and as soon as the data is sent it is removed from the server.

In order to send a command line to clients an administrator execute the Method on the StfleR Engine Class as follows:

wmic /namespace:\\root\stifler path StifleREngine.Id=1 CALL RunCmdLine“Blah”,"C:\windows\notepad.exe","ALL"

The strings are automatically expanded with environment variables, so the following command would be translated from:

%WINDIR%\Notepad.exe “%ProgramFiles%\2Pint Software\StifleR\Eula.txt”

To:

C:\Windows\Notepad.exe “%C:\Program Files%\2Pint Software\StifleR\Eula.txt”

StifleR Client PowerShell Execution.

This operates in much the same way as the Command Line execution, but using PowerShell instead. Each script is distributed to the client and executed. Any dependencies for other modules etc should be allowed for before executing the script.

To execute a PowerShell script you would run the following command:

StifleR Client BITS Job Creation

The BITS Job creation feature allows you to create BITS jobs, with or without a completion command line. This allows you do distribute software or command line changes if required with package source content, effectively giving you an alternative to your regular software distribution channel.

This feature can be used to pre-schedule/pre-distribute content before it is required by the business. When accessed by the other clients the content will then already have been distributed to the remote Locations, greatly reducing the time to deliver. This can also help to create a much improved experience for end users when they access content.

You can for example use this feature to create a job that pulls down files over a certain threshold from a website running the corporate intranet/extranet pages. Greatly reducing the transfer speed when clients are accessing the corporate intranet. Another use case is to schedule an out of hours transfer of the top 10 most accessed files from the corporate SharePoint sites.

To enable this feature you will need to:

1. Create a job Instance on the StifleR Server using WMI

2. Use the DeployJob Method on this newly created Instance.

• To create a new Job Instance CMD:

• To achieve the same in PowerShell the following should be run:

• This command should then return something like:

• If you check in WMI you should see something like this:

• Select that job and call the DeployJob Method with the following command:

wmic /namespace:\\root\stifler path Jobs.DisplayName="Install My Software Again" call DeployJob "ALL"

• This will return the following given a successful distribution of the command:

Linking Several Subnets into a “Location”

Linking a Subnet with another creates a virtual Parent Location object. You link the Child to the Parent. Currently StifleR only supports Many to One relationship in a simple Parent – Children relationship.

To get the GUIDs of your existing Subnets run the following WQL Query:select SubnetId, Id from Subnets

You can then use the Guid and SubnetId to link two together as follows:wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" call LinkWithSubnet "d379934a-72c7-433a-a3fe-50092b6c4abf"

This should, if successful, output something like:

Please note that in this process the Child must be identified by the SubnetID and that the Parent Location by GUID.

In order to “Unlink” a Subnet, you would run the same LinkWithSubnet method but with an empty (zero value) Parent GUID:-wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" call LinkWithSubnet "00000000-0000-0000-0000-00000000000"

The above then allows for the two subnets to be treated as a single entity for bandwidth and other management tasks. This is not required for StifleR Standard but is a required action for StifleR Enterprise as the Blue Leaders and Red Leaders use this information for the Inter-VLAN transfer of BranchCache data.

The StifleR client sends back the MAC address for the gateway. In most cases this can be used to track VLANs that are linked in the same Locations with different IP ranges.

This means that the StifleR Server WMI Class called ‘Clients’ has a property on each Instance (client connected to StifleR) called GatewayMAC which holds the MAC in the format of: AA-BB-CC-11-22-33.

You can use the following WQL statement to find ranges from the same switch/Location:Select * from Clients where ? Inner Join Subnets on SubnetId.

You can also set up locations through the Dashboard interface

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

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.

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.

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.

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”

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