This guide is designed to get you up and running with StifleR in a ’Proof of Concept’ or LAB environment. For full design and implementation guidelines – read the Planning and Deployment Guide.
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.
StifleR requires a functioning Microsoft Peer to Peer (P2P) infrastructure in order to fully optimize your software distributions. Typically this includes BranchCache and/or ConfigMgr Peer Cache and/or Windows 10 Delivery Optimization.
LEDBAT is designed to automatically yield bandwidth to users and applications, while consuming the entire bandwidth available when the network is not in use. It’s a scavenger protocol – it scavenges whatever network bandwidth is available on the network, and uses it. LEDBAT can optimize any TCP sender-side workload. It is enabled on the Content Server side and can be monitored by StifleR.
In order to track LEDBAT enabled downloads, each LEDBAT enabled content server (or SCCM DPs) requires an IIS ‘Response Header’ to be added that will tag LEDBAT traffic so that it can be identified by StifleR Clients. You can use the appcmd.exe command line program for this.
A Suitable Server to act as the StifleR Server – this can be any server for the purposes of testing as the load will be very light.
Windows client systems are required, onto which you will install the StifleR Client software. These should represent your corporate client build (OS revision etc) as closely as possible.
Pre-requisite
Windows 7 SP1 or later
Supported are x86 or x64 versions of the operating systems
Professional, Enterprise or Ultimate versions
Newer Educational SKU is also supported
Microsoft .Net 4. 7 .2 (or higher) must be installed on the client
Microsoft .Net 4. 7 .2 (or higher) must be installed on the Server
Hotfixes for Windows 7 - https://support.microsoft.com/en-us/kb/3036149 (not required but fixes a
bug within BITS that can cause it to ignore Bandwidth Policy)
For the purposes of testing content delivery to low-bandwidth locations, we recommend that you emulate as closely as possible the WAN configuration of your production setup, sepcifically the available bandwdith. You can do this using NEWT, a VYOS Linux Router, or method of your choice.
StifleR is designed to provide two main enhancements to Enterprise-wide Content Distribution.
To greatly reduce the volume of WAN traffic transferred from content servers to remote
client systems by using Microsoft Peer to Peer technology.
To provide granular monitoring and control over the volume of WAN (and LAN) traffic, and
provide administrators with the ability to optimize network utilization and effectively control
bandwidth usage.
For a typical StifleR implementation the order in which you should deploy and configure each component of the system is as follows:-
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.
Deploy Rules for your environment
Install StifleR on a server and configure dashboards
Install Client in Service mode
Check configuration
Enable debug logging if required
Plan ongoing configuration
Configure Target Bandwidth
Configure Subnet Description
Configure Delivery Optimization
Windows 7 SP1 or later
Supported are x86 or x64 versions of the operating systems
Professional, Enterprise or Ultimate versions
Newer Educational SKU is also supported
Microsoft .Net 4.6.2 must be installed on the client
The client is a .Net executable with some C++ helper DLLs. It will run on any operating system that is capable of running .Net 4.6 and BranchCache. This includes most operating systems from Windows 7 SP1 and above with the exceptions of Home and other consumer versions of Windows.
For the purposes of testing we will be installing the StifleR Client in ’Service Mode’
You can install the StifleR Client interactively, via the MSI wizard based install. This is described in the StifleR Planning and Deployment guide. For the purposes of expediency and testing however, we will install the client using the MSI command line.
For example:
To install the StifleR Client with default settings, in Windows Service Based Mode with a single StifleR server defined , and the URL for the StifleR rules XML download, run the following command line from an elevated command prompt:
The full table showing the available MSI properties, switches, options and defaults can be found in the Planning and Deployment guide.
Service Driven Mode
Check that the 2Pint Software StifleR Client Service is Running
Check that the service is generating Event log entries to the StifleR event log
Once you install the StifleR client on some test systems, they will report to the StifleR server, which will start to populate the Location information based on the data sent back from the clients.
Each ’newly discovered’ location/subnet has a set of default parameters, and for the purposes of testing, there are some configuration changes that should be made to enable optimal performance while testing.
On the StifleR server – run the following command from an elevated Command prompt
Where xxx.xxx.xxx.xxx is the subnet ID of your test location and
xxxx is the target bandwidth that you wish to allow for that subnet in Kilobits. So 1024 = 1 Mbit
The Target Bandwidth is the network total bandwidth usage limit that is defined for ALL StifleR clients at that location – so if the limit is set to 4Mbit/s – then the TOTAL bandwidth usage across all clients at that location will not exceed that limit.
Scripted
The summary information for a subnet provides an easy to read description of the subnet in the StifleR dashboards.
Run the following commands from an elevated Command prompt.
You can of course substitute the entries above with those of you own choosing.
Manually through the Dashboards
From the main StifleR Menu (Top LHS matrix icon) navigate to the dashboard for the particular subnet on which you wish to add some summary information. You may then click on a field and you will be presented with an edit box into which you may enter the required details.
WARNING: It is possible to set your Delivery Optimization Peer Caching boundaries to match your Microsoft Configuration Manager Boundary Group boundaries. It is important that you do not use this method if you are using StifleR to configure Delivery Optimization and vice versa.
If you are using Windows 10 Delivery Optimization, StifleR can ensure correct Peer to Peer boundaries are respected.
To achieve this, you need to set two parameters per subnet, the DODownloadMode and DOGroupID. These settings mirror the Policy settings for Delivery Optimization on the client systems.
The DOGroupID must be a unique GUID. You can generate a GUID using PowerShell (New-GUID command) or you could copy the GUID of the subnet itself and use that.
If you have multiple subnets within a location, and you want all StifleR clients to share content across those subnets, simply set the same Group ID for all subnets at that location.
For example, in order to configure this capability, you could run the following commands from an elevated command prompt on the Stifler Server:
Once the above parameters are set, the Delivery Optimization clients will only share content with other clients that have the same Group ID.
NOTE As the DO group is meant to be well connected and used specifically for P2P file sharing there is no Blue Leader functionality as all members should be local.
PowerShell Snippet
This example loops through all subnets and enables Delivery Optimization Download Mode in ‘Group Mode’ (2)
It then sets the DOGroupID using the GUID for that subnet. This is the most basic configuration and means that DO will only share content with other clients on the same subnet.
Other Delivery Optimization Settings
In order to get the best performance from Delivery Optimization, 2Pint recommends that you set the following Policy items.
1. Max Cache Age (in seconds) – Set this to zero (0) so that content is not removed from the cache once downloaded. The default is only 3 days.
2. Minimum Peer Caching Content File Size (in MB) – Set this to 1 to make sure that all files over 1MB in size will be shared via P2P. The default for this is 50MB or 100MB (depending on Windows 10 version) which excludes a lot of content.
These are the minimum settings that we recommend for efficient Delivery Optimization Peer Caching. There are many other DO setting available – see this link for more information.
https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization
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.
Requires .Net 4.7.2 to be installed on the server.
If you want to use the same server to host the dashboards - install IIS as well.
If you wish to use a Custom App Pool in IIS – create that beforehand
Installation account must have Administrator rights (or run the MSI Installer elevated)
Ensure you have the License.cab available for the installer to access.
Firewall – open ports 1414 (Client comms) and 9000 (Dashboard comms) Inbound for TCP
traffic
The StifleR client will check through its queue of active downloads (both BITS and DO) and will prioritize them according to a locally held XML configuration file containing a set of rules that are configured centrally by the administrator and automatically distributed to clients.
This file contains a simple rule set that defines the content download jobs and the priority that the administrator has assigned to each job type. See the StifleR Rules XML Guide for more details on how to create and configure the rules file. The latest version of the StifleRulez.xml file can always be found through the default client download link:
http://2pintsoftware.com/download/stiflerrulez/
The clients will download the rules definition XML at a configurable interval from the configured URL. In order to use a custom file this URL must be created, and for the purposes of testing we will assume that it is on the same server as StifleR itself.
File location
Place the stiflerulez.xml in the following folder on the StifleR server:
Create a Virtual folder in IIS
From an elevated PowerShell prompt, execute the following command:
This command will create a virtual folder which you will then use during the StifleR client install to configure the clients to automatically update their rules definition. The URL will be:
http://yourserverfqdn/StiflerRules/stiflerulez.xml
Note: If you do not configure your own internal rules definition URL, the clients will use the default client download link (above) and use the one located on the 2Pint website.
We are now ready to install the StifleR server component.
From an Elevated Command prompt launch StifleR.Installer64.msi
Start the installation by executing the correct installer (x64 for x64 systems). The Welcome dialog will appear
Click the Next button and the End User License Agreement page appears. After you have read through the EULA check the box to indicate that you agree to the terms and conditions.
Next is the Licensing dialogue. Enter the Path or click on the “…” button to browse to the location of the License.cab file. Browse and select a valid License.cab file and click ‘Open’ The path to the license file will now be updated.
NOTE: If you select an old expired license file the installer will continue but the StifleR service may stop soon after starting
WARNING At the present time do not install any Feature as stand alone. At the time of writing there is no automatic method that allows a clean uninstall of these features when installed without the StifleR Server Service.
Next, configure the account under which you would like the StifleR service to run, either LocalSystem, or using a specific domain account. Note that, if use a domain (or local user) account it must have the ‘Logon as a Service’ right.
Next, you can choose a port for the StifleR service. The default is 1414 but you can change that here. Click the ‘Test Port’ button to test that the port is available and working.
This page allows you to configure the installation of the Dashboards onto the IIS Site. You can leave the defaults or configure a Custom App Pool if required.
Next is the Installation Folder location where you want to install the StifleR service files.
Next is an option to allow the installer to configure the Microsoft Firewall to create the required exceptions for SignalR, Web Service and Beacon Server communication
Next you need to enter the Name of the StifleR Administrative Groups You will need to create these groups in AD and add your Global Administrator, Dashboard Access and Global Read Operator accounts accordingly.
We’re now ready to unleash the StifleR magic, so go ahead and click on Install, sit back and enjoy a nice cup of tea, you’ve earned it.
All going well you will see the Finish dialogue and StifleR will be ready to
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:
Check that the service is running - not stopped or in any other state.
Navigate to the StifleR installation directory.
Check for the License.nfo files. If this is missing the service may not be licensed properly.
Open up the configuration file (StifleR.Service.exe.config ) and check that the expected values
are present. For a detailed description of each value see the StifleR Planning and Deployment Guide.
Open up the Windows Event Viewer MMC and check that StifleR Server events are being
logged:
Ensuring WMI is operational
Open up wbemtest.exe and connect to the Root\StifleR namespace.
Open up the StifleREngine class:
Note: If you are new to the world of WMI then you may find a third party tool such as WMIExplorer a little more user friendly.
Ensure you can see the WMI methods:
Hit the Instances button:
You should see the default Instance of the StifleREngine with the ID of 1:
Select this Instance. Scroll down in the properties window. Ensure that LicensedVersion is
not null and that the other values are similar to those below
