StifleR Feature Details
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.
If you browse to your StifleR Dashboards web site URL http://YourServerURL/StifleRDashboard you will be presented with the following splash page.
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.
Heading | Explanation |
Main Statistics | Queue Sizes and Bandwidth usage over last 15mins, Hour, Day |
Maps and Globe | |
Globe | An interactive planetary globe showing active clients and download activity in various locations around the world |
Maps | A World or continent map view of Client activity |
Transfer Overview | Live, up to the second statistics, showing Queue Lengths, Download size, Bandwidth usage and client activity. Drill down from here for summary data on Leaders, Subnets, Locations and clients. |
Cache Overview | Gives at a glance Enterprise wide view over BranchCache and DO cache availability and utilization |
Top 10 Downloads | Shows a graphical view of the current Top 10 Downloads along with a drill down list for further analysis |
Max Downloads | Top 5 Donut graphs giving data on Internal and External downloads by Count, Data, Size, Source, P2P and Hosts |
Running Sequences | |
OS Deployments | At a glance overview of Active Operating System Deployments. This view shows only deployment of task sequences flagged as operating system task sequences by ConfigMgr. For example, task sequences having an OS Image Package, an OS Upgrade Package, or a Restart Computer (configured to restart into the boot image) action in them. |
OSD Deployments List | List of current Active Operating System Deployments with drill down. Includes where these are running by geographical location. Like the OS Deployments view, this view shows only deployment of task sequences flagged as operating system task sequences by ConfigMgr. |
Task Sequence | At a glance overview Active Task Sequences not flagged by ConfigMgr as operating system task sequences, for example application deployment task sequences. |
Task Sequence List | List of current Active Task Sequences with drill down. Like the Task Sequence view, it only shows Active Task Sequences not flagged by ConfigMgr as operating system task sequences. The view includes where these are running by geographical location. |
Servers | Server List with connection details |
Clients | |
Clients Overview | At a glance overview |
StifleR Server | |
StifleR Leaders | A list of Red and Blue leaders with queue details, P2P ratios, bandwidth settings etc along with drill down options |
Server Settings | A summary of the current Server Settings including those contained in the StifleR.Service.exe.config with the ability to make changes to those settings where configurable |
Performance | Gives details on the actual StifleR server performance |
Query StifleR | Beta at time of writing – WOW! |
WMI Browser | Beta at time of writing – WOW! |
Locations | Drops down further to allow you to access specific location dashboard or details set with granular drill down available for further analysis |
Subnet Information | Drops down to give you a list view of all subnets or allows you to choose a dashboard view for specific subnets to monitor Active Transfers, Bandwidth usage right down to individual client activity |
Countries | Drop down list with geographical drill down |
NOTE: StifleR Dashboards should not be viewed on directly on the Server. Servers are generally not optimized for graphics display. Also the Dashboards present up to the second information and if a Dashboard web page is left open, in a background tab, the information that would be displayed on the web page is cached. This will start to hog resources on the machine on which the Dashboards are being viewed. It is therefore best practice to close Dashboards once finished
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.
Note: All Clients from a single subnet must be communicating with the same StifleR server or multiple Red Leaders will be assigned.
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.
The latest version of the StifleRulez.xml can always be found here for reference: http://2pintsoftware.com/download/stiflerrulez/
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.
If the rule file is missing or if the timer has triggered, the client will try to get a new file from the URL defined in the clients’ configuration file under the StifleRulezURL key string. Merge your own edits with the one downloaded from 2Pint Software and host this file internally on your corporate LAN. The default value of the StifleRulezURL key is http://2pintsoftware.com/wp-content/uploads/StifleRulez.xml.
NOTE This file does not support the Content-Length as it is hosted on a CDN. To allow StifleR to use HTTP download instead of BITS set the client configuration key UseBITSForRulezDownload to 0 in order to use regular HTTP instead of BITS. Set it to 1 to use BITS for downloading new definition files. BITS requires Content-Length which some NAS/Apache servers don’t do by default. The default file size is ~10Kb
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
Call | [ In/Out ]Params&type | Status |
ModifyJobs | [IN ]action(string) [IN ]force(boolean) [IN ]jobName(string) [IN ]StifleRType(sint32) [IN ]Target(string) [OUT]ReturnValue(string) | Implemented |
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.
NOTE: If no Red Leader can be selected the StifleR server will raise an error event in the Event log.
Last updated
