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 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.
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.
Note: The V2 Red Leaders will store the V1 hash data in addition to the V2 hash data. This increases the BranchCache size by 100%.
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.
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:
The requesting client sends out a BranchCache Multicast WS-Discovery (Web Services Dynamic Discovery) probe with a target port of 3702
This is picked up by the Blue Leader in the same subnet, hereafter referred to as “Leader”
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
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
Clients that hold the data in their cache respond with a Probe Match to the Leader in the segment
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
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
The data stream is then forwarded to the requesting client via the leader which acts as a proxy
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.
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”
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:
NOTE: Although the script will be transferred over SSL, if enabled, it would not be the best practice from a security point of view to include clear text passwords in the script itself. There is a theoretical possibility that someone with admin rights on the client can get access to the script in clear text due to the way that the PowerShell engine works.
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.
NOTE This feature is not intended to provide an alternative to a complete systems management solution such as System Centre Configuration Manager. It lacks the rich end user interface and appropriate targeting mechanism which are dependent on hardware inventory etc. This should be regarded as a powerful add-on, allowing you to quickly implement foremost content changes to your enterprise environment. As BranchCache will be used for the transferring mechanism it is not crucial that all clients execute/receive the instruction as long as at least a number of clients at each remote Location execute the command
To enable this feature you will need to:
Create a job Instance on the StifleR Server using WMI
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 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
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.
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 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.
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.
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.
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
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
StifleR reports crucial events as Windows Event log items. You may use these to trigger scripts for certain actions.
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.
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.
The Server can instruct the Clients to connect to an alternate server if required.
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.
The following BITS Priority values are applied according to the Download Priority values shown above:
These priority values also appear in the dashboards.
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.
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.
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
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.
The action parameter determines what we want to do with 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
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.
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.
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.
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.
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:
If the name is set to * all jobs are modified.
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:
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"
Which machines should run this?
ALL = All connected machines.
IPSubnet = All machines within a network segment.
GUID = The connection ID of an individual machine.
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.
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.
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.
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
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
