If the client hardware can run Windows, it can run the StifleR Client. CPU & Memory utilization is very low.
Pre-requisite
Windows 7 SP1 or later
Supported are x86 or x64 versions of the operating systems
Professional, Enterprise or Ultimate versions
Newer Educational SKU is also supported
Microsoft .NET 4.7.2 must be installed on the client
The client is a .NET 4.7.2 executable with some C++ helper DLLs. It will run on any operating system that is capable of running .NET 4.7.2 and BranchCache. This includes most operating systems from Windows 7 and above with the exceptions of Home and other consumer versions of Windows.
Hotfixes for Windows 7 - BITS might ignore the throttling policy and consume the WAN circuits in Windows 7 SP1 or Windows Server 2008 R2 SP1 (not required but fixes a bug within BITS that can cause it to ignore Bandwidth Policy)
The StifleR Client can be installed in one of three modes:
Windows Service Based Mode – always connected to the StifleR Server, running as a Windows Service
Event Triggered Mode – only starts & connects when a download job is created and running
Read Only Mode
The benefit of Service Mode is that the Administrator can send configuration changes to the Client immediately at any time. This does not happen in the Event Driven mode as the client is only active when a download job is run and the client will only receive configuration changes at start up.
When running as a service, the StifleR client runs as a Windows Service and monitors job creation every few seconds according to the configured interval.
The client is not always running in this mode lowering utilization on both client and server. This however means that the server cannot reliably perform certain configuration tasks on the client in real time.
When the StifleR client is event driven it is triggered by the Windows ETW (Event Tracking for Windows) system using a Scheduled Task that launches the StifleR Client on BITS Event ID 3 (BITS Job created). Once all queued BITS jobs have completed, the Client exits out.
The reason that Event Driven mode was first written into the product was to cater for a situation where a customer may deploy your content in ’Maintenance Windows’ within set times during offpeak hours for instance and may not want the service running outside these hours. We have not seen any requirement for this in real world usage and accordingly this mode should be considered for advanced use only.
This mode requires separate licensing. It is a limited version only for network monitoring and dashboard visibility.
The StifleR client can be run on a Windows Server system where, for example, you may want to monitor the Bandwidth performance of an SCCM Pull Distribution Point. In order to do this you must edit the following line into the StifleR.ClientApp.exe.config file and restart the StifleR service:
Once the Service has been restarted, the server can be monitored like any other client. NB: It will not appear in the ‘Servers’ dashboard.
StifleR controls access to the two main server components, i.e the SignalR Hub and the Web service. This control applies to both users (which required access to StifleR Dashboards) and StifleR Clients (who need to access the SignalR Hub).
Access to the StifleR Dashboards and WMI objects are controlled by Domain Group membership and StifleR Configuration file settings. These are described below:
If the AllowAnonymousRead is enabled (value of “1”) in the StifleR Configuration file, we allow all read operations and the following options are not in play.
Full Administrative Access to StifleR Server is restricted to Accounts that are members of a Global Administrators Group. This group is defined during the installation of the StifleR Server. These Global Administrators can then grant specific rights (read/write) over individual resources to Delegated Administrators. Delegated Administrators can only see and administer those Sites and Subnets over which they have been granted control. See table below for full details.
*StifleR Configuration file setting name
NOTE; Unless otherwise stated, the following settings can be found in the StifleR.Service.exe.config file which is located in the StifleR Server Installation folder.
If the AllowAnonymousSignalRConnections value is set to “1” – then any StifleR client can connect. This is default currently, as older StifleR Clients (pre- 1.9.7.4) are not capable of ANY authentication and would be rejected if this were set to “0”. This can be disabled by setting the ConnectionSendCredentials option to “0” in the configuration file of the client.
The StifleR client runs as Local System (NT AUTHORITY\System)
If the client and the server are both in the same domain (or trusted), then the Local System account uses the computer account (hostname followed by a $ character, i.e. computer1$) to login on the remote computer. This can then be checked on the server side for limiting access, i.e. verify that the machines account (computer1$) is part of a specific group that gives the right access.
This is configured using the following settings
RequireAgentGroupMembership=”1”
If the above is set, a second setting, AgentGroupMembership is then used to define the RequiredGroup. e.g. AgentGroupMembership=”2PINT\StifleRClientAccess”
Note: If the client or the server is not in a domain, or the trusted domain, then the Local System account uses ANONYMOUS LOGON. This cannot be verified against a group, and would fail if the server is configured with RequireAgentGroupMembership.
If the client population is spread across a number of different domains, or are not domain joined, you can use certificates to control access.
If RequireAgentClientCertificate=”1” is set in the StifleR Config file, the client is required to attach a client certificate to the SignalR connection. This requires the CertificateClientThumbprint and CertificateRootThumbprint values to be configured (added) with a thumbprint of a local certificate which is then present in the personal (MY) store in the local machine store location of the client. The first certificate in the store chain from that thumbprint is used.
The server will then verify the certificate. Failing to verify the certificates will return a 403 error to the requesting client.
NOTE: Client certificates have nothing to do with HTTPS usage, they are separate entities and HTTPS does not verify that the client can authenticate as client certificates do.
There is a further (less secure) method that can be used if you are unable to use Group membership of Client Certificates. This requires a client ‘token’ value to be configured on the server and client. The value for the Server Configuration is RequestAgentToken which should be configured with a string that will then be used by clients to connect (and should be treated like a password).
You can test access to StifleR using the following URL – which will list the group membership and access rights of the current user. The url should be as follows:
http(s)://FQDN.OF.STIFLER.SERVER:9000/api/test
Group
Description
Access
Global Administrators
DefaultStifleRAdmins*
Full read and write right access to ALL objects
All (does NOT require Dashboard Access membership)
Dashboard Access
StifleRDashboardAccess*
Access to dashboard and overview statistics only
Statistics, summary data etc. No WMI access
Global Read
DefaultStifleRRead*
Gives read only rights to ALL locations and statistics. Including WMI.
Read Access on ALL locations. Must be member of Dashboard Access also
Location Administrators
Delegated Admin Role. Provides read (or write) access to individual locations.
Read /write access to only selected (defined) locations. Needs to be in Dashboard Access in order to connect to the dashboard system.
The following (client) ports are used for the InterVLAN feature (see later). An asterisk (*) indicates a dynamic Port number. BranchCache tries to use a random port among the dynamic port range (49152-65535) as specified in RFC6335 section 6. Port Number Ranges:
Server – Client Communication
Source – dynamic
Destination – Port 1414 TCP/IP & Port 1414 UDP for Web Sockets
Web Server - Dashboards
Source - dynamic
Port 9000 is used by server to host the dashboard/data API. Dashboard uses it to connect to the REST API to get data
Port 80 - dashboards
Beacon Server Port
For clients to send iperf packets – Server TCP 5201
Planning for integrating StifleR into your Content Distribution System is simple. Like most technical projects however, preparation and attention to details pays dividends.
Location of the StifleR server should be considered although it is not too critical unless you have multiple geographical locations etc. in which case you may consider having multiple StifleR servers at key hub locations. More important is the spec of the server and its Network connectivity. Bear in mind that the server will have incoming and outgoing connections to all StifleR clients – sometimes all at once during a large scheduled deployment.
The following table can be used as a summarized view of the hardware requirements.
StifleR is CPU intensive. Since StifleR does not use that many threads, a higher frequency (Ghz) is recommended. We recommend at least a 2.4Ghz processor with 8 cores. Don’t forget that most CPU’s must also handle some of the Network connectivity management.
StifleR writes a lot of historical data to databases, as well as maintaining in-RAM memory objects. Since each connection and all connection data is stored in RAM a decent size of RAM is recommended but 32GB should be plenty for most installations.
StifleR saves a lot of information to ESENT databases, especially with the System Resource Tracking features enabled. Fast SSD disks are preferred for housing these Databases.
Each client has a non-managed SignalR client connection (web sockets) to the server, so if you want to run 100k clients to a single server you need to beef up the network connectivity.
If you are supporting a large number of clients, you probably want dual or quad 10Gb/s NIC’s for your StifleR server. This will ensure that the NIC’s have enough power to manage the large number of connections.
StifleR server requires Windows Server 2012 with Microsoft .NET version 4.7.2 or higher. If you wish to run StifleR on Windows server 2008 contact us first for a chat.
There are also requirements around IIS settings. Please refer to the Dashboard installation section for important information in this regard.
Multiple StifleR servers can be configured for larger enterprises so that clients can fail-over to a second server should the primary server become unavailable.
For larger installations we recommend splitting the load across several StifleR servers. For example one server per geographical region.
The server-side component (iperf3.exe) can run on any Windows OS (talk to us if you want to run it on Linux) It acts as the end point to which the StifleR Client Red Leaders send test packets. This allows the Red Leaders to accurately measure the maximum bandwidth available between the a Subnet/Location and the content source. Typically, you will install this component on a server in a central location (such as an SCCM Distribution Point) from which your clients obtain the bulk of their content. If you have a central datacenter for instance you can simply install the StifleR Beacon service onto any server at that location. The StifleR Beacon Service may be installed on the StifleR Server if required but there is no dependency on this configuration.
We recommend that http communication channels only be used in your initial high level testing. In a production environment we strongly recommend that you configure StifleR communication to be secured over https. For more information on SSL configuration, and all things certificate related, please refer to the companion document “Securing StifleR operations using SSL” which gives an overview of not only the StifleR and SignalR configuration but also how to set up the underlying Configuration Manager security environment to get you started.
The StifleR client will check through its queue of active downloads (both BITS and DO) and will prioritize them according to a locally held XML configuration file containing a set of rules that are configured centrally by the administrator and automatically distributed to clients.
This file contains a simple rule set that defines the content download jobs and the priority that the administrator has assigned to each job type. The “StifleR Rules XML Guide” is available for download from 2Pint website on the StifleR Product Page which gives details on how to create and configure the rules file. There is a default rules file copied into the ProgramData location as part of the Client installation but this is static and should only be used for initial basic testing purposes.
The clients will download the rules definition XML from a configured URL. If you wish to configure your own rules definition file or your client do not have internet access then you need to create this URL on your internal IIS server. If not then the clients will default to use one which is stored on the 2Pint website.
SignalR can be used in a variety of client platforms. This section describes the system requirements for using SignalR in web browsers, Windows desktop applications, Silverlight applications, and mobile devices.
When StifleR’s SignalR driven Dashboards are hosted in IIS, the following versions and configurations are supported.
IIS 10
IIS 8, 8.5 or IIS 8 Express
IIS 7 and 7.5. Support for extensionless URLs is required
IIS must be running in integrated mode; classic mode is not supported. Message delays of up to 30 seconds may be experienced if IIS is run in classic mode using the Server-Sent Events transport
The hosting application must be running in full trust mode
Note: If a client operating system is used, such as for development (Windows 8 or Windows 7), full versions of IIS or Cassini should not be used due to the built in limit of 10 simultaneous connections imposed This limit will be reached very quickly as connections are transient, frequently reestablished, and are not disposed of immediately when no longer being used. IIS Express should be used on client operating systems.
Note: For SignalR to use WebSocket, IIS 8 or IIS 8 Express must be used, the server must be using Windows 8, Windows Server 2012, or later, and WebSocket must be enabled in IIS. For information on how to enable WebSocket in IIS, see IIS 8.0 WebSocket Protocol Support.
SignalR can be used in a variety of web browsers, but typically, only the most recent two versions are supported.
Applications that use SignalR in browsers must use jQuery version 1.6.4 or major later versions (such as 1.7.2, 1.8.2, or 1.9.1).
SignalR can be used in the following browsers:
Microsoft Internet Explorer versions 8, 9, 10, and 11. Modern, Desktop, and Mobile versions are supported
Microsoft Edge
Mozilla Firefox: current version - 1, both Windows and Mac versions
Google Chrome: current version - 1, both Windows and Mac versions
Safari: current version - 1, both Mac and iOS versions
Opera: current version - 1, Windows only
Android browser
In addition to requiring certain browsers, the various transports that SignalR uses have requirements of their own. The following transports are supported under the following configurations:
*: 6+ required for full functionality.
While SignalR may run without major issues in older browser versions, we do not actively test SignalR in them and generally will not fix bugs that may appear in them.
StifleR uses the concept of 'Roaming Clients' and enables the ability to set bandwidth according to the client location and connectivity. A roaming client (in StifleR terms) is one that is not connected to the corporate network i.e. a known location/subnet or is non-domain joined and/or authenticated.
In these cases there are a couple of choices as to how these clients can be configured. These are determined by the StifleR Server setting DefaultRoamingBandwidth.
The default setting is 0 (disabled) which means that by default a StifleR client that roams will have all Bandwidth policies removed.
If, however, that parameter is set to anything other than zero Roaming policy will be applied (split between Delivery Optimization and BITS)
i.e. If a Default RoamingBandwidth of 50Mbs (51200) is set then the clients would get 25Mbs for BITS and 25Mbs for Delivery Optimization
There are two types of Roaming Client – Roaming and connected to a StifleR server: (possible if the client still has a route to the StifleR Server – via Azure for instance) and - Roaming but not connected to a StifleR server.
Well Connected locations are networks where the bandwidth available to clients is fairly generous (>100Mb/s). In this scenario StifleR can still assist with improving Peer-to-Peer and caching efficiencies, which help to offload both network and memory/CPU load from source servers (Distribution Points etc.)
How it Works:
Instead of setting a 'Target Bandwidth', you can set the location to 'WellConnected' and then set DO and BITS (BranchCache) Bandwidth limits. A Red Leader will still be selected, but the bandwidth allocated to 'Non-Red Leaders' is the same. This allows for faster P2P transfers and faster deployments in general.
The Default Setting is False - (Not Well Connected)
Note: You can change a subnet to Well Connected and the clients at that location will get the new Well-Connected bandwidth settings from the server. If you change back to Not Well Connected, the clients will not revert to the original Subnet Target Bandwidth until the next service restart.
Transport
*Internet
Explorer
Chrome
(Windows or iOS)
Firefox
Safari
(OSX or iOS)
Android
WebSockets
10+
current – 1
current - 1
current – 1
N/A
Server-Sent Events
N/A
current – 1
current - 1
current – 1
N/A
ForeverFrame
8+
N/A
N/A
N/A
4.1
Long Polling
8+
current – 1
current - 1
current – 1
4.1
StifleR automatically ‘learns’ about networks as the StifleR clients connect and report data to the server. The Server builds up a list of subnets with a default bandwidth limit set for each new one that is discovered. This information is stored in the StifleR Database file which is stored in the StifleR Server program data folder.
To manually “pre-configure” the StifleR Network Infrastructure you can load all of your network information into StifleR prior to deploying any clients. This can be achieved via automation through PowerShell/WMI scripting etc,.
As mentioned above, in the default process, when a StifleR Client reports in from a subnet that does not exist, a new subnet is automatically created with default parameters applied.
There is however a much more intelligent method that uses PowerShell scripting to Generate and then Modify settings for these newly discovered locations. This feature is enabled within the StifleR.Service.exe.config file using the following parameters:
NOTE: The default setting for each of these options is disabled (0). Changing this to a value of “1” enables the feature. Location in this context is not referring to a StifleR Enterprise “Location” but rather discovered subnets.
NOTE: Sample Generate and Modify scripts can be found in the installation folder.
Enable key
<add key="GenerateNewLocationsWithPowerShell" value="0"/>
Default path to the script for PS Generation of Sites
This first option is the most commonly used, as it allows you to set a default ‘template’ for a new subnet according to your preferences. For instance, the overall default Target Bandwidth for a new location may be 1024Mb/s, and you may want to set this to be higher (or lower).
PowerShell can generate any parameter for a new subnet and logic can be used to determine different settings depending on the incoming criteria (subnet, IP Address Range, Physical Location, Computer Name etc)
If the GenerateNewLocationsWithPowerShell setting is enabled, the script identified in the PowerShellExtensionLocationCreateScriptPath is executed as soon as a Client reports in a new subnet.
A basic script is as follows:
Once this data is returned you can then write some new data back to the new subnet
The new subnet must have a unique GUID
Once you have a way to identify the subnet you can edit configuration options. In the following snippet we set a Target Bandwidth of 4096 and setup the Delivery Optimization policy so that the clients in that subnet will only Peer within that subnet.
Finally, we write the new subnet – job done!
return $Location
Enable Key:
Default path to script for PS modification
This option is similar to the Generate function but allows you to Modify a subnet once is has been created. This enables you to have your Generate script set some defaults for new subnets and then let the Modify script change some further parameters depending on other criteria.
If the ModifyNewLocationsWithPowerShell setting is enabled, the script identified in PowerShellExtensionLocationModifyScriptPath is executed as soon as a new subnet has been created
A basic script is as follows:
Once we have the new location we can do some lookups, for example examine the IPAddress and set a new target bandwidth based on the Address Range – being in PowerShell land the sky is the limit! Here’s some pseudo code to give you an idea:
If subnet starts with 192 – then target bandwidth should be 10Mb
If subnet starts with 10 – then target bandwidth should be 2Mb
Once subnets are known to StifleR you can then group local subnets together in Parent/Child relationships to form Locations. You can then use these Locations to control Bandwidth usage for the multiple subnets or VLANs as a single administrative unit. As part of your StifleR infrastructure planning you should gather as much information as you can regarding your geographic locations and associated WAN/LAN configurations, speed etc and then group your subnets into StifleR Locations as required. Please feel free to contact us for recommendations in this regard. This process can be automated as above.
$locationId = [guid]::NewGuid()
