Comment on page
StifleR Feature Details
- 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
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
Figure 15 checking the WMI Provider with PowerShell
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.
<StifleRData xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<VersionInfo>
<Issuer>2Pint Software</Issuer>
<Version>1.7.6.0</Version>
<Date>06-06-2018</Date>
</VersionInfo>
<TypeData>
<Type TypeID="001" Match="Equals">Download StifleRulez File</Type> <!-- StifleR Rules Update-->
<Type TypeID="002" Match="URLContains">Express</Type> <!-- MS Express Update-->
<!-- Generic Windows Downloads Section-->
<Type TypeID="100" Match="Contains">Push Notification Platform Job</Type>
<Type TypeID="101" Match="Equals">WU Client Download</Type> <!-- Windows Update-->
<Type TypeID="102" Match="Equals">Windows Store</Type> <!-- Windows Store - W10 DO Only-->
<Type TypeID="103" Match="Equals">UpdateBinary</Type><!-- MS OneDrive-->
<Type TypeID="104" Match="Equals">SpeechModelDownloadJob</Type>
<Type TypeID="105" Match="Equals">SkypeUpdate</Type>
<Type TypeID="106" Match="Equals">Setup Installer</Type>
<Type TypeID="107" Match="Equals">Font Download</Type>
<Type TypeID="108" Match="Contains">DMRCBitsJob</Type>
<Type TypeID="109" Match="Contains">Microsoft Outlook Offline Address Book</Type>
<Type TypeID="110" Match="Equals">Silverlight Updater</Type>
<Type TypeID="111" Match="URLContains">MicrosoftMaps</Type> <!-- MS Maps Update-->
<Type TypeID="112" Match="Equals">PreSignInSettingsConfigJSON</Type>
<Type TypeID="113" Match="Equals">Windows DLP Manager</Type>
<!-- MS ConfigMgr Section-->
<Type TypeID="200" Match="Contains">CCMSETUP DOWNLOAD</Type> <!--CM Auto upgrade client job-->
<Type TypeID="201" Match="URLContains">SCCM_BranchCache$</Type> <!--All types of CM PeerCache transfers-->
<Type TypeID="202" Match="URLContains">SCRIPTGUID</Type> <!-- CM Run SCript-->
<Type TypeID="203" Match="URLContains">sms_dcm</Type> <!-- CM Configuration Baseline Traffic-->
<Type TypeID="204" Match="URLContains">sms_pol</Type> <!-- ConfigMgr Policy Traffic-->
<Type TypeID="205" Match="Contains">CCM Message Upload</Type> <!-- ConfigMgr Inventory Upload-->
<Type TypeID="207" Match="Equals" WellConnected="0" CCMDTSType="4" WinPE="1">CCMDTS Job</Type> <!--Task Sequence in WinPE :
Required deployment-->
<Type TypeID="227" Match="Equals" WellConnected="1" CCMDTSType="4" WinPE="1">CCMDTS Job</Type> <!--Task Sequence in WinPE :
Required deployment-->
<Type TypeID="208" Match="Equals" UserInitiated="1" DownloadOnDemand="1" CCMDTSType="4">CCMDTS Job</Type> <!--Task Sequence in
Full OS : User Initiated : Download on Demand-->
<Type TypeID="209" Match="Equals" DownloadOnDemand="1" CCMDTSType="4">CCMDTS Job</Type> <!--Task Sequence in Full OS :
Required Deployment : Download on Demand -->
<Type TypeID="210" Match="Equals" UserInitiated="1" DownloadOnDemand="0" CCMDTSType="4">CCMDTS Job</Type> <!--Task Sequence in
Full OS : User Initiated : Download All B4 Execute -->
<Type TypeID="211" Match="Equals" DownloadOnDemand="0" CCMDTSType="4">CCMDTS Job</Type> <!--Task Sequence in Full OS :
Required Deployment : Download All B4 Execute -->
<Type TypeID="212" Match="Equals" UserInitiated="1" CCMDTSType="8">CCMDTS Job</Type> <!--Application/Virtual in Full OS : User
Initiated -->
<Type TypeID="213" Match="Equals" CCMDTSType="8">CCMDTS Job</Type> <!--Application/Virtual in Full OS : Required Deployment -->
<Type TypeID="214" Match="Equals" UserInitiated="1" CCMDTSType="0">CCMDTS Job</Type> <!--Pkg/Program in Full OS : User Initiated -->
<Type TypeID="215" Match="Equals" CCMDTSType="0">CCMDTS Job</Type> <!--Pkg/Program in Full OS : Required Deployment -->
<Type TypeID="216" Match="Equals" UserInitiated="1" CCMDTSType="5">CCMDTS Job</Type> <!-- Software Update in Full OS : User Initiated -
->
<Type TypeID="217" Match="Equals" CCMDTSType="5">CCMDTS Job</Type> <!-- Software Update in Full OS : Required Deployment -->
<!-- All others Misc Section includes Internet based downloads and catch-all rules-->
<Type TypeID="300" Match="Contains">.crx</Type>
<Type TypeID="301" Match="Contains">chrome_installer.exe</Type>
<Type TypeID="302" Match="Contains">ArmReaderJobsID</Type>
<Type TypeID="303" Match="URLContains" Internet="1">adobe.com</Type>
<Type TypeID="304" Match="Contains">DropBoxClient</Type>
<Type TypeID="305" Match="Contains">GoogleEarth</Type>
<!-- This should always be the last section - catch-all rules for anything that isn't detected above-->
<Type TypeID="900" Match="SmallerThan" Internet="0">32768</Type>
<Type TypeID="901" Match="LargerThan" Internet="0">1073741824</Type>
<Type TypeID="902" Match="SmallerThan" Internet="1">32768</Type>
<Type TypeID="903" Match="LargerThan" Internet="1">1073741824</Type>
<Type TypeID="904" BranchCache="1" Internet="1" />
<Type TypeID="905" BranchCache="1" Internet="0" />8
<Type TypeID="906" BranchCache="0" Internet="1" />
<Type TypeID="907" BranchCache="0" Internet="0" />
</TypeData><!-- ***** END OF TYPEDATA SECTION *****-->
<DownloadTypes>
<Download TypeID="001" StifleRPriority="100" Name="StifleR Rules Updater"/>
<Download TypeID="002" StifleRPriority="100" Name="CM Express Update"/>
<Download TypeID="100" StifleRPriority="3000" Name="Windows Platform"/>
<Download TypeID="101" StifleRPriority="1000" Name="Windows Update"/>
<Download TypeID="102" StifleRPriority="1000" Name="Windows Store"/>
<Download TypeID="103" StifleRPriority="3000" Name="Microsoft OneDrive Update"/>
<Download TypeID="104" StifleRPriority="3000" Name="Microsoft Speech Update"/>
<Download TypeID="105" StifleRPriority="3000" Name="Skype Updater"/>
<Download TypeID="106" StifleRPriority="3000" Name="Windows Setup Installer"/>
<Download TypeID="107" StifleRPriority="3000" Name="Font Download" />
<Download TypeID="108" StifleRPriority="3000" Name="Windows Device Management"/>
<Download TypeID="109" StifleRPriority="100" Name="Microsoft Outlook OAB Sync" Bandwidth="512" />
<Download TypeID="110" StifleRPriority="3000" Name="Silverlight Updater"/>
<Download TypeID="111" StifleRPriority="3000" Name="Microsoft Maps Update"/>
<Download TypeID="112" StifleRPriority="3000" Name="OneDrive Settings"/>
<Download TypeID="113" StifleRPriority="3000" Name="WIP Manager Update"/>
<Download TypeID="200" StifleRPriority="1000" Name="CM Client Upgrade"/>
<Download TypeID="201" StifleRPriority="100" Name="CM Peer Cache P2P" />
<Download TypeID="202" StifleRPriority="100" Name="CM Run Script" />
<Download TypeID="203" StifleRPriority="100" Name="CM Configuration Baseline"/>
<Download TypeID="204" StifleRPriority="100" Name="CM Policy Download"/>
<Download TypeID="205" StifleRPriority="3000" Name="CM Inventory Upload"/>
<Download TypeID="206" StifleRPriority="1000" Name="CM WinPE User TS" Bandwidth="512" />
<Download TypeID="256" StifleRPriority="100" Name="CM WinPE User TS Well Connected"/>
<Download TypeID="207" StifleRPriority="1000" Name="CM WinPE Required TS"/>
<Download TypeID="227" StifleRPriority="100" Name="CM WinPE Required TS WC"/>
<Download TypeID="208" StifleRPriority="1000" Name="CM Available TS" Bandwidth="512" />
<Download TypeID="209" StifleRPriority="1000" Name="CM Required TS"/>
<Download TypeID="210" StifleRPriority="1000" Name="CM Available TS" Bandwidth="512" />
<Download TypeID="211" StifleRPriority="1000" Name="CM Required TS"/>
<Download TypeID="212" StifleRPriority="1000" Name="CM Available Application" />
<Download TypeID="213" StifleRPriority="2000" Name="CM Required Application" />
<Download TypeID="214" StifleRPriority="1000" Name="CM Available Package" />
<Download TypeID="215" StifleRPriority="2000" Name="CM Required Package" />
<Download TypeID="216" StifleRPriority="1000" Name="CM Available Update" />
<Download TypeID="217" StifleRPriority="1000" Name="CM Required Update" />
<Download TypeID="300" StifleRPriority="3000" Name="Google Chrome Updater" Bandwidth="512" />
<Download TypeID="301" StifleRPriority="3000" Name="Google Chrome Updater" Bandwidth="512" />
<Download TypeID="302" StifleRPriority="3000" Name="Adobe Updater" Bandwidth="512" />
<Download TypeID="303" StifleRPriority="3000" Name="Adobe Updater" Bandwidth="512" />
<Download TypeID="305" StifleRPriority="3000" Name="Google Earth Installer" Bandwidth="512" />
<Download TypeID="900" StifleRPriority="2000" Name="Small Internal Prio 2" Bandwidth="64" />
<Download TypeID="901" StifleRPriority="3000" Name="Large Internal Prio 3" Bandwidth="64" />
<Download TypeID="902" StifleRPriority="2000" Name="Small Internet Prio 2" Bandwidth="128" />
<Download TypeID="903" StifleRPriority="3000" Name="Large Internet Prio 3" Bandwidth="256" />
<Download TypeID="904" StifleRPriority="2000" Name="BranchCache External" Bandwidth="64" />
<Download TypeID="905" StifleRPriority="2000" Name="BranchCache Internal" Bandwidth="64" />
<Download TypeID="906" StifleRPriority="3000" Name="Non-BranchCache External" Bandwidth="128" />
<Download TypeID="907" StifleRPriority="3000" Name="Non-BranchCache Internal" Bandwidth="256" />
</DownloadTypes>
</StifleRData>
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:
ForeGround = 0
High = 1,
Normal = 2,
Low = 3
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.
Figure 17 StifleR BITS control Rules Match table
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 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.
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:
bitsadmin /list
BITSADMIN version 3.0 [ 7.7.9600 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.
BITSAdmin is deprecated and is not guaranteed to be available in future
versions of Windows.
Administrative tools for the BITS service are now provided by BITS PowerShell
cmdlets.
{CD50C4FB-285E-49C3-9CDB-ABEE042B99EE} 'apabepa' SUSPENDED 0 / 0 0 / 0
Listed 1 job(s).
Then we run the following command to Cancel all jobs containing the string "bepa":
PS C:\> Invoke-WmiMethod -Namespace root\StifleR -Path StifleREngine.Id=1 -
Name ModifyJobs -ArgumentList "Cancel", $false, "%bepa%", "", "ALL"
__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 1
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
ReturnValue : Sent modification to ALL clients
PSComputerName :
Then we see the log entry that the client has removed the job.
If we then try to list it:
bitsadmin /list
BITSADMIN version 3.0 [ 7.7.9600 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.
BITSAdmin is deprecated and is not guaranteed to be available in future
versions of Windows.
Administrative tools for the BITS service are now provided by BITS PowerShell
cmdlets.
Listed 0 job(s).
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.
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:
- 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
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).
Figure 18 shows a client on subnet #1 requests data which is picked up by Blue Leader #1 which is then forwarded to and broadcast over Subnets #2 and #3 via Blue Leader #2 and Blue Leader #3. The Server transmits the Leader list for every subnet/location
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.
Figure 19 shows the client in Subnet #3 picking up the request and responding to Blue Leader #3, which then picks up the response and sends it on to Blue Leader #1, which rewrites the response and sends it to the requesting Client in Subnet#1.
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.
Figure 20 shows the last piece of the IneterVLAN puzzle, the requesting client connects to Blue Leader #1 to get the data. Blue Leader #3 forwards the request to the client in Subnet #3, similar to a proxy.
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:
Figure 21 StifleR Client PowerShell Execution
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:
- 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:
wmic /namespace:\\root\stifler path Jobs call AddJob 1,"Install.exe
/s","Override.exe","Description of Install My Software","Install My Software
Again",("http://myserver/myfile.fil c:\myown\executionpath"),
"Passw0rd","True",3,"domain\user"
- To achieve the same in PowerShell the following should be run:
Invoke-WmiMethod -Namespace root\StifleR -Path Jobs -Name AddJob -ArgumentList
1,"Install.exe /s","Override.exe","Description of Install
My Software","Install My Software Again",("http://myserver/myfile.fil
c:\myown\executionpath","http://myserver/myfile2.fil
c:\myown\executionpath2"), "Passw0rd","True",3,"domain\user"
Figure 22 StifleR Client BITS Job Creation
- This command should then return something like:
Executing (Jobs)->AddJob()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
ReturnValue = "95eb1d30-5eaa-4846-bd38-7d05a6ff084d";
};
- 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:
Executing (\\NUC5\root\stifler:Jobs.DisplayName="Install My Software Again")->DeployJob()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
ReturnValue = "Sent BITS Job to ALL";
};
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 SubnetsYou 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:
Executing (\\NUC5\root\stifler:Subnets.subnetID="192.168.138.0")->LinkWithSubnet()
Method execution successful.
Out Parameters:
Instance of __PARAMETERS
{
ReturnValue = 0;
};
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 modified 25d ago