StifleR Enterprise Edition Features

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 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:

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

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).

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.

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:

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.

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:

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 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:

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