StifleR Feature Details
StifleR 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
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
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: https://github.com/2pintsoftware/StifleRRules/blob/master/StifleRulez.xml
Note: For detailed information regarding the StifleRulez.xml file, see the following page: StifleRulez.xml Configuration Guide
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.
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.
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.
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:
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
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:
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.
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.
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 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
Last updated
