# Welcome to 2Pint documentation Welcome to the 2Pint Software documentation hub - the central resource for deploying, integrating, and maintaining 2Pint’s suite of products designed to make software and OS delivery faster, smarter, and more efficient. Our mission is to empower IT professionals with tools that optimize bandwidth usage, streamline OSD processes, and simplify large-scale deployments across distributed environments. *** ### **StifleR** StifleR is a real-time content distribution and network control platform designed to protect bandwidth while accelerating software delivery across any network. It provides full visibility and control over how content is downloaded by endpoints, without disrupting business-critical traffic. Working alongside Microsoft Endpoint Manager, Intune, Windows Update for Business, and other solutions, StifleR dynamically manages traffic using native Microsoft technologies such as BranchCache, Delivery Optimization, BITS, and LEDBAT. Administrators gain real-time insight into network usage, can throttle or prioritize traffic in low-bandwidth scenarios, and remotely troubleshoot endpoints using built-in tools. Whether endpoints are on LAN, WAN, VPN, WiFi, home networks, or in the cloud, StifleR automatically adapts to changing network conditions and locations, ensuring efficient, predictable, and controlled content delivery at scale {% content-ref url="/spaces/SdKKJqJhW8GvhMBmgTTJ/pages/64bS8yqxcOxyPbrq9fnP" %} [Prerequisites](/stifler/3.0/setup/prerequisites) {% endcontent-ref %} {% content-ref url="/spaces/SdKKJqJhW8GvhMBmgTTJ/pages/C2N0hgj5J5eIbXysow21" %} [Installation](/stifler/3.0/setup/installation) {% endcontent-ref %} *** ### **DeployR** DeployR is a next-generation operating system deployment solution designed for modern, flexible environments. It enables reliable deployment of Windows, Linux, and ChromeOS from cloud, on-premises, or hybrid infrastructures, with real-time monitoring and troubleshooting built in. As a core component of the 2Pint Software platform, DeployR combines a modern task sequence engine, web-based management, peer-to-peer content distribution, and live dashboards to support scenarios such as new device provisioning, break/fix recovery, and clean OS rebuilds. With native Windows Autopilot integration and extensibility through community-driven scripts and templates, DeployR is a powerful replacement for legacy tools like Microsoft Deployment Toolkit (MDT). {% content-ref url="/spaces/JO9NLelA0RS8JB4i9oaQ/pages/shix1der8yWAn3pVabIf" %} [Prerequisites](/deployr/1.1/setup/prerequisites) {% endcontent-ref %} {% content-ref url="/spaces/JO9NLelA0RS8JB4i9oaQ/pages/F5ARIcQfm9q5fHuHTQ5K" %} [Installation](/deployr/1.1/setup/installation) {% endcontent-ref %} {% content-ref url="/spaces/JO9NLelA0RS8JB4i9oaQ/pages/UVGB2UYunanxCJQJyKVB" %} [Updating](/deployr/1.1/setup/updating) {% endcontent-ref %} *** ### **iPXE Anywhere** A modern PXE and HTTP/HTTPS booting platform that enables dynamic and secure OS deployments. iPXE Anywhere works across VLANs, VPNs, and even the internet—delivering WinPE boot images and full OS installs from any location. {% content-ref url="/spaces/5nkrKH5nKL8LvEgvw7HO/pages/Tr5n55CuSTOsRw10vNCg" %} [Planning](/2pxe-server/planning/planning-your-implementation) {% endcontent-ref %} {% content-ref url="/spaces/5nkrKH5nKL8LvEgvw7HO/pages/k8mnNtpfg9IL7iPueCFp" %} [Installation](/2pxe-server/installation/installation-and-configuration) {% endcontent-ref %} *** ### **2PXE Web Service** A backend API and automation layer used by iPXE Anywhere and OSD Toolkit. Enables powerful workflows, reporting, and integration with Microsoft Configuration Manager and third-party tools via PowerShell. {% content-ref url="/spaces/dPQYwSRdBiXGQUCntFwx/pages/6u3S70edgCgpXbVDKl5g" %} [Installation](/ipxe-ws/installation/ipxe-anywhere-web-service-install) {% endcontent-ref %} *** ### **OSD Toolkit** A free utility that injects BranchCache and BITS into your WinPE environment—enabling peer-assisted Windows imaging at scale, with minimal WAN usage. Integrates seamlessly with StifleR for full deployment visibility and control. {% content-ref url="/spaces/2TKXuL2g2cUsjqBYN3Jc/pages/-LhD0CYUH2hOqb2JctTm" %} [Start Here - OSD Toolkit 3.1.9.0](/osd-toolkit) {% endcontent-ref %} # Your StifleR guide This is the StifleR 3.1 (current) release documentation. For other versions, please select the dropdown list at the top left and select the correct version. Welcome to the StifleR documentation site, the real-time content distribution control system from 2Pint Software. StifleR provides a complete, seamless re-architecting of how any content (software, updates, OS images etc.) is distributed through your business network.\\ \ StifleR is compatible with Microsoft Configuration Manager (SCCM), Microsoft Intune and hybrid environments — a perfect fit for the modern business infrastructure on a cloud journey. \ In this documentation, you will find the necessary information to successfully integrate StifleR into your environment, from initial evaluation to production roll out. ## From setup to success This guide will help you through every step of using StifleR — from setup to production deployment. For an overview of StifleR is, a summary of how it works, and an explanation of how it improves content delivery in SCCM, Intune, or hybrid environments, see the [About section](/stifler/about/stifler-overview). Next, you'll find the [prerequisites](/stifler/setup/prerequisites): infrastructure, supported systems, firewall requirements, and etc. The [Installation ](/stifler/setup/installation)section explains how to set up the StifleR components. Once installed, the [Configuration ](broken://pages/Ij2NSUaOTJEPNqhFsOMr)section guides you to create content policies, monitor activity, and use reports. ## Quick to start, easy to test Getting started with StifleR is straightforward. By reviewing the [prerequisites ](/stifler/setup/prerequisites)and completing the [installation](/stifler/setup/installation), you can quickly begin enhancing content distribution using native Microsoft technologies such as BranchCache and Delivery Optimization. With minimal initial configuration, StifleR can be deployed in a lab or production environment and then expanded and refined as needed to support enterprise-scale deployments. # Release notes {% updates format="full" %} {% update date="2026-08-26" %} ## StifleR 3.1.2634.667 * \- Added MOM 2.4 support: the proxy address is now delivered to clients via location policy * Added roaming client grouping by country * Added certificate-based application authentication for the Graph API, with secret-based authentication retained for backward compatibility * Improved performance by reducing overhead during Graph API token acquisition * Simplified the DeployR task sequence editor to prevent unintended deletions * Updated bundled third-party components to address reported security vulnerabilities * Fixed beacon bandwidth measurements failing on some clients * Fixed RemoteR connecting only to the first client opened in a tab, so remote tools now connect for each client opened * Fixed RemoteR disconnect notifications being shown for a client other than the one currently open * Fixed clients being shown as offline in Client Search after reconnecting * Fixed server-side AgentId assignment logic * Fixed dashboard charts not rendering when recreated, which could leave network group bandwidth usage graphs empty * Fixed extended browser caching of the dashboard, so updated dashboard files and configuration are picked up after an upgrade * Fixed OSD task sequence progress not displaying when no peer-to-peer transfer data was available * Fixed task sequence step definition options ordering * Fixed multi-line log record parsing in the log viewer * Fixed script paths for PowerShell scripts in Settings * Fixed the DeployR content item filter and entity version selection * Removed a duplicate version label from the DeployR content item version selection {% endupdate %} {% update date="2026-07-07" %} ## StifleR 3.1.2627.641 * Added roaming client grouping by country * Added MOM 2.4 proxy address to clients via location policy * Improved performance by reducing overhead during Graph API token acquisition * Fixed OSD task sequence progress not displaying when no peer-to-peer transfer data was available * Fixed task sequence step definition options ordering * Fixed DeployR entity version selection in the content item, step definition, and task sequence pickers * Fixed DeployR content item filtering * Fixed multiline log record parsing for log entries spanning multiple lines in task sequence logs * Fixed script paths for PowerShell (.ps1) scripts in Settings * Fixed server-side AgentId assignment logic * Fixed clients incorrectly shown as offline in Client Search after reconnecting {% endupdate %} {% update date="2026-06-22" %} ## StifleR 3.1.2626.583 * Introducing Role-Based Access Control (RBAC) * Migrated to new licensing platform * Added client read-only mode via feature-based policy * Added 2PXE infrastructure services and DeployR Community support * Improved OIDC sign-in reliability and dashboard authentication handling * Security improvements and vulnerability fixes {% endupdate %} {% endupdates %} # Prerequisites StifleR consists of several interconnected components (Server, ActionHub, Dashboard, Beacon, WMI Agent and Client). Each requires compatible OS versions, frameworks, and communication access. \ Before installing the StifleR components, please ensure the following pre-requisites are in place: ## Permissions StifleR controls access to the two main server components the SignalR Hub and the Web service. This control applies to both users (who access StifleR Dashboards) and StifleR Clients (who access the SignalR Hub). Access is managed through Active Directory Global groups, which must be created in advance. It is recommended to define two groups: * StifleR Global Admins - Full read and write right access to ALL objects. * StifleR Global Read - Gives read only rights to ALL locations and statistics. Including WMI. *** ## Firewall Configuration {% hint style="danger" %} Please review it carefully before installation. {% endhint %} Ensure that network communication between all StifleR components is not blocked by internal or external firewalls. Each service relies on specific ports for data exchange. [Complete list of required Firewall ports and directions.](/stifler/setup/prerequisites/firewall-ports) *** ## Antivirus Exclusions To ensure stable operation and prevent interference with communication or telemetry, configure antivirus or endpoint protection exclusions for all StifleR components. Exclude the common installation and data directories from active scanning: * C:\Program Files\2Pint Software\\ * %ProgramData%\2Pint Software\StifleR\\ * Additionally, exclude each service executable corresponding to the installed components (for example StifleR.Server.exe) *** ## StifleR server * Windows Server 2019 or newer * Minimum 4 vCPUs, 4 GB RAM (scale with client count) * Minimum 10 GB free space for logs and telemetry * .NET Framework: 4.8 (mandatory) * Microsoft SQL Server 2016+ (Express, Standard, or Enterprise) * db\_owner permissions required for StifleR DB account System performance and capacity depend on deployment scale and client volume. [A complete overview of recommended specifications](/stifler/setup/prerequisites/hardware-requirements). ### Service Account * Dedicated domain or local account * “Log on as a service” right * Read/write access to %ProgramData%\2Pint\StifleR * Must have db\_datareader and db\_datawriter on StifleR DB *** ## StifleR dashboard * Windows Server 2019 or newer * 2 vCPUs, 4 GB RAM minimum (scale with concurrent users) * .NET Framework: 4.8 (mandatory) * IIS ### Certificates * Valid SSL certificate required for HTTPS deployment * Optional internal CA or self-signed acceptable for test environments *** ## Action Hub * Windows 11 (Pro, Enterprise, Education), including ARM64-powered Windows 11 devices, and Windows Server 2016 or newer. * .NET Framework: 4.8 (mandatory) ### Service Account Recommended to use a dedicated domain service account with: * “Log on as a service” right * Write permissions to %ProgramData%\2Pint\StifleR and log directories * Account must have sufficient rights to execute configured scripts or API calls. *** ## Beacon * Windows 11 (Pro, Enterprise, Education), including ARM64-powered Windows 11 devices, and Windows Server 2016 or newer. * .NET Framework: 4.8 (mandatory) *** ## StifleR Client * Windows 10 and 11 (Pro, Enterprise, Education), including ARM64-powered Windows 11 devices, and Windows Server 2016 or newer. * .NET Framework: 4.8 (mandatory) ### Service Account * Requires read/write access to: * %ProgramData%\2Pint\StifleR (for local cache and logs) * HKLM\Software\2Pint\StifleR (for configuration and telemetry keys) *** ## WMI Agent (optional) * Windows 11 (Pro, Enterprise, Education), including ARM64-powered Windows 11 devices, and Windows Server 2016 or newer. * .NET Framework: 4.8 (mandatory) ### Service Account Recommended to run under a dedicated domain account with: * Local Administrator rights on target endpoints * “Log on as a service” permission * Remote WMI access rights in root\cimv2 and root\Microsoft\Windows\DeliveryOptimization * If SQL reporting is enabled, the account must have db\_datawriter on the StifleR database. # Hardware requirements The following table can be used as a summarized view of the hardware requirements for StifleR.
SizeCPUMemoryNICDisk
Under 10,000 clients4 cores8GBVirtual / 1GB1x SSD for DBs
10,000 — 20,000 clients8 cores16GB1GB / 10GB2x SSD for DBs
20,000 — 50,000 clients16 cores32GB10GB4x SSD for DBs
50,000 — 100,000 clients32 cores64GB2x10GB6x SSD for DBs
100,000 — 200,000 clients48 cores256GB4x10GB8x SSD for DBs
### CPU 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. ### Memory StifleR writes a lot of historical data to databases, and also maintains in-RAM memory objects. Since each connection and all connection data is stored in RAM a decent allocation of RAM is recommended but 32GB should be plenty for most installations. ### Disk 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. ### Network Connectivity Each client initiates a non-managed SignalR client connection (web sockets) to the server, so if you want 100k clients to connect 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. ### Redundancy 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. # Firewall ports This page provides a detailed overview of the network ports required for the **InterVLAN** feature and related services. It outlines the specific client ports used by **StifleR Client** and **BranchCache**, including communication flow and directionality. Refer to the tables below for the full list of ports, usage descriptions, and whether they require explicit allowance in your firewall configuration. Additionally you can review [BranchCache Distributed Cache Mode](https://stifler.docs.2pintsoftware.com/introduction/technical-overview/2pint-branchcache-administrator-guide#toc462952235) for firewall ports needed for BranchCache communications #### Stifler Service local firewall port openings required — outgoing
NameDescriptionLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
StifleR ServiceGlobal catalog LDAPAnyfor Domain accounts usage32683268TCPNo
Stifler ServicehttpsAnyConnection for the dashboard443443TCPNo
Stifler ServiceSQL Server Service BrokerAnyonly if SQL is enabled40224022TCPYes
Stifler ServiceSQL Server serviceAnyonly if SQL is enabled14331433UDPYes
#### Stifler client local firewall port openings required — incoming
NameExecutableLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
Blue Leader Data From Remote Peer TwoPint.PeerDist.BlueGreenLeader.exeAnyAny1337AnyTCPYes
Green Leader Peer DataTwoPint.PeerDist.BlueGreenLeader.exeAnyAny1337, 1339AnyTCPYes
Blue Leader Peer DataTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal Subnet1338AnyTCPYes
Peer ProbesTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal Subnet3702AnyUDPYes
Blue Leader Peer Probe MatchTwoPint.PeerDist.BlueGreenLeader.exeAnyAnyAny3702UDPYes
mDNSTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal Subnet5353AnyUDPYes
Stifler ServiceStifler ClientAnyAny1414AnyTCP
#### Stifler client local firewall port openings required — outgoing
NameExecutableLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
Beacon - iPerf packetsAnyStifler BeaconsAny5201UDPYes
Beacon - FastPingAnyStifler BeaconsAny5200TCPYes
Blue Leader Data to requesting PeerSYSTEMAnyAnyAny1338TCPYes
Blue Leader Data From Remote PeerTwoPint.PeerDist.BlueGreenLeader.exeAnyAny1337AnyTCPYes
Green Leader Peer DataTwoPint.PeerDist.BlueGreenLeader.exeAnyAnyAny1337.1339TCPYes
Blue Leader Peer DataTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal SubnetAny1338TCPYes
Peer ProbesTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal Subnet3702AnyUDPYes
Blue Leader Peer Probe MatchTwoPint.PeerDist.BlueGreenLeader.exeAnyAnyAny3702UDPNo
Blue Leader Probe PortTwoPint.PeerDist.BlueGreenLeader.exeAnyAny37033703UDPYes
mDNSTwoPint.PeerDist.BlueGreenLeader.exeAny5353UDP
Access to Stifler ServiceStifler.Client.exeAnyAny or Stifler serverAny1414UDPNo
Access to Stifler ServiceStifler.Client.exeAnyAny or Stifler serverAny1414TCPNo
Access to Stifler ServiceTwopint.remotetools.host.exeAnyAny or Stifler server + Action hubsAny1415UDPNo
Access to Stifler ServiceTwopint.remotetools.host.exeAnyserver + Action hubsAny1415TCPNo
Access to Stifler ServiceBrowserAnyStifler ServerAny9000TCPNo
Access to Stifler ServiceBrowserAnyAny or Stifler serverAny1414TCPNo
Access to Stifler ServiceBrowserAnyAny or Stifler server + Action hubsAny1415TCPNo
#### BranchCache local firewall port openings required — incoming
NameExecutableLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
BranchCache Content Retrieval (HTTP-In)SYSTEMAnyAny1337AnyTCPYes
BranchCache Hosted Cache Server (HTTP-In)SYSTEMAnyAny1339.443AnyTCPYes
BranchCache Peer Discovery (WSD-In)%SYSTEMROOT%\system32\svchost.exeAnyLocal Subnet3702AnyTCPNo
#### BranchCache local firewall port openings required — outgoing
NameExecutableLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
BranchCache Content Retrieval (HTTP-Out)SYSTEMAnyAnyAny1337TCPYes
BranchCache Hosted Cache Client (HTTP-Out)SYSTEMAnyAnyAny1339.443TCPYes
BranchCache Hosted Cache Server(HTTP-Out)SYSTEMAnyAny1339.443AnyTCPYes
BranchCache Peer Discovery (WSD-Out)%SYSTEMROOT%\system32\svchost.exeAnyLocal SubnetAny3702UDPNo
# Network topology When deploying the StifleR solution in your environment, it is important to consider your network topology. An important concept to understand when working with Network Topologies in StifleR is the relationship between three network types: * **Network –** an individual subnet. * **Network Group –** a Network Group contains one or more subnets (defined as Networks) which are reachable with good speed to each other.\ Some additional information: * Traffic is not considered a cost inside a network group * Designed to limit peer-to-peer traffic at certain sites * Peer-to-peer traffic is never shared between network groups * Bandwidth controls are applied to Network Groups, so understanding bandwidth limitations within this level of the topology is important to consider * **Location –** represents a physical location in StifleR and contains one or several Network Groups. It contains physical information such as address, administrators etc. It defines a physical, worldly location, hence the name Location. A Location can store one or several Network Groups which contain Networks. The diagram below illustrates the logical structure of a StifleR network topology.
# Installation This section provides a step-by-step process to install each component of the StifleR platform. Whether you're evaluating via Proof of Concept or implementing a full production deployment, this is the correct order of installation to get a clean and functional environment. {% hint style="success" %} We recommend when deploying 2Pint software in your environment, to initially validate against your UAT or QA environment before rolling out in production. {% endhint %} [Testing and validation](/stifler/setup/testing-and-validation) are used to confirm that StifleR operates correctly and meets expectations in your environment. A Proof of Concept can be used to verify behavior, performance, and visibility before expanding usage, and the same testing scenarios can also be applied in production environments in a controlled manner. Before proceeding to installation, ensure that: * [Required firewall ports are opened](/stifler/setup/prerequisites/firewall-ports) * [Antivirus exclusions are applied](/stifler/setup/prerequisites#antivirus-exclusions) * [Necessary permissions are granted](/stifler/setup/prerequisites#permissions) ## Order of installation For a standard StifleR implementation, the recommended order for deploying and configuring each component is as follows: 1. [Install StifleR Server](/stifler/setup/installation/stifler-server-installation) – Core engine managing all operations. 2. [Install StifleR Dashboard](/stifler/setup/installation/stifler-dashboard-installation) – Web UI for monitoring and configuration.

If you are installing StifleR for DeployR management only you don't need to install or configure the rest of StifleR components. StifleR client is optional in boot media for monitoring purposes.

3. [Install Action HUB](/stifler/setup/installation/stifler-actionhub-installation) – Dynamic, real-time actions across the StifleR ecosystem. 4. [Install Beacon](/stifler/setup/installation/stifler-beacon-installation) – Gathers telemetry and identifies active subnets. 5. [Install StifleR Client](/stifler/setup/installation/stifler-client-installation) – Client that monitors network activity, reports and enforces policies. 6. [Install WMI Agent](/stifler/setup/installation/stifler-wmi-agent-installation) (optional) – Agent that replaces traditional WMI. 7. [Install CacheR](/stifler/setup/installation/cacher-installation) (optional) – content tracking and pre-caching. ## Prerequisites for Configuration Manager If Configuration Manager is being used as part of the PoC, the following additional setup is required. Detailed configuration steps can be found on the linked documentation pages. {% tabs fullWidth="false" %} {% tab title="Enabling BranchCache" %} BranchCache is the key Microsoft peer-to-peer technology which StifleR optimizes. It is important to enable BranchCache on all relevant systems. * If using Configuration Manager, enable BranchCache on all Servers / CM distribution points * If you have a simple lab environment, you should perform this step (if required) on all your distribution points * If you are planning on testing in a production environment, make sure that you perform this step ONLY on the relevant distribution point your test clients will obtain their deployment content from. See: [Configuring BranchCache on Windows Server](/stifler/configuration/windows-server-branchcache-configuration) {% endtab %} {% tab title="Enabling DO" %} As well as BranchCache, StifleR can utilize download jobs which use Microsoft's Delivery Optimization (DO) peering technology. See: [Configuring Delivery Optimization](/stifler/configuration/delivery-optimization-configuration) {% endtab %} {% tab title="BITS Policy " %} Check for and remove any BITS policy that has been set within Configuration Manager and/or Active Directory. Such settings can interfere with the efficient operation of the automated Bandwidth mechanisms in StifleR. In the Configuration Manager console, BITS settings can be configured in "Client Settings":

Make sure that this is set to No (default setting), as this configures a local BITS policy on the clients which we do not want.

**Remove any BITS AD Group Policy (if configured)**\ Within the Active Directory Group Policy Editor, go to: \ Computer Configuration -> Policies -> Administrative templates -> Network -> Background Intelligent Transfer Service (BITS) Ensure that there are no BITS policies configured. If present, remove them to avoid affecting any test clients. {% endtab %} {% endtabs %} ### [**Configure the network topology**](/stifler/configuration/stifler-network-locations) * Configure target bandwidth * Configure subnet description * Configure Delivery Optimization ## Upgrading from StifleR 3.0 to 3.1 The upgrade from 3.0 to 3.1 is in-place. Install the new server over the existing installation and restart the service. ### After upgrading #### Set up RBAC roles RBAC is new in 3.1. No roles exist after upgrade — you need to create them if you want to use fine-grained access control. Your existing Global Admin and Global Read configuration (set via the Config Editor `AdministratorGroup` and `ReadGroup` settings) carries over automatically. Users in those groups will continue to have full or read-only access as before. If you do not set up any roles, users who are not Global Admin or Global Read will be blocked at login. Create at least one role with appropriate permissions for your users before rolling out to production. See [Roles and Permissions](https://2ps.visualstudio.com/StifleR/_wiki/wikis/StifleR.wiki?wikiVersion=GBwikiMaster\&pagePath=/StifleR%203.1/Documentation%20\(drafts\)/roles%20and%20permissions) for how to create roles and assign claim rules. #### Remote Tools permissions are not migrated In 3.0, Remote Tools had its own access control configuration. That configuration is **not carried over** to 3.1. ### Rolling out 3.1 clients You do not need to upgrade all clients at the same time as the server. | Scenario | Behaviour | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | 3.0 client → 3.1 server | Works normally. 3.0 clients are unaware of the new capability endpoint and ignore it. | | 3.1 client → 3.0 server | Client defaults to standard mode. The 3.0 server does not support the licensing endpoint, so the client assumes no restriction is intended. | You can upgrade the server first and roll out 3.1 clients at your own pace. 3.1 clients still pointing at a 3.0 server will run in full mode — no disruption during the transition. # StifleR Server installation ## Prerequisites * Review [StifleR Server Requirements](/stifler/setup/prerequisites/hardware-requirements) page for server specifications, etc. * Open the required [firewall ports](/stifler/setup/prerequisites/firewall-ports) * Create and populate the [StifleR Administrative Security Groups](/stifler/setup/prerequisites#permissions) * Activate Microsoft .NET 4.8 * Provide installation account with Administrator rights * Enter license key (optional at this point) * Decide on whether the StifleR Service will be using SSL \ (optional at this point, but recommended). For more information on using SSL, see [this page](/stifler/configuration/securing-stifler-operations-with-ssl). ### Optional components **Internet Information Services (IIS):** The StifleR Server API runs its own web service, so IIS is **NOT** required unless: * You will be hosting the [StiflerRulez](#configure-the-stifler-rules-xml) site on the same server. {% hint style="info" %} Quick Hint for when updating, when running any of the 2Pint installers, the process will stop the service for that application, then set the service to manual to make sure it doesn't get started again during the process. This is why it's important to run the Config Editors after the upgrade, as that will both start the service again and set it to automatic. {% endhint %} ## Installation From an Elevated Command prompt launch **StifleR.Installer64.msi**. You also can launch installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
*** At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
*** At the "Destination Folder" screen, enter the path to the directory where the StifleR server program files should be installed and then click **Next**.
*** At the "Ready to install..." screen, click **Install** to begin the installation.
*** At the "Completed" screen, the installation wizard is complete. Make sure that checkbox on the bottom left is set to Launch Configuration Editor. Click **Finish** and enjoy a nice cup of tea, you’ve earned it.
*** After you press finish, a new configuration window will pop up. To get started, you will need configure several items: * Groups with full Administrator access to StifleR * Groups with Read access to StifleR * StifleR Server license key * SignalR endpoint certificate thumbprint * Web Service endpoint certificate thumbprint There may be other items to configure, based on your environment. Toggle over to "Show advanced" to see all of those other items. {% hint style="info" %} Note: The Administrators groups are not created automatically. They must be created in advance. Please refer to the [StifleR Administrative Security Groups](broken://pages/6dTpPnF4VVC0AG8h8eb3) section. {% endhint %}
*** {% hint style="info" %} Note: If using a local or domain account, the account must have "Logon as a Service" rights. {% endhint %} *** Aftrer configuring critical settings, please click the Verify button. After verification is complete, press the Save button to save all settings and start the StifleR service. *** ## Post-installation checks ### Checking the StifleR service state Open services.msc to validate that the **2Pint Software Stifler Server** service is installed and running, or run the following PowerShell command and validate that the service is present and running: ``` Get-Service -Name StifleRServer | Select Status ``` ### Checking the StifleR installation directory * If using a licensing file for licensing, check for the **License.nfo** files. If this is missing the service may not be licensed properly. * Open up the configuration file, [**StifleR.Service.exe.config**](broken://pages/nHStlYiqePE9p1g7bKrM), and check that the expected values are present. ### Checking the event logs To validate that the StifleR Server Event Logging structure has been created, execute the following PowerShell command: ``` Get-WinEvent -ListLog TwoPintSoftware-StifleR.Service-* | Where-Object { $_.RecordCount } ``` Validate the following output:
### Checking WMI configuration Execute the following PowerShell command to verify that the WMI Class Root\StifleR and methods were created successfully: ``` Get-CimClass -Namespace Root\StifleR -ClassName StifleREngine | where {$_.CimClassMethods} | Select CimClassName, CimClassMethods ``` Validate the following output:
Execute the following PowerShell command to get the StifleR License information: ``` Get-CimInstance -NameSpace Root\StifleR -ClassName StifleREngine ``` Validate the following output:
### Checking API permissions To test access to the StifleR Server API, open a web browser, and enter the StifleR Server URL such as: ***http(s)://servername:9000/api/test*** The page should display the results of your permissions as in the example below:
### Checking StiflerRules website availability To learn more about this file see: [StifleRulez.xml Configuration Guide](/stifler/configuration/stiflerulez.xml-2.x-definitions) This file is hosted on GitHub, but you can also host it yourself on the same server that will host the Dashboard. If you'd like to host it in your environment, follow the instructions in the [StifleRulez.xml Configuration Guide](/stifler/configuration/stiflerulez.xml-2.x-definitions). # StifleR Dashboard installation Prerequisites ## Installation From an Elevated Command prompt launch **StifleR.Dashboard.Installer64.msi**. At the "Welcome" screen, feel welcomed, and then click **Next**.
*** At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
*** At the "Destination Folder" screen, enter the path to the directory where the StifleR dashboard program files should be installed and then click **Next**.
*** At the "Select Operation Mode and Parameters" screen, verify the URLs for the dashboard to connect to the StifleR server and dashboard web service. By default, the port number for the StifleR service is 1414. If during the [StifleR Server installation](/stifler/setup/installation/stifler-server-installation), a different port was used, modify the URL accordingly. Once complete, click **Next** to continue. {% hint style="info" %} Note: By default, the installation wizard will define the URLs as HTTP-based sites. It is acceptable to install the Dashboard using HTTP for testing, but in production, it is strongly recommended to use HTTPS. To configure the Dashboard to use HTTPS, simply change the URLs to https\://\:\.\ For more information on how to secure IIS for HTTPS, see: [Using a Web Server Certificate](/stifler/configuration/securing-stifler-operations-with-ssl/using-a-full-iis-certificate). {% endhint %}
*** At the "Ready to install..." screen, click **Install** to begin the installation.
*** At the "Completed" screen, the installation wizard is complete. Click **Finish**.
## Post installation #### Confirm Config File Open notepad elevated, browse to the server.json file located in the C:\Program \ Files\2Pint Software\StifleR Dashboards\Dashboard Files\assets\config folder, and ensure the controller and hub values are set to [https://FQDN:Port](https://documentation.2pintsoftware.com/stifler/setup/installation/https:/FQDN:Port) as in the examples below (these should already be set properly from the installation): * "controller": "" * "hub": ""
### Installed to non default location If you've installed the dashboard to a non-standard location, IE D:\2Pint\Dashboard, you must update the StifleR config so it knows where to find the dashboard. If you don't, then you'll get some errors trying to pull up the dashboard through port 9000.
### Testing the StifleR Dashboard website Navigate to the StifleR Dashboard website by visiting the URL defined during the setup wizard. By default this would be something like:\ ****
# StifleR ActionHub installation ## Prerequisites * Windows 11 Pro, Enterprise, Education or Windows Server 2016 or newer * .NET Framework: 4.8 (mandatory) ## Installation From an elevated command prompt launch **StifleR.ActionHub.msi**. You also can launch installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the StifleR Dashboard program files should be installed and then click **Next**.
At the "Ready to install..." screen, click **Install**
At the "Completed" screen, the installation wizard is complete. Click **Finish.**
After Installation you will need to do configuration in Config Editor. Enter the StifleR Server URL and the URL for ActionHub. In the example, ActionHub is installed on the same server as StifleR, so we're using the same name, but specifying port 1415 for ActionHub.
## Post Installation After ActionHub is installed, navigate in your StifleR Dashboard to the infrastructure services list. You will find all of your installed ActionHubs and will need to approve them under Actions.
# StifleR Beacon installation For more information about what a Beacon Server is and does, see the [Beacons Page](/stifler/operations-and-features/beacons). ## Prerequisites | Requirement | Detail | | -------------------------- | -------------------------------------------------------------- | | Operating system | Windows Server 2016 or newer; Windows 10 version 1607 or newer | | Runtime | Microsoft .NET 8 | | Network — inbound TCP 5201 | iPerf3 bandwidth measurement port | | Network — inbound TCP 5200 | FastPing latency check port | | Credentials | Local administrator | | StifleR Server | Must be running and reachable before the beacon can register | Both ports must be reachable from the subnets whose clients will be measured. If you\ use Windows Firewall, the installer creates the required rules automatically. For\ third-party firewalls, open TCP 5200 and TCP 5201 inbound. > **iPerf3 is included.** The beacon installer ships iPerf3 as part of the installation.\ > You do not need to install iPerf3 separately on the beacon, nor on client machines —\ > the StifleR Client agent ships its own copy. *** ## Installation Steps 1. Download the beacon installer (`StifleR.Beacon.x64.msi`) from 2Pint Software. 2. Run the installer from an elevated command prompt or right-click → **Run as**\ **administrator**. 3. Accept the license agreement and choose a destination folder (default is\ `C:\Program Files\2Pint Software\StifleR Beacon`). 4. Click **Install**. The installer registers the beacon as a Windows service\ and starts it. 5. After installation completes, open the **StifleR Beacon Config Editor** from the\ Start menu or the installation directory. 6. Set **StifleR Server** (under **Infrastructure**) to the URL of your StifleR\ Server API, for example `https://stifler.contoso.com:9000/`. 7. Click **Save** and restart the beacon service. *** ## Post-Installation: Approving the Beacon The beacon registers with the StifleR Server automatically on startup. It will not\ be used for measurements until it has been approved. 1. Open the StifleR Dashboard. 2. Navigate to **Administration → Infrastructure Services**. 3. Find the newly registered beacon (it will show **Pending** status). 4. Click the beacon entry and select **Approve**. Once approved, the beacon appears on the **Beacons** page and is available for\ assignment to network groups, locations, or areas. *** ## Verifying the Installation After approval, confirm the beacon is healthy: * The **Beacons** page shows the beacon with an **Online** status indicator. A beacon\ is considered online if it has sent a heartbeat within the last 30 seconds (default\ threshold; configurable in the server settings). * The **Infrastructure Services** page shows the beacon version and last heartbeat\ time. If the beacon shows as offline immediately after approval, verify that the StifleR\ Server URL is correctly configured in the Config Editor and that the service has been\ restarted after the change. # StifleR Client installation ## Prerequisites * Windows 10 or later * Windows Server 2016 or later * Supported are x86 or x64 versions of the operating systems (x86 for Windows 10 only) * Professional, Enterprise, Education, or LTSC editions for client operating systems * Microsoft .NET 4.8 must be installed ## **Installation** ### **Manual installation** From an elevated command prompt launch **StifleR-ClientApp.msi**. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the StifleR Client program files will be installed and then click **Next**.
At the "Ready to install..." screen, click **Install** to begin the installation.
At the "Completed" screen, the installation wizard is complete. Click **Finish** and enjoy a nice glass of craft beer, you’ve earned it.
After finishing installation, the configuration tool will open. Enter the URLs and settings.
StifleR Rules URL needs to be updated for something you host internally, or one hosted on GitHub:\ Set the StifleR Server URL(s) to your StifleR Server with Port 1414. Then configure rest of the Client settings how you'd like for your environment {% hint style="info" %} There is no shortcut in the Start Menu for the StifleR Client Configuration App. It can be launched directly from its install location: \*installation path\*\2Pint Software\StifleR Client\TwoPint.ConfigEditor.Wpf\TwoPint.ConfigEditor.Wpf.exe {% endhint %} ### Unattended installation With StifleR 2.14 there is an option to install StifleR Client unattended. To take advantage of this option you will need to install one client using the manual approach. After completion, you will be able to export the settings that you have configured into a .2psimport file. To export the file – which you can then use to import for unattended installations – launch the Client Configuration Editor located here: C:\Program Files\2Pint Software\StifleR Client\TwoPint.ConfigEditor.Wpf\TwoPint.ConfigEditor.Wpf.exe Once the editor is open, customize the settings for the environment then go to Export -> Create 2PS import file for MSI only, and save it with a filename such as: settings.2psImport.
This file will contain the required settings in custom JSON format, where any string value containing " " (space) is replaced with "%20", and final output is stripped of all " " (space); here is an example: {% hint style="info" %} You will need to open this file with a text editor to view the contents {% endhint %} ``` {"SettingsOptions":{"StifleRulezURL":"https://stifler.company.com/StifleRulez.xml%20","LogEventLevel":"Verbose","StiflerServers":"[\u0022http://stifler.company.com:1414\u0022]","UseServerAsClient":"True","SignalRLogging":"True"}} ``` In order to use this configuration together with an MSI installer, you will need to add the **OPTIONS=** parameter ``` msiexec /qn /l*v "log.log" /i StifleR-ClientApp-x64.msi OPTIONS={"SettingsOptions":{"StifleRulezURL":"https://stifler.company.com/StifleRulez.xml%20","LogEventLevel":"Verbose","StiflerServers":"[\u0022http://stifler.company.com:1414\u0022]","UseServerAsClient":"True","SignalRLogging":"True"}} ``` Alternatively, if you add the 2psimport file into your source content, you can call it directly as in this example:
``` msiexec /i StifleR-ClientApp-x64.msi AUTOSTART=1 OPTIONS="settings.2psImport" /quiet /l*v "C:\Windows\Temp\StifleRClientInstall.log" ``` Note for **ConfigMgr** environments, we recommend creating a install.cmd, so you can set the realtive path with the %\~dp0 syntax, the install string would be: ``` msiexec /i StifleR-ClientApp-x64.msi AUTOSTART=1 OPTIONS="%~dp0settings.2psImport" /quiet /l*v "C:\Windows\Temp\StifleR3.0ClientInstall.log" ```
Then in **ConfigMgr**, your install command would be install.cmd
When installed manually, once complete the installer will launch the Configuration Editor. After the settings have been confirmed, the Configuration Editor will set the service to "Automatic Startup" and then start it. In unattended mode, to start the service when completed, pass the parameter **AUTOSTART=1** to MSI. Note that this parameter will only be used in unattended/quiet or basic mode, and project has *Config Editor* support. ``` msiexec /quiet /l*v "StifleRClientInstall.log" /i StifleR-ClientApp-x64.msi AUTOSTART=1 OPTIONS={"SettingsOptions":{"StifleRulezURL":"https://stifler.company.com/StifleRulez.xml%20","LogEventLevel":"Verbose","StiflerServers":"[\u0022http://stifler.company.com:1414\u0022]","UseServerAsClient":"True","SignalRLogging":"True"}} ``` {% hint style="info" %} Replace stifler.company.com with the name of your StifleR server. {% endhint %} ## Post installation ### Service status Open services.msc to validate that the **2Pint Software Stifler Client** service is installed and running. Alternatively, run the following PowerShell command and validate that the service is present and running: ``` Get-Service -Name StifleRClient | Select Status ``` Validate the following output:
### Event logging To validate that the StifleR Server event logging structure has been created, execute the following PowerShell command: ``` Get-WinEvent -ListLog TwoPintSoftware-StifleR.ClientApp* | Where-Object { $_.RecordCount } ``` Validate the following output:
# StifleR WMI Agent installation If you’d like to request a trial and explore our product, please visit [this](https://2pintsoftware.com/products/stifler#download) page. Existing customers should use the link provided by our team to proceed. ## Prerequisites * Windows 11 Pro, Enterprise, Education or Windows Server 2016 or newer * .NET Framework: 4.8 (mandatory) ## Installation From an elevated command prompt launch **StifleR.WMIAgent.msi**. You can also launch the installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the StifleR WMI Agent program files will be installed and then click **Next**.
At the "Ready to install" screen, click **Install** to begin the installation.
At the "Completed" screen, the installation wizard is complete. Click **Finish**.
After installation you will need to enter the URL(s) for your StifleR Server in the configuration settings editor.
# CacheR installation CacheR lets you take your content distribution efficiency to the next level. Building on the long-established best practices of StifleR, with CacheR you can now have full visibility of ‘content at rest’ (in the local cache) of your endpoints as well as the real-time content download dashboards provided. For optimal peering performance and bandwidth saving it is critical to know and control where content is cached. CacheR allows you to not only visualize where business-critical applications have been cached, but also to automate further pre-caching where needed. Pre-caching content closer to your end users ensures that critical content such as operating systems and large applications can be installed quickly and with minimal network impact. This leads to a much-improved end user experience. ## Prerequisites * Working Stifler Setup with version 3.0 or newer * Windows Server (2Pint used Windows Server Standard 2022) * MS SQL (Express works for lab but not recommended for production) * SQL Management Studio * Webserver certificate ### Create SQL database and tables manually (optional) {% hint style="info" %} As long as the account running the service has access to SQL and is allowed to create databases and tables it will be automatically created and this can be skipped. If not it needs to be created using the following process. {% endhint %} {% hint style="warning" %} If you let the service create the database make sure that the account connecting with SQL Mgmt Studio is sysadm on the SQL service so the database can be accessed. {% endhint %} On the server, open SQL Management Studio (install if needed) and create a new Database called CacheR.\ If on a remote server, make sure to apply the correct security rights for the services. (Computer account if running as local system, or the service account used for the services) ## Installation ### Install WebApi service {% hint style="info" %} WebAPI service is the service the clients use to report the local status of cache content and what the StifleR dashboard is using when communicating with CacheR. {% endhint %} From an Elevated Command prompt launch **TwoPint.CacheR.WebApi.Installer64.msi**. You also can launch installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the CacheR WebApi program files should be installed and then click **Next**.
At the "Ready to install..." screen, click **Install** to begin the installation.
At the "Completed" screen, the installation wizard is complete. Make sure that checkbox on the bottom left is set to Launch Configuration Editor. Click **Finish** and enjoy a nice cup of tea, you’ve earned it.
### Configure CacheR WebAPI Service Use the **Configuration Editor** to complete the initial CacheR setup. All required fields must be populated before the service can be verified and started. * **Enable HTTPS** (recommended) to secure communication between CacheR, clients, and upstream services. HTTPS is strongly recommended for production environments. * In **HostCertificateThumbPrint**, enter the thumbprint of the SSL certificate bound to the CacheR service.The certificate must be present in the local computer certificate store and include the appropriate DNS name. * **Provide the SQL connection string** used by CacheR WebAPI to store operational data. Example: ``` Server=.\SQLEXPRESS;Database=CacheR;Trusted_Connection=True;MultipleActiveResultSets=true;TrustServerCertificate=True ``` * **Define the StifleR Server URL** that CacheR will register with and report to.\ Example: ``` https://dp01.corp.mblab.org:9000/ ``` * Click **Verify** to validate all settings. Once verification completes successfully, click **Save** to apply the configuration. * After saving, a confirmation dialog will appear indicating that the configuration was saved successfully. You will be prompted to set the **CacheRWebAPI** service startup type to **Automatic** and start the service. Select **Yes** to apply the startup configuration and start the service immediately.
### Install Worker Service {% hint style="info" %} The CacheR Worker service is responsible for connecting to content sources and calculating content hashes. It also generates the ZIP files that are used by clients when reporting content status to the CacheR Web API. These ZIP files are downloaded by the clients directly from the Web API as part of the reporting process. {% endhint %} From an Elevated Command prompt launch **TwoPint.CacheR.Worker.Installer64.msi**. You also can launch installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the CacheR Worker service program files should be installed and then click **Next**.
At the "Ready to install..." screen, click **Install** to begin the installation.
At the "Completed" screen, the installation wizard is complete. Make sure that checkbox on the bottom left is set to Launch Configuration Editor. Click **Finish** and enjoy a nice cup of tea, you’ve earned it.
#### Configure CacheR Worker service * Enter the **Domain** where the service account resides. * In **UserName**, specify the service account used by the CacheR Worker service.\ This account is used to access Distribution Point IIS shares and calculate content hashes. * Provide the **Password** for the specified service account. * **Provide the SQL connection string** used by CacheR WebAPI to store operational data. Example: ``` Server=.\SQLEXPRESS;Database=CacheR;Trusted_Connection=True;MultipleActiveResultSets=true;TrustServerCertificate=True ``` * Click **Verify** to validate all settings. Once verification completes successfully, click **Save** to apply the configuration. * After saving, a confirmation dialog will appear indicating that the configuration was saved successfully. You will be prompted to set the **CacheRWebAPI** service startup type to **Automatic** and start the service. Select **Yes** to apply the startup configuration and start the service immediately.
### Configure Stifler to enable CacheR To enable CacheR functionality, start the **StifleR Service Config Editor** on the machine where it is installed. Enable **Show Advanced**, search for **CacheR**, and then enable **Show CacheR features**. **Verify and Save the configuration** and restart the StifleR service if prompted to ensure the changes take effect.
Once CacheR features are enabled, open the **StifleR Dashboard** and navigate to **Infrastructure Services**. The CacheR server will appear in the list and must be approved before it can be used by StifleR.
After approval, select the CacheR server and set it as the **Default** CacheR instance. If multiple CacheR servers exist in the environment, only one can be configured as the default at any given time.
When the CacheR server is approved and set as default, additional CacheR related sections will become available in the **StifleR Dashboard**, confirming that CacheR is enabled and ready for configuration and operation.
Additional guidance on operating CacheR is available in the CacheR [documentation](/stifler/operations-and-features/cacher-operations) section. # Testing and validation ## Objectives The objective for the testing and validation phase of a PoC can be summarized as: * Manage and control traffic across all networks (subnets/locations) to distribute software efficiently, reduce bandwidth usage, and avoid large server infrastructure – without impacting business operations * Verify that peer-to-peer traffic functions correctly and offloads the network as intended, including proper integration with BITS/BranchCache, Delivery Optimization, and LEDBAT. * Gain real-time visibility into network traffic to identify bottlenecks and ensure software distribution is controlled and reconfigurable. ### Lab testing To complete a StifleR PoC in a lab environment, requirements vary based on whether Intune and/or Configuration Manager is used: {% tabs %} {% tab title="Intune" %} * A functioning Intune instance with several applications that can be used for testing purposes. Ideally no less than 500 MB in size (1 GB recommended). * Choose 2-3 subnets with 3 or more client PCs each that are registered with Intune: * Ideally two of the subnets should be in the same location with good connectivity to one another. * It is recommended that some clients should reside on a subnet that has slower connectivity to an Internet gateway. {% endtab %} {% tab title="Configuration Manager" %} * Microsoft Configuration Manager Primary Site server: * This server will provide all of the CM Roles such as a Management Point, Distribution Point, etc. on a single server. * Configure 2-3 subnets with 3 or more client PCs each that are Configuration Manager clients. * Ideally two of the subnets should be in the same location which have good connectivity with one another. * It is recommended that some clients should reside on a subnet which has slower connectivity to a distribution point. In a lab environment, this can be achieved by installing a virtual appliance such as a pfSense router, which supports bandwidth limiting. * Choose several applications that can be used for testing purposes. Ideally no less than 500 MB in size (1 GB recommended). {% endtab %} {% endtabs %} ### Production environment testing To complete a StifleR PoC in a production environment, requirements vary based on whether Intune and/or Configuration Manager is used:: {% tabs %} {% tab title="Intune" %} * A functioning Intune instance with several applications that can be used for testing purposes. Ideally no less than 500 MB in size (1 GB recommended). * Choose 2-3 subnets with 3 or more client PCs each that are registered with Intune: * Ideally two of the subnets should be in the same location with good connectivity to one another. * It is recommended that some clients should reside on a subnet that has slower connectivity to an Internet gateway. {% endtab %} {% tab title="Configuration Manager" %} * Choose 2–3 subnets with 3 or more client PCs each that are Configuration Manager clients. * Ideally two of the subnets should be in the same location with good connectivity to one another. * It is recommended that some clients should reside on a subnet that has slower connectivity to a distribution point. * Choose several applications that can be used for testing purposes. Ideally no less than 500 MB in size (1 GB recommended). {% endtab %} {% endtabs %} ## StifleR Server ### Implementing bandwidth-limiting server components | Name | Description | Requirement / Benefit | | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | Limits the number of concurrent downloads to a certain subnet (location) | Maximizes the efficiency of built-in Microsoft peer-to-peer tech. Ensures a single download of content per location. Further leverages Microsoft Data Deduplication to reduce data transferred | Limit content transfers to the absolute minimum required | | Limits the download speed to a fixed set of Kb/s per location | Ensures that business bandwidth is protected by allocating a set amount of bandwidth to content download traffic | Protect business bandwidth usage at all locations | | Slow down, increase, pause, restart or kill all BITS download jobs | At busy times, or during emergencies – provides complete and instant control over all in-flight transfers | Flexible, reactive ability to control all content transfers | ### Manage Microsoft peer-to-peer technologies: Background Intelligent Transfer Service (BITS) and Delivery Optimization (DO) | Name | Description | Requirement / Benefit | | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Single Site Download | Enhances Microsoft BranchCache to enable multi-subnet/multi-VLAN transfers | Limit content transfers to the absolute minimum required | | Windows Store (WSfB) | Manage Windows Store and/or Windows Store For Business Downloads | Manage Delivery Optimization transfers regardless of source – while maintaining bandwidth limits | | Microsoft Intune | Manage content downloads from Intune | Limit content transfers to the absolute minimum required | | Windows Update / WUfB | Manage content downloads from Windows Update / Windows Update for Business | Limit content transfers to the absolute minimum required | | Integrate with and manage new Microsoft bandwidth management technologies | Microsoft is implementing LEDBAT and CUBIC congestion control methods within Windows to facilitate bandwidth management within the operating system | Use built-in technologies at no further cost where possible | ### Reporting and visualization | Name | Description | Requirement / Benefit | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Real-time visibility | Dashboards provide real-time tracking of all the above content transfers. Provide efficiency stats and highlight any issues | Single location to track and manage all types of downloads | | Long-term trend analysis | Recording all data to a DB for analysis/data visualization/reporting/trending (optional) | Long-term tracking of data transfers – can reduce cloud storage/egress costs | | Scripting Interface | Allow for customizations using an API or interface to automate items. | Complex scenarios | | Deduplicated cache management | Store a copy of Windows Enterprise N media as well as Windows Enterprise media with minimum additional storage footprint | Reduced cache footprint | | Pre-caching | Pre-cache content for future deployments | Build and/or deploy faster | ### Network Requirements
NameUse caseBenefit
Network topologyAbility to dynamically build the network topologyThe systems management team can see the full network dynamically without interaction with the network group
VLANsNetwork teams add VLANs without notifying the endpoint management team resulting in inefficient content distribution causing outagesAuto-generation of networks
Auto network group creationAutomatically create a new subnet / office location which may be unknownThe ability to create auto network groups within the dedicated tooling and not rely on external infrastructure or manual creation​
## StifleR Dashboard To view the activities of the StifleR Clients, open the StifleR Dashboard on the StifleR Server by visiting the dashboard URL: There won’t be much in the way of traffic data yet, but you should be able to see the clients that were added in the previous steps. Drill down the [Clients](/stifler/operations-and-features/overview-and-navigation/devices/clients) section of the dashboard to see the clients that have checked in. Confirm that the clients have connected to the dashboard before proceeding. ### Deploy an application or Intune App to a single client PC and monitor the download In this step you will deploy and monitor, in real time, a deployment to a single client: * Target a single client system only with the required deployment created in the previous step. You can use an ‘As soon as possible’ deployment schedule. * On the targeted test client perform a Client Policy Refresh to speed up the deployment. * Review the content transfer in the StifleR Dashboard. ### Deploy the same application or Intune App to peers In this step you will deploy and monitor a deployment to peers: * Target two or more clients on the same subnet with the same application or Intune App deployment. * Target other clients on a separate subnet with the same application or Intune App deployment. * Review the content transfers in the StifleR Dashboard. # Ping Identity integration StifleR integrates with Ping Identity using OpenID Connect (OIDC) to provide centralized authentication and authorization based on identity groups. This approach allows organizations to control access to the StifleR Dashboard and its features without managing local users, aligning StifleR with modern identity and Zero Trust practices. At a high level, Ping Identity is responsible for authenticating users and issuing identity tokens, while StifleR consumes group information from those tokens to determine what a user is allowed to see and do. ## **Global access control via pingIdentity groups** StifleR supports global access control by mapping Ping Identity groups directly to predefined access levels. During authentication, the user’s group membership is included in the OIDC token and evaluated by StifleR. Typical usage includes: * A read-only group that grants visibility across the StifleR Dashboard without allowing changes. * An administrative group that provides full access to view, modify, and manage StifleR configuration and data. These groups are defined in Ping Identity and referenced in the StifleR Service Config Editor, ensuring that access is enforced consistently for all users logging in through Ping Identity. ## **Centralized and auditable access management** By using Ping Identity as the authentication provider, all user access to StifleR is centrally managed and auditable. User lifecycle actions such as onboarding, role changes, or removal of access are handled entirely in Ping Identity, with no need to modify StifleR directly. This model reduces administrative overhead, improves security posture, and ensures that StifleR access always reflects the organization’s identity governance policies. *** ## Configuration ### Create Groups in PingIdentity Log in to the PingIdentity admin console and navigate to **Groups**.
Create the following groups using the **Default** population: * **DefaultStifleRRead** – global read-only access to the StifleR Dashboard * **DefaultStifleRAdmins** – full administrative access
### Configure Attribute Mappings Open the applications and create application of OIDC type.
Attributes must be mapped so that tokens include user information (e.g., groups). Navigate to **Attribute Mappings**.
Edit the mappings and add a new global attribute: * **Name**: groups * **PingOne Mapping**: Group Names Save the changes.
Verify that the attribute is included in the "openid" scope.
### Configure Resources and Scopes Open the **Resources** tab and select **Edit**.
Enable the following scopes: * profile (required) * phone, address, email (optional) Save the configuration.
Navigate to **Resources → OpenID Connect → Attributes → Edit** and map: * Username → name * Username → preferred\_username Save the changes.
### Configure Application Settings Go to **Applications → \[Your Application] → Configuration → Edit**. Configure: * **Response Types**: Authorization Code, Access Token, ID Token * **Grant Types**: Authorization Code, Implicit * **Redirect URI**: Full StifleR backend URL (including port) * **Sign-off URL**: Same as Redirect URI Save the configuration.
#### Activate the Application Set the application state to **Active**.
### Configure StifleR for PingIdentity #### Collect Application Values From the PingIdentity application configuration, note the following values for use in StifleR: * AuthAuthority **→** Issuer URL e.g.: (must include trailing slash) * AuthClientId **→** Client ID (GUID) * AuthRedirectUri **→** Same as configured * Dashboard URL **→** https\://\[Full StifleR URL]/# #### StifleR Service Config Editor Run the **StifleR Service Config Editor** and open **Access Settings**. Configure: * Authentication Method: oidc * OIDC Provider: PingIdentity * OIDC Claim Type: groups * OIDC Groups with StifleR Global Admin Access: DefaultStifleRAdmins * OIDC Groups with Stifler Global Read Access: DefaultStifleRRead * OIDC Issuer URL: * OIDC Redirect URL: https\:///api/Account/Callback * OIDC Dashboard URL: Full URL to StifleR Dashboard Save the configuration.
#### Configure Dashboard Authentication On the StifleR Dashboard server, update config.json: * authprovider = 2 (PingIdentity) Save the file.
### Configure RBAC with PingIdentity #### PingIdentity Group for RBAC Create an additional PingIdentity group for RBAC use.
Add users to the group.
#### Create Claim Rule in StifleR In the StifleR Dashboard, go to **Administration → Security → Rules → New Rule**. Configure: * Type: Claim * Claim Type: External * Claim Name: groups * Claim ID: PingIdentity group name
#### Create and Assign Role Go to **Administration → Security → Roles → New Role**. Configure the role name, access area, and allowed operations. Save the role.
Expand the newly created Role add click Add Rule
#### Validate Permissions Log in with a user who belongs to the PingIdentity group. Open the user menu in the top-right corner and verify assigned roles.
# Entra ID integration StifleR can use **Microsoft Entra ID** as its identity provider to authenticate users and determine access to the StifleR Dashboard. Authentication is performed using **OpenID Connect (OIDC)**, while authorization decisions are based on Entra ID security group membership. This integration removes the need for local user management in StifleR and allows access to be governed entirely by Entra ID, using the same identities, groups, and policies already in place across the organization. When a user signs in, Entra ID validates the identity and issues an OIDC token that includes group information. StifleR consumes this information and applies access rules accordingly, ensuring that users only see and manage what they are permitted to. ## Group-Based Access Model Access to StifleR is controlled by mapping Entra ID security groups to StifleR access levels. Common patterns include: * A **read-only group** that allows users to view all Dashboard data without making changes. * An **administrative group** that grants full control over configuration, monitoring, and management features. These groups are defined and maintained in Entra ID and referenced in the StifleR Service Config Editor. This ensures that access rules are applied consistently for all users authenticating through Entra ID. ## Centralized Governance and Compliance Using Microsoft Entra ID as the authentication authority centralizes identity governance for StifleR. All access changes - such as adding users, modifying permissions, or revoking access - are performed in Entra ID and immediately reflected in StifleR at the next login. This approach simplifies administration, improves auditability, and ensures that StifleR access aligns with organizational security, compliance, and Zero Trust requirements. ## Configuration ### Create Entra ID Groups Log in to the **Microsoft Azure Portal**, open **Microsoft Entra ID**, and navigate to **Groups**.
Create the following security groups: * **DefaultStifleRRead** – global read-only access to all StifleR pages * **DefaultStifleRAdmins** – full administrative access Groups must be created as **Security** type.
Add users to each group by opening the group, selecting **Members**, and clicking **Add members**.
*** ### Register the Application Navigate to **App registrations** and either select an existing application or create a new one for StifleR.
*** ### Configure Authentication Open the application and go to **Authentication (Preview)**, then select **Add Redirect URI**.
Choose **Web** as the platform type.
Configure the **Redirect URI** to point to the StifleR Service callback endpoint: https\://\[YourDomain]:9000/api/Account/Callback
*** ### Configure Token Claims Open **Token configuration**.
Add a **Groups claim** and select **Security groups** so that group membership is included in the OIDC token.
*** ### Configure StifleR Service Open **StifleR Service Config Editor** and update the access settings. Set **Authentication Method** to oidc and configure the following: * **"OIDC Provider name"** - Name representing the external OIDC Provider * **"OIDC Claim type"** - String value of External OIDC provider custom application attribute. For EntraID should be "groups", for PingIdentity based on attribute name defined by admin * **"OIDC Groups with StifleR Global Admin Access"** - External OIDC provider security groups that have full admin rights to StifleR. (Define group ID (GUID) instead of name) * **"OIDC Groups with StifleR Global Read Access"** - External OIDC provider security groups have read access to StifleR global data, all locations and all items. (Define group ID (GUID) instead of name) * "**OIDC Issuer URL"**: Ping Identity: should be in format '[https://auth.pingone.eu/\[EnvironmentID\]/as/](https://auth.pingone.eu/%5BEnvironmentID%5D/as/) ' ending with a slash. Entra ID: Should be in format '[https://login.microsoftonline.com/\[TenantID\]/v2.0](https://login.microsoftonline.com/%5BTenantID%5D/v2.0) ' * **"OIDC Client Identifier"** - The unique identifier assigned to your application by the OpenID Connect provider. * **"OIDC Redirect URL"** - The URL in your application where the OpenID Connect provider will send the user after completing authentication. This must match one of the redirect URIs registered with your identity provider.It should be in format https\://\[YourDomain]:9000/api/Account/Callback. * **"OIDC Dashboard URL"** - Full URL to StifleR Dashboard. Should be in format https\://\[YourDomain]/StiflerDashboard/#. * **"OIDC Authentication ticket expiration (minutes)"** - Expiration time in minutes for OpenID Connect authentication ticket. Verify and Save the configuration.
# Remote tools configuration Remote Tools in StifleR provide secure, real-time access to endpoint diagnostics and troubleshooting capabilities directly from the StifleR Dashboard. These tools allow administrators and support teams to inspect and interact with managed devices without requiring direct network access or separate remote access solutions. Available features include file and registry exploration, WMI and event log viewing, log file access (by default we are monitoring Intune and SCCM logs, but you can configure it based on your own needs and preferences), performance counters, resource monitoring, task management, detailed device information, command-line access via CMD and PowerShell, as well as remote assistance and RDP tunneling and much more. Together, these tools enable efficient troubleshooting, monitoring, and support while maintaining centralized control and visibility. *** {% hint style="info" %} Before configuring Remote Tools, ensure that ActionHub is [installed](/stifler/setup/installation/stifler-actionhub-installation) and available. \ ActionHub is required to enable remote connectivity and functionality for all Remote Tools features. {% endhint %} ## Action hub assignment We provide three options on how to assign action hub so it can be elected for the clients, below we will describe all of three options. ### Area assignment * Navigate to your areas in StifleR dashboard under Networks * Open infrastructure services tab * Press on add relation button * Select your action hub and press OK
### Network group assignment * Navigate to your network groups in StifleR dashboard under Networks * Edit network group where you want to have active Action hub * This will lead you to new page, scroll down until you will see Infrastructure services tab * Open infrastructure services tab * Press on add relation button * Select your action hub and press OK
### Making ActionHub default * Navigate to your Infrastructure services in StifleR dashboard under Administration * Open ActionHub tab (or find your ActionHub in the list) * Press on three dots under actions * Mark ActionHub as default
## Granting permissions ### Rules creation Based on account group where you want to grant permissions for remote tools you can edit and create specific set of permissions. Initially you will need to create a set of rules based on access level. * Navigate to rules in StifleR dashboard under security * Press on new rule button * Fill all the needed information * Press on Create
### Role Creation Based on role specific group members will do have access to specific features of remote tools. * Navigate to roles in StifleR dashboard under security * Press on new rule button * Fill all the needed information and select needed features access * Press on Create
### Assigning rules to roles * Navigate to roles in StifleR dashboard under security * Press on arrow button on preffered role * Press on add rule button * Select preffered rule * Press on Update
## Enabling remote tools By security reasons remote tools are disabled by default, in order to enable them you will need to configure StifleR client configuration and StifleR server configuration. ### Client side configuration * Open StifleR client configuration on client side * \*installation path\*\2Pint Software\StifleR Client\TwoPint.ConfigEditor.Wpf\TwoPint.ConfigEditor.Wpf.exe * Enable advanced options * Navigate to Remote tools specific settings * Enable features based on your preference * Press on verify and save
### Server side configuration * Open StifleR server configuration on client side * \*installation path\*\2Pint Software\StifleR Server\TwoPint.ConfigEditor.WpfTwoPint.ConfigEditor.Wpf.exe * Enable advanced options * Navigate to dashboard settings * Enable show RemoteR features * Press on verify and save
# Roles and Permissions (RBAC) StifleR RBAC is built from two separate concepts: * **Rules** — define *who* matches. A rule contains a claim matcher: either a Windows AD group or an OIDC claim. Rules are managed under **Administration > Rules** and can be reused across multiple roles. * **Roles** — define *what* matched users can do. A role is a named grouping with a set of permissions. Rules are assigned to roles to determine membership. When a user authenticates, StifleR checks which rules match their identity, finds all roles those rules belong to, unions the permissions across those roles, and applies the result for the session. Changes take effect on the user's next login. ## Create a rule Rules define the claim that identifies a user or group. Create rules first, then assign them to roles. Go to **Administration > Rules** and click **New rule**. ### Windows AD group 1. Enter a **Name** for the rule (e.g. `AD – Network Admins`). 2. Set **Claim type** to `Windows`. 3. Set **Claim name** to the fully qualified AD group name: `DOMAIN\GroupName`. 4. Click **Save**. ### OIDC (Entra ID / Ping Identity) 1. Enter a **Name** for the rule (e.g. `Entra – Network Admins`). 2. Set **Claim type** to `External`. 3. Set **Claim name** to the claim type your identity provider sends — typically `groups`. 4. Set **Claim id** to the claim value for the group — for Entra ID this is the group's **object ID** (a GUID, not the display name). 5. Click **Save**. > **Entra ID tip:** To find a group's object ID, go to **Entra ID > Groups**, open the group, and copy the **Object ID** field. To confirm the claim is present in the token, sign in as a test user and inspect the token at [jwt.ms](https://jwt.ms/) . If the `groups` claim is missing, group claims must be enabled in the app registration under **Token configuration**. ## Create a role 1. Go to **Administration > Roles** and click **New role**. 2. Enter a descriptive name, for example `Network Admins` or `DeployR – Read Only`. 3. Click **Save**. ## Assign rules to the role 1. In the **Role list**, expand the role by clicking the arrow next to it. 2. Click **Add rule**. 3. Select the rule you created and confirm. A role can have multiple rules. A user is included in the role if they match **any** of the assigned rules. ## Assign permissions 1. Open the role editor for the role. 2. You will see a matrix of feature sets, with subjects as rows and Read / Write / Delete as columns. 3. Check the verbs you want to grant for each subject. 4. Click **Save**. ## Editing a role To change who belongs to a role, expand it in the Role list and add or remove rules. To change what the role can do, open the role editor and update the permissions matrix. ## Deleting a role Go to **System > Roles**, select the role, and click **Delete**. Affected users lose the permissions that role granted on their next login. ## Assigning permissions In the role editor you will see a matrix of feature sets, each with its subjects as rows and Read / Write / Delete as columns. Check the verbs you want to grant for each subject: * **Read** — view data, navigate to pages * **Write** — create and modify records * **Delete** — remove records Subjects within a feature set are independent — you can grant `BootImage: Read+Write` without granting `TaskSequence` access at all. A user with no permissions for a feature set cannot navigate to any of its pages. > **Feature set visibility:** If a feature set is unlicensed or disabled (via the Features page), all permissions under it are denied regardless of role configuration. Subjects for unlicensed features will appear greyed out in the matrix. ## Permission reference by feature set ### Administration Controls access to system configuration. | Subject | Read | Write | Delete | | --------------------- | ---------------------------- | ----------------------- | ---------------- | | License | View license details | — | — | | Feature | View feature state | Enable/disable features | — | | User | View users and sessions | — | — | | Rule | View claim rules | Create/edit rules | Delete rules | | Role | View roles | Create/edit roles | Delete roles | | Policy | View policies | Create/edit policies | Delete policies | | InfrastructureService | View infrastructure services | — | — | | ServerHealth | View server health | — | — | | NetworkGroupTemplate | View templates | Create/edit templates | Delete templates | ### Devices | Subject | Read | Write | Delete | | --------- | -------------------------------------------- | --------------- | -------------- | | Device | View clients, search, hardware info, history | Set power level | Delete clients | | Elevation | View local admins, sessions, elevation stats | — | — | ### Networks | Subject | Read | Write | Delete | | ------------ | ------------------- | ---------------------------------------------------------- | --------------------- | | Area | View areas | Create/edit areas | Delete areas | | Location | View locations | Create/edit locations | Delete locations | | NetworkGroup | View network groups | Create/edit groups, Resume/Suspend/Cancel, WoL | Delete network groups | | Network | View networks | Create/edit networks, Resume/Suspend/Cancel, WoL, Reassign | Delete networks | ### BandwidthManagement | Subject | Read | Write | Delete | | ---------------------------- | ----------------- | -------------------- | --------------- | | ThrottlingPolicy | View policies | Create/edit policies | Delete policies | | BranchCacheSettings | View settings | Modify settings | — | | DeliveryOptimizationSettings | View settings | Modify settings | — | | Traffic | View traffic data | — | — | ### DeployR | Subject | Read | Write | Delete | | ------------------ | ------------------------ | ---------------------------- | ----------------------- | | BootImage | View boot images | Create/edit boot images | Delete boot images | | TaskSequence | View task sequences | Create/edit task sequences | Delete task sequences | | StepDefinition | View step definitions | Create/edit step definitions | Delete step definitions | | ApplicationContent | View application content | — | — | | OsContent | View OS content | — | — | | DriverPackContent | View driver pack content | — | — | | OtherContent | View other content | — | — | ### CacheManagement | Subject | Read | Write | Delete | | ------- | -------------------------- | ----- | ------ | | Usage | View cache usage reporting | — | — | ### OsdDeployments | Subject | Read | Write | Delete | | --------- | -------------------------- | --------------------------------- | ---------------------------- | | Osd | View OSD deployments | Create/edit OSD deployments | Delete OSD deployments | | Autopilot | View Autopilot deployments | Create/edit Autopilot deployments | Delete Autopilot deployments | | Generic | View generic deployments | Create/edit generic deployments | Delete generic deployments | ### CacheR | Subject | Read | Write | Delete | | ------------------ | ------------------------ | ----- | ------ | | Packages | View packages | — | — | | DistributionPoints | View distribution points | — | — | | TrackedContent | View tracked content | — | — | ### RemoteR > **Note:** RemoteR permissions control access to individual remote tools. Users without the relevant permission will see each tool disabled with a "No permission" message. Accessing the client page itself requires Devices.Device read permission. ## Testing a role To test without logging out of your admin session, open a separate browser profile or private window and sign in as the test user. For Windows Integrated Auth, you can also launch Edge under a different identity from a command prompt: ``` **runas /user:DOMAIN\testuser msedge.exe ``` # Windows Server BranchCache Configuration ## Enabling BranchCache on ConfigMgr Distribution Points BranchCache is a Windows feature that enables peer-to-peer content sharing between clients on the same network. When used with Microsoft Configuration Manager (ConfigMgr), BranchCache allows clients to download content from a local peer instead of repeatedly downloading the same content from a remote distribution point (DP). This can significantly reduce WAN bandwidth consumption and improve deployment performance. For BranchCache to function correctly with Configuration Manager, it must be enabled both in **Windows Server** and in the **Configuration Manager distribution point configuration**. In the Configuration Manager console, open the **Administration** workspace and expand **Site Configuration** and select **Servers and Site System Roles**. Select which distribution points you want to enable and open the distribution point **Properties**. Under the "General" tab, choose the option: Enable and configure BranchCache for this distribution point. To allow clients to retrieve BranchCache content from a distribution point, BranchCache must be enabled in the Configuration Manager console. #### Steps 1. Open the **Configuration Manager Console**. 2. Navigate to: Administration → Site Configuration → Servers and Site System Roles 3. Select the server hosting the **Distribution Point** role. 4. Open the **Distribution Point Properties**. 5. On the **General** tab, enable:
Once this option is enabled, Configuration Manager will automatically install the **BranchCache Windows feature** on the distribution point if it is not already installed. ### Enable BranchCache on a Distribution Point Using PowerShell BranchCache can also be enabled through PowerShell when connected to the Configuration Manager environment. {% hint style="info" %} Replace \ with the fully qualified domain name of the distribution point. {% endhint %} ```powershell Set-CMDistributionPoint -EnableBranchCache $true -SiteSystemServerName ``` {% hint style="info" %} If you are using more than one DP, the BranchCache 'Server Secret' is the same on each of them. The 'Server Secret' is stored in the registry: HKLM:\Software\Microsoft\Windows NT\CurrentVersion\PeerDist\SecurityManager\Restricted Value: Seed If you have configured BranchCache functionality using the ConfigMgr UI then the same server secret will be automatically seeded across DPs. {% endhint %} ## Enabling BranchCache in Windows Server BranchCache can also be installed directly in Windows Server using either the graphical interface or PowerShell. ### Using Windows Server Manager 1. Open **Server Manager**. 2. Navigate to **Add Roles and Features**. 3. Select the **BranchCache** feature and install it. ### Using PowerShell ```powershell Install-WindowsFeature -Name BranchCache ``` ## Verify BranchCache Installation You can verify that BranchCache is installed on the distribution point by running the following PowerShell command: ```powershell Get-WindowsFeature | ? name -eq BranchCache ``` If the feature is installed, it will appear in the list with the status **Installed**. ## Modifying the BranchCache Cache Location On a distribution point, you may want to move the BranchCache cache folder to a different disk for performance or capacity reasons. Example: Move the cache to `D:\BranchCache\LocalCache` 1. Create the target directory. 2. Run the following command: ``` netsh br set localcache directory=D:\BranchCache\Localcache ``` ## Modifying the BranchCache Cache Size You can configure the size of the BranchCache cache using the following command: ``` netsh br set cachesize ``` Usage: ``` set cachesize [size=]{DEFAULT|} [[percent=]{TRUE|FALSE}] ``` Examples: ``` set cachesize DEFAULT set cachesize 20971520 set cachesize size=20 percent=TRUE ``` ## Data Deduplication and BranchCache Data Deduplication is a Windows Server feature that reduces storage consumption by identifying and eliminating duplicate blocks of data. When used together with BranchCache, Data Deduplication provides an additional performance advantage. Both technologies use the same hashing algorithm. When Data Deduplication is enabled on a distribution point, the deduplication engine calculates content hashes during its scheduled optimization process. These hashes can then be reused by BranchCache when serving content to clients. This provides two important benefits: * Reduces CPU load on the distribution point during content requests * Avoids potential time-out issues caused by on-demand hash calculations Additionally, Data Deduplication reduces storage usage and network traffic by minimizing redundant data blocks. For these reasons, **2Pint Software strongly recommends enabling Data Deduplication on distribution points used with BranchCache.** ## Enabling Data Deduplication on a Distribution Point The following PowerShell script enables Data Deduplication on a distribution point volume. {% hint style="info" %} Update the `$dedupVolume` variable to match the drive letter used for Configuration Manager content. {% endhint %} ```powershell #Set the drive letter $dedupVolume = "E:" Import-Module ServerManager Add-WindowsFeature -Name FS-Data-Deduplication #Enable Deduplication on the volume Enable-DedupVolume $dedupVolume Set-DedupVolume -Volume $dedupVolume -MinimumFileAgeDays 0 -ExcludeFolder $dedupVolume\SMSPKG, $dedupVolume\SMSPKGSIG, $dedupVolume\SMSSIG$ Write-Output "Starting Dedup Jobs..." $j = Start-DedupJob -Type Optimization -Memory 75 -Priority High -Volume $dedupVolume $j = Start-DedupJob -Type GarbageCollection -Full -Memory 75 -Priority High -Volume $dedupVolume $j = Start-DedupJob -Type Scrubbing -Full -Memory 75 -Priority High -Volume $dedupVolume do { Write-Output "Dedup jobs running. Status:" $state = Get-DedupJob | Sort-Object StartTime -Descending $state | ft if ($state -eq $null) {Write-Output "Completing, please wait..."} sleep -s 5 } while ($state -ne $null) Write-Output "Done DeDuping" Get-DedupStatus | fl * ``` # Delivery optimization configuration Starting with Windows 10, Microsoft introduced [**Delivery Optimization (DO)**](https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization) as a built-in Windows component used to download content from Microsoft services, peers on the local network, or caching servers. Delivery Optimization is commonly used for distributing Windows Updates, Microsoft Store content, and other cloud-delivered packages. Microsoft provides administrators with several methods to manage Delivery Optimization configuration on client devices, including: * **Group Policy** (via Active Directory) * **Microsoft Intune policies** * **Client Settings in Configuration Manager** When StifleR is used to manage content downloads, it is important to ensure that existing Delivery Optimization configuration settings do not conflict with the configuration applied by StifleR. ## How StifleR Manages Delivery Optimization StifleR manages Delivery Optimization settings through the use of [**Templates**](/stifler/operations-and-features/features-overview/templates). Templates are applied to **Network Groups**, and each Network Group can contain one or more **subnets**. These Network Groups effectively function as **peering boundaries**, allowing StifleR to control how clients share content within a defined network scope. Delivery Optimization itself uses a similar concept called **DO Groups**, which define the scope of peer-to-peer sharing between devices. StifleR templates can automatically configure DO Groups based on the defined Network Groups, ensuring that clients only peer with other devices within the same logical network. Through Templates, StifleR can centrally define Delivery Optimization settings and enforce consistent configuration across clients in the same Network Group. For detailed information about which Delivery Optimization settings can be managed by StifleR, refer to the corresponding configuration reference [table](/stifler/operations-and-features/overview-and-navigation/devices/stifler-server/templates-detail#delivery-optimization). ## Group Policy considerations Microsoft allows Delivery Optimization settings to be configured using **Group Policy** through Active Directory or **device configuration policies in Intune**. If Delivery Optimization settings are already managed through Group Policy or Intune, they may override or conflict with the settings applied by the StifleR client. This can prevent StifleR from properly managing Delivery Optimization behavior. For this reason, it is recommended to review existing Delivery Optimization policies and remove or disable any settings that may conflict with StifleR’s configuration. Refer to the Delivery Optimization configuration reference [table](/stifler/operations-and-features/overview-and-navigation/devices/stifler-server/templates-detail#delivery-optimization) to identify which settings are controlled by StifleR. ## Configuration Manager considerations In Configuration Manager environments, Delivery Optimization can also be influenced by Configuration Manager client settings. StifleR manages Delivery Optimization peering groups based on how **Network Groups** are defined within StifleR. To avoid conflicts, Configuration Manager should not automatically assign Delivery Optimization group identifiers. When implementing StifleR in a Configuration Manager environment, ensure the following client setting is **disabled**:
Disabling this setting allows StifleR to fully control the Delivery Optimization group configuration based on its Network Group structure. # Configuring a Beacon Server Prior to configuration, a Beacon server must be installed in your environment. See [StifleR Beacon installation](/stifler/setup/installation/stifler-beacon-installation) for more information. *** ## Assigning a Beacon to Network Groups Beacons are assigned within the StifleR Dashboard. Assignments can be made at any\ topology level; StifleR resolves the best beacon for each network group by walking\ the hierarchy: **Network group → Location → Area → Default** The most specific assignment wins. Assign beacons as close as possible to the groups\ they should measure for the most representative results. ### Default beacon Marking a beacon as **Default** makes it the fallback for any network group that has\ no explicit assignment at the network group, location, or area level. A default beacon\ is not required if all groups have direct assignments. *** ## Measurement Priority When a beacon is assigned, you can choose how the measurement result is applied: | Setting | Behaviour | | --------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Beacon measure priority** | StifleR adjusts the throttle target automatically based on new measurements | | **Template priority** | Measurement results are recorded but the template's fixed values are used for throttling; beacon data is ignored | *** ## Triggering Measurements ### Scheduled (automatic) Measurements run automatically on a configurable schedule. Every 30 minutes the\ StifleR Service scans all network groups and queues those that are due. A group is due\ when it has not been measured within the configured measurement interval (default: 6 days). ### Manual (ad-hoc) Open the relevant network group in the dashboard and click **Measure now** in the\ **Bandwidth and throttling settings** section. Results appear in the Beacons table\ within seconds. Ad-hoc measurements take priority over the scheduled queue. *** ## Server Configuration Settings Open the **Config Editor** for the StifleR Server. ### Bandwidth Settings | Setting | Default | Description | | ---------------------------------------------------------- | ----------------- | -------------------------------------------------------------------------------------------- | | Maximum bandwidth measurement interval in seconds | `518400` (6 days) | How long to wait before re-measuring a network group. Set to `3600` for hourly measurements. | | Maximum bandwidth poll interval between subnets in seconds | `10` | Delay between polling cycles inside the measurement loop. | | Bandwidth Tuning | See note | Beacon measurement must be enabled here. See Bandwidth Tuning. | ### Infrastructure Settings | Setting | Default | Description | | --------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------ | | Heartbeat rate online threshold for infrastructure service in seconds | `30` | A beacon is considered offline if its last heartbeat is older than this value. | > **Both levels required.** Beacon measurement must be enabled in the server-level\ > **Bandwidth Tuning** setting **and** in each network group's own **Bandwidth Tuning**\ > setting. If either is missing, the group is silently skipped. *** ## Beacon Configuration Settings Open the **Config Editor** for the StifleR Beacon. ### Infrastructure | Setting | Default | Description | | ----------------------------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------- | | StifleR Server | *(required)* | Full URL to the StifleR Server API | | Heartbeat frequency for beacon in seconds | `30` | How often the beacon sends its heartbeat and measurement counters to the server | | Beacon preferred FQDN | *(optional)* | Override the hostname the server advertises to clients. Useful when the beacon's DNS name differs from its system hostname. | ### Binding | Setting | Default | Description | | ---------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Port for binding | `5201` | iPerf3 listen port | | Port for ping | `5200` | FastPing (TCP latency) listen port | | IP address for binding | *(auto)* | Leave blank to use the interface that connects to the StifleR Server. Set explicitly if the beacon is multihomed and you need to control which address clients connect to. | | Prefer IPv4 over IPv6 | `true` | When the beacon has both address families, prefer IPv4 | *** ## How to Configure Hourly Measurements 1. Open the Config Editor for the **StifleR Server**. 2. Under **Bandwidth Settings**, set **Maximum bandwidth measurement interval in**\ **seconds** to `3600`. 3. Confirm that beacon measurement is enabled in **Bandwidth Tuning** at the server level. 4. In the dashboard, confirm each target network group also has beacon measurement\ enabled in its own **Bandwidth Tuning** field. 5. Restart the StifleR Service. *** ## Troubleshooting ### No measurements running at all * **Beacon measurement not enabled at server level**: Open the Config Editor and confirm\ beacon measurement is enabled in the server-level Bandwidth Tuning settings. * **Beacon measurement not enabled on the network group**: Each network group has its own\ Bandwidth Tuning field. Both the server and the group must have beacon measurement\ enabled. This is the most common cause of measurements appearing configured but never\ running. * **No beacon assigned**: The network group (or its parent location/area) must have a\ beacon assigned. Groups with no reachable beacon are silently skipped. * **Beacon offline**: The beacon must have sent a heartbeat within the configured\ threshold (default 30 seconds) to be considered online. * **Client capability not enabled**: The bandwidth measurement capability must be\ enabled in the client's feature set. This is on by default for Standard-tier and\ above licensing. ### Measurements less frequent than expected * Check the **Maximum bandwidth measurement interval** setting. The default is 6 days. * The service scans for eligible groups every **30 minutes**. Even with a 1-hour\ interval configured, measurements may lag up to 30 minutes past their due time. * Each network group tracks its own last measurement date. Verify it is being updated\ by checking the group in the dashboard. ### Measurements failing * **Firewall**: TCP 5200 and TCP 5201 must be open inbound on the beacon from all\ client subnets being measured. * **iPerf3 not running**: Check beacon event logs. The beacon restarts iPerf3\ automatically if it stops, but a persistent failure (for example a port conflict)\ will appear in the logs. * **DNS resolution**: The client resolves the beacon's hostname before connecting. If\ DNS fails, it falls back to the registered IP address. # Configuring StifleR SQL History Enabling SQL History in StifleR means that all data transfers will be logged to a defined SQL database. This extends the visibility of historical client content downloads, but requires additional components. ## Choosing a database host The SQL History feature requires a SQL database and host. The SQL database can be hosted on a remote SQL server or installed on the StifleR Server. SQL Express can be used, but depending on the number of clients and content downloads, the database size may exceed the 10 GB limit of SQL Express. ## Setting permissions for the SQL database The SQL History feature will attempt to write to the SQL database using the user context in which the StifleR Server service is running. For example, if the StifleR Server service is running as "Local System" (default) then the computer account ($ComputerName) of the StifleR server needs to be granted access to SQL. If the StifleR Server service is running under a service account, the service account will need to be granted access. ### Required SQL permissions The StifleR Server computer or service account will need **db\_creator** permissions to the SQL instance to create and manage the SQL database. ### Enabling SQL History in the StifleR Server configuration file To enable StifleR SQL History, you will need to edit the [StifleR Server Configuration File](broken://pages/nHStlYiqePE9p1g7bKrM) **(StifleR.Service.exe.config)** by setting the **SQLHistory** value to **1**. 
<add key="SQLHistory" value="1"/>
### Configuring the history database configuration string In the same StifleR Server configuration file, you must define the database server, instance name, and database name (optional). See the below example of the connection string you should edit in your .config file: ```xml ``` ## Restarting the StifleR Server service After editing and saving the **StifleR.Service.exe.config** file, for the changes to take effect, restart the "2Pint Software StifleR Server" service. {% hint style="info" %} Important: The StifleR SQL History database will not automatically be created after service restart. The database will be created when a client attempts to download content and reports the download status to the StifleR server. {% endhint %} # Securing StifleR operations with SSL ## Introduction This document provides guidance on how to secure StifleR communications with SSL. Securing StifleR is straightforward, but as with anything involving Microsoft Security and Certificates, you need to get it exactly right or it just won’t play ball. This document provides details around security configuration and describes the process of setting up a certificate for self-hosting SignalR, the communication platform upon which StifleR is built. ### What exactly do we need to secure? There are two components that must be secured: * **SignalR Endpoint Communications -** the StifleR Server service that the clients communicate with (default port 1414). * **StifleR Web API -** the WebAPI service that the Dashboard connects to (default port 9000). {% hint style="info" %} Note: If the StifleR Server service and the StifleR Dashboard are hosted on separate servers, both servers will need their own certificates. {% endhint %} # Prerequisites Certs! We love them. Here's what you need to integrate them with StifleR. ## **Server certificate** Ideally a security certificate can be provided by an internal certificate authority (CA) or a CA on the public Internet. For an internal CA, see [Using a web server certificate](/stifler/configuration/securing-stifler-operations-with-ssl/using-a-full-iis-certificate) for more information. If it is difficult to acquire a web server certificate, you can use a [self-signed certificate](/stifler/configuration/securing-stifler-operations-with-ssl/using-iis-to-create-a-self-signed-certificate). {% hint style="info" %} Note: If the StifleR Server service and the StifleR Dashboard are hosted on separate servers, both servers will need their own certificates. {% endhint %} ## **Client certificate** (if using a self-signed certificate) * If using a self-signed certificate, the clients will need their own certificate. # Using a web server certificate Once you go to production – especially public production – you will need an 'official' certificate signed by an internal certificate authority (CA) or one of the global certificate authorities. If you have an internal certificate authority, and have the ability to request a certificate, follow these steps to [Request a web server certificate](/stifler/configuration/securing-stifler-operations-with-ssl/using-a-full-iis-certificate/requesting-a-web-server-certificate). Self-signed certificates are great for testing under SSL to make sure your application works, but they aren't practical for production apps as the certificate would have to be installed on every machine you'd expect to trust this certificate. If you must use a self-signed certificate, see [Using a self-signed certificate](/stifler/configuration/securing-stifler-operations-with-ssl/using-iis-to-create-a-self-signed-certificate). # Requesting a web server certificate The process for requesting a new certificate depends on your company policies. This document describes how to request a new web certificate if using an Active Directory Enrollment Policy. To request a web server certificate: 1. Open the local machine certificate snap-in by entering the command: **certlm.msc**. 2. Expand the Personal folder and right-click the Certificates folder. In the context menu, select **All Tasks** - **Request New Certificate...**\ ![](/files/26j0utQmM1wVY9Do04xf) 3. In the "Certificate Enrollment" wizard, at the "Before You Begin" screen, click **Next**. 4. At the "Select Certificate Enrollment Policy" screen, select **Active Directory Enrollment Policy** and then click **Next**. 5. At the "Request Certificates" screen, select the web server certificate template, and click: **More information is required to enroll for this certificate. Click here to configure settings.** 6. At the "Certificates Properties" screen, in the "Alternative name" section, use the Type drop-down and select **DNS**. In the Value field, enter the FQDN of the StifleR server on which the certificate will be installed. You can also add additional values for DNS (CNAME) Aliases. Click **OK** to save the settings.\ ![](/files/h8xBqrk7FFzDoq6hS0TM) 7. Once complete, click **Enroll** and then click **Finish** to close the wizard. 8. You should see the certificate in the certificates store. **Double-click** the certificate and click the **Details** tab. 9. Scroll down and select the **Subject Alternative Name** field. In the value box, you should see the DNS Name you entered earlier. 10. Select the **Thumbprint** field. In the value box, you should see the certificate thumbprint. This can be copied by using the hotkeys **CTRL-C**. It is important to capture this value to add to the StifleR Config file when implementing HTTPS in StifleR. \ ![](/files/UrPxUUn4WUEYL19ApWmP) # Using a self-signed certificate If you don't have a web server certificate which has been issued by an internal or public Certificate Authority, but you'd like to test StifleR with SSL operations, you can create a self-signed certificate. This can be done within the Internet Information Services (IIS) Manager. Once the self-signed certificate is created and clients are configured to trust it, you can follow the steps to [Configure StifleR to use SSL](/stifler/configuration/securing-stifler-operations-with-ssl/running-signalr-with-ssl). ## Creating the self-signed certificate 1. Open IIS Manager (InetMgr). 2. Select the Computer Name or root. 3. Open the **Server Certificates** link. 4. In the Actions pane, select **Create Self-Signed Certificate**. 5. At the "Specify Friendly Name" dialog box, enter a **friendly name** and select the **Personal** store. Click **OK** to create the certificate. ![](/files/95U9GtDUI2qLl3KEOJ6i) ### Copy the self-signed certificate to the Trusted Root Certification Authorities store Once you have a self-signed certificate, you need one more step to make the certificate trusted so that HTTP clients will accept it on your machine without error. The process involves copying the certificate from the personal store to the trusted machine store: 1. From the Run command execute: **certlm.msc**. 2. Go into **Personal | Certificates** folder and find your certificate. 3. Right-click and copy the certificate, and paste it into the to **Trusted Root Certification Authorities** | **Certificates** folder. ![](/files/IaaT1stFY0YqAgIiGWrQ) Now that you have a self-signed server certificate, you must now install the certificate on your clients so they will trust the server certificate. To do this, you will have to export the self-signed certificate to a file. ## Exporting a self-signed certificate Once you have a self-signed certificate, you can export it so it can be installed on clients: 1. From the Run command execute: **certlm.msc**. 2. Go into **Personal | Certificates** folder and find your certificate. 3. Right-click the certificate, and in the context menu, select **All Tasks** | **Export**. 4. At the "Certificate Export Wizard" click **Next**. 5. At the "Export Private Key" screen, select **Yes, export the private key**, and click **Next.** 6. Proceed through the rest of the wizard and the end result should be a **.PFX** file which can be imported on clients. {% hint style="info" %} Note: In the Certificate Export Wizard, you will be asked to secure the certificate with a group or username or password. If automating the deployment of the certificate, using a group may be easier than a password, so the password is not exposed in whatever command you use to import the certificate on a client. If importing the certificate manually, a password is acceptable. {% endhint %} ## Importing the self-signed certificate on clients For clients to trust the self-signed certificate on the StifleR Server, the exported certificate (.pfx) file will need to be imported into the following client **LocalMachine** certificate stores: * Personal\Certificates (My) * Trusted Root Certificate Authorities\Certificates This can be done by using the certutil.exe -importpfx command or this can also be done via PowerShell using the following command: ``` #imports the certificate to the Personal Certificates (My) store Import-PfxCertificate -FilePath -CertStoreLocation Cert:\LocalMachine\My #imports the certificate to the Trusted Root Certificate Authorities store Import-PfxCertificate -FilePath -CertStoreLocation Cert:\LocalMachine\Root ``` # Configuring StifleR to use SSL With the certificate installed, to switch to SSL for SignalR and Dashboard communications, you will need to do the following: * Modify the StifleR Server configuration settings. * Modify the Dashboard configuration file. * Modify the StifleR Client configuration file. ### StifleR Server Service You'll also need to modify the SignalR URL and Web Service URLS in the[ StifleR Server Configuration File](broken://pages/nHStlYiqePE9p1g7bKrM): ``` ``` This binds SignalR to all IP addresses on Port 1414. You can also specify a specific IP address, but using \* is more portable especially if you set the value as part of a shared configuration file. The [certificate thumbprint](/stifler/configuration/securing-stifler-operations-with-ssl/finding-the-certhash) will also need to be added to the [StifleR Server Configuration File](broken://pages/nHStlYiqePE9p1g7bKrM): ``` ``` For the StifleR Server to use any changed settings above, the StifleR Server service must be restarted. ### StiflelR Dashboard URL Configuration To configure the web page which will connect to the SignalR service, change the URL in the file [StifleR Dashboard Configuration File](broken://pages/sL3rvzzq7UovRhGxpCfa). The value should reflect the https URLs for the StifleR Server: ``` "controller": "https://StifleRServer.domain.com:9000", "hub": "https://StifleRServer.domain.com:1414" ``` {% hint style="info" %} As with all certificates, make sure that the FQDN that exactly matches the certificate name. If the Dashboard is hosted on the local machine, you cannot use 'localhost', NetBiosName, or IP address. Use only the name to which the certificate is assigned. {% endhint %} ### Clients On new and existing StifleR Clients, the SSL info is set in the [StifleR Client Configuration File](broken://pages/oawEeEGDtdQVU7o0yKF6): ``` ## Using the local certificate store to get the certificate thumbprint 1. Open the local machine certificate snap-in by entering the command: **certlm.msc**. 2. Expand the **Personal** - **Certificates** folder and locate the certificate. 3. Double-click to open the certificate and at the **Details** tab, look for the **Thumbprint** property which contains the hash.
![](/files/5YhLVnepIwHpqo9FNvtW) # StifleR Client access control options This page describes options for controlling StifleR Client access to the StifleR Server. These options are not referring to securing communications such as HTTPS. ## Client AD group membership The StifleR client runs as Local System (NT AUTHORITY\System). If the client and the server are both in the same domain (or a trusted domain)**,** then the client's Local System account uses the computer account credentials to access the StifleR server. If an administrator wants to further limit client access to the StifleR server, an AD group can be used in which clients who are members of the group will be permitted access. To configure the AD group, use the following settings in the [StifleR Server Configuration File](broken://pages/nHStlYiqePE9p1g7bKrM): **RequireAgentGroupMembership** = "1" If the above is set, a second setting, **AgentGroupMembership** must be configured to define the AD group name. As an example: AgentGroupMembership = "2PINT\StifleRClientAccess" {% hint style="info" %} Note: If the client or the server is **not** in a domain, or a trusted domain, then the Local System account attempts to use ANONYMOUS LOGON. This cannot be verified against a group, and would fail if the setting **RequireAgentGroupMembership** is configured. {% endhint %} ## Client certificates If the client population is spread across a number of different domains, or are not domain joined, you can use certificates to control access. To require a client certificate, the setting: **RequireAgentClientCertificate** must be defined in the [StifleR Server Config file](broken://pages/nHStlYiqePE9p1g7bKrM). If enabled, the settings: **CertificateClientThumbprint** and **CertificateRootThumbprint** must also be defined in the configuration file. The 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. {% hint style="info" %} NOTE: Client certificates are not related to web-based communication or HTTPS. They are separate entities and HTTPS does not verify that the client can authenticate as client certificates do. {% endhint %} ## Client token There is a further (less secure) method that can be used if you are unable to use group membership or client certificates. This requires a client ‘token’ value to be configured on the server and client. The setting for the [StifleR Server configuration file](broken://pages/nHStlYiqePE9p1g7bKrM) 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). # Online services 2PintSoftware Online Services (OS) is a cloud-hosted component designed to extend and enhance the capabilities of StifleR. It acts as a supporting service that enables communication with external systems and provides essential backend functionality required for selected StifleR features. Online Services is not required for core StifleR traffic management but is used to enable specific cloud-assisted capabilities. ## Core Functions Currently, 2PintSoftware Online Services provides the following functionality: * **Third-party API integration**\ Enables communication with external services, primarily location-based platforms such as Azure Maps, to support geographic visualization and mapping features within StifleR. * **Licensing telemetry**\ Handles license registration, validation, and telemetry reporting to ensure correct licensing state across StifleR deployments. *** ## Data Transmission and Privacy 2PintSoftware Online Services exchanges a limited and well-defined set of data with 2Pint Software’s cloud infrastructure. This data exchange supports features such as geographic mapping, license validation, and high-level telemetry for StifleR environments. No end-user identity data or content payloads are transmitted. *** ## Data Types Transmitted ### Location Services – Network Geocoding For network-level geolocation, the following data may be transmitted: * Geographic coordinates only, with no associated identifiers. * Coordinates are derived from the client’s best available location estimate, typically provided by Windows Location Services. ### Location Services – Client Geocoding For client-side geolocation, the following data may be transmitted: * Nearby BSSIDs (Wi-Fi access point identifiers) used solely for coordinate translation. * No additional client information, device identifiers, or network metadata is sent. ### Telemetry Data The following telemetry information may be transmitted to Online Services: * SHA256 hash of the license key * SHA256 hash of the StifleR server host name * Product identifier (for example, StifleR) * Number of currently connected clients * Total number of clients observed * StifleR version All telemetry values are designed to support licensing validation and product usage insights only. *** ## Disabling Data Transmission If telemetry or geolocation services are not desired, administrators can disable specific Online Services features through configuration settings. ### Disable Location Services To prevent any location-related data from being transmitted: 1. On the StifleR server, modify the default network creation flags. 2. Disable the following flags: * BSSIDExistingLocation * GeoData This disables both coordinate-based and BSSID-based geocoding requests. ### Disable License Telemetry (Heartbeats) To stop license telemetry (heartbeat communication) from being sent to Online Services: * Disable Online Services heartbeats in the StifleR configuration. Once disabled, no periodic licensing validation or telemetry updates will be transmitted. # Licensing and Features StifleR uses license keys to unlock features, and lets administrators enable or disable individual features without re-entering a key. This document covers how to obtain and apply a license, what the available features are, and how to troubleshoot common problems. ### Overview StifleR licensing has two layers: 1. **License keys** — cryptographically signed keys issued by 2Pint Software. Each license key contains three things: one or more **product codes** that determine which features it unlocks, the **number of clients** the license covers, and an **expiry date**. 2. **Feature management** — once a feature is unlocked by a license key, administrators can enable or disable it from the dashboard without changing the key. When the StifleR Service starts, it validates every installed license key. Each valid key unlocks one or more features. Feature management then combines those unlocked features with the administrator's on/off toggles — and, for the DeployR Community edition, the most recent Online Services heartbeat result — to produce the set of features that are currently enabled. The resulting state is what is shown on the **Licenses** and **Features** pages in the dashboard. #### Always-included features Three features are always active regardless of licensing: **Administration**, **Devices**, and **Networks** (collectively called PlatformR). These cannot be disabled.\ \ \--- ### Features at a glance | Feature | What it covers | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Administration | License management, feature toggles, user and role administration, server health | | Devices | Client device management, elevation data, SRUM data | | Networks | Areas, locations, network groups, networks | | BandwidthManagement | Throttling policies, BranchCache and Delivery Optimization settings, traffic visibility | | CacheManagement | Cache usage reporting | | OsdDeployments | OSD task sequences, Autopilot, generic deployments | | DeployR | Full DeployR integration — task sequences, boot images, application and OS content | | CacheR | CacheR distribution points, packages, tracked content | | RemoteR | Remote tools — file explorer, registry viewer, WMI viewer, event logs, performance counters, remote assistance, RDP, and more | | MOM | MOM integration | ### Installation and prerequisites #### Obtaining a key Contact 2Pint Software or your reseller to obtain a license key. #### Applying a key 1. Open the **StifleR Config Editor** on the server running the StifleR Service. 2. Navigate to **General Settings**. 3. Enter the key in the **License Keys** field. 4. If you have multiple keys (for example, a separate CacheR key alongside a StifleR key), add each additional key to the **License Keys** list. 5. Save and restart the StifleR Service. The service validates all keys at startup. Duplicate keys (case-insensitive) are deduplicated automatically. #### Online license validation The **DeployR Community** edition (product code `DC`) is the only license type that requires online validation. The StifleR Service must be able to reach the 2Pint Online Services endpoint at `https://api.service.2pintsoftware.com` at least once per hour — see [Online Services heartbeat](#online-services-heartbeat) for the grace-period behaviour. All other license types are validated locally on the server and do not require any outbound connectivity for licensing.\ \ \--- ### Dashboard pages #### Licenses page Navigate to **Administration > Licenses** in the dashboard to view the Licenses page. The page shows: * A table listing each installed license with columns: **Name**, **Type**, **Expires on**, **Nodes**, and **Days left**. * The **last Online Services heartbeat** result — time of the last successful contact with 2Pint Online Services, and any error if the last attempt failed. * A summary of **connected clients** compared against **licensed node counts**. #### Features page Navigate to **Administration > Features** in the dashboard to view the Features page. The page shows: * A table listing every known feature with columns: **Name**, **Licensed**, **Enabled**, **License type**, **Expiration**, **Nodes**, and **Disabled reason**. * Toggle buttons for each licensed, non-always-included feature. Clicking a toggle opens a confirmation dialog and then enables or disables the feature immediately. Changes take effect instantly. The always-included features (Administration, Devices, Networks) do not have toggle buttons and cannot be disabled.\ \ \--- ### Online Services heartbeat The DeployR Community edition requires a successful heartbeat to 2Pint Online Services at least once per hour for its features to remain enabled. This is checked continuously while the service is running. **Grace period:** If the heartbeat cannot be reached, features remain enabled for up to **1 hour** after the last successful contact. If the outage exceeds 1 hour, the DeployR feature is disabled until connectivity is restored. **At startup:** If no heartbeat has ever succeeded, the 1-hour grace period starts from service start time. **Mixed keys:** If you have two license keys installed — one with the DeployR Community and another with DeployR Enterprise — the heartbeat requirement does not apply; the standard key exempts the feature from online validation. To check the current heartbeat status, go to the **Licenses page** in the dashboard — it shows the time of the last successful contact and any error from the most recent attempt.\ \ \--- ### Disabled reasons The **Disabled reason** column on the Features page explains why a licensed feature is not currently active. The possible reasons are: | Disabled reason | Meaning | | ------------------------------------- | -------------------------------------------------------------------------------------------------- | | *License expired* | The covering license key has passed its expiry date. | | *License tampering detected* | The license key signature does not validate — the key may have been modified. | | *Online services connection required* | DeployR Community edition; the last successful Online Services heartbeat was more than 1 hour ago. | | *Disabled by administrator* | An administrator toggled this feature off on the Features page. | ### Permissions Viewing and managing licenses and features requires Administration permissions. # Access Control StifleR's access control system has three layers that work together: [**licensing**, **features**,](/stifler/operations-and-features/licensing-and-features) and [**RBAC permissions**](/stifler/configuration/roles-and-permissions-rbac). ``` License key  ──▶  Feature sets unlocked  ──▶  Admin enables/disables  ──▶  RBAC permissions apply ``` Your license determines which **feature sets** are available. Features can be globally enabled or disabled by an administrator on the Features page. Within each enabled feature set, **RBAC subjects** (for example BootImage, TaskSequence, ThrottlingPolicy) define what a user can act on, and **verbs** (Read, Write, Delete) define how. If a feature is unlicensed or disabled, all RBAC permissions under its subjects are denied — regardless of what roles grant. ### Access hierarchy | Level | Description | Configuration | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | **Global Admin** | Full access to everything. Bypasses all permission checks. | StifleR Service Config Editor — `AdministratorGroup` or OIDC group mapping | | **Global Read** | Read-only access to all feature sets, dashboard-wide. | StifleR Service Config Editor — `ReadGroup` or OIDC group mapping | | **Role-based (RBAC)** | Fine-grained permissions granted through roles. A user can have multiple roles; effective permissions are the union of all roles. | [Roles And Permissions (RBAC)](/stifler/configuration/roles-and-permissions-rbac) | | **No access** | No roles, not global admin or read. Blocked at login. | — | For **Windows authentication**, Global Admin and Global Read are configured in the StifleR Service Config Editor via the `AdministratorGroup` and `ReadGroup` settings. For **OIDC authentication**, they are mapped via group claims in your identity provider (see [Entra ID Integration](/stifler/configuration/entra-id-integration) or [Ping Identity Integration](/stifler/configuration/ping-identity-integration)). Role-based permissions are managed within the StifleR dashboard under **System > Roles**. ### Licensed feature sets Your license key(s) determines which feature sets are available. **Administration**, **Devices**, and **Networks** are always available. All other feature sets require a license key and can be enabled or disabled by an administrator. If a feature set is missing from the permissions matrix or from the dashboard menu, it is either unlicensed or has been disabled under **System > Features**. See [Licensing and Feature Management](/stifler/operations-and-features/licensing-and-features) for how to apply license keys and manage feature toggles. ### Feature sets and subjects Each feature set contains subjects. A permission record grants a user access to one or more subjects within a feature set, for specified verbs (Read, Write, Delete). | Feature set | Subjects | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Administration | License, Feature, User, Rule, Role, Policy, InfrastructureService, ServerHealth, NetworkGroupTemplate | | Devices | Device, Elevation, Srum | | Networks | Area, Location, NetworkGroup, Network | | BandwidthManagement | ThrottlingPolicy, BranchCacheSettings, DeliveryOptimizationSettings, Traffic | | CacheManagement | Usage | | OsdDeployments | Osd, Autopilot, Generic | | DeployR | StepDefinition, TaskSequence, BootImage, ApplicationContent, OsContent, DriverPackContent, OtherContent | | CacheR | Packages, DistributionPoints, TrackedContent | | RemoteR | FileExplorer, FileContent, RegistryViewer, WmiViewer, EventLogs, PerformanceCounters, ResourceMonitor, TaskManager, DeviceInformation, RemoteAssistance, Rdp, RemoteCli, TsData, Intune, TunnelRdp, ReadLog | | MOM | *(no subjects defined yet)* | > **Note:** This page describes dashboard user access control. For client agent access control (restricting which StifleR Client agents can connect to the server), see StifleR Client Access Control Options. # CacheR operations ## Adding distribution points Distribution Points in CacheR are currently used to represent availability only. \ To add Distribution Points, open the **StifleR Dashboard** and navigate to **Cache Management**, then **CacheR**, and select **Distribution Points**. If multiple CacheR servers are present, select the CacheR server you want to configure.
Add a new Distribution Point and provide a friendly name and the root URL of the Distribution Point.
Once added, the CacheR Worker service will process the entry. When processing is complete, the Distribution Point status will change to **Available**, confirming that it has been successfully detected and validated.
## Tracking content ### Manually adding CacheTracks (packages) Before manually creating CacheTracks, you must gather several required details. These include the **Package ID or Application ID**, the **Package Version** is the ConfigMgr details that is needed so those values need to be collected from there. And the **Base URL** where the content is hosted. Tools such as [**BCMon**](https://github.com/2pintsoftware/BranchCache/tree/master/BCMon) or the PowerShell script [**Get-ConfigMgrContentLocationFromMP.ps1**](https://github.com/2pintsoftware/ConfigMgr/blob/master/Get-ConfigMgrContentLocationFromMP.ps1) can be used to identify and confirm the correct content URLs.
To add a CacheTrack, navigate to **Cache Management** in the StifleR Dashboard, then **CacheR**, and select **Packages**. Choose the appropriate CacheR server if prompted, then select **Add** to create a new package entry.
Populate all required fields with the collected information and confirm the configuration. {% hint style="danger" %} After clicking OK there might be a small delay, DON’T click again! {% endhint %}
Once the package has been processed, opening the package details should show that all URLs were successfully parsed and validated. At this stage, use the **Download zip file** option to verify that CacheR is functioning correctly and that the zip file is accessible. This download URL is also the address that must be used later for client-side reporting.
Additionally, verify on the CacheR server that the zip file has been created in the designated **zipfiles** directory. ``` \\install path\CacheR\CacheR.Files\ZipFiles ``` ### Manually configuring client side reporting For a client to report its caching status back to CacheR, several values must be provided. These include the **Zip file URL**, which is the relative path shown under **Download File** for the package in the StifleR Dashboard, the **CacheR Secret Key** obtained from the configuration editor, the **CacheR URL**, and the **CacheR Port**, which defaults to **9050**. Client-side reporting is performed using the **Cacher.Client.exe** command-line tool. The syntax requires specifying the CacheR endpoint, port, zip file path, CacheTrack GUID, and the secret key. ``` Cacher.Client.exe ``` Each client must execute this command for every CacheTrack it is expected to report on. To scale this process, it is recommended to distribute and execute these commands using a **Configuration Manager Configuration Item** or an **Intune Remediation Script**, ensuring consistent and automated reporting across devices. ### Automated CacheTrack Management with CacheRCIManager.ps1 For environments using Configuration Manager, the script **CacheRCIManager.ps1** provides a fully automated approach to managing CacheTracks and client-side reporting. This script synchronizes Configuration Manager packages and applications used within one or more Task Sequences into both CacheR and a single Configuration Item (CI). The script treats the specified Task Sequence or Task Sequences as the authoritative source. Any content referenced in the Task Sequences is automatically added to CacheR and the CI. Conversely, content that no longer exists in the Task Sequences is removed from CacheR and the CI by default. This ensures long-term consistency without manual cleanup. As a result, a single Configuration Item is created containing one compliance setting per package or application used in the specified Task Sequences. Each compliance setting runs a lightweight PowerShell detection script that invokes **Cacher.Client.exe**, allowing clients to report their caching status back to the CacheR server. This approach guarantees that CacheR and the Configuration Item remain fully synchronized with Task Sequence changes. After updating a Task Sequence, simply re-run the script to refresh CacheTracks and reporting logic automatically. #### **Prerequisites (must be in place before first run)** | Prerequisite | Details | | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | ConfigurationManager PowerShell module (installed automatically when installing CM Admin Console) | $env:SMS\_ADMIN\_UI\_PATH must exist | | CacheR PowerShell module | Unzip CacheRApi.0.1.0.zip and add the unzipped folder into your PowerShell modules folder. | | AdminService enabled and reachable on the SMS Provider | Semi optional, only used for cleaning up old CI revisions. More housekeeping than an actual requirement. | | A manually created (empty) Configuration Item in ConfigMgr with the exact name given in parameter -DestinationCIName | Script does NOT create the CI for you | | Permissions | Account running the script needs full Control on the CI | #### **Required Parameters** | Parameter | Description | Example | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ | | -SiteCode | SCCM site code | "P01" | | -ProviderMachineName | FQDN of SMS Provider | cm01.contoso.com" | | -SourceTSNames | One or more TS names (exact match) | Windows 11 24H2", "Win11 PreCache" | | -DestinationCIName | Name of the CI that will be managed | “2Pint CacheR Update” | | -CacheRserver | FQDN to CacheR Server | | | -CacheRPort | WebAPI port (default 9050) | 9050 | | -CacheRApiKey | API key configured in CacheR, found in Config Editor tool | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | | -DPFQDN | Full https URL to a Distribution Point that CacheR can reach | | | -SizeInMB | Minimum size of packages to track (default 1 MB) | 50 | | -PrefixToSkip | If a child TS contains content you do not want tracked by CacheR or added to the CI, name it with this prefix (default: SkipPreCache) and it will be automatically excluded. | NoPreCache" | | -IgnoreContentDifferences | Keep packages/apps in CI/CacheR even if they are no longer found in TS | - | #### Typical scheduled execution (example) ``` .\CacheRCIManager.ps1 -CacheRserver https://cacher-01. contoso.com -CacheRApiKey "11111111-2222-3333-4444-555555555555" -CacheRPort 9050 -ProviderMachineName "cm01.contoso.com" -SiteCode "P01" -SourceTSNames "One Task Sequence", "Another Task Sequence", "A third Task Sequence" -DestinationCIName "2Pint CacheR Update" -SizeInMB 20 -DPFQDN "https://dp01.contoso.com" ``` Run this daily (or after every TS change) via Scheduled Task running under a service account with the required rights. # Remote tools features ## Overview Within the Client Details page for a specific client, at the top right of the **Connection information** section, there is a small tool icon, which if clicked, opens a drop down menu which displays the following actions:
**Start RDP Session -** creates an RDP file to execute a Remote Desktop session with the client. **Start a PowerShell session over SignalR -** opens a page which allows remote PowerShell commands to the client. **Start remote Performance Counter session -** opens a page which displays remote Performance Counter information. **Start a remote WMI browsing session -** opens a page which enumerates the WMI database of the remote computer. **View eventlogs over SignalR -** opens a page which displays the Event Logs of the remote client. **Start a Netmon session -**opens a page which displays netmon session on the remote client. ## Remote PowerShell Session StifleR provides the ability to execute a remote PowerShell session using the Dashboard that replicates the full functionality of Windows PowerShell as it would be executed locally. To execute a PowerShell command on the client, type the command into the bottom text box and click the **Execute** button. The output will be displayed in the console output pane.
Within the blue bar towards the top of the screen, there are several quick action buttons which can execute pre-defined common commands. Clicking these buttons will execute the respective command on the remote client. * **Get computer info** * **Test NetConnection** * **Ping** * **Get BC Status** * **Get DO config** * **Flush BranchCache** * **IP config** * **Network stats** * **Flush CCM cache**
## Remote Performance Counter StifleR provides remote access to the performance counter for a single device, allowing administrators to monitor and optimize system performance in real time. The table view allows you to define required categories and set multiple counters at once to analyze performance, compare category data with each other, check live system performance, and search and filter for results and keywords.
## Remote WMI Browsing StifleR provides remote access to WMI (Windows Management Instrumentation) for a single device. The table view allows you to expand the various WMI classes and instances on the remote machine.
## Remote Event Log Viewer The StifleR provides remote access to Event Logs for a single device. In the left pane, select the event log you would like to view, then select the **icon** in the View column. The right pane should expand to enumerate the events. For more text based detail for the specific event, select the **icon** in the View column. The table view allows you to find relevant information quickly by setting custom filters, enabling disabling empty logs, searching for data by any keyword or simply sorting data by required criteria.
## Remote Netmon Session The StifleR provides remote access to Netmon data for a single device.
# Client Read-Only Mode StifleR clients can operate in two modes: * **Full mode** — the client actively monitors and manages bandwidth, applying throttling policies to BITS and Delivery Optimization transfers. * **Read-only mode** — the client monitors and reports network activity but does not intervene in any transfers. In read-only mode the client: * Reports network activity, downloads, and status to the server as normal * Does **not** apply bandwidth policies * Does **not** manage BranchCache or Delivery Optimization settings ## How the server controls client mode When a StifleR client starts up, it checks in with the server to receive its licensing state. The server evaluates whether the **BandwidthManagement** feature is licensed and enabled: * **Licensed and enabled** → client runs in full mode * **Unlicensed or disabled** → client runs in read-only mode This means you can switch an entire fleet between full and read-only mode from the server, without touching client configuration. Go to **Administration > Features**, toggle BandwidthManagement off, and all clients will enter read-only mode on their next start. > **Note:** A client's mode is determined once at startup and does not change while it is running. This is by design — certain operations must happen at startup, and changing mode mid-session would leave the client in an inconsistent state. Clients already running are not affected until they restart. ## Identifying read-only clients Read-only clients report their status back to the server. You can find all clients currently running in read-only mode using the **Flag Search** in the dashboard and filtering for the **Read Only** flag. ### Local override A client can be configured to always run in read-only mode regardless of what the server says. This is useful for deploying the client in monitoring-only mode to a site before bandwidth management is needed. Contact 2Pint Software or refer to the client configuration reference for details. ### Behaviour when the server is unreachable If the client cannot reach the server at startup, it falls back to the licensing state from its last successful connection. If the client has never successfully connected to the server, it defaults to full mode. ### Version compatibility | Client version | Server version | Behaviour | | -------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | 3.1 | 3.1 | Server controls mode via licensing state | | 3.1 | 3.0 | Client defaults to full mode — the 3.0 server does not support the licensing endpoint, so the client assumes no restriction is intended | | 3.0 | 3.1 | Client runs normally — 3.0 clients are not mode-controlled by the server | You can upgrade the server to 3.1 and roll out 3.1 clients gradually. 3.1 clients on a 3.0 server will run in full mode during the transition. # Bandwidth management and allocation ## Overview In most corporate environments clients will connect in several different ways depending on location and scenario. Bandwidth control must make allowances for these different scenarios with connected clients on managed networks, roaming clients, and those connecting over VPN. Clients may be on well-connected networks or slow links with or without peers. StifleR must also recognize and cater for situations where the StifleR server cannot be contacted. The StifleR Client can be configured to recognize these different situations and adjust bandwidth allowances accordingly. The following is an overview of the various scenarios: ## Network group types A network group can be of the following types: * Regular * Well connected * VPN Depending on the setting the bandwidth is allocated very differently. Typically a Well Connected network has more than 50Mb/s network bandwidth available to it as it’s less strict on the bandwidth throttling and allows for overconsumption for short periods of time for improved user experience. ## Control options Just because a client is assigned bandwidth does not mean that it will automatically use it. If a Red Leader is assigned a large amount of bandwidth but all content for the download element is available from other peers, there will be no bandwidth used. All bandwidth values below are in Kilobits per second (Kbps). The below table references the different properties within a [template](/stifler/operations-and-features/overview-and-navigation/devices/stifler-server/templates-detail) which is applied to a network group.
Network Group PropertyDefinition
TypeDefines how bandwidth is controlled, like VPN, Regular, and Well Connected.
LocalInternetBreakoutIf set, downloads from the internet are throttled differently than non-internet downloads. Disabled by default.
TargetBandwidthThe bandwidth assigned to Red Leaders.
InternetBandwidthWhat bandwidth Internet downloads should have when local Internet breakout is set.
LEDBATTargetBandwidthValue to assign Red Leader BITS jobs when LEDBAT has been detected.
NonRedLeaderBITSBandwidthValue set for BITS downloads that are not leader in regular networks.
NonRedLeaderDOBandwidthValue set for DO downloads that are not leader in regular networks.
WellConnectedDOSet on BITS downloads for well connected networks.
WellConnectedBITSSet on DO downloads for well connected networks.
BandwidthTuningHistoric and future use, not used currently.
WellConnectedSplitbandwidthControls how bandwidth is split to clients for well connected networks. Not used for regular networks currently.
### Red Leader and non-leader clients The use of a [Red Leader](/stifler/operations-and-features/features-overview/client-leader-roles/red-leader) is to improve peering efficiency by allowing a single client to get bytes slightly faster than other clients. It’s a 100% dynamic allocation and does not impact the client being the Red Leader. ## Well-connected network groups In this mode the StifleR client does not allow for sharing bandwidth from the DO pool to the BITS pool and vice versa if only one download technology is actively downloading as the regular or VPN networks do. ### Red Leader bandwidth assignment for well-connected networks On a well-connected network the bandwidth for the Red Leader role is as per the below formula. The value that is the highest of the two wins: * WellConnectedDO and WellConnectedBITS values split by the number of clients downloading for all networks in the network group. * The Target Bandwidth divided by number of networks that are actively downloading (active networks) Whatever value is the highest of above is assigned to the Red Leader only for well-connected networks. > #### Example: > > If there are 4 active networks in the same network group, which has been assigned to use 20 Mbps (target bandwidth). \ > Each Red Leader is assigned bandwidth based on the formula: 20 Mbps / 4 = 5 Mbps, but the WellConnectedDO and WellConnectedBITS values are set to 100 Mbps.\ > Lets say that only 10 clients are downloading content among these 4 networks. This means that the Red Leader will be assigned 100 Mb/10 = 10 Mbps as 10 Mbps is a higher value than 5 Mbps. > > If there were 30 clients downloading content, the 4 Red Leaders would each get 5 Mbps as 100 Mbps/30 = 3.3 Mbps which is less than 5. > > The reason for this logic is to allow fast downloads on well-connected networks regardless of how many clients are connected. ### Non-leader bandwidth assignment in well-connected networks Clients are allocated the bandwidth according to the split setting. If the WellConnectedSplitbandwidth option is set to 1 in the [StifleR Server Config File](broken://pages/nHStlYiqePE9p1g7bKrM), (enabled by default in StifleR 2.10 and above), the bandwidth per client is calculated as: * WellConnectedDOBandwidth value / per number of clients downloading * WellConnectedBITSBandwidth value / per number of clients downloading * Internet value for local Internet Breakup is also calculated as per InternetBandwidth / per number of clients downloading from the Internet. {% hint style="info" %} Note: There is no sharing across the bandwidth pools when a network group is well connected. {% endhint %} If the WellConnectedSplitbandwidth options is not set, bandwidth is assigned to actual values of the WellConnectedDOBandwidth and WellConnectedBITSBandwidth values. ### Internet bandwidth for well-connected networks with Internet breakout Set Bandwidth for Internet can be assigned differently than regular downloads if the network group is set to throttle the Internet traffic differently. This only applies to non Red Leaders. The throttling limits are different for well-connected networks depending if WellConnectedSplitbandwidth is enabled for the network group. If this is enabled, the logic for any non Red Leader is that it gets bandwidth as per the following formula: * Internet bandwidth value / clients running Internet downloads If WellConnectedSplitbandwidth is not set, the value is instead set to the actual value per client, i.e. each client is assigned the InternetBandwidth value as bandwidth for downloads coming from the Internet. ### LEDBAT assignment for Red Leaders in well-connected networks How does this work? The Red Leaders are assigned a special LEDBAT value which is typically allowed to be higher than the regular TargetBandwidth property. Any download job that then has been detected as LEDBAT capable will be allowed to use this value. LEDBAT bandwidth will be assigned to the Red Leader only, and only for BITS jobs. If the download has the return header set for LEDBAT, the running job will be assigned the value from the LEDBATTargetBandwidth setting for the network group. The value is assigned to the Red Leaders same as any other Red Leader bandwidth using the formula: * LEDBATTargetBandwidth / active networks ## Regular network groups In this mode the StifleR client allows for sharing bandwidth from the DO pool to the BITS pool and vice versa if only one download technology is actively downloading. A BITS job can therefore be assigned both the DO and the BITS download policy for a single BITS job. ### Red Leader bandwidth assignment for regular networks Bandwidth for the Red Leaders are assigned as: * TargetBandwidth / number of downloading networks > Example: > > If you have 3 networks but only 2 networks are active, and the TargetBandwidth is set to 18 Mbps. Each of the two Red Leaders on the active networks will be assigned 9 Mbps each. ### Non-leader bandwidth assignment for regular networks Non-leader bandwidth assignment for this type of network are calculated as such: BITS: NonRedLeaderBITSBandwidth is assigned to the client. DO: NonRedLeaderDOBandwidth is assigned to the client. The client is then assigned one value or doubling them up if there is only one download technology active. If both are active, the individual values are used. > Example: > > BITS is assigned 128 Kbps, and DO 128 Kbps. Then if there is only BITS transferring, BITS is then assigned 128 + 128 = 256 Kbps. > > If there is both a BITS job and a DO download, each technology gets 128 Kbps. > > If there is just one DO job, the client gets 256 Kbps, via 128+128. ### Internet bandwidth for regular networks with Internet breakout set Bandwidth for Internet can be assigned differently than regular downloads if the network group is set to throttle the internet traffic differently. This only applies to non Red Leaders. This differs for how it works for well connected networks. WellConnectedSplitbandwidth is not used for regular networks. For regular networks that have Internet breakout enabled, the logic is as per the following formula: * InternetBandwidth / active Internet clients ### LEDBAT bandwidth assignment for regular networks LEDBAT bandwidth will be assigned to the Red Leader only, and only for BITS jobs. Same as for LEDBAT for well-connected networks. If the download has the return header set for LEDBAT, the running job will be assigned the value from the LedbatBandwidth setting from the network group. The value is assigned to the Red Leaders as any other Red Leader bandwidth, using the formula: * LedbatBandwidth / active networks ## VPN network groups VPN networks assign bandwidth differently compared to regular and well-connected networks, as there is no assigned Red Leader. This is because peering is typically not desired or possible on VPN networks. In this mode, the StifleR client allows for sharing bandwidth from the DO pool to the BITS pool and vice versa if only one download technology is actively downloading. Each client is assigned: BITS: The network group target bandwidth / 2 / active clients for the network. DO: The network group target bandwidth / 2 / active clients for the network. The bandwidth is then shared across the download technologies. > #### Examples: > > A network group has 100 Mbps set for a VPN network. There are 10 active (downloading) VPN clients, that are only downloading content using BITS. > > Each client is assigned the following bandwidth: > > BITS is then assigned: 100 / 2 / 10 = 5 Mbps. > > DO is assigned: 100 / 2 / 10 = 5 Mbps. > > As bandwidth is shared for VPN and there is only BITS jobs, the 10 clients assign 5+5 = 10 Mbps per client toward the BITS download. ### Internet bandwidth for VPN networks with local Internet breakout (split tunnel) If the VPN network group has been set for local Internet breakout, any client that has Internet download enabled is assigned the value of the Internet bandwidth assigned to the network group. Typically this is used to set the Internet bandwidth to 0, i.e. unlimited as this download is then using the network that the VPN is accessing from. If breakout is not set, bandwidth for Internet downloads is throttled the same way as any other download. ## Roaming clients Clients that are roaming are clients that are not assigned to a network group but are able to connect to the StifleR server. Bandwidth is assigned for roaming clients from the DefaultRoamingBandwidth configuration value in the local [StifleR Server Configuration file](broken://pages/nHStlYiqePE9p1g7bKrM). If the server sends an updated value, the client will update the local configuration to the new value. 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). > Example: > > If Default RoamingBandwidth is set to 50 Mbps (51200) then the clients would get 25 Mbps for BITS and 25 Mbps for Delivery Optimization. ## Disconnected clients At start up, the StifleR client will automatically set the DefaultDisconnected Bandwidth limits (DO and BITS) values which are defined in the [client configuration file](broken://pages/oawEeEGDtdQVU7o0yKF6). The client's bandwidth settings will then be set as per the following logic: * If the StifleR Server name can be resolved, but is not allowing connections, we assign the disconnected client bandwidth settings as per the [client configuration file](broken://pages/oawEeEGDtdQVU7o0yKF6). * If the server is not resolved using DNS and not reachable, we remove all throttling. # Bandwidth tuning monitoring and control ## Overview ### Bandwidth Tuning StifleR continuously monitors network conditions and can dynamically adjust client download bandwidth to maximize performance while minimizing the impact on other network traffic. Rather than relying on fixed bandwidth limits, Bandwidth Tuning allows StifleR to react to changing network conditions, ensuring that available bandwidth is used efficiently without degrading the user experience. Bandwidth Tuning can respond to several network conditions, including increased latency, unusually low or high bandwidth utilization, LEDBAT-enabled content servers, and measured network capacity obtained through the StifleR Beacon. Depending on the selected configuration, StifleR can automatically increase or decrease client bandwidth to maintain optimal performance. ### Configuration Scope Bandwidth Tuning is configured at two levels: * **Server level** - Defines which Bandwidth Tuning features are available globally. These settings are configured using the **StifleR Config Editor**. * **Network Group level** - Determines which of the globally enabled features apply to a specific Network Group. These settings are configured from the **StifleR Dashboard**. A feature must be enabled at both levels before it becomes active for a Network Group. ### Available Bandwidth Tuning Features The following Bandwidth Tuning options are available: | Feature | Description | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Latency** | Monitors network latency and adjusts bandwidth when the configured latency threshold is exceeded or returns to normal. | | **LowBandwidth** | Detects when bandwidth utilization is significantly below the configured target and attempts to increase throughput. | | **HighBandwidth** | Detects when bandwidth utilization exceeds the configured target, typically indicating that bandwidth throttling is not being applied correctly. | | **LEDBAT** | Enables LEDBAT++ congestion control, allowing higher bandwidth utilization while automatically yielding to higher priority network traffic. | | **Beacon Measurement** | Uses the StifleR Beacon and iPerf3 to periodically measure the maximum available bandwidth for a Network Group and use that value when calculating bandwidth limits. | By default, the StifleR Server enables **Latency**, **LEDBAT**, and **Beacon Measurement**. ### Bandwidth Tuning Values Internally, StifleR stores Bandwidth Tuning options as bit flags, allowing multiple features to be enabled simultaneously. | Feature | Value | | ------------------ | ----- | | Latency | 1 | | LowBandwidth | 2 | | HighBandwidth | 4 | | LEDBAT | 8 | | Beacon Measurement | 16 | The values are additive. For example: * **7** enables **Latency**, **LowBandwidth**, and **HighBandwidth** (1 + 2 + 4). * **25** enables **Latency**, **LEDBAT**, and **Beacon Measurement** (1 + 8 + 16), which is the default server configuration. The same values are used when configuring individual Network Groups. A feature must be enabled both globally and for the Network Group before StifleR applies it. ### Event Logging Whenever a Bandwidth Tuning feature adjusts bandwidth or detects that a configured threshold has been exceeded, StifleR records the event in the Windows Event Log. These events can be used to verify that Bandwidth Tuning is functioning as expected and to assist with troubleshooting network performance. *** ## Latency Detection Latency Detection allows StifleR to dynamically adjust client download bandwidth based on the network latency between the client and the download source. This helps maximize available bandwidth while preventing download traffic from negatively impacting interactive applications or other business-critical network traffic. StifleR continuously measures the round-trip time (RTT) using ICMP ping requests. If the content source is located on the internal network, latency is measured directly to that server. For Internet-based content sources, latency is measured to the StifleR Server instead. When the measured latency exceeds the configured **Latency Threshold**, StifleR gradually reduces the available download bandwidth. Once latency returns below the threshold for the configured recovery period, bandwidth is increased incrementally until the configured target bandwidth is reached. ### Configuration To use Latency Detection: 1. Enable **Latency** in the server-level **Bandwidth Tuning** configuration. 2. Enable **Latency** for the required Network Group. 3. Configure the following Network Group settings: * **TargetBandwidth** - The maximum bandwidth available to clients in the Network Group. * **LatencyThreshold** - The latency value, in milliseconds, that triggers bandwidth adjustment. Only when all three conditions are met will StifleR automatically tune bandwidth based on network latency. ### How Bandwidth Adjustment Works Latency Detection does not immediately switch between bandwidth values. Instead, StifleR gradually adjusts the configured bandwidth to avoid sudden fluctuations in network utilization. The rate at which bandwidth increases or decreases is controlled by several server configuration settings, including: | Setting | Description | | ---------------------------------- | ------------------------------------------------------------------------------------------- | | **LatencyWarningDecreaseDuration** | Time that latency must remain above the configured threshold before bandwidth is reduced. | | **LatencyWarningDecreaseFactor** | Controls how aggressively bandwidth is reduced when the threshold is exceeded. | | **LatencyWarningIncreaseDuration** | Time that latency must remain below the threshold before bandwidth begins increasing again. | | **LatencyWarningIncreaseFactor** | Controls how quickly bandwidth is restored toward the configured target. | These settings are configured on the StifleR Server and apply globally to all Network Groups using Latency Detection. ### Example The following example enables Latency Detection for a Network Group: * **TargetBandwidth:** 700 Kbps * **LatencyThreshold:** 70 ms If the measured latency exceeds **70 ms**, StifleR begins reducing client bandwidth according to the configured decrease settings. Once latency remains below **70 ms** for the configured recovery period, bandwidth is gradually increased until the configured **TargetBandwidth** is reached. This adaptive approach allows clients to make efficient use of available bandwidth while automatically responding to changing network conditions. ### WMI Configuration Example The following commands configure a Network Group with a target bandwidth of **700 Kbps**, enable **Latency Detection**, and set the latency threshold to **70 milliseconds**. ``` wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set TargetBandwidth=700wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set BandwidthTuning=1wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set LatencyThreshold=70 ``` Alternatively, the same settings can be configured from the **StifleR Dashboard**, which is the recommended approach for day-to-day administration. *** ## Low Bandwidth Detection Low Bandwidth Detection monitors download throughput and identifies situations where clients consistently use significantly less bandwidth than the configured target. This can indicate that bandwidth is being unnecessarily restricted or that another component in the environment is limiting download performance. Unlike Latency Detection, which responds to network conditions, Low Bandwidth Detection focuses on underutilization. When the measured bandwidth remains below the configured threshold, StifleR can automatically increase the available bandwidth in an attempt to achieve the desired throughput. ### Configuration To enable Low Bandwidth Detection: 1. Enable **LowBandwidth** in the server-level **Bandwidth Tuning** configuration. 2. Enable **LowBandwidth** for the required Network Group. 3. Configure the **LowBandwidthThreshold** value for the Network Group. Once enabled, StifleR continuously compares the current download throughput against the configured threshold and adjusts bandwidth when appropriate. ### Common Causes Low Bandwidth Detection is most useful for identifying environments where download performance is lower than expected despite sufficient network capacity. Common causes include: * Bandwidth limits configured too conservatively * Server-side throttling * Quality of Service (QoS) policies * Misconfigured Group Policy settings * External network restrictions * Other infrastructure components limiting throughput If Latency Detection is not reporting increased latency while Low Bandwidth Detection continues to trigger, the issue is typically related to configuration or infrastructure rather than network congestion. ### Recommendations Low Bandwidth Detection should be thoroughly tested before being deployed in production environments. Increasing bandwidth too aggressively can lead to higher network utilization than intended, particularly on slower or shared links. When used together with **Latency Detection**, StifleR can safely increase bandwidth when the network has available capacity while automatically reducing it if latency begins to rise. This combination generally provides more predictable results than using Low Bandwidth Detection on its own. ### Monitoring Whenever the configured low bandwidth threshold is exceeded, StifleR records the event in the Windows Event Log. These events can be used to verify that bandwidth tuning is functioning correctly and to identify locations where download performance may be limited by external factors. *** ## High Bandwidth Detection High Bandwidth Detection monitors download throughput and identifies situations where clients consume more bandwidth than the configured target. This typically indicates that the expected bandwidth limits are not being applied correctly, allowing clients to exceed the intended network usage. Unlike Low Bandwidth Detection, which identifies underutilization, High Bandwidth Detection focuses on protecting the network by detecting unexpected increases in bandwidth consumption. ### Configuration To enable High Bandwidth Detection: 1. Enable **HighBandwidth** in the server-level **Bandwidth Tuning** configuration. 2. Enable **HighBandwidth** for the required Network Group. 3. Configure the **HighBandwidthThreshold** value for the Network Group. When enabled, StifleR continuously compares the current download throughput against the configured threshold. If the threshold is exceeded, the event is recorded and StifleR can adjust bandwidth according to the configured tuning settings. ### Common Causes High Bandwidth Detection is primarily intended as a diagnostic feature. If clients consistently exceed the configured bandwidth target, it is usually an indication that bandwidth management is not functioning as expected. Common causes include: * Conflicting Group Policy settings * Incorrect or missing BITS policies * Insufficient permissions preventing policy application * BITS policy corruption * Inconsistent Windows updates or known BITS issues * Other configuration issues preventing StifleR from enforcing the intended bandwidth limits Investigating these conditions can help identify why clients are not respecting the configured bandwidth policy. ### Recommendations High Bandwidth Detection is particularly useful for validating new deployments and troubleshooting environments where clients appear to consume more bandwidth than expected. Rather than serving as a replacement for bandwidth policies, it acts as an early warning mechanism that helps identify configuration or policy issues before they affect the wider network. ### Monitoring Whenever the configured high bandwidth threshold is exceeded, StifleR records the event in the Windows Event Log. These events provide valuable diagnostic information and can assist in identifying misconfigured clients, policy conflicts, or other issues affecting bandwidth management. *** ## LEDBAT StifleR supports Microsoft's Low Extra Delay Background Transport (LEDBAT) technology, allowing clients to make more efficient use of available network bandwidth while automatically yielding to higher-priority traffic. This enables background downloads to run at higher speeds without negatively impacting interactive applications or user activity. When LEDBAT is enabled, StifleR can apply a separate bandwidth policy specifically for LEDBAT-enabled downloads. Because LEDBAT continuously adjusts its transmission rate based on network congestion, administrators can typically configure a higher target bandwidth than would be appropriate for standard BITS transfers. ### How It Works When a client starts a BITS download, StifleR checks whether the content server supports LEDBAT. If LEDBAT is detected, StifleR applies the **LEDBAT Target Bandwidth** configured for the Network Group. For downloads from servers that do not support LEDBAT, the standard **Target Bandwidth** is used instead. This allows organizations to take advantage of higher throughput when downloading from LEDBAT-enabled servers while maintaining standard bandwidth limits for all other content sources. ### Configuration To enable LEDBAT support: 1. Enable **LEDBAT** in the server-level **Bandwidth Tuning** configuration. 2. Enable **LEDBAT** for the required Network Group. 3. Configure the **LEDBATTargetBandwidth** value for the Network Group. 4. Enable LEDBAT on the content server. 5. Configure the content server to return the following HTTP response header: ``` LEDBAT: true ``` The client automatically detects this header and applies the configured LEDBAT bandwidth policy. ### Recommended Deployment LEDBAT is particularly beneficial for environments where clients download content from central Distribution Points or other IIS-based content servers. Since LEDBAT automatically backs off when foreground traffic is detected, administrators can safely configure a higher **LEDBAT Target Bandwidth** than the standard **Target Bandwidth**, improving download performance without increasing network congestion. ### Example The following PowerShell example configures a Network Group to use a **LEDBAT Target Bandwidth** of **20 Mbps**: ``` Set-WmiInstance -Namespace root\StifleR ` -Class Subnets ` -Arguments @{ SubnetID = "192.168.4.0" LEDBATTargetBandwidth = 20480 } ``` Once configured: * Downloads from LEDBAT-enabled content servers use the **LEDBAT Target Bandwidth**. * Downloads from standard content servers continue to use the regular **Target Bandwidth**. * LEDBAT automatically adjusts transmission rates to minimize the impact on foreground network traffic. ### Best Practices * Enable LEDBAT on IIS content servers before configuring higher bandwidth limits. * Configure the **LEDBAT Target Bandwidth** based on the available network capacity and deployment requirements. * Continue using a standard **Target Bandwidth** for content sources that do not support LEDBAT. * Validate LEDBAT functionality by confirming that the required HTTP response header is returned by the content server. *** ## Beacon Measurement Beacon Measurement allows StifleR to actively determine the maximum available bandwidth for a Network Group rather than relying on a manually configured bandwidth limit. It uses the StifleR Beacon service and iPerf3 to perform scheduled bandwidth tests between clients and a designated Beacon server, providing an accurate representation of the available network capacity. Unlike the other Bandwidth Tuning features, which continuously react to live network conditions, Beacon Measurement runs on a configurable schedule. The measured maximum bandwidth is stored for each Network Group and can be used to automatically calculate bandwidth limits as a percentage of the available capacity. ### How It Works Only the **Red Leader** within a Network Group performs Beacon measurements. During a scheduled measurement, the Red Leader communicates with the configured StifleR Beacon server using iPerf3 to determine the maximum available upstream and downstream bandwidth. After the test completes, the measured maximum downstream bandwidth is stored for the Network Group. If a newer measurement reports a higher maximum bandwidth, the stored value is updated. Lower measurements do not overwrite the existing value, preventing temporary network congestion from reducing the configured bandwidth baseline. This measured bandwidth can then be used by StifleR when calculating the effective download throttle for clients within the Network Group. ### Bandwidth Calculation Beacon Measurement allows bandwidth policies to be expressed as a percentage of the measured network capacity instead of a fixed bandwidth value. For example: * Measured maximum bandwidth: **100 Mbps** * Configured percentage: **50%** The resulting effective target bandwidth becomes **50 Mbps**. This approach automatically adapts to different network speeds without requiring administrators to manually configure bandwidth limits for every location. ### Template Priority The way Beacon measurements are applied depends on the selected template priority. #### Beacon Measure Priority When **Beacon Measure Priority** is selected, each successful bandwidth measurement automatically updates the effective bandwidth limit for the Network Group. As network capacity changes over time, StifleR adjusts the calculated target bandwidth accordingly. #### Template Priority When **Template Priority** is selected, Beacon measurements are still performed and recorded, but the fixed bandwidth values configured in the Network Group template continue to take precedence. In this mode, the measurement data is available for monitoring purposes but does not influence client throttling. ### Configuration Requirements Beacon Measurement must be enabled in two locations before measurements will run: * **Server-level Bandwidth Tuning**, which enables the StifleR Service to schedule bandwidth measurements. * **Network Group Bandwidth Tuning**, which marks an individual Network Group as eligible for measurement. If Beacon Measurement is disabled at either level, the Network Group is skipped without generating an error. This is the most common reason why measurements appear to be configured but never execute. ### Beacon Server The StifleR Beacon service hosts the iPerf3 endpoint used during bandwidth measurements. It can be installed on any supported Windows server and is typically deployed close to the primary content source, such as a ConfigMgr Distribution Point or another central server that clients regularly access. Although the Beacon service can be installed on the StifleR Server, this is not a requirement. There is no dependency between the two services, allowing the Beacon to be deployed wherever it best represents the available network path. ### Measurement Schedule Beacon measurements are performed automatically by the Red Leader: * When a new Network Group is created. * When the first Red Leader is elected. * Periodically thereafter according to the configured measurement schedule. This allows StifleR to maintain an up-to-date view of the maximum available bandwidth without requiring manual intervention. ### Forcing a Measurement For testing or troubleshooting purposes, a bandwidth measurement can be triggered manually using the `UpdateMaxBandwidth` WMI method. #### WMIC ``` wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.26.0" call UpdateMaxBandwidth ``` #### PowerShell ``` $Subnet = Get-WmiObject -Namespace root\StifleR ` -Class Subnets ` -Filter "SubnetID='192.168.26.0'"Invoke-WmiMethod -Path $Subnet.__PATH -Name UpdateMaxBandwidth ``` ### Best Practices * Deploy the Beacon service as close as possible to the primary content source. * Enable Beacon Measurement at both the server and Network Group levels. * Use **Beacon Measure Priority** when you want bandwidth limits to adapt automatically to changing network conditions. * Use **Template Priority** when bandwidth limits should remain fixed regardless of measured network capacity. * Verify that only one Red Leader performs measurements for each Network Group, as this is the expected behavior. *** ## Automatic Latency Tuning Automatic Latency Tuning enables StifleR to continuously optimize download bandwidth based on real-time network latency. Instead of applying a fixed bandwidth limit, StifleR dynamically adjusts client bandwidth to maintain an acceptable latency while maximizing the use of available network capacity. This feature is particularly useful for networks where available bandwidth varies throughout the day or where maintaining a responsive user experience is more important than enforcing a fixed download rate. ### How It Works StifleR continuously measures the round-trip latency between the client and the monitored endpoint. * For **internal content sources**, latency is measured directly to the content server. * For **Internet-based content sources**, latency is measured to the StifleR Server. When latency exceeds the configured **Latency Threshold**, StifleR gradually reduces the available download bandwidth. Once latency returns below the threshold for the configured recovery period, bandwidth is incrementally increased until the configured **Target Bandwidth** is reached. This continuous adjustment allows StifleR to maximize download performance while automatically responding to changing network conditions. ### Required Configuration Automatic Latency Tuning requires the following Network Group settings: | Setting | Description | | -------------------- | ----------------------------------------------------------------------- | | **TargetBandwidth** | The maximum bandwidth available for downloads. | | **BandwidthTuning** | Must include the **Latency** option. | | **LatencyThreshold** | The latency value, in milliseconds, that triggers bandwidth adjustment. | These settings can be configured from the **StifleR Dashboard** or through WMI. ### Example Configuration The following example configures a Network Group with: * Target bandwidth: **700 Kbps** * Latency monitoring enabled * Latency threshold: **70 ms** ``` wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set TargetBandwidth=700wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set BandwidthTuning=1wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set LatencyThreshold=70 ``` When latency exceeds **70 ms**, StifleR automatically reduces bandwidth. Once latency remains below the threshold for the configured recovery period, bandwidth is gradually restored until it reaches the configured target. ### Tuning Behaviour Bandwidth adjustments are controlled by several server-side configuration settings, allowing administrators to determine how quickly StifleR responds to changing network conditions. | Setting | Purpose | | ---------------------------------- | -------------------------------------------------------------------------------- | | **LatencyWarningDecreaseDuration** | Time latency must remain above the threshold before bandwidth is reduced. | | **LatencyWarningDecreaseFactor** | Determines how aggressively bandwidth is reduced. | | **LatencyWarningIncreaseDuration** | Time latency must remain below the threshold before bandwidth begins increasing. | | **LatencyWarningIncreaseFactor** | Determines how aggressively bandwidth is restored toward the target value. | These settings apply globally to all Network Groups using Automatic Latency Tuning and can be configured in the **StifleR Service** configuration. ### Recommendations Automatic Latency Tuning is recommended for environments where network conditions fluctuate throughout the day. Rather than relying on static bandwidth limits, it allows StifleR to continuously balance download performance against network responsiveness, ensuring that background transfers make efficient use of available bandwidth without impacting interactive traffic. *** ## Server Configuration Options Bandwidth Tuning behavior is controlled by several server-side configuration settings in the **StifleR Service** configuration. These settings determine how quickly StifleR reacts to changing network conditions and how aggressively bandwidth is increased or decreased. The default values are suitable for most environments, but they can be adjusted to better match the characteristics of slower WAN links or high-speed LAN environments. ### Latency Adjustment Settings #### LatencyWarningDecreaseDuration Defines how long the measured latency must remain above the configured **Latency Threshold** before StifleR begins reducing the available bandwidth. **Default:** `10000` milliseconds (10 seconds) ``` ``` #### LatencyWarningDecreaseFactor Controls how aggressively bandwidth is reduced when latency exceeds the configured threshold. The configured **TargetBandwidth** is divided by this value during each adjustment cycle. **Default:** `1.4` ``` ``` For example, if the configured **TargetBandwidth** is **2000 Kbps**, the first reduction would lower the bandwidth to approximately **1428 Kbps**. #### LatencyWarningIncreaseDuration Defines how long latency must remain below the configured threshold before StifleR begins restoring bandwidth. **Default:** `10000` milliseconds (10 seconds) ``` ``` #### LatencyWarningIncreaseFactor Determines how quickly bandwidth is restored after latency returns to an acceptable level. Instead of immediately restoring the full bandwidth, StifleR gradually increases the available bandwidth during each adjustment cycle. **Default:** `5` ``` ``` For example, if: * TargetBandwidth = **2000 Kbps** * Current TunedBandwidth = **500 Kbps** StifleR increases the bandwidth by: ``` TargetBandwidth / LatencyWarningIncreaseFactor ``` Result: ``` 2000 / 5 = 400 Kbps ``` The new **TunedBandwidth** becomes **900 Kbps**, with additional increases occurring every adjustment interval until the configured target bandwidth is reached. ### Adjustment Cycle By default, StifleR evaluates network latency every **10 seconds**. If latency exceeds the configured threshold for longer than the configured decrease duration, bandwidth is gradually reduced. Once latency remains below the threshold for the configured recovery period, bandwidth is incrementally restored according to the configured increase factor. This gradual adjustment prevents sudden bandwidth changes while allowing StifleR to maximize throughput without negatively affecting interactive network traffic. # Beacons ## Overview A StifleR Beacon is a lightweight Windows service that acts as a fixed measurement endpoint on your network. StifleR clients (specifically the elected Red Leader for a subnet) run iPerf3 bandwidth tests against the beacon to determine the maximum available throughput between that subnet and the beacon's location. Deploy beacons on servers from which clients typically receive bulk content — for example, ConfigMgr distribution points, datacenter file servers, or cloud egress nodes. A beacon placed alongside your content source gives the most representative measurement of what clients actually experience. Measurement results are stored per network group and feed directly into bandwidth throttling decisions. Instead of a hard-coded cap, StifleR can limit downloads to a configurable percentage of the measured maximum. *** ## How Measurements Work ### Scheduled measurements The StifleR Service runs a continuous measurement loop: 1. Every **30 minutes**, it scans all network groups and queues any that are due for\ a new measurement. 2. A network group is queued if **all** of the following are true:\ \- A beacon is reachable from the group (see [Beacon Assignment](https://2ps.visualstudio.com/StifleR/_wiki/wikis/StifleR.wiki/168/Beacon-3.x-#beacon-assignment) below)\ \- Beacon measurement is enabled at both the server level and the network group level\ (see [Configuring a Beacon Server](https://2ps.visualstudio.com/StifleR/_wiki/wikis/StifleR.wiki?wikiVersion=GBwikiMaster\&pagePath=/configuration/configuring%20a%20beacon%20server))\ \- The group has not been measured within the configured measurement interval (default: 6 days) 3. The StifleR Service instructs the best-connected client on that network group\ (preferring 10 Gbps → 1 Gbps → 100 Mbps links) to run a measurement. 4. The client runs iPerf3 in reverse mode: the beacon sends data, the client\ measures download throughput. 5. The result is stored as a maximum bandwidth figure on the network group. ### Ad-hoc measurements Clicking **Measure now** on a network group in the dashboard triggers an immediate measurement. This bypasses the 30-minute schedule and takes priority over any queued scheduled measurements. The result appears in the Beacons table within a few seconds. *** ## Beacon Assignment When the StifleR Service looks for a beacon to use for a network group, it resolves the assignment by walking the topology in priority order and returning the first match: | Priority | Assignment type | Description | | -------- | --------------- | ------------------------------------------------ | | 1 | Network group | Beacon explicitly assigned to this network group | | 2 | Location | Beacon assigned to the parent location | | 3 | Area | Beacon assigned to the parent area | | 4 | Default | Beacon marked as the global default fallback | A beacon does **not** need to be marked Default unless it should serve network groups with no explicit assignment at any topology level. Assign beacons as close to the target groups as possible for the most representative measurements. If no beacon is found via any of these levels, the network group is silently skipped until an assignment is made. ### Client-Side Requirement The StifleR client agent must have the **Bandwidth Measurement** capability enabled in its feature set to accept and act on measurement requests from the server. This is enabled by default. *** ## What the Beacon Measures and Reports The beacon itself does not run measurements — it is a passive iPerf3 server. It does, however, count measurements by monitoring its own iPerf3 process and reports the running totals (**Measures Started** and **Measures Completed**) to the StifleR Server with each heartbeat. These counters are visible in the dashboard under **Administration → Infrastructure Services**. Measurement results are stored on the network group and visible in the **Network Groups** view, along with the date and time of the last measurement. # 2Pint BranchCache guide ## Introduction The aim of this document is to assist Administrators in understanding and implementing Microsoft BranchCache and associated technologies in order to maximize the benefits of this often overlooked Windows Service. This document focusses on Distributed Mode BranchCache over HTTP. This is the most commonly used mode of operation when BranchCache is used for Content Distribution via Microsoft ConfigMgr/WSUS etc. So what is BranchCache? Here’s a nice description from the Microsoft Protocol docs on the subject: “The goal of the Content Caching and Retrieval System is to decrease WAN network use. This is accomplished by caching content that has been retrieved over a WAN link (or any high latency link) from a content server by a set of actors (computers, applications, or people) connected to a local area network (LAN) and making it available for subsequent use within the LAN environment in a secure and effective manner. The overall effect is to reduce WAN traffic and therefore increase application performance.” In other words, it’s WAN accelerator, which caches content locally to avoid unnecessary round trips to the data source by allowing clients on the same subnet to retrieve content from peer systems. \*\*IT DOES NOT DOWNLOAD STUFF\*\* Or: “It makes your network go faster” ### BranchCache Distributed Cache Mode * Limited to a single subnet. So if, for instance you have separate subnets for wired vs wireless clients you will effectively have 2 distributed caches and content may well be copied twice to that location. * High mobility can mean that content can ‘go missing’ if a user has cached content (to a laptop for instance) and then relocates. * Initially requires two copies of content to be stored – one in the content download location and one in the BranchCache cache. (the content can be deleted and still be retrieved from the BranchCache cache) **Basic Operation** * PC1 performs a ‘Get’ Request – but downloads the Identifiers (hash) that *describe* the content. * PC1 performs a local broadcast to see if anyone else has this content. If they do, PC1 will get it locally from peers. If the content is NOT local, PC1 will go back to the server and get the content. Once downloaded, the content is then available to peers on that subnet. * PC2 performs a ‘Get’ Request – but downloads the Identifiers (hash) that *describe* the content. * PC2 performs a local broadcast to see if anyone else has this content. * PC1 has the content, so PC2 will transfer it locally from PC1. **Distributed Cache Mode Communications** {% @mermaid/diagram content="flowchart LR ``` subgraph DCM["Distributed Cache Mode"] direction LR subgraph Remote CS["Content Server/\nDistribution Point"] end subgraph Subnet["Subnet A"] PB["Peer B\nWith Content"] PA["Peer A\n3,8"] PA -->|4| PB PB -->|5| PA PA -->|6| PB PB -->|7| PA end PA -->|1| CS CS -->|2| PA PA -.->|9| CS CS -.->|10| PA end %% Styling classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px classDef server fill:#add8e6,stroke:#333,stroke-width:2px classDef peer fill:#90EE90,stroke:#333,stroke-width:2px classDef subnet fill:#f0f8ff,stroke:#333,stroke-width:2px classDef peernocache fill:#fff0f0,stroke:#333,stroke-width:2px linkStyle 6,7 stroke-width:2px,fill:none,stroke:red; linkStyle 3 stroke-width:4px,fill:none,stroke:green; class CS server class PB peer class Subnet,Remote subnet class PA peernocache" %} ``` **Request Flow** 1. TCP 443\ HTTP(S) GET request for content 2. TCP 443\ Returns content metadata + hashes 3. Checks local cache for content 4. UDP 3702 (Broadcast)\ WS-Discovery broadcast (MC): Searching for peers with content ID 5. UDP 3702 (Unicast)\ WS-Discovery response: Indicates content availability 6. TCP 1337\ Requests content segments 7. TCP 1337\ Sends encrypted content segments 8. Verifies received segments against hashes from server **Fallback**\ If no clients responds with content hashes or if hash verification fails. 9. TCP 443\ Requests Content from source 10. TCP 443\ Sends requested Content ## BranchCache Theory “Buckle up – there aren’t many screen shots.” This section can be a bit ‘dry’, but it’s worth sticking with the clever theory behind BranchCache as it helps you to understand where the heck your data went when you get to play with it. ### BranchCache Versions The first, and one of the most important items to consider and understand before you implement BranchCache is the two different versions. They behave differently, don’t necessarily play well together, and are an important factor in any BranchCache implementation. At the time of writing, BranchCache is available on Windows Server 2008 R2 / Windows 7 Clients and later \- We’ll refer to this as **Version 1 BranchCache** It’s also available on Windows Server 2012/2016 versions, and Windows 8/10/11 clients. \- We’ll refer to this as **Version 2 BranchCache** ### BranchCache ‘Content’ Explained “BranchCache Does Not Care About Files!” The BranchCache Content Server is responsible for slicing up content into chunks. It’s these chunks that are requested and downloaded by BC clients, not files. It works slightly differently (and more efficiently) in Version 2 than Version 1. #### The Hash (or Content Identifier) “No Hash = No Content!” The BranchCache Content Server generates Hashes for content that is requested by clients. This hash, or Content Identifier is then used to locate content from other peer systems. {% hint style="info" %} **Important** BranchCache Content Server will only generate the Hashes for content at the time of the request. It’s fairly fast at doing this, but on a very busy server, with many content requests per second, a ‘Hash Generation ‘queue may form. This can mean that a client system which requests content will not be able to utilize BranchCache as the hash is not available yet, and the client will simply download the content and cannot place it into the BranchCache cache or locate the content on peer systems. Hashes can be pre-generated to mitigate this, and this is explained in a later section. You don’t really need to know this but.. here’s what a BranchCache Hash consists of: **Server Secret** – Shhh. Used as a key in order to create a content-specific hash that is sent to clients. **Hash of Data (Hod)**– the juice, the magic, the stuff dreams are made of. It’s what BranchCache uses to make sense of the files it needs to download. **Segment Secret** – Used as the encryption key to generate the Segment ID (along with the HoD) **Segment ID** – Used to locate the content once the Hash is downloaded {% endhint %} #### Segments and Blocks BranchCache’s currency is Segments. You can think of a segment as a ‘*Unit of Discovery’*. That is to say, it’s what the BranchCache client asks for when it’s on the hunt for requested data once it has the Hash for that content. In V1 - within that segment there are Blocks, which are the ‘*Unit of Download’*. So these are the individual chunks of data that are downloaded once the segment is found. Chopping things up like this means that the network isn’t clogged by these 32Mb segments flying around in one lump. In V2 however it changes quite significantly. Read on. **Windows 7/WS2008R2 (Version 1.0)** *Content* is divided into *Segments,* which is further divided into *Blocks*. A Segment is a Binary string of 32Mb - and the last segment of a file can of course be less than 32Mb unless the content divides into exact 32Mb chunks. The Block Size for Version 1.0 is 64k –again the last block can be smaller for obvious reasons. The important thing to remember here is that if a file has a change at the beginning of the file, with V1.0 content, you would invalidate the entire segment because all of the block sizes are fixed and would therefore change. So a change in a file results in at least a 32Mb download (in files bigger than 32Mb of course!) **Windows 8.x/WS2012 (Version 2.0)** V2.0 does away with these fixes size blocks, because the segment ‘chunking’ algorithms used result in variable block sizes of 32-128k. So we really don’t have the same distinction of Segment and Blocks. V2.0 uses Deduplication algorithms – to determine those block sizes. So in a file change scenario with V2 and its use of variable block sizes, it’s more likely that the blocks later in the file will still be the same, and only those blocks that have changed need to be downloaded. V2 also uses the Deduplication technology introduced in WS2012/16 but this will be covered later in this document, as it’s freaking awesome. Basically duplicate blocks of data are not downloaded by V2 BranchCache which makes for massive savings across files with identical data blocks such as WIM files or Documents etc. ### The BranchCache Caches “Where’s My Cheese?” The BranchCache Cache is a database of content, and/or hashes of content. Simple. BranchCache Maintains two caches, both on the Content Server and Client. It’s important to learn to distinguish between the two. By default, these are located at: **%WINDIR%\ ServiceProfiles\NetworkService\AppData\Local** #### The Publication Cache – **\PeerDistPub** folder The is the **HashCache** – where generated hashes are stored.\* **Content Server –** the Hash Cache is populated is content requests come in to the server. **Client System –** the Hash Cache is usually empty, unless content is injected (imported). *\*If Windows Server Deduplication is enabled, the BranchCache HashCache can be empty, as BranchCache (V2) is designed to utilize the Deduplication Chunk Store.* #### The Republication Cache – \PeerDistRepub folder This is the DataCache – where content is stored (and hashes that were downloaded by the client – but mostly content) **Content Server** – Usually empty (unless the content server itself is a client), as the content server only needs to generate the Hashes of the data. The Content is already stored (as files). **Client System** - The data cache will be populated with downloaded BranchCache content. ### Security Here is a typical BranchCache operation from a security viewpoint. Server authenticates the client and performs authorization checks. Server transmits content information structure to the client only if the client has access. Transfer happens over the accelerated protocol –HTTP/S etc. Client uses content information structure to calculate: -segment id (public) -encryption key (private) Client multicasts the **segment id** to find a peer with the data. Client downloads encrypted blocks from a peer and decrypts them with the **encryption key** Cached data is stored in encrypted form in the BranchCache Cache The above is Out-Of-The-Box behaviour. No further security configuration is required. {% hint style="info" %} Note: Data in the Cache is not encrypted on Windows 7 but is on Windows 8 and above. But on even if it’s not encrypted on Windows 7 you cannot browse this info and need a high privilege account to access it. Data transferred over the wire is encrypted. Data in the Cache is not stored by file but by hash. So even if you know the name of the file you can’t get the data. In order to get to the data, you need to be admin and have the hash which is protected by the login to the IIS server. {% endhint %} ## BranchCache Configuration ### Cache Management The simple rule for cache management is that on Content Servers you need to configure the HashCache, and on Clients it’s the DataCache. So here’s what you can configure with regards to the cache. #### **Location (V1/V2)** You don’t have to accept the defaults for BranchCache cache location – you can move it to another drive for instance. #### **Size (V1/V2)** Size does of course matter in the BranchCache world. Default 5% of disk space for the Data Cache, and 1% for the Hash Cache – on both Content Servers and Clients. {% hint style="info" %} TIP: For servers , you can calculate the size of the Hash Cache that you might need. Hashes are around 1/2000th the size of the original content, so if you know the total content that the server will be providing you can set the cache size accordingly. In a mixed (V1/V2) client environment – bear in mind that you will need double the space as V1 and V2 hashes are different. {% endhint %} **Segment Age (V2 Only)** This applies to the data cache only, and specifies the default age in days for which segments are valid. The default is 28 days and you can increase this to 9999 if you so wish. **BranchCache Cache in Windows 10** Windows 10 clients can now benefit from dynamic cache resizing. This means that you can set a large Data Cache size – safe in the knowledge that the Cache will dynamically shrink if the system experiences a Low Disk Space event. Segments in the cache will be removed based on the ‘last accessed’ date, so that content that is frequently used will be left alone, while the older segments will be removed first.. #### Configuring the Cache Size V1/2 – Using Netsh.exe Specifies the size of the local cache as either a percentage of the size of the hard disk where the cache is located or as an exact number of bytes. Syntax: For the DataCache: ``` Netsh.exe br set cachesize [ size= ]{ DEFAULT | Number } [[percent= ]{ TRUE | FALSE } ] Netsh br set cachesize 123456 (sets the size in bytes) Netsh br set cachesize size=20 percent=TRUE (sets the size in % of disk) ``` For the HashCache: ``` Netsh.exe br set publicationcachesize [ size= ]{ DEFAULT | Number } [[percent= ]{ TRUE | FALSE } ] Netsh br set publicationcachesize 123456 (sets the size in bytes) Netsh br set publicationcachesize size=20 percent=TRUE (sets the size in % of disk) ``` V2 – Using PowerShell Use Get-BCStatus to see the current Cache locations and sizes: ![](/files/7qgMtfABLhLTFdj5cPF8) To configure the HashCache with PowerShell, you need to get the WMI instance, and feed it to the set-bccache cmdlet. See below: ``` Get-CimInstance -ClassName MSFT_NetBranchCacheHashCache -Namespace root\standardcimv2| set-bccache -Percentage 10 ``` To do the same for the DataCache: ``` Get-CimInstance -ClassName MSFT_NetBranchCacheDataCache -Namespace root\standardcimv2| set-bccache -Percentage 50 ``` #### Changing the Cache Locations In some cases you may want to change those default Cache locations – easy peasy: V1/2 Remember that the default location is - **%WINDIR%\ServiceProfiles\NetworkService\AppData\Local\PeerDistRepub** ``` Netsh.exe br set localcache DEFAULT – Sets the DataCache back the the above default Netsh.exe br set localcache directory=C:\BranchCache\DataCache – Sets the DataCache to an alternate location ``` And the HashCache? Remember that the default location is - **%WINDIR%\ServiceProfiles\NetworkService\AppData\Local\PeerDistpub** ``` Netsh.exe br set publicationcache DEFAULT – Sets the HashCache back the the above default Netsh.exe br set publicationcache directory=C:\BranchCache\HashCache – Sets the DataCache to an alternate location ``` V2 In PowerShell it’s a case of supplying the old and new cache locations To change the DataCache location: ``` set-bccache -Path "$ENV:WINDIR\ServiceProfiles\NetworkService\AppData\Local\PeerDistRepub" -MoveTo "C:\DataCache" ``` To change the HashCache location: ``` set-bccache -Path "$ENV:WINDIR\ServiceProfiles\NetworkService\AppData\Local\PeerDistPub" -MoveTo "C:\hashcache" ``` #### Setting the DataCache Segment Age Only available in V2 – in V1 it is set to a default of 28 days. This applies to the data cache only, and specifies the default age in days for which segments are valid. The default is 28 days and you can increase this to 9999 if you so wish. PowerShell – pretty simple ``` Set-BCDataCacheEntryMaxAge –TimeDays 100 ``` ### Pre-Generating Hashes V2 Only (2Pint Software Free Tools can be used for V1) To ensure that BranchCache Hashes are always available to clients (remember, No Hash = No Data), you can use the BranchCache PowerShell cmdlets to pre-generate hashes on the BranchCache Content Server. {% hint style="info" %} Note: If using Data Deduplication in Windows Server 2012/16, the Deduplication service will create the hashes for you. So this configuration will not be required. {% endhint %} To generate hashes on a content server, in this case a Microsoft Configuration Manager Distribution Point: ``` Publish-BCWebContent –Path D:\ SCCMContentLib -Recurse ``` The -Recurse switch forces hash generation for content within folders and subfolders under the root folder in the command. {% hint style="info" %} *Tip: If you are frequently adding content you may want to run this command daily as a scheduled task.* {% endhint %} ### Optimizing BranchCache in a Mixed Client Environment Sometimes you may have V1 and V2 clients within the same subnets. This can be complicated but the rules are as follows. If you do nothing, the worst that can happen is that you will have two downloads of the same content per subnet. One will be shared by V1 clients and one by V2 clients. V1 and V2 clients cannot ‘peer’, because the BranchCache Hash and Databases are different V2 Clients Can however, download V1 hashes. This is called ‘downgrading’ and means that you will only need one download per subnet but you will not be able to take advantage of Deduplication. #### Enabling BranchCache Version Support Using Policy Set the ‘Configure Client BranchCache Version Support’ policy for clients of Windows 8 and above. Set it to ‘Windows Vista with BITS 4.0 installed, Windows 7, or Windows Server 2008 R2.’ The Windows 8/10 clients will then only download V1 hashes. Using PowerShell Enable-BCDowngrading This will set the client into V1 mode. Disable-BCDowngrading Will reset things back to V2 ### Enable BranchCache on Client Systems To enable BranchCache to function on a Windows System, the following items must be configured. The BranchCache Service must be configured for the correct mode (Distributed Mode for the purposes of this document) The Windows Firewall must be configured to allow BranchCache Peer Content Retrieval and Discovery. There are quite a few ways to enable BranchCache in Distributed Mode on clients systems. The most common are described below. #### Using Microsoft Configuration Manager Client Settings From Configuration Manager you can configure some BranchCache settings from within the Client Settings node in the Configuration Manager Console. This configures local policy, and enables BranchCache in distributed mode. You can also configure the data cache size this way, but not the Segment Age setting.
#### Using Group Policy In the Group Policy Management Editor console, expand the following path: Computer Configuration > Policies > Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer, Network, BranchCache. Click BranchCache, and then in the details pane, double-click Turn on BranchCache. The policy setting dialog box opens. In the Turn on BranchCache dialog box, click Enabled, and then click OK. To enable BranchCache distributed cache mode, in the details pane, double-click Set BranchCache Distributed Cache mode. The policy setting dialog box opens. In the Set BranchCache Distributed Cache mode dialog box, click Enabled, and then click OK. ![](/files/QmqT2zQXBxfr0icOtrtP) This method alone does not configure the Windows Firewall for BranchCAche however and this must be performed seperately. #### Configure Windows Firewall with Advanced Security Inbound Traffic Rules In the Group Policy Management console, right-click the BranchCache client computers GPO that you created previously. Click Edit. The Group Policy Management Editor console opens. In the Group Policy Management Editor console, expand the following path: Computer Configuration > Policies > Windows Settings > Security Settings, Windows Firewall with Advanced Security, Windows Firewall with Advanced Security – LDAP…, Inbound Rules. Right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Content Retrieval (Uses HTTP). Click Next. In Predefined Rules, click Next. In Action, ensure that Allow the connection is selected, and then click Finish. **Important** You must select Allow the connection for the BranchCache client to be able to receive traffic on this port. To create the WS-Discovery firewall exception, again right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Peer Discovery (Uses WSD). Click Next. In Predefined Rules, click Next. In Action, ensure that Allow the connection is selected, and then click Finish. **Important** You must select Allow the connection for the BranchCache client to be able to receive traffic on this port. Repeat the above steps for Outbound rules, i.e allowing the following. ![](/files/DlgQGO4lXCDR0R4g9jfo) #### Using Netsh.exe The below command will set the BranchCache service to distributed mode and also configure the Windows Firewall in one go: ``` Netsh.exe br set service MODE=Distributed ``` #### Using PowerShell The following PowerShell command will set the client to use BranchCache in distributed mode. This will also configure the BranchCache service in distributed mode and also configure the Windows Firewall. ``` Enable-BCDistributed ``` ### Configure BranchCache in Configuration Manager Setting up BranchCache with ConfigMgr is relatively easy. BranchCache can be enabled for all deployment types withing ConfigMgr, and will work seamlessly providing that the Distribution Points are all ’BranchCache Enabled’, and Deployments are BranchCache enabled at creation time. #### Enable BranchCache on ConfigMgr Distribution Points To enable and configure BranchCache on a Distribution Point, it’s a simple as checking the following box on the Distribution Point properties. ![](/files/2p1szugbY3aOsnbT10iv) #### Enable BranchCache for Deployments All BranchCache enabled deployments should be configured to ’download content from distribution point and run locally.’ Additionally: Software Update Deployments: Download Settings Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’ Package Deployments: Distribution Points Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’ Application Deployments: Content Tab on the Deployment Type – complete the checkbox ’Allow clients to share content with other clients on the same subnet’ Task Sequences (Current Branch Only): Distribution Points Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’ ### Testing Downloads via BITS and BranchCache This section applies to ConfigMgr but works equally well without. Just use a different content source for testing. Create and distribute a Package containing some files (small and large to test all scenarios). Then you need to get the Package ID – which looks like XYZ12345.6 (XYZ being the sitecode, and it will only have the .x version stamp if it’s been updated at some point), and a file within the package which you will use as the source for the download. Once you have that, just create your URL and put it into the PowerShell below. Once you execute the script – it will prompt you for credentials, so use a relevant domain account with sufficient rights to download the content.. Then – all being well, BITS will connect to the DP, and download the content. Import-Module BitsTransfer \# URL to file on DP $source = " SMS\_DP\_SMSPKG$/CEN00000.0/filename.exe " \# Local file path here $dest = "C:\Temp" $Job = Start-BitsTransfer *-DisplayName* '2Pint Job' -Authentication Negotiate *-Credential* domain.local\administrator -Source $source \` *-Destination* $dest -TransferType Download -Priority Normal -Asynchronous -RetryInterval 60 while (($Job.JobState -eq "Transferring") -or ($Job.JobState -eq "Connecting") -or ($Job.JobState -eq "TransientError") -or ($Job.JobState -eq "Suspended") ) \` { **sleep** 5;} # Poll for status, sleep for 5 seconds, or perform an action. Switch($Job.JobState) { "Transferred" {Complete-BitsTransfer -BitsJob $Job} "Error" {$Job | **Format-List** } # List the errors. default {$Job | **Format-List** } # Perform corrective action. } Checking the results **On the DP server** – Check the BranchCache Kernel mode perfmon counters for: BranchCache aware HTTP requests Total Hash generations Accepted (if it’s a new file and no other clients have requested it yet) Total Hash Retrievals Accepted The above counters will tell you if BranchCache is functioning, and that your http requests are making it through Note: If are you using De-Duplication on the volume that stores the packages on the DP, you won’t see any Hash creation stats in perfmon because it is likely using the Deduplication chunk store hashes. **On the Client** Check the BITS Event Log – Applications And Services – Microsoft – Windows – BITS-Client-Operational Event 3 – BITS Job is created Event 59 Your file gets added to the BITS job Event 60 – File is copied – you can check to see if the peerProtocalFlags is set (it should be 1 if you are BranchCaching) Event 4 – Job done, and you can see how much was copied from the DP vs Peers ### BITS Optimization and Bandwidth Throttling Although this document describes BranchCache operations, in most Content Distribution scenarios, the Background Intelligent Transfer Service BITS) performs the actual download. BITS is heavily integrated with BranchCache, and can be optimised for BranchCache enabled downloads. BITS Policy there are 2 Group Policies that provide fairly granular control of BITS bandwidth usage during working / non-working days/hours and during scheduled maintenance days/hours. These are the only BITS policies that you should consider using, as they are the most recent and efficient available. TIP:Do NOT use the ConfigMgr Client Setting BITS policy as it is old and not configured for optimal BranchCache downloads. The 2 GPOs can be found under Computer Configuration -> Administrative Templates -> Network -> Background Intelligent Transfer Service 1 Set up a maintenance schedule to limit the maximum network bandwidth used for BITS background transfers 2 Set up a work schedule to limit the maximum network bandwidth used for BITS background transfers #### The Work Schedule This is the general day to day BITSPolicy setting used throughout your network. This policy setting limits the network bandwidth that Background Intelligent Transfer Service (BITS) uses for background transfers during the work and non-work days and hours. The work schedule is defined using a weekly calendar, which consists of days of the week and hours of the day. All hours and days that are not defined in a work schedule are considered non-work hours. If you enable this policy setting, you can set up a schedule for limiting network bandwidth during both work and non-work hours. After the work schedule is defined, you can set the bandwidth usage limits for each of the three BITS background priority levels: high, normal, and low. You can specify a limit to use for background jobs during a work schedule. For example, you can limit the network bandwidth of low priority jobs to 128 Kbps from 8:00 A.M. to 5:00 P.M. on Monday through Friday, and then set the limit to 512 Kbps for non-work hours. If you disable or do not configure this policy setting, BITS uses all available unused bandwidth for background job transfers. ![](/files/ktzD0j2smA0KflhhYSLq) The Work Schedule is shown above. Of particular note, is the checkbox at the top left of the ’Options’ pane, entitled ’Ignore bandwidth limits if the source and destination are on the same subnet’. This box must be checked as it allows BranchCache-enabled BITS transfers between Peers on the same subnet to transfer at higher speed (up to 60Mb/s). If this is not checked, Peer-to-peer transfers will only happen at the current throttled speed. #### The Maintenance Schedule This policy setting limits the network bandwidth that Background Intelligent Transfer Service (BITS) uses for background transfers during the maintenance days and hours. Maintenance schedules further limit the network bandwidth that is used for background transfers. This means that it overrides the work schedule and these values take presence. If you enable this policy setting, you can define a separate set of network bandwidth limits and set up a schedule for the maintenance period. You can specify a limit to use for background jobs during a maintenance schedule. For example, if normal priority jobs are currently limited to 256 Kbps on a work schedule, you can further limit the network bandwidth of normal priority jobs to 20 Kbps from 8:00 A.M. to 10:00 A.M. on a maintenance schedule. If you disable or do not configure this policy setting, the limits defined for work or non-work schedules will be used. The bandwidth limits that are set for the maintenance period supersede any limits defined for work and other schedules. ![](/files/bgQ8Nx8C1rQH06Vqzaja) #### BITS and BranchCache FlashCrowd Events A Flashcrowd event occurs when BITS/BranchCache are clever enough to detect that it’s downloading a segment that has been requested by many other clients. BranchCache generates a message to the BITS service – to the effect that you will see a burst (usually 15) of Events in the BITS event log with an ID of 208. This tells the BITS client to wait’, because someone is downloading the content that is being requested and it may be available soon. The net result of this is that even if you have a ConfigMgr deployment where all of the clients execute the content download at the same time, all is not lost. Tweaks You can also configure BITS Flash-Crowd behavior via the registry so that those back-off intervals can be increased – which you may want to tweak if your clients are on the end of a particularly slow WAN link. There are 3 entries that count are here: HKEY\_LOCAL\_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\ MaximumBackgroundCacheRetries HKEY\_LOCAL\_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\ MaximumForegroundCacheRetries These values determine the number of retries depending on whether the BITS job in question is a FOREGROUND or BACKGROUND priority job. HKEY\_LOCAL\_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\CacheRetryIntervalMsec This next value determines the interval between the retries, so in reality you may want to just edit this, which will increase the overall back-off period. By default, this is set to 1000 (1 second) So you can double the back-off just by changing this to 2000 #### Other BITS Tips 1. When using a speed over 2048 Kbit/s set the policy to use Mb instead of Kb. It just works better. 2. If you are on Windows 7, always apply Fixes an issue where BITS can ignore Policy and goes as fast as it can. 3. BITS stops doing BranchCache if it didn’t get the hash data the first 3 attempts. This is hardcoded. 4. Always use a BITS policy for BranchCache downloads! It just works better.. ### BranchCache and Windows Server Data Deduplication One of the most advance features of BranchCache with V2 was the integration with Data Deduplication in Windows Server 2012/16. With this new innovation, BranchCache can perform deduplication on an actual transfer and on its own Cache storage. In addition, BranchCache will use the Deduplication chunk store for hash retrieval, which saves on processing time and resource. #### What is Data Deduplication? Deduplication is used to improve storage utilization and can also be applied to network data transfers to reduce the number of bytes that must be sent across the wire. In the deduplication process, unique chunks of data, or byte patterns, are identified and stored during a process of analysis. As the analysis continues, other chunks are compared to the stored copy and whenever a match occurs, the redundant chunk is replaced with a small reference that points to the stored chunk. Given that the same byte pattern may occur dozens, hundreds, or even thousands of times (the match frequency is dependent on the chunk size), the amount of data that must be stored or transferred can be greatly reduced. #### Deduplication Evaluation To aid in the evaluation of datasets Microsoft created a portable evaluation tool. When the Deduplication feature is installed, DDPEval.exe is installed to the \Windows\System32\ directory. This tool can be copied and run on Windows 7 or later systems to determine the expected savings that you would get if deduplication was enabled on a particular volume. DDPEval.exe can be run on a Content Server and the output will tell you of the potential savings. Certain types of data are particularly suited to deduplication as there are many common data block within the structure. Examples are .WIM files, Word Documents, Driver Libraries etc. #### Deduplication Configuration **Configure and run DeDuplication on a ConfigMgr Distribution Point** Because BranchCache uses the DeDupe chunk store to get hashes we need to ensure that when Deduplication runs, it is considering all files. You can do this by running the following PowerShell. We don’t want to DeDupe ALL of the folders however. ConfigMgr doesn’t like you to DeDup the Content Source folders (not supported), all we really want to hit is the Content Library itself (the \SCCMContentLib folder at the root of the drive), and we can do this by excluding the other ConfigMgr folders that we don’t want, namely the *SMSPKG,SMSPKGSIG and SMSSIG$ folders* ``` $dedupVolume = "E:" #(set the drive letter here) Set-DedupVolume -Volume $dedupVolume -MinimumFileAgeDays 0 –ExcludeFolder $dedupVolume\SMSPKG, $dedupVolume\SMSPKGSIG, $dedupVolume\SMSSIG$ Write-Output "Starting Dedup Jobs..." $j = Start-DedupJob -Type Optimization -Volume $dedupVolume $j = Start-DedupJob -Type GarbageCollection -Volume $dedupVolume $j = Start-DedupJob -Type Scrubbing -Volume $dedupVolume do { Write-Output "Them Dedup jobs is running. Status:" $state = Get-DedupJob | Sort-Object StartTime -Descending $state | ft if ($state -eq $null) {Write-Output "Completing, please wait..."} sleep -s 5 } while ($state -ne $null) #cls Write-Output "Done DeDuping" Get-DedupStatus | fl * ``` So the above snippet with configure DeDupe to include all files, except those in folders that we excluded. It the runs the necessary Deduplication jobs on the volume and places the hashes in the chunk store ready for BranchCache clients to access. ### Reporting on BranchCache Success Although BranchCache works well in reducing WAN traffic it’s often difficult to tell when it is or isn’t working. Here are some methods of measuring BITS and/or BranchCache performance. #### Event Log The BITS Event Log provides information as to where the BITS download data originated from. Event 4 – on completion of a download will provide this info. #### BranchCache Performance Counters One way to check if BranchCache is being used is to monitor the BranchCache performance counters, these three counters in particular: *Retrieval: Bytes from cache*—This shows how much data is being obtained via BranchCache instead of directly from the source server. *Retrieval: Bytes from server*—This shows how much is being obtained directly from the source server, not from BranchCache. *Retrieval: Bytes served*—This shows how data from the local machine's BranchCache has been sent to other BranchCache clients. This saves other clients from obtaining the data from the original source. {% hint style="info" %} TIP: In Testing, you can reset the BranchCache perfmon counters using the following PowerShell cmdlet: **Reset-BC -ResetPerfCountersOnly** There is a full list of the counters with descriptions here: {% endhint %} #### 2Pint Reporter Toolset This can give you a more graphical representation of a download in real-time. (shown n below) You can download this free tool from ![C:\Users\administrator\Pictures\bits\_bc\_anatomy.png](/files/eXSYP3VelWRszSCNeUsC) ### Summary That’s all for now, hope it was useful. This is very much a work in progress and we plan to add further docs around BranchCache as and when we get the time. Any ideas on what you would like to see next? Ping us over at: ### Appendix A BranchCache Netsh.exe commands: BranchCache PowerShell Cmdlets: MSDN Peer Distribution APIs: # StifleR WMI provider Windows Management Instrumentation (WMI) is a Command and Control (C\&C) infrastructure that is integrated within Windows. It provides three primary capabilities: * Exposing state information regarding a configurable entity * Invoking control methods on a configurable entity * Publishing events from a configurable entity These facilities are a complete instrumentation solution for any Windows application, and multiple system components expose information through the use of WMI providers. This information can be consumed from a multitude of languages and technologies by WMI consumers, using a standard query language (WQL). The StifleR server interface for automation is a WMI Provider In practical terms this means the administrator uses a WMI interface to communicate and control the StifleR server component. The primary advantage to using WMI in favour of other communication technologies that abound is that WMI is a standardized C\&C mechanism which can be consumed by numerous existing C\&C frameworks. Most Windows components expose C\&C information using WMI, and it is preferable that a single C\&C framework is used instead of reinventing a C\&C framework for each individual component. This makes a single C\&C tool suitable for a variety of configurable and controllable entities. Most automation of StifleR is done through the StifleR WMI Provider. This is present under the [\\\\](file:///\\\ROOT\StifleR)[ROOT](file:///\\\ROOT\StifleR)[\\](file:///\\\ROOT\StifleR)[StifleR](file:///\\\ROOT\StifleR) WMI namespace on the StifleR server itself.
### Updating Values StifleR is a multithreaded asynchronous service, which means that the changes done through WMI cannot be guaranteed. A change might return the original value and not the changed value, so keep this in mind when scripting against StifleR. If the returned value does not match the value that you are attempting to write it has not been successful and will have to be retried. After creating or making configuration changes, you should check to ensure that the value you to set has been changed to what is actually running. Some values are checked as part of the function to ensure that the change was successful and will return a failure if not. But some simple value changes have to be verified, as the underlying code runs asynchronously and on multiple threads in order to maximize performance. The reason StifleR has been designed to work this way is because the internal workings are running on multiple threads asynchronously which may or may not have write access to the internal data structures at any given time. Rather than waiting for a lock to be lifted, using precious resources, the data is flushed to free resources. This allows StifleR to support an extreme large number of simultaneous connections. For example, if you are trying to set the TargetBandwidth for a Location, make sure that there is a check for the running value after the Set command and make sure that the value has in fact been updated. ### Listing Method and Instance Parameters ``` Using WMI with the CALL and GET /? parameters will give the following outputs: C:\>wmic /namespace:\\root\stifler path StifleREngine CALL /? Method execution operations. USAGE: CALL [] NOTE: ::= | , The following verb(s)/method(s) are available: ``` | `Call` | `[ In/Out ]Params&type` | `Status` | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------- | | `GetErrorDescription` |

\[IN ]errorcode(uint32)

\[OUT]ReturnValue(string)

| `Implemented` | | `GetErrorDescriptionFromString` |

\[IN ]hexcode(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `ModifyJobs` |

\[IN ]action(string)

\[IN ]force(boolean)

\[IN ]jobName(string)

\[IN ]StifleRTypeName(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `Notify` |

\[IN ]messageLine1(string)

\[IN ]messageLine2(string)

\[IN ]messageLine3(string)

\[IN ]picturePath(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `RunCmdLine` |

\[IN ]arguments(string)

\[IN ]fileName(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `RunPowerShellScript` |

\[IN ]script(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `TestFunction` | `[OUT]ReturnValue(string)` | `Implemented` | | `UpdateRules` |

\[IN ]fileUrl(string)

\[IN ]Target(string)

\[IN ]useBits(boolean)

\[OUT]ReturnValue(string)

| `Implemented` | | `UpdateServerList` |

\[IN ]reconnect(boolean)

\[IN ]ServerList(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `WOL` |

\[IN ]MAC(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | ``` C:\Windows\system32>wmic /namespace:\root\stifler path StifleREngine GET /? Property get operations. USAGE: GET [] [] NOTE: ::= | , The following properties are available: ``` | `Property` | `Type` | `Operation` | | -------------------------- | ----------------- | ----------- | | `ActiveBlueLeaders` | `sint32` | `Read` | | `ActiveNetworks` | `sint32` | `Read` | | `ActiveRedLeaders` | `sint32` | `Read` | | `ClientInfoCompleted` | `sint64` | `Read` | | `ClientInfoInitiated` | `sint64` | `Read` | | `Clients` | `sint32` | `Read` | | `Company` | `string` | `Read` | | `ConnectedUser` | `string` | `Read` | | `Contact` | `string` | | | `DataEngineThreadState` | `string` | `Read` | | `ExpiryDate` | `datetime` | `Read` | | `HubConnectionCompleted` | `sint64` | `Read` | | `HubConnectionInitiated` | `sint64` | `Read` | | `Id` | `sint32` | `Read` | | `JobReporDeltatInitiated` | `sint64` | `Read` | | `JobReportCompleted` | `sint64` | `Read` | | `JobReportDeltaCompleted` | `sint64` | `Read` | | `JobReportInitiated` | `sint64` | `Read` | | `LicensedVersion` | `string` | `Read` | | `Licensee` | `string` | `Read` | | `ListAccess` | `array of string` | `Read` | | `Nodes` | `uint64` | `Read` | | `NumberOfClients` | `sint32` | `Read` | | `RedLeaderRunInfo` | `string` | `Read` | | `RedLeaderSelectionThread` | `string` | `Read` | | `Type` | `string` | `Read` | | `ValidFor` | `string` | `Read` | | `Version` | `string` | `Read` | Some properties will be listed as Operation “Write” which means you can use the SET verb to write to them. To find all items that allows Write, replace GET /? with SET /?. An example how to use the SET operator `wmic /namespace:\\root\stifler path Subnets.SubnetID="192.168.90.44" SET Description=Test` ### Further Reading There used to be a large section in this document devoted to WMI with screen shots and tables explaining each setting in detail. The good news is that this information still exists on the 2Pint Support KB site which you can view if you search for ”StifleR WMIC Command Line Tool” # Backup and recovery This document guides you through a backup and recovery of a StifleR Server. ## Backup Operations StifleR have several components that needs to be backed up in order to do a successful recovery if something happens to the server. The components are: * StifleR Databases * StifleR Configuration File * StifleR License File * StifleR Rules File * Extra scripts ### StifleR Databases Backup of the five StifleR databases can be done either online or offline. The benefit of the online method is that you don’t have to stop the StifleR Server service during backup, but the downside is that it forces you to run a repair job of the database before they can be used in a restore. The offline backup method means stopping the StifleR service during backup, and then start it again after backup has completed. Benefits with this method is that you don’t have to repair the database before a restore. The StifleR databases are using the Extensible Storage Engine (ESE) runtime in Windows (ESENT), and as such are often called ESENT databases. In addition to the core database files, the EDB files, ESE is also using recovery logs which are in the same folder as each database file. By default, the databases are stored in C:\ProgramData\2Pint Software\StifleR\Server\Databases , and while the StifleR databases are not very big, we recommend storing them on data volume rather than the OS volume. ![The five database files in their default location.](/files/-ME0WIJWJzISZjBZHSYH) ![A database file and its recovery log files.](/files/-ME0WIJX8T7cGPzkp20v) {% hint style="info" %} Note: The StifleR databases can be migrated to another drive using [this process](/stifler/guides/backup-and-recovery/moving-the-stifler-server-databases-to-a-new-drive-on-the-same-server). {% endhint %} ### StifleR Configuration File The StifleR Configuration File (StifleR.Service.exe.config) is located in the StifleR Server installation directory. ### StifleR Rules File The StifleR Rules File is often added to the C:\ProgramData\2Pint Software\StifleR\Rules folder, but can be in any folder as long as the IIS virtual directory knows where it is. ### Extra Scripts Additional custom scripts, like maintenance scripts, utility scripts, and generate location scripts should also be included in the daily backup. ## Backup Maintenance Task We recommend that you automate the StifleR backup by scheduling our backup script to run at least once per day. In the [2Pint GitHub repository](https://github.com/2pintsoftware/StifleRScripting/tree/master/Maintenance), we provide a sample script that can be run in either online or offline mode, and if you select the offline mode, the script takes care of stopping and starting the StifleR Server service before and after the backup. The sample scripts also have sections for backing up additional files, like the rules file, that may be stored outside the normal StifleR installation directories. If that’s the case, simply modify the script to reflect your environment. ## Backup Archiving In addition to daily snapshots of the StifleR VM, or traditional daily file-level backup via your regular backup software, we recommend archiving at least a week worth of backup sets on a different server. The StifleR backups sets are quite small, rarely over 10 GB even in larger environments. ## Client Behavior during Backup and Recovery If the client cannot connect to server, due to networking roaming or other issues, the client will try to connect to the next server in the list. Failing to connect to a valid server eventually causes the client go into a disconnected state during which the bandwidth configure for disconnected mode will be applied. Once the StifleR Server has been restored, clients will automatically check in again, and go back to normal operations. ## Recovery Operations Restoring a StifleR Server is straight forward. If you have been using the offline backup, the restore process is a follow: 1. Make sure to install a new VM with the same server name, disk layout, and OS version 2. Install the version of StifleR you had before. 3. Stop the StifleR service, delete the empty databases, and restore the ones you have in your backup. 4. Restore the Configuration File 5. Restore the Rules file, and recreate the IIS virtual directory 6. Restore any additional scripts, and re-create scheduled tasks etc. 7. Start the StifleR service For an online backup the process is quite similar 1. Make sure to install a new VM with the same server name, disk layout, and OS version 2. Install the version of StifleR you had before. 3. Stop the StifleR service, delete the empty databases, and restore the ones you have in your backup. 4. Repair the StifleR databases using esentutl /p 5. Restore the Configuration File 6. Restore the Rules file, and recreate the IIS virtual directory 7. Restore any additional scripts, and re-create scheduled tasks etc. 8. Start the StifleR service # Moving the StifleR Server Databases to a New Drive on the Same Server ## Summary The 2Pint StifleR Server, by default, stores its databases in the %ProgramData% folder which is typically located on the C: drive. In some cases, an admin might want to move the databases to another drive. The steps below describes the process of migrating the StifleR databases to another folder on the same server. ## Procedure 1. On the server hosting the StifleR server, create a new folder where you would like to store the databases. In this example, the folder will be **D:\StifleRDBs**. 2. **Stop** the "2Pint Software StifleR Server" service. 3. Copy the folder structure from **C:\ProgramData\2Pint Software\StifleR\Server\Databases** to the folder created in step 1, Ex: **D:\StifleRDBs**. 4. To modify the configuration, you will need to edit the **StifleR.Service.exe.config** and **appSettings-override.xml** files. It is recommended to make a backup copy of the file before proceeding. The file is located in the installation directory in which StifleR was installed. 5. Open a text editor as administrator and edit the **StifleR.Service.exe.config** file. 6. In the StifleR.Service.exe.config file, under the **\** line, add the following: ``` ``` 7. **Save** the StifleR.Service.exe.config file then **start** the "2Pint Software StifleR Server" service. 8. Check the **Event Viewer** - **Applications and Services Logs** - **TwoPintSoftware** - **StrifleR.Service** - **Operational** and check for errors. ## Verification 1. Open the StifleR Dashboard and verify that you can logon and verify that the data is available as expected, specifically your Networks. 2. If all looks well, feel free to delete the **Databases** folder under: C:\ProgramData\2Pint Software\StifleR\Server. If not, see the next section to Backout of the change. ## Backout 1. If an error occurred and you need to restore the previous configuration. Stop the **2Pint Software StifleR Server** service. 2. Restore the backup copy of the **StifleR.Service.exe.config** and start the **2Pint Software StifleR Server** service. # Maintenance tasks The StifleR Server(s) needs regular maintenance like any other critical infrastructure to function effectively and continuously. In this section you find an operations guide that the sysadmin or operations team can follow to maintain a StifleR Environment. The guide is divided in to daily, weekly, monthly, and quarterly operation tasks. In general the tasks described in these documents should be implemented into whatever ticketing system that is being used, such as Service Now, Remedy or Zendesk. ## Daily Maintenance Tasks 1. Verify that the nightly backup was successful 2. Check free disk space on all volumes on the StifleR Server (s) 3. Review the StifleR Server Event log 4. Review the StifleR Resource Manager log (if implemented) ## Weekly Maintenance Tasks 1. Review all daily tasks 2. Review and disk space usage on the StifleR Server(s), and compare to previous week to see trends etc. 3. Verify that networks haven’t changed (boundaries etc.) ## Monthly Maintenance Tasks To be added, but these are for preparing for upgrades, and to establish long term trends. Usually scheduled meetings with workplace managers and other team members. ## Quarterly to semi-annual Maintenance Tasks 1. Review the security plan for any needed changes 2. Change accounts and passwords if necessary according to your security plan 3. Review the maintenance schedule for upgrades to the StifleR platform 4. Check StifleR performance to ensure changes have not been made that affect operations 5. Review the disaster recovery plan for any needed changes 6. Perform a site recovery according to the disaster recovery plan in a test lab # Troubleshooting #### Debug Logging Levels For both Client and Server, Debug Logging has 6 levels 1 = Errors Only 2 = Warning 3 = OK 4 = Informative 5 = Debug This is set via the Configuration value: `` {% hint style="warning" %} WARNING – Debug Logging should not be enabled on a production server for anything other than troubleshooting purposes and should only ever be run for a maximum of about 5 minutes at a time before disabling (0) {% endhint %} #### StifleR Server 1. Logs – there are many! 1. Enable at installation using DEBUGLOG=n .msi switch (n Debug levels 1-6 available) 2. Enable after installation by editing the **StifleR.Service.exe.config** file – `` (n Debug levels 1-5 available). Service restart not required 2. StifleR Service events are logged in the Windows Event Log at Event Viewer > Applications and Services Logs > StifleR 3. Verbose logging can be viewed (for a short time only!) through a command window by running the executable directly in Interactive Mode. You must stop the Service first! **TIP** – If you have an installation that does not complete or a service that refuses to start. Fire up the executable in interactive mode and check any error messages that appear. 4. WMI See this guide and the 2Pint KB 5. Dashboards – Lots of information in the Dashboards to help with troubleshooting. The Performance Dashboard in particular gives you some at a glance Server health information 6. Power Shell troubleshooting script (contact 2Pint Support for the latest) #### Dashboards and Access Check You can test access to StifleR using the following URLs – http(s)://FQDN.OF.STIFLER.SERVER:9000/api/test Which will list the group membership and access rights of the current user http(s)://FQDN.OF.STIFLER.SERVER /stiflerdashboard/ce.png Which, if working correctly, will show the .png 2Pint Software Logo image from the dashboard folder. #### StifleR Client 1. Client.log 1. Enable at installation using DEBUGLOG=n .msi switch (n Debug levels 1-6 available) 2. Enable after installation by editing the StifleR.ClientApp.exe.config file – `` (n Debug levels 1-5 available) Service restart not required 2. StifleR Service events are logged in the Windows Event Log at Event Viewer > Applications and Services Logs > StifleR #### BITS Command Line tool >BITSADMIN {% hint style="info" %} NOTE: This is something you should be familiar with if you are testing with BITS technologies associated with 2Pint tech. {% endhint %} #### BranchCache etc 1. CMD Line >netsh br show status all – will get you started 2. Microsoft P2P Reporting – see 2Pint KB for how to enable this feature on your test servers 3. 2Pint Reporting Tools – particularly the BITSBCReporter Command Line Tool 4. PowerShell 5. Windows Performance Monitor 6. 2Pint Software Web site – all manner of tips and tricks # StifleR client command line options This page covers what command line options can be sent to the StifleR client. The StifleR Client executable accepts various command line arguments which can be used for troubleshooting and configuration. When executing most command lines, the /Service switch should be used. /? - Check the manual for command line options. /Service - Simulates running as a service, should always be used otherwise clients exits. /Locale - Displays OS installed language info /IETW - ETWInstaller.InstallETWManifests /UETW - ETWInstaller.UninstallETWManifest /Set - Sets values in config file as in Key=value format /RemoveFilterDriver - removes the StifleRS.sys filter drivers /ResetPolicy removes the BITS & DO Maintenance Policy /Task - Do not run as a service but as triggered from events, client will exit /jobid: - Command line execution for BITS service, used with /Task /LogEventLevel - 0-5 /Log - specifies which log to display * Bandwidth * BITSBranchCache * DeliveryOptimization * Location * MainLoop * Program * SignalR * TypeDetection /Debug - Waiting for debugger - for development purposes only. # BranchCache across subnets ## Overview To support BranchCache across subnets, StifleR uses the [Blue Leader](/stifler/operations-and-features/features-overview/client-leader-roles/enterprise-environment-blue-leader) feature that is enabled by default when connecting multiple subnets together to form a location. Here are some troubleshooting tips. {% hint style="info" %} **Note:** For the Blue Leader threads to start, you need to have at least 2 subnets linked in a location, and you need to have at least two active clients on each subnet. Until these requirements are met, there is no visibility in the Blue Leader logs. {% endhint %} ## Blue Leader Troubleshooting Checklist 1. Make sure the Blue Leader firewall ports are opened. If you are using TCP 1337 for BranchCache, the Blue Leader port will be TCP 1338. You also need UDP 3703-3705 open in addition to the default UDP 3702 port for BranchCache 2. Make sure the subnets are configured for Low Bandwidth, and linked together via the Location feature in StifleR. 3. Make sure there are at least two active clients on each subnet. 4. For BranchCache OSD support across subnets, the WinPE Firewall must be disabled after the BCEnabler action has run. In your task sequence, add a run command line step that runs the command: **wpeutil disablefirewall**\ For more information about how to implement BranchCache in OSD, check out the [2Pint OSD Toolkit](https://osd.docs.2pintsoftware.com/). ## Intra-VLAN Transfer Logs and flow The same flow can go bi-directional at any given time, i.e. the diagram below show traffic that is requested in Subnet A from Subnet B, but at the same time Subnet B can be requesting the same (or other traffic from Subnet A). ![](/files/-MAX9ww3nOiw8aC9Hij-) ### Verification methods Verify that the clients are working, on the blue leaders, verify that the ports have been bound OK by running the following command: ``` Netstat -aon | findstr / ":3703" ``` That should return a line with the PID as the last entry. Then that PID entry can be used to verify the rest of the ports: ![](/files/-MAWu2rO_pYxCljggH47) The value of 8824 indicates the PID in this example, so we can use that query all the ports used with the following, similar command: ![](/files/-MAWu2rP8wcAZHgVotwA) You can also query the other ports as per the first way: ![](/files/-MAWu2rQpiW261DhhvxH) Then we want to make sure that the port used to proxy the HTTP traffic is bound OK by the HTTP.SYS, in order to do this we need to run the following command: ``` Netstat -aon | findstr / ":1338" ``` Where 1338 is the default port used to bridge BranchCache traffic in StifleR. The following result indicates that the HTTP server has crashed and not recovered, as no port is bound: ![](/files/-MAWu2rRhpeEfx315_jE) This can be the case, even though the UDP ports are bound. StifleR client 1.9.8 and upwards deals with this in a better way and this scenario should not happen. The result should look like this: ![](/files/-MAWu2rST1esSUoU74UL) ### Detection of traffic It can be hard to troubleshoot this, but on the client that requests the data, you should see connections to Blue Leader that is in the same subnet as the requesting client, the following command will list all connections if run on the requesting client: ``` Netstat -aon | findstr / ":1338" ``` The should then return one or several entries pointing to the Blue Leader. #### Which port is BranchCache operating on? You need to both set the URL acl as well as set the right registry value. ``` netsh http show urlacl | findstr /i "0131501b-d67f-491b-9a40-c4bf27bcb4d4" ``` ![](/files/-MAWu2rTm-FtDwH2lATx) ### Hosted Cache Mode Settings Set the ports in the following location: **Computer\HKEY\_LOCAL\_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerDist\HostedCache\Connection** Reg\_Dword: ConnectPort Reg\_Dword: wListenToPort ![](/files/-MAWu2rUMEdhallxF7TB) # Overview StifleR is designed for organizations committed to network optimization.\ It does not simply reduce WAN bandwidth used — it ensures content is delivered intelligently to end users and endpoints from the best, local sources, while also considering overhead to minimize lag and maximize delivery speed. StifleR utilizes Microsoft peer-to-peer methods, but builds in intelligence, visibility, and control. It provides live data, dynamic traffic shaping, and real-time control for IT teams to understand content distribution flows — whether delivering Windows Updates, Office updates, or business applications. Regardless of whether your ecosystem is built on SCCM, Intune, or hybrid, StifleR guarantees that you're not losing business-critical traffic to content delivery. It empowers IT teams to maintain productivity and limit unnecessary network consumption. ## What does it do? StifleR is designed for organizations committed to network optimization.\ It does not simply reduce WAN bandwidth used — it ensures content is delivered intelligently to end users and endpoints from the best, local sources, while also considering overhead to minimize lag and maximize delivery speed. StifleR utilizes Microsoft peer-to-peer methods, but builds in intelligence, visibility, and control. It provides live data, dynamic traffic shaping, and real-time control for IT teams to understand content distribution flows — whether delivering Windows Updates, Office updates, or business applications. Regardless of whether your ecosystem is built on SCCM, Intune, or hybrid, StifleR guarantees that you're not losing business-critical traffic to content delivery. It empowers IT teams to maintain productivity and limit unnecessary network consumption. ## Why do you need it? StifleR is designed for organizations committed to network optimization.\ It does not simply reduce WAN bandwidth used - it ensures content is delivered intelligently to end-users and endpoints from the best, local sources, while also considering overhead to minimize lag and maximize delivery speed. StifleR utilizes Microsoft peer-to-peer methods, but builds in intelligence, visibility, and control. It provides live data, dynamic traffic shaping, and real-time control for IT teams to understand content distribution flows - whether delivering Windows Updates, Office updates, or business applications. Regardless of whether your ecosystem is built on SCCM, Intune, or hybrid, StifleR guarantees that you're not losing business-critical traffic to content delivery. It empowers IT teams to maintain productivity and limit unnecessary network consumption. ## How it works Without StifleR, there’s no control over competing bandwidth for network traffic. Background updates, media streaming, and file synchronizations all degrade time-sensitive business processes like POS transactions, deployments, or security updates. StifleR is the controller.\ It treats content delivery as a control plane and gives IT full visibility into what's moving across the network — and the power to manage it in real time. * Critical traffic is prioritized * Background content is governed As more endpoints run the StifleR client, the network becomes more efficient: instead of each device downloading content from a remote server, they source it from a nearby local endpoint. With StifleR, your network behaves in a predictable, efficient manner — aligned with your organization's business priorities. ## StifleR architecture and operation StifleR functions as an integration layer built on Microsoft’s methods of content delivery, offering a unified, intelligent approach to managing enterprise downloads. It integrates with: * BranchCache: Enhances Windows’ native WAN optimization and peer discovery across subnets. * Delivery Optimization (DO): Improves Microsoft's P2P engine with policy management, group control, and activity reporting. * Configuration Manager Client Peer Cache: Supports peer-based distribution in SCCM and increases efficiency. * LEDBAT: Recognizes and reports on background traffic to ensure critical communications remain unaffected. All communication is enabled through SignalR, Microsoft’s real-time web communication framework, allowing for persistent bi-directional connections, dynamic orchestration, and real-time telemetry. ### Bandwidth measurement — Beacon Server StifleR Beacon Servers are deployed at content sources (like datacenters or distribution points). They serve as reference endpoints that help clients benchmark bandwidth performance. This enables dynamic adjustments based on live network conditions. ### SignalR communication The StifleR server uses SignalR over OWIN (Open Web Interface for .NET) to create reliable, bi-directional communication with clients and dashboards. * Sessions start as HTTP connections and upgrade to WebSockets for persistent messaging. * While deep understanding of SignalR isn’t required for everyday use, it’s helpful for scripting or advanced customizations. Further documentation on SignalR, SSL configuration, and secure operations can be found on the 2Pint Software Knowledge base. ### StifleR rules The StifleR client checks through its queue of active downloads (both BITS and DO) and then prioritizes them according to a locally held XML configuration file (StifleRulez.xml) which contains a set of rules that are configured centrally by the administrator and automatically downloaded by the 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. As an example, Microsoft Maps sync could be set to a low priority, while Windows Update patches would be set to high. Using this rule set, you can effectively control which downloads should be completed ahead of others. All of these configuration settings can be changed centrally at any time with any such changes automatically replicated to your clients in seconds. # Key innovations Microsoft’s native peer-to-peer technologies — like BranchCache, BITS, and Delivery Optimization — are powerful, but lack the fine-grained control needed to fully protect business-critical bandwidth.\ StifleR bridges that gap with deep visibility and dynamic control over how content is delivered across your network. ### Bandwidth control Out of the box, Microsoft’s Background Intelligent Transfer Service (BITS) allows only broad, static control over bandwidth usage based on generic job priority levels. For example, user-initiated Configuration Manager (CM) downloads default to *Foreground Priority*, which consumes all available bandwidth - regardless of the importance of other traffic or policies in place. StifleR steps in to give administrators real power over these transfers: * Per-job bandwidth and priority controls — Override Microsoft defaults and set custom priorities for specific job types, content categories, or delivery scenarios. * Real-time policy enforcement — Adjust transfer settings dynamically through the StifleR agent, down to the individual download level. * Centralized management — Apply and refine policies from a single console across your entire device estate. **Dynamic, latency-aware throttling** Setting a job’s priority isn’t enough when multiple clients are pulling content from a remote data center over limited WAN links. Static bandwidth caps often lead to congestion, bottlenecks, and a degraded user experience. StifleR goes beyond simple limits by: * Monitoring live network latency during transfers. * Automatically adjusting transfer speeds to keep traffic within customizable QoS boundaries. * Prioritizing critical services and ensuring that background downloads never starve business operations. Whether it’s software distribution, updates, or user-driven downloads, StifleR gives you intelligent control over every byte — ensuring high performance for end users and peace of mind for IT. ### Single site download StifleR revolutionizes how content is distributed across distributed networks by introducing intelligent, dynamic leadership roles — Red Leaders and Blue Leaders — to manage downloads efficiently and reduce WAN saturation. Instead of allowing every client in a subnet to simultaneously pull updates or applications from remote servers, StifleR designates a Red Leader — the most suitable client in that subnet — to act as the primary downloader. This client fetches the required content and then redistributes it locally using Microsoft’s native peer-to-peer caching protocols such as BranchCache or Delivery Optimization. This “single-source-per-subnet” approach dramatically minimizes redundant WAN traffic and accelerates delivery times for all clients on the local network. But StifleR doesn’t stop there. In multi-subnet environments, Blue Leaders are elected to coordinate content sharing across subnet boundaries. These Blue Leaders listen for local discovery broadcasts and forward them to their counterparts across the site, enabling cross-subnet peering. The result: content is downloaded once to the site and shared seamlessly between all peers across the LAN — no matter how segmented the local network might be. This model delivers powerful benefits: * Reduction in WAN usage, especially during large-scale deployments or updates. * Faster delivery times by leveraging the fastest, best-connected clients. * Dynamic bandwidth conservation, where non-leader clients throttle back to prevent link saturation. * Complete visibility and control over which clients act as distribution points, all managed in real-time through the StifleR Dashboard. By managing content delivery this way, StifleR ensures that your business-critical bandwidth stays available while maximizing the efficiency of Microsoft’s native content distribution stack. ## Microsoft protocols and how StifleR enhances them StifleR doesn’t rely on its own proprietary data transfer engine. Instead, it enhances and optimizes Microsoft’s native peer-to-peer and content delivery services. By layering intelligent controls on top of these technologies, StifleR delivers superior performance and centralized management — without replacing the underlying mechanisms. ### BranchCache BranchCache is a tried WAN optimization technology embedded in Windows, that reduces the amount of bandwidth consumed by allowing clients within a site to cache and share content locally. Limitations in Microsoft’s native implementation of BranchCache limit its usability in more difficult network configurations due to the reliance on broadcast-based peer discovery. StifleR solves this problem by adding centralized control, and an expanded peer discovery method. Administrators can centrally configure and administer BranchCache peering policies allowing localized content sharing not only within a single subnet, but also across well-connected subnets at a site, extended the local peer-to-peer content exchange. 2Pint Software takes this a step further by developing a tool to leverage the BranchCache functionality in the WinPE space, so that peer caching is utilized during the Operating System Deployment (OSD) phase. This delivers dramatic reductions in build times, and WAN utilization, when PC imaging and refreshing. This is a significant advantage for businesses in a remote or constrained bandwidth location Key Benefits: * Centralized control over BranchCache behavior and peering scope. * Peer-to-peer sharing across subnet boundaries, not just within a single broadcast domain. * Full utilization of BranchCache even in WinPE, improving OSD efficiency and scalability. * Seamless integration into existing Microsoft content distribution workflows. With StifleR, BranchCache becomes more than just a background efficiency tool — it evolves into a strategic asset for fast, bandwidth-aware content delivery across your enterprise. ### Delivery Optimization (DO) Delivery Optimization (DO) is Microsoft’s modern, HTTP-based peer-to-peer content delivery technology designed to reduce network load by sharing content between devices or offloading downloads to a local caching server. It plays a central role in the distribution of Windows Updates, Microsoft Store apps, Intune content, and more — especially in Windows 10 and later. While DO operates largely under the orchestration of Microsoft’s cloud services, StifleR brings local intelligence and control to the process, transforming DO into a fully manageable enterprise-grade solution. What StifleR adds to DO: * Custom peer group management: Define logical, location-aware peering boundaries so content is shared only among the most relevant clients - whether that’s per site, subnet, or organizational unit. * Policy enforcement: Apply consistent configuration across your environment, ensuring Delivery Optimization behaves in line with corporate standards and network constraints. * Real-time Visibility and reporting: Monitor when and where DO is being used, track peer-sharing effectiveness, and validate that content delivery is functioning efficiently — all through the StifleR Dashboard. Key Benefits: * Minimizes WAN usage by maximizing local peer-to-peer content sharing. * Increases efficiency and predictability of DO behavior across varied network environments. * Provides the operational insight and controls that native DO lacks, especially for larger or more distributed organizations. With StifleR managing your DO infrastructure, you gain enterprise-level governance over Microsoft’s peer-assisted delivery platform — unlocking its full potential while safeguarding bandwidth and user productivity. ### Background Intelligent Transfer Service (BITS) Background Intelligent Transfer Service (BITS) is a Windows service that performs background file transfers using idle network bandwidth. It purpose is to minimizes network disruption by throttling downloads so that they don’t interfere with applications or user activity. BITS is useful for pushing content silently in the background, while there are limited native controls - particularly in enterprise scenarios where policies must be consistent, precise, and visible. **What StifleR adds to BITS:** * Centralized bandwidth policy management: Develop bandwidth usage rules across sites, subnets, and network zones that prevent BITS from overwhelming all available bandwidth — especially across limited WAN links. * Granular throttling controls: Go beyond BITS’s default behavior with the ability to set usage thresholds based on content type, time of day, or job priority. * Visibility into job activity: Monitor BITS traffic in real time, giving IT teams the insight they need to adjust policies dynamically and respond proactively to congestion issues. Key benefits: * Prevents low-priority downloads from competing with mission-critical traffic like video calls, POS transactions, or software deployments. * Ensures consistent BITS behavior across diverse networks and client configurations. * Provides the governance and control BITS lacks natively — reducing risk, increasing efficiency. With StifleR acting as the policy and visibility layer for BITS, organizations can fully leverage its strengths while eliminating its blind spots — ensuring content moves efficiently without compromising other key services. ### LEDBAT LEDBAT (Low Extra Delay Background Transport) is Microsoft’s latency-sensitive protocol for background data transfers. It is designed to scale data throughput automatically based on network conditions in real time, using only available bandwidth, and deferring immediately to higher priority traffic as it occurs. LEDBAT can be very beneficial in Configuration Manager distribution points, which require large amounts of content data to be transferred in a way that does not disrupt important and/or critical business activity Native LEDBAT limitations:\ By default, LEDBAT operates silently, with little to no built-in reporting or control. Administrators often lack visibility into which transfers are using LEDBAT or how it's impacting performance. How StifleR enhances LEDBAT functionality: * Transfer-level visibility — StifleR identifies and reports which content transfers are using LEDBAT, providing a clear view of background bandwidth activity. * Performance monitoring — Real-time telemetry shows how LEDBAT behaves across endpoints, helping teams evaluate its effectiveness and tune policies accordingly. * Operational confidence — With full insight into LEDBAT traffic, administrators can trust background transfers to remain non-intrusive and aligned with business priorities. Outcome:\ StifleR transforms LEDBAT from a passive background feature into an actively monitored and controlled component of your enterprise content delivery framework. # Your StifleR guide This is the StifleR 3.0 release documentation. For other versions, please select the dropdown list at the top left and select the correct version. Welcome to the StifleR documentation site, the real-time content distribution control system from 2Pint Software. StifleR provides a complete, seamless re-architecting of how any content (software, updates, OS images etc.) is distributed through your business network.\\ \ StifleR is compatible with Microsoft Configuration Manager (SCCM), Microsoft Intune and hybrid environments — a perfect fit for the modern business infrastructure on a cloud journey. \ In this documentation, you will find the necessary information to successfully integrate StifleR into your environment, from initial evaluation to production roll out. ## From setup to success This guide will help you through every step of using StifleR — from setup to production deployment. For an overview of StifleR is, a summary of how it works, and an explanation of how it improves content delivery in SCCM, Intune, or hybrid environments, see the [About section](/stifler/3.0/about/stifler-overview). Next, you'll find the [prerequisites](/stifler/3.0/setup/prerequisites): infrastructure, supported systems, firewall requirements, and etc. The [Installation ](/stifler/3.0/setup/installation)section explains how to set up the StifleR components. Once installed, the [Configuration ](broken://pages/Ij2NSUaOTJEPNqhFsOMr)section guides you to create content policies, monitor activity, and use reports. ## Quick to start, easy to test Getting started with StifleR is straightforward. By reviewing the [prerequisites ](/stifler/3.0/setup/prerequisites)and completing the [installation](/stifler/3.0/setup/installation), you can quickly begin enhancing content distribution using native Microsoft technologies such as BranchCache and Delivery Optimization. With minimal initial configuration, StifleR can be deployed in a lab or production environment and then expanded and refined as needed to support enterprise-scale deployments. # Release notes {% updates format="full" %} {% update date="2026-08-26" %} ## StifleR 3.0.2634.269 * Added MOM 2.4 support: the proxy address is now delivered to clients via location policy, and the MOM external URL now includes the required /api path * Improved performance by reducing overhead during Graph API token acquisition * Updated bundled third-party components to address reported security vulnerabilities * Improved chart data grouping * Improved the label and description for the WiFi allow list setting * Remote tools now require a client running version 3.0 or later * Fixed a client crash during OS deployment tracking when task sequence environment variables were empty * Fixed a client crash on Windows versions older than Windows 10 1709 * Fixed beacon bandwidth measurements failing on some clients * Fixed clients being shown as offline in Client Search and on overview pages after reconnecting * Fixed an error in client search when a client had no active connection * Fixed server-side AgentId assignment logic * Fixed RemoteR connecting only to the first client opened in a tab, so remote tools now connect for each client opened * Fixed RemoteR disconnect notifications being shown for a client other than the one currently open * Fixed Autopilot monitoring when deployed via DeployR * Fixed dashboard charts not rendering when recreated, which could leave network group bandwidth usage graphs empty * Fixed main overview calculations * Fixed the VPN and regular network filter on the main overview page * Fixed percentage values displayed in tables * Fixed the CacheR download button * Fixed an error on the OSD page that could prevent details from loading * Fixed log file viewing, including the parsing of multi-line log records * Fixed script paths for PowerShell scripts in Settings * Removed a duplicate version label from the DeployR content item version selection {% endupdate %} {% update date="2026-06-05" %} ## StifleR 3.0.2623.250 * Fixed invoke-powershell method execution via RemoteR * Fixed DeployR content items multiple flag edit * Fixed an issue where responses did not always redirect to OIDC login page after token expiry * Fixed multiple client crashes referencing SHCORE.dll and COM objects leaking on early iterator exit * Fixed AccessViolation in nfapi.dll during client shutdown * Fixed memory leak in WlanQueryInterface on the client * Fixed client process termination caused by an unhandled exception during operation * Fixed NRE in CalculateNewLocationHashesWorker during service startup * Fixed unbounded memory growth and race condition in server-side dictionary handling * Fixed SecurityServices handle leak and potential crash * Cached negative CCM DTS lookups to prevent WMI query storm at scale * Fixed ClientApp shutdown crash caused by undisposed timers firing after teardown * Fixed issue where client search did not show any results * Improved AgentId duplicate detection and server-assignment logic, now configurable * Improved StifleR Service startup time by narrowing Web API assembly scan * Fixed AzureAD group parsing for clients running Windows 26H1 * Fixed Autopilot issue causing excessive Graph API requests * Improved Graph API reliability and responsiveness with request timeouts and reduced redundant calls * Centralized performance counters for more consistent monitoring and improved stability when counters are unavailable * Fixed web API authentication log messages * Added a network column to CacheR client results * Fixed MCC server propagation to assigned locations through infrastructure services * Security improvements and vulnerability fixes {% endupdate %} {% update date="2026-04-08" %} ## StifleR 3.0.2613.211 * Moved client schedule cleanup to a separate worker process for improved scalability at large client counts * Added SRUM data pre-caching worker and refactored SRUM service for better performance * Split Red Leader and Blue Leader settings into separate configuration options with flag descriptions * Fixed Blue Leader getting unassigned unexpectedly * Fixed issue with certain types of CCMDTS jobs * Fixed client overview search links on the Dashboard * Optimized SRUM endpoint performance with bulk ESENT queries and 24-hour result caching * Optimized location history report generation with pre-grouped hardware data * Fixed roaming clients query to consistently use the correct database index * Added Beacon lookup for assigned locations * Fixed Beacon election logic for automatic measurements * Fixed Beacon availability request handling * Fixed Beacon measurement sort order * Fixed Client Beacon measurement log directory path creation * Fixed Client crash caused by disposed handle race condition * Fixed date parsing in Remote Tools log viewer * Added error search on the Dashboard splash page * Enabled Server GC for StifleR Service to reduce garbage collection pause durations * Disabled client schedule writes by default * Reworked CacheR results view with dedicated networking page, progress bars, and tables replacing charts * Updated Angular and amCharts to latest minor versions * Security improvements and vulnerability fixes {% endupdate %} {% update date="2026-02-27" %} ## StifleR 3.0.2609.96 * Fixed issue where updating a DeployR Content Item version incorrectly affected higher versions * Various performance improvements and optimizations
{% endupdate %} {% update date="2026-02-06" %} ## StifleR 3.0.2606.51 * Reworked networking card summary to modal popup for improved usability * Dashboard filters now allow exclusion of selected networks (for example, VPN networks) * Added support for detecting WFP-based VPN clients * Added UI to configure per-process bandwidth throttling limits * Fixed issue with Service /VerifyAdmin tool * Fixed issue with CacheR client unable to download content * Security improvements and vulnerability fixes
{% endupdate %} {% update date="2026-01-21" %} ## StifleR 3.0.2604.17 * Added autosave support for DeployR Tags * Updated WiX installer behaviour to allow the Client to fully clean up files on uninstall * Improved stability of Task Sequence StepData handling to reduce contention * Improved ActionHub diagnostic logging * Fixed Service stability when performance counters are unavailable * Fixed issues with Content Item List selection and deselection * Fixed scenarios where processed lookups were not deleted correctlyduring network changes * Fixed issue occurring after TaskSequenceHistory WMI calls Fixed missing or incorrect data in main overview monthly reporting endpoints * Fixed installer and command-line package compatibility issues * Fixed build versioning to ensure all binaries share consistent version numbers * Updated Install End User License Agreement * Security improvements and vulnerability fixes
{% endupdate %} {% update date="2025-12-17" %} ## What's new in StifleR 3.0 * **Real-time Autopilot provisioning tracking** * **Real-time DeployR OS deployment monitoring** * **Task sequence execution and historical reporting** for both **ConfigMgr** and **DeployR** * **Network creation attempt visibility** * **Role-Based Access Control (RBAC)** with configurable rules and roles **Simplified Management** * New installers and enhanced configuration management for faster, easier updates and maintenance **Remote Tools (Web-Based)** * Browser-based management and troubleshooting tools, including: * File and event-based logging * Explorer and registry access * WMI, Performance Monitor, Resource Monitor, and Task Manager * And more... **Advanced Insights** * Over **300% more analytics data points** for deeper operational intelligence * **Location services with device geo-tracking** to quickly locate, diagnose, and resolve issues StifleR 3.0 sets a new standard for real-time intelligent bandwidth management across all traffic types, delivering deep deployment visibility—empowering IT teams with unmatched control, insight, and efficiency . {% endupdate %} {% endupdates %} # Prerequisites StifleR consists of several interconnected components (Server, ActionHub, Dashboard, Beacon, WMI Agent and Client). Each requires compatible OS versions, frameworks, and communication access. \ Before installing the StifleR components, please ensure the following pre-requisites are in place: ## Permissions StifleR controls access to the two main server components the SignalR Hub and the Web service. This control applies to both users (who access StifleR Dashboards) and StifleR Clients (who access the SignalR Hub). Access is managed through Active Directory Global groups, which must be created in advance. It is recommended to define two groups: * StifleR Global Admins - Full read and write right access to ALL objects. * StifleR Global Read - Gives read only rights to ALL locations and statistics. Including WMI. *** ## Firewall Configuration {% hint style="danger" %} Please review it carefully before installation. {% endhint %} Ensure that network communication between all StifleR components is not blocked by internal or external firewalls. Each service relies on specific ports for data exchange. [Complete list of required Firewall ports and directions.](/stifler/3.0/setup/prerequisites/firewall-ports) *** ## Antivirus Exclusions To ensure stable operation and prevent interference with communication or telemetry, configure antivirus or endpoint protection exclusions for all StifleR components. Exclude the common installation and data directories from active scanning: * C:\Program Files\2Pint Software\\ * %ProgramData%\2Pint Software\StifleR\\ * Additionally, exclude each service executable corresponding to the installed components (for example StifleR.Server.exe) *** ## StifleR server * Windows Server 2019 or newer * Minimum 4 vCPUs, 4 GB RAM (scale with client count) * Minimum 10 GB free space for logs and telemetry * .NET Framework: 4.8 (mandatory) * Microsoft SQL Server 2016+ (Express, Standard, or Enterprise) * db\_owner permissions required for StifleR DB account System performance and capacity depend on deployment scale and client volume. [A complete overview of recommended specifications](/stifler/3.0/setup/prerequisites/hardware-requirements). ### Service Account * Dedicated domain or local account * “Log on as a service” right * Read/write access to %ProgramData%\2Pint\StifleR * Must have db\_datareader and db\_datawriter on StifleR DB *** ## StifleR dashboard * Windows Server 2019 or newer * 2 vCPUs, 4 GB RAM minimum (scale with concurrent users) * .NET Framework: 4.8 (mandatory) * IIS ### Certificates * Valid SSL certificate required for HTTPS deployment * Optional internal CA or self-signed acceptable for test environments *** ## Action Hub * Windows 11 (Pro, Enterprise, Education), including ARM64-powered Windows 11 devices, and Windows Server 2016 or newer. * .NET Framework: 4.8 (mandatory) ### Service Account Recommended to use a dedicated domain service account with: * “Log on as a service” right * Write permissions to %ProgramData%\2Pint\StifleR and log directories * Account must have sufficient rights to execute configured scripts or API calls. *** ## Beacon * Windows 11 (Pro, Enterprise, Education), including ARM64-powered Windows 11 devices, and Windows Server 2016 or newer. * .NET Framework: 4.8 (mandatory) *** ## StifleR Client * Windows 10 and 11 (Pro, Enterprise, Education), including ARM64-powered Windows 11 devices, and Windows Server 2016 or newer. * .NET Framework: 4.8 (mandatory) ### Service Account * Requires read/write access to: * %ProgramData%\2Pint\StifleR (for local cache and logs) * HKLM\Software\2Pint\StifleR (for configuration and telemetry keys) *** ## WMI Agent (optional) * Windows 11 (Pro, Enterprise, Education), including ARM64-powered Windows 11 devices, and Windows Server 2016 or newer. * .NET Framework: 4.8 (mandatory) ### Service Account Recommended to run under a dedicated domain account with: * Local Administrator rights on target endpoints * “Log on as a service” permission * Remote WMI access rights in root\cimv2 and root\Microsoft\Windows\DeliveryOptimization * If SQL reporting is enabled, the account must have db\_datawriter on the StifleR database. # Hardware requirements The following table can be used as a summarized view of the hardware requirements for StifleR.
SizeCPUMemoryNICDisk
Under 10,000 clients4 cores8GBVirtual / 1GB1x SSD for DBs
10,000 — 20,000 clients8 cores16GB1GB / 10GB2x SSD for DBs
20,000 — 50,000 clients16 cores32GB10GB4x SSD for DBs
50,000 — 100,000 clients32 cores64GB2x10GB6x SSD for DBs
100,000 — 200,000 clients48 cores256GB4x10GB8x SSD for DBs
### CPU 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. ### Memory StifleR writes a lot of historical data to databases, and also maintains in-RAM memory objects. Since each connection and all connection data is stored in RAM a decent allocation of RAM is recommended but 32GB should be plenty for most installations. ### Disk 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. ### Network Connectivity Each client initiates a non-managed SignalR client connection (web sockets) to the server, so if you want 100k clients to connect 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. ### Redundancy 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. # Firewall ports This page provides a detailed overview of the network ports required for the **InterVLAN** feature and related services. It outlines the specific client ports used by **StifleR Client** and **BranchCache**, including communication flow and directionality. Refer to the tables below for the full list of ports, usage descriptions, and whether they require explicit allowance in your firewall configuration. Additionally you can review [BranchCache Distributed Cache Mode](https://stifler.docs.2pintsoftware.com/introduction/technical-overview/2pint-branchcache-administrator-guide#toc462952235) for firewall ports needed for BranchCache communications #### Stifler Service local firewall port openings required — outgoing
NameDescriptionLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
StifleR ServiceGlobal catalog LDAPAnyfor Domain accounts usage32683268TCPNo
Stifler ServicehttpsAnyConnection for the dashboard443443TCPNo
Stifler ServiceSQL Server Service BrokerAnyonly if SQL is enabled40224022TCPYes
Stifler ServiceSQL Server serviceAnyonly if SQL is enabled14331433UDPYes
#### Stifler client local firewall port openings required — incoming
NameExecutableLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
Blue Leader Data From Remote Peer TwoPint.PeerDist.BlueGreenLeader.exeAnyAny1337AnyTCPYes
Green Leader Peer DataTwoPint.PeerDist.BlueGreenLeader.exeAnyAny1337, 1339AnyTCPYes
Blue Leader Peer DataTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal Subnet1338AnyTCPYes
Peer ProbesTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal Subnet3702AnyUDPYes
Blue Leader Peer Probe MatchTwoPint.PeerDist.BlueGreenLeader.exeAnyAnyAny3702UDPYes
mDNSTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal Subnet5353AnyUDPYes
Stifler ServiceStifler ClientAnyAny1414AnyTCP
#### Stifler client local firewall port openings required — outgoing
NameExecutableLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
Beacon - iPerf packetsAnyStifler BeaconsAny5201UDPYes
Beacon - FastPingAnyStifler BeaconsAny5200TCPYes
Blue Leader Data to requesting PeerSYSTEMAnyAnyAny1338TCPYes
Blue Leader Data From Remote PeerTwoPint.PeerDist.BlueGreenLeader.exeAnyAny1337AnyTCPYes
Green Leader Peer DataTwoPint.PeerDist.BlueGreenLeader.exeAnyAnyAny1337.1339TCPYes
Blue Leader Peer DataTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal SubnetAny1338TCPYes
Peer ProbesTwoPint.PeerDist.BlueGreenLeader.exeAnyLocal Subnet3702AnyUDPYes
Blue Leader Peer Probe MatchTwoPint.PeerDist.BlueGreenLeader.exeAnyAnyAny3702UDPNo
Blue Leader Probe PortTwoPint.PeerDist.BlueGreenLeader.exeAnyAny37033703UDPYes
mDNSTwoPint.PeerDist.BlueGreenLeader.exeAny5353UDP
Access to Stifler ServiceStifler.Client.exeAnyAny or Stifler serverAny1414UDPNo
Access to Stifler ServiceStifler.Client.exeAnyAny or Stifler serverAny1414TCPNo
Access to Stifler ServiceTwopint.remotetools.host.exeAnyAny or Stifler server + Action hubsAny1415UDPNo
Access to Stifler ServiceTwopint.remotetools.host.exeAnyserver + Action hubsAny1415TCPNo
Access to Stifler ServiceBrowserAnyStifler ServerAny9000TCPNo
Access to Stifler ServiceBrowserAnyAny or Stifler serverAny1414TCPNo
Access to Stifler ServiceBrowserAnyAny or Stifler server + Action hubsAny1415TCPNo
#### BranchCache local firewall port openings required — incoming
NameExecutableLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
BranchCache Content Retrieval (HTTP-In)SYSTEMAnyAny1337AnyTCPYes
BranchCache Hosted Cache Server (HTTP-In)SYSTEMAnyAny1339.443AnyTCPYes
BranchCache Peer Discovery (WSD-In)%SYSTEMROOT%\system32\svchost.exeAnyLocal Subnet3702AnyTCPNo
#### BranchCache local firewall port openings required — outgoing
NameExecutableLocal AddressRemote AddressLocal PortRemote PortProtocolCustomizable
BranchCache Content Retrieval (HTTP-Out)SYSTEMAnyAnyAny1337TCPYes
BranchCache Hosted Cache Client (HTTP-Out)SYSTEMAnyAnyAny1339.443TCPYes
BranchCache Hosted Cache Server(HTTP-Out)SYSTEMAnyAny1339.443AnyTCPYes
BranchCache Peer Discovery (WSD-Out)%SYSTEMROOT%\system32\svchost.exeAnyLocal SubnetAny3702UDPNo
# Network topology When deploying the StifleR solution in your environment, it is important to consider your network topology. An important concept to understand when working with Network Topologies in StifleR is the relationship between three network types: * **Network –** an individual subnet. * **Network Group –** a Network Group contains one or more subnets (defined as Networks) which are reachable with good speed to each other.\ Some additional information: * Traffic is not considered a cost inside a network group * Designed to limit peer-to-peer traffic at certain sites * Peer-to-peer traffic is never shared between network groups * Bandwidth controls are applied to Network Groups, so understanding bandwidth limitations within this level of the topology is important to consider * **Location –** represents a physical location in StifleR and contains one or several Network Groups. It contains physical information such as address, administrators etc. It defines a physical, worldly location, hence the name Location. A Location can store one or several Network Groups which contain Networks. The diagram below illustrates the logical structure of a StifleR network topology.
# Installation This section provides a step-by-step process to install each component of the StifleR platform. Whether you're evaluating via Proof of Concept or implementing a full production deployment, this is the correct order of installation to get a clean and functional environment. {% hint style="success" %} We recommend when deploying 2Pint software in your environment, to initially validate against your UAT or QA environment before rolling out in production. {% endhint %} [Testing and validation](/stifler/3.0/setup/testing-and-validation) are used to confirm that StifleR operates correctly and meets expectations in your environment. A Proof of Concept can be used to verify behavior, performance, and visibility before expanding usage, and the same testing scenarios can also be applied in production environments in a controlled manner. Before proceeding to installation, ensure that: * [Required firewall ports are opened](/stifler/3.0/setup/prerequisites/firewall-ports) * [Antivirus exclusions are applied](/stifler/3.0/setup/prerequisites#antivirus-exclusions) * [Necessary permissions are granted](/stifler/3.0/setup/prerequisites#permissions) ## Order of installation For a standard StifleR implementation, the recommended order for deploying and configuring each component is as follows: 1. [Install StifleR Server](/stifler/3.0/setup/installation/stifler-server-installation) – Core engine managing all operations. 2. [Install StifleR Dashboard](/stifler/3.0/setup/installation/stifler-dashboard-installation) – Web UI for monitoring and configuration.

If you are installing StifleR for DeployR management only you don't need to install or configure the rest of StifleR components. StifleR client is optional in boot media for monitoring purposes.

3. [Install Action HUB](/stifler/3.0/setup/installation/stifler-actionhub-installation) – Dynamic, real-time actions across the StifleR ecosystem. 4. [Install Beacon](/stifler/3.0/setup/installation/stifler-beacon-installation) – Gathers telemetry and identifies active subnets. 5. [Install StifleR Client](/stifler/3.0/setup/installation/stifler-client-installation) – Client that monitors network activity, reports and enforces policies. 6. [Install WMI Agent](/stifler/3.0/setup/installation/stifler-wmi-agent-installation) (optional) – Agent that replaces traditional WMI. 7. [Install CacheR](/stifler/3.0/setup/installation/cacher-installation) (optional) – content tracking and pre-caching. ## Prerequisites for Configuration Manager If Configuration Manager is being used as part of the PoC, the following additional setup is required. Detailed configuration steps can be found on the linked documentation pages. {% tabs fullWidth="false" %} {% tab title="Enabling BranchCache" %} BranchCache is the key Microsoft peer-to-peer technology which StifleR optimizes. It is important to enable BranchCache on all relevant systems. * If using Configuration Manager, enable BranchCache on all Servers / CM distribution points * If you have a simple lab environment, you should perform this step (if required) on all your distribution points * If you are planning on testing in a production environment, make sure that you perform this step ONLY on the relevant distribution point your test clients will obtain their deployment content from. See: [Configuring BranchCache on Windows Server](/stifler/3.0/configuration/windows-server-branchcache-configuration) {% endtab %} {% tab title="Enabling DO" %} As well as BranchCache, StifleR can utilize download jobs which use Microsoft's Delivery Optimization (DO) peering technology. See: [Configuring Delivery Optimization](/stifler/3.0/configuration/delivery-optimization-configuration) {% endtab %} {% tab title="BITS Policy " %} Check for and remove any BITS policy that has been set within Configuration Manager and/or Active Directory. Such settings can interfere with the efficient operation of the automated Bandwidth mechanisms in StifleR. In the Configuration Manager console, BITS settings can be configured in "Client Settings":

Make sure that this is set to No (default setting), as this configures a local BITS policy on the clients which we do not want.

**Remove any BITS AD Group Policy (if configured)**\ Within the Active Directory Group Policy Editor, go to: \ Computer Configuration -> Policies -> Administrative templates -> Network -> Background Intelligent Transfer Service (BITS) Ensure that there are no BITS policies configured. If present, remove them to avoid affecting any test clients. {% endtab %} {% endtabs %} ### [**Configure the network topology**](/stifler/3.0/configuration/stifler-network-locations) * Configure target bandwidth * Configure subnet description * Configure Delivery Optimization ## Upgrading from 2.10 to 3.0 {% hint style="warning" %} If StifleR was previously installed to a custom destination path, version 3.0 will ignore that location and install to the default path C:\Program Files\2Pint Software. If you need to continue using a custom installation path, you must first uninstall StifleR version 2.10 before installing version 3.0. {% endhint %} {% hint style="warning" %} The SQL Server download database must be recreated as an empty database for new data to be populated and appear correctly. {% endhint %} #### Upgrade instructions * **Stop StifleR** • On the existing server, stop the StifleR Service. • Confirm it is fully stopped before proceeding (StifleR.Service.exe is not running, and service status is Stopped). {% hint style="info" %} Note: Your database locations may be different if you have configured different path(s) in StifleR.Service.exe.config per this guide: [Moving the StifleR Server Databases to a New Drive on the Same Server | StifleR 2.10 | Product Documentation](https://documentation.2pintsoftware.com/stifler/2.10/operations/backup-and-recovery/moving-the-stifler-server-databases-to-a-new-drive-on-the-same-server) {% endhint %} * **Back up files, registry and data** Make backups of: * Databases (all StifleR-related DBs): * C:\ProgramData\2Pint Software\StifleR\Server\Databases * Install paths (entire folders), especially: * C:\Program Files\\... (default location) {% hint style="info" %} Keep these backups together and clearly labeled (server name + date). {% endhint %} * **Uninstall old components** * Uninstall the StifleR Service * Uninstall the StifleR Dashboard * **Install StifleR Server** * Install the [StifleR Service](/stifler/3.0/setup/installation/stifler-server-installation). * Use your backed-up config file from Program Files to retrieve/restore config key items * **Reapply previous customizations (from 2.10)** * Open the Configuration Editor. * Re-implement any customizations you had in 2.10. (settings, groups, paths, ports any non-default tuning) {% hint style="info" %} Use the backed-up config file as your reference for what to carry over (settings, groups, paths, ports any non-default tuning). {% endhint %} * **Install StifleR Dashboard and set up IIS manually** * Install the [StifleR Dashboard](/stifler/3.0/setup/installation/stifler-dashboard-installation). * Manually configure IIS for the dashboard: * Create/assign the site (or application under a site) * Configure bindings as needed (host header, port, TLS if applicable) * Ensure the app pool identity and permissions match your security approach * **Install StifleR 3.0 components** * Install Action Hub/Beacon/WMI Agent. * Through Infrastructure Services in the StifleR Dashboard, confirm component(s) connect successfully. * Through Infrastructure Services in the StifleR Dashboard, approve the StifleR component. #### Quick validation and cleanup checklist (recommended) * Service starts cleanly on the new server * Dashboard loads and authenticates correctly * Admin groups behave correctly (access control) * Action Hub is installed and functional * (If applicable) remove/clean up any old IIS site/app pool entries related to the dashboard only after you’ve confirmed you have backups. # StifleR Server installation ## Prerequisites * Review [StifleR Server Requirements](/stifler/3.0/setup/prerequisites/hardware-requirements) page for server specifications, etc. * Open the required [firewall ports](/stifler/3.0/setup/prerequisites/firewall-ports) * Create and populate the [StifleR Administrative Security Groups](/stifler/3.0/setup/prerequisites#permissions) * Activate Microsoft .NET 4.8 * Provide installation account with Administrator rights * Enter license key (optional at this point) * Decide on whether the StifleR Service will be using SSL \ (optional at this point, but recommended). For more information on using SSL, see [this page](/stifler/3.0/configuration/securing-stifler-operations-with-ssl). ### Optional components **Internet Information Services (IIS):** The StifleR Server API runs its own web service, so IIS is **NOT** required unless: * You will be hosting the [StiflerRulez](#configure-the-stifler-rules-xml) site on the same server. ## Installation From an Elevated Command prompt launch **StifleR.Installer64.msi**. You also can launch installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
*** At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
*** At the "Destination Folder" screen, enter the path to the directory where the StifleR server program files should be installed and then click **Next**.
*** At the "Ready to install..." screen, click **Install** to begin the installation.
*** At the "Completed" screen, the installation wizard is complete. Make sure that checkbox on the bottom left is set to Launch Configuration Editor. Click **Finish** and enjoy a nice cup of tea, you’ve earned it.
*** After you press finish, a new configuration window will pop up. To get started, you will need configure several items: * Groups with full Administrator access to StifleR * Groups with Read access to StifleR * StifleR Server license key * SignalR endpoint certificate thumbprint * Web Service endpoint certificate thumbprint There may be other items to configure, based on your environment. Toggle over to "Show advanced" to see all of those other items. {% hint style="info" %} Note: The Administrators groups are not created automatically. They must be created in advance. Please refer to the [StifleR Administrative Security Groups](broken://pages/6dTpPnF4VVC0AG8h8eb3) section. {% endhint %}
*** {% hint style="info" %} Note: If using a local or domain account, the account must have "Logon as a Service" rights. {% endhint %} *** Aftrer configuring critical settings, please click the Verify button. After verification is complete, press the Save button to save all settings and start the StifleR service. *** ## Post-installation checks ### Checking the StifleR service state Open services.msc to validate that the **2Pint Software Stifler Server** service is installed and running, or run the following PowerShell command and validate that the service is present and running: ``` Get-Service -Name StifleRServer | Select Status ``` ### Checking the StifleR installation directory * If using a licensing file for licensing, check for the **License.nfo** files. If this is missing the service may not be licensed properly. * Open up the configuration file, [**StifleR.Service.exe.config**](broken://pages/nHStlYiqePE9p1g7bKrM), and check that the expected values are present. ### Checking the event logs To validate that the StifleR Server Event Logging structure has been created, execute the following PowerShell command: ``` Get-WinEvent -ListLog TwoPintSoftware-StifleR.Service-* | Where-Object { $_.RecordCount } ``` Validate the following output:
### Checking WMI configuration Execute the following PowerShell command to verify that the WMI Class Root\StifleR and methods were created successfully: ``` Get-CimClass -Namespace Root\StifleR -ClassName StifleREngine | where {$_.CimClassMethods} | Select CimClassName, CimClassMethods ``` Validate the following output:
Execute the following PowerShell command to get the StifleR License information: ``` Get-CimInstance -NameSpace Root\StifleR -ClassName StifleREngine ``` Validate the following output:
### Checking API permissions To test access to the StifleR Server API, open a web browser, and enter the StifleR Server URL such as: ***http(s)://servername:9000/api/test*** The page should display the results of your permissions as in the example below:
### Checking StiflerRules website availability To learn more about this file see: [StifleRulez.xml Configuration Guide](/stifler/3.0/configuration/stiflerulez.xml-2.x-definitions) This file is hosted on GitHub, but you can also host it yourself on the same server that will host the Dashboard. If you'd like to host it in your environment, follow the instructions in the [StifleRulez.xml Configuration Guide](/stifler/3.0/configuration/stiflerulez.xml-2.x-definitions). # StifleR Dashboard installation Prerequisites ## Installation From an Elevated Command prompt launch **StifleR.Dashboard.Installer64.msi**. At the "Welcome" screen, feel welcomed, and then click **Next**.
*** At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
*** At the "Destination Folder" screen, enter the path to the directory where the StifleR dashboard program files should be installed and then click **Next**.
*** At the "Select Operation Mode and Parameters" screen, verify the URLs for the dashboard to connect to the StifleR server and dashboard web service. By default, the port number for the StifleR service is 1414. If during the [StifleR Server installation](/stifler/3.0/setup/installation/stifler-server-installation), a different port was used, modify the URL accordingly. Once complete, click **Next** to continue. {% hint style="info" %} Note: By default, the installation wizard will define the URLs as HTTP-based sites. It is acceptable to install the Dashboard using HTTP for testing, but in production, it is strongly recommended to use HTTPS. To configure the Dashboard to use HTTPS, simply change the URLs to https\://\:\.\ For more information on how to secure IIS for HTTPS, see: [Using a Web Server Certificate](/stifler/3.0/configuration/securing-stifler-operations-with-ssl/using-a-full-iis-certificate). {% endhint %}
*** At the "Ready to install..." screen, click **Install** to begin the installation.
*** At the "Completed" screen, the installation wizard is complete. Click **Finish**.
## Post installation #### Confirm Config File Open notepad elevated, browse to the server.json file located in the C:\Program \ Files\2Pint Software\StifleR Dashboards\Dashboard Files\assets\config folder, and ensure the controller and hub values are set to [https://FQDN:Port](https://documentation.2pintsoftware.com/stifler/3.0/setup/installation/https:/FQDN:Port) as in the examples below (these should already be set properly from the installation): * "controller": "" * "hub": ""
### Installed to non default location If you've installed the dashboard to a non-standard location, IE D:\2Pint\Dashboard, you must update the StifleR config so it knows where to find the dashboard. If you don't, then you'll get some errors trying to pull up the dashboard through port 9000.
### Testing the StifleR Dashboard website Navigate to the StifleR Dashboard website by visiting the URL defined during the setup wizard. By default this would be something like:\ ****
# StifleR ActionHub installation ## Prerequisites * Windows 11 Pro, Enterprise, Education or Windows Server 2016 or newer * .NET Framework: 4.8 (mandatory) ## Installation From an elevated command prompt launch **StifleR.ActionHub.msi**. You also can launch installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the StifleR Dashboard program files should be installed and then click **Next**.
At the "Ready to install..." screen, click **Install**
At the "Completed" screen, the installation wizard is complete. Click **Finish.**
After Installation you will need to do configuration in Config Editor. Enter the StifleR Server URL and the URL for ActionHub. In the example, ActionHub is installed on the same server as StifleR, so we're using the same name, but specifying port 1415 for ActionHub.
## Post Installation After ActionHub is installed, navigate in your StifleR Dashboard to the infrastructure services list. You will find all of your installed ActionHubs and will need to approve them under Actions.
# StifleR Beacon installation For more information about what a Beacon Server is and does, see the [Beacons page](/stifler/3.0/operations-and-features/features-overview/beacons). ## Prerequisites * Windows 11 Pro, Enterprise, Education or Windows Server 2016 or newer * Microsoft .NET 4.8 * By default, the Beacon service listens on TCP port 5201 so this port should be open * Installation account must have Administrator rights ## Installation From an elevated command prompt launch **StifleR.Service.Beacon.Installer64.msi**. At the "Welcome" screen, feel welcomed, and then click **Next**.
*** At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
*** At the "Destination Folder" screen, enter the path to the directory where the StifleR Beacon server program files will be installed and then click **Next**.
*** At the "Ready to install..." screen, click **Install** to begin the installation.
*** At the "Completed" screen, the installation wizard is complete. Click **Finish** and enjoy a nice cup of kombucha, you’ve earned it.
*** After installation you will need to enter the URL for the StifleR Server in the configuration editor.
## Validation After a Beacon Server is installed, it should attempt to report in to the StifleR Server. This can be validated in the StifleR Dashboard, under **Administration, Infrastructure services**. Once there, click on the 3 dots in the Beacon Service row, then "Approve"
Prior to a Beacon being used, you must complete the configuration by following the instructions on this page: [Configuring a Beacon Server](/stifler/3.0/configuration/configuring-a-beacon-server). # StifleR Client installation ## Prerequisites * Windows 10 or later * Windows Server 2016 or later * Supported are x86 or x64 versions of the operating systems (x86 for Windows 10 only) * Professional, Enterprise, Education, or LTSC editions for client operating systems * Microsoft .NET 4.8 must be installed ## **Installation** ### **Manual installation** From an elevated command prompt launch **StifleR-ClientApp.msi**. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the StifleR Client program files will be installed and then click **Next**.
At the "Ready to install..." screen, click **Install** to begin the installation.
At the "Completed" screen, the installation wizard is complete. Click **Finish** and enjoy a nice glass of craft beer, you’ve earned it.
After finishing installation, the configuration tool will open. Enter the URLs and settings.
StifleR Rules URL needs to be updated for something you host internally, or one hosted on GitHub:\ Set the StifleR Server URL(s) to your StifleR Server with Port 1414. Then configure rest of the Client settings how you'd like for your environment {% hint style="info" %} There is no shortcut in the Start Menu for the StifleR Client Configuration App. It can be launched directly from its install location: \*installation path\*\2Pint Software\StifleR Client\TwoPint.ConfigEditor.Wpf\TwoPint.ConfigEditor.Wpf.exe {% endhint %} ### Unattended installation With StifleR there is an option to install StifleR Client unattended. To take advantage of this option you will need to install one client using the manual approach. After completion, you will be able to export the settings that you have configured into a .2psimport file. To export the file – which you can then use to import for unattended installations – launch the Client Configuration Editor located here: C:\Program Files\2Pint Software\StifleR Client\TwoPint.ConfigEditor.Wpf\TwoPint.ConfigEditor.Wpf.exe Once the editor is open, customize the settings for the environment then go to Export -> Create 2PS import file for MSI only, and save it with a filename such as: settings.2psImport.
This file will contain the required settings in custom JSON format, where any string value containing " " (space) is replaced with "%20", and final output is stripped of all " " (space); here is an example: {% hint style="info" %} You will need to open this file with a text editor to view the contents {% endhint %} ``` {"SettingsOptions":{"StifleRulezURL":"https://stifler.company.com/StifleRulez.xml%20","LogEventLevel":"Verbose","StiflerServers":"[\u0022http://stifler.company.com:1414\u0022]","UseServerAsClient":"True","SignalRLogging":"True"}} ``` In order to use this configuration together with an MSI installer, you will need to add the **OPTIONS=** parameter ``` msiexec /qn /l*v "log.log" /i StifleR-ClientApp-x64.msi OPTIONS={"SettingsOptions":{"StifleRulezURL":"https://stifler.company.com/StifleRulez.xml%20","LogEventLevel":"Verbose","StiflerServers":"[\u0022http://stifler.company.com:1414\u0022]","UseServerAsClient":"True","SignalRLogging":"True"}} ``` Alternatively, if you add the 2psimport file into your source content, you can call it directly as in this example:
``` msiexec /i StifleR-ClientApp-x64.msi AUTOSTART=1 OPTIONS="settings.2psImport" /quiet /l*v "C:\Windows\Temp\StifleRClientInstall.log" ``` Note for **ConfigMgr** environments, we recommend creating a install.cmd, so you can set the realtive path with the %\~dp0 syntax, the install string would be: ``` msiexec /i StifleR-ClientApp-x64.msi AUTOSTART=1 OPTIONS="%~dp0settings.2psImport" /quiet /l*v "C:\Windows\Temp\StifleR3.0ClientInstall.log" ```
Then in **ConfigMgr**, your install command would be install.cmd
When installed manually, once complete the installer will launch the Configuration Editor. After the settings have been confirmed, the Configuration Editor will set the service to "Automatic Startup" and then start it. In unattended mode, to start the service when completed, pass the parameter **AUTOSTART=1** to MSI. Note that this parameter will only be used in unattended/quiet or basic mode, and project has *Config Editor* support. ``` msiexec /quiet /l*v "StifleRClientInstall.log" /i StifleR-ClientApp-x64.msi AUTOSTART=1 OPTIONS={"SettingsOptions":{"StifleRulezURL":"https://stifler.company.com/StifleRulez.xml%20","LogEventLevel":"Verbose","StiflerServers":"[\u0022http://stifler.company.com:1414\u0022]","UseServerAsClient":"True","SignalRLogging":"True"}} ``` {% hint style="info" %} Replace stifler.company.com with the name of your StifleR server. {% endhint %} ## Post installation ### Service status Open services.msc to validate that the **2Pint Software Stifler Client** service is installed and running. Alternatively, run the following PowerShell command and validate that the service is present and running: ``` Get-Service -Name StifleRClient | Select Status ``` Validate the following output:
### Event logging To validate that the StifleR Server event logging structure has been created, execute the following PowerShell command: ``` Get-WinEvent -ListLog TwoPintSoftware-StifleR.ClientApp* | Where-Object { $_.RecordCount } ``` Validate the following output:
# StifleR WMI Agent installation If you’d like to request a trial and explore our product, please visit [this](https://2pintsoftware.com/products/stifler#download) page. Existing customers should use the link provided by our team to proceed. ## Prerequisites * Windows 11 Pro, Enterprise, Education or Windows Server 2016 or newer * .NET Framework: 4.8 (mandatory) ## Installation From an elevated command prompt launch **StifleR.WMIAgent.msi**. You can also launch the installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the StifleR WMI Agent program files will be installed and then click **Next**.
At the "Ready to install" screen, click **Install** to begin the installation.
At the "Completed" screen, the installation wizard is complete. Click **Finish**.
After installation you will need to enter the URL(s) for your StifleR Server in the configuration settings editor.
# CacheR installation CacheR lets you take your content distribution efficiency to the next level. Building on the long-established best practices of StifleR, with CacheR you can now have full visibility of ‘content at rest’ (in the local cache) of your endpoints as well as the real-time content download dashboards provided. For optimal peering performance and bandwidth saving it is critical to know and control where content is cached. CacheR allows you to not only visualize where business-critical applications have been cached, but also to automate further pre-caching where needed. Pre-caching content closer to your end users ensures that critical content such as operating systems and large applications can be installed quickly and with minimal network impact. This leads to a much-improved end user experience. ## Prerequisites * Working Stifler Setup with version 3.0 or newer * Windows Server (2Pint used Windows Server Standard 2022) * MS SQL (Express works for lab but not recommended for production) * SQL Management Studio * Webserver certificate ### Create SQL database and tables manually (optional) {% hint style="info" %} As long as the account running the service has access to SQL and is allowed to create databases and tables it will be automatically created and this can be skipped. If not it needs to be created using the following process. {% endhint %} {% hint style="warning" %} If you let the service create the database make sure that the account connecting with SQL Mgmt Studio is sysadm on the SQL service so the database can be accessed. {% endhint %} On the server, open SQL Management Studio (install if needed) and create a new Database called CacheR.\ If on a remote server, make sure to apply the correct security rights for the services. (Computer account if running as local system, or the service account used for the services) ## Installation ### Install WebApi service {% hint style="info" %} WebAPI service is the service the clients use to report the local status of cache content and what the StifleR dashboard is using when communicating with CacheR. {% endhint %} From an Elevated Command prompt launch **TwoPint.CacheR.WebApi.Installer64.msi**. You also can launch installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the CacheR WebApi program files should be installed and then click **Next**.
At the "Ready to install..." screen, click **Install** to begin the installation.
At the "Completed" screen, the installation wizard is complete. Make sure that checkbox on the bottom left is set to Launch Configuration Editor. Click **Finish** and enjoy a nice cup of tea, you’ve earned it.
### Configure CacheR WebAPI Service Use the **Configuration Editor** to complete the initial CacheR setup. All required fields must be populated before the service can be verified and started. * **Enable HTTPS** (recommended) to secure communication between CacheR, clients, and upstream services. HTTPS is strongly recommended for production environments. * In **HostCertificateThumbPrint**, enter the thumbprint of the SSL certificate bound to the CacheR service.The certificate must be present in the local computer certificate store and include the appropriate DNS name. * **Provide the SQL connection string** used by CacheR WebAPI to store operational data. Example: ``` Server=.\SQLEXPRESS;Database=CacheR;Trusted_Connection=True;MultipleActiveResultSets=true;TrustServerCertificate=True ``` * **Define the StifleR Server URL** that CacheR will register with and report to.\ Example: ``` https://dp01.corp.mblab.org:9000/ ``` * Click **Verify** to validate all settings. Once verification completes successfully, click **Save** to apply the configuration. * After saving, a confirmation dialog will appear indicating that the configuration was saved successfully. You will be prompted to set the **CacheRWebAPI** service startup type to **Automatic** and start the service. Select **Yes** to apply the startup configuration and start the service immediately.
### Install Worker Service {% hint style="info" %} The CacheR Worker service is responsible for connecting to content sources and calculating content hashes. It also generates the ZIP files that are used by clients when reporting content status to the CacheR Web API. These ZIP files are downloaded by the clients directly from the Web API as part of the reporting process. {% endhint %} From an Elevated Command prompt launch **TwoPint.CacheR.Worker.Installer64.msi**. You also can launch installation as it is – the installer will ask for elevation when needed. At the "Welcome" screen, feel welcomed, and then click **Next**.
At the "End-User License Agreement" screen, once you have reviewed the EULA, check the box: \ **I accept the terms in the License Agreement**, and then click **Next**.
At the "Destination Folder" screen, enter the path to the directory where the CacheR Worker service program files should be installed and then click **Next**.
At the "Ready to install..." screen, click **Install** to begin the installation.
At the "Completed" screen, the installation wizard is complete. Make sure that checkbox on the bottom left is set to Launch Configuration Editor. Click **Finish** and enjoy a nice cup of tea, you’ve earned it.
#### Configure CacheR Worker service * Enter the **Domain** where the service account resides. * In **UserName**, specify the service account used by the CacheR Worker service.\ This account is used to access Distribution Point IIS shares and calculate content hashes. * Provide the **Password** for the specified service account. * **Provide the SQL connection string** used by CacheR WebAPI to store operational data. Example: ``` Server=.\SQLEXPRESS;Database=CacheR;Trusted_Connection=True;MultipleActiveResultSets=true;TrustServerCertificate=True ``` * Click **Verify** to validate all settings. Once verification completes successfully, click **Save** to apply the configuration. * After saving, a confirmation dialog will appear indicating that the configuration was saved successfully. You will be prompted to set the **CacheRWebAPI** service startup type to **Automatic** and start the service. Select **Yes** to apply the startup configuration and start the service immediately.
### Configure Stifler to enable CacheR To enable CacheR functionality, start the **StifleR Service Config Editor** on the machine where it is installed. Enable **Show Advanced**, search for **CacheR**, and then enable **Show CacheR features**. **Verify and Save the configuration** and restart the StifleR service if prompted to ensure the changes take effect.
Once CacheR features are enabled, open the **StifleR Dashboard** and navigate to **Infrastructure Services**. The CacheR server will appear in the list and must be approved before it can be used by StifleR.
After approval, select the CacheR server and set it as the **Default** CacheR instance. If multiple CacheR servers exist in the environment, only one can be configured as the default at any given time.
When the CacheR server is approved and set as default, additional CacheR related sections will become available in the **StifleR Dashboard**, confirming that CacheR is enabled and ready for configuration and operation.
Additional guidance on operating CacheR is available in the CacheR [documentation](/stifler/3.0/operations-and-features/cacher-operations) section. # Testing and validation ## Objectives The objective for the testing and validation phase of a PoC can be summarized as: * Manage and control traffic across all networks (subnets/locations) to distribute software efficiently, reduce bandwidth usage, and avoid large server infrastructure – without impacting business operations * Verify that peer-to-peer traffic functions correctly and offloads the network as intended, including proper integration with BITS/BranchCache, Delivery Optimization, and LEDBAT. * Gain real-time visibility into network traffic to identify bottlenecks and ensure software distribution is controlled and reconfigurable. ### Lab testing To complete a StifleR PoC in a lab environment, requirements vary based on whether Intune and/or Configuration Manager is used: {% tabs %} {% tab title="Intune" %} * A functioning Intune instance with several applications that can be used for testing purposes. Ideally no less than 500 MB in size (1 GB recommended). * Choose 2-3 subnets with 3 or more client PCs each that are registered with Intune: * Ideally two of the subnets should be in the same location with good connectivity to one another. * It is recommended that some clients should reside on a subnet that has slower connectivity to an Internet gateway. {% endtab %} {% tab title="Configuration Manager" %} * Microsoft Configuration Manager Primary Site server: * This server will provide all of the CM Roles such as a Management Point, Distribution Point, etc. on a single server. * Configure 2-3 subnets with 3 or more client PCs each that are Configuration Manager clients. * Ideally two of the subnets should be in the same location which have good connectivity with one another. * It is recommended that some clients should reside on a subnet which has slower connectivity to a distribution point. In a lab environment, this can be achieved by installing a virtual appliance such as a pfSense router, which supports bandwidth limiting. * Choose several applications that can be used for testing purposes. Ideally no less than 500 MB in size (1 GB recommended). {% endtab %} {% endtabs %} ### Production environment testing To complete a StifleR PoC in a production environment, requirements vary based on whether Intune and/or Configuration Manager is used:: {% tabs %} {% tab title="Intune" %} * A functioning Intune instance with several applications that can be used for testing purposes. Ideally no less than 500 MB in size (1 GB recommended). * Choose 2-3 subnets with 3 or more client PCs each that are registered with Intune: * Ideally two of the subnets should be in the same location with good connectivity to one another. * It is recommended that some clients should reside on a subnet that has slower connectivity to an Internet gateway. {% endtab %} {% tab title="Configuration Manager" %} * Choose 2–3 subnets with 3 or more client PCs each that are Configuration Manager clients. * Ideally two of the subnets should be in the same location with good connectivity to one another. * It is recommended that some clients should reside on a subnet that has slower connectivity to a distribution point. * Choose several applications that can be used for testing purposes. Ideally no less than 500 MB in size (1 GB recommended). {% endtab %} {% endtabs %} ## StifleR Server ### Implementing bandwidth-limiting server components | Name | Description | Requirement / Benefit | | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | Limits the number of concurrent downloads to a certain subnet (location) | Maximizes the efficiency of built-in Microsoft peer-to-peer tech. Ensures a single download of content per location. Further leverages Microsoft Data Deduplication to reduce data transferred | Limit content transfers to the absolute minimum required | | Limits the download speed to a fixed set of Kb/s per location | Ensures that business bandwidth is protected by allocating a set amount of bandwidth to content download traffic | Protect business bandwidth usage at all locations | | Slow down, increase, pause, restart or kill all BITS download jobs | At busy times, or during emergencies – provides complete and instant control over all in-flight transfers | Flexible, reactive ability to control all content transfers | ### Manage Microsoft peer-to-peer technologies: Background Intelligent Transfer Service (BITS) and Delivery Optimization (DO) | Name | Description | Requirement / Benefit | | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Single Site Download | Enhances Microsoft BranchCache to enable multi-subnet/multi-VLAN transfers | Limit content transfers to the absolute minimum required | | Windows Store (WSfB) | Manage Windows Store and/or Windows Store For Business Downloads | Manage Delivery Optimization transfers regardless of source – while maintaining bandwidth limits | | Microsoft Intune | Manage content downloads from Intune | Limit content transfers to the absolute minimum required | | Windows Update / WUfB | Manage content downloads from Windows Update / Windows Update for Business | Limit content transfers to the absolute minimum required | | Integrate with and manage new Microsoft bandwidth management technologies | Microsoft is implementing LEDBAT and CUBIC congestion control methods within Windows to facilitate bandwidth management within the operating system | Use built-in technologies at no further cost where possible | ### Reporting and visualization | Name | Description | Requirement / Benefit | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Real-time visibility | Dashboards provide real-time tracking of all the above content transfers. Provide efficiency stats and highlight any issues | Single location to track and manage all types of downloads | | Long-term trend analysis | Recording all data to a DB for analysis/data visualization/reporting/trending (optional) | Long-term tracking of data transfers – can reduce cloud storage/egress costs | | Scripting Interface | Allow for customizations using an API or interface to automate items. | Complex scenarios | | Deduplicated cache management | Store a copy of Windows Enterprise N media as well as Windows Enterprise media with minimum additional storage footprint | Reduced cache footprint | | Pre-caching | Pre-cache content for future deployments | Build and/or deploy faster | ### Network Requirements
NameUse caseBenefit
Network topologyAbility to dynamically build the network topologyThe systems management team can see the full network dynamically without interaction with the network group
VLANsNetwork teams add VLANs without notifying the endpoint management team resulting in inefficient content distribution causing outagesAuto-generation of networks
Auto network group creationAutomatically create a new subnet / office location which may be unknownThe ability to create auto network groups within the dedicated tooling and not rely on external infrastructure or manual creation​
## StifleR Dashboard To view the activities of the StifleR Clients, open the StifleR Dashboard on the StifleR Server by visiting the dashboard URL: There won’t be much in the way of traffic data yet, but you should be able to see the clients that were added in the previous steps. Drill down the [Clients](/stifler/3.0/operations-and-features/overview-and-navigation/devices/clients) section of the dashboard to see the clients that have checked in. Confirm that the clients have connected to the dashboard before proceeding. ### Deploy an application or Intune App to a single client PC and monitor the download In this step you will deploy and monitor, in real time, a deployment to a single client: * Target a single client system only with the required deployment created in the previous step. You can use an ‘As soon as possible’ deployment schedule. * On the targeted test client perform a Client Policy Refresh to speed up the deployment. * Review the content transfer in the StifleR Dashboard. ### Deploy the same application or Intune App to peers In this step you will deploy and monitor a deployment to peers: * Target two or more clients on the same subnet with the same application or Intune App deployment. * Target other clients on a separate subnet with the same application or Intune App deployment. * Review the content transfers in the StifleR Dashboard. # Ping Identity integration StifleR integrates with Ping Identity using OpenID Connect (OIDC) to provide centralized authentication and authorization based on identity groups. This approach allows organizations to control access to the StifleR Dashboard and its features without managing local users, aligning StifleR with modern identity and Zero Trust practices. At a high level, Ping Identity is responsible for authenticating users and issuing identity tokens, while StifleR consumes group information from those tokens to determine what a user is allowed to see and do. ## **Global access control via pingIdentity groups** StifleR supports global access control by mapping Ping Identity groups directly to predefined access levels. During authentication, the user’s group membership is included in the OIDC token and evaluated by StifleR. Typical usage includes: * A read-only group that grants visibility across the StifleR Dashboard without allowing changes. * An administrative group that provides full access to view, modify, and manage StifleR configuration and data. These groups are defined in Ping Identity and referenced in the StifleR Service Config Editor, ensuring that access is enforced consistently for all users logging in through Ping Identity. ## **Centralized and auditable access management** By using Ping Identity as the authentication provider, all user access to StifleR is centrally managed and auditable. User lifecycle actions such as onboarding, role changes, or removal of access are handled entirely in Ping Identity, with no need to modify StifleR directly. This model reduces administrative overhead, improves security posture, and ensures that StifleR access always reflects the organization’s identity governance policies. *** ## Configuration ### Create Groups in PingIdentity Log in to the PingIdentity admin console and navigate to **Groups**.
Create the following groups using the **Default** population: * **DefaultStifleRRead** – global read-only access to the StifleR Dashboard * **DefaultStifleRAdmins** – full administrative access
### Configure Attribute Mappings Open the applications and create application of OIDC type.
Attributes must be mapped so that tokens include user information (e.g., groups). Navigate to **Attribute Mappings**.
Edit the mappings and add a new global attribute: * **Name**: groups * **PingOne Mapping**: Group Names Save the changes.
Verify that the attribute is included in the "openid" scope.
### Configure Resources and Scopes Open the **Resources** tab and select **Edit**.
Enable the following scopes: * profile (required) * phone, address, email (optional) Save the configuration.
Navigate to **Resources → OpenID Connect → Attributes → Edit** and map: * Username → name * Username → preferred\_username Save the changes.
### Configure Application Settings Go to **Applications → \[Your Application] → Configuration → Edit**. Configure: * **Response Types**: Authorization Code, Access Token, ID Token * **Grant Types**: Authorization Code, Implicit * **Redirect URI**: Full StifleR backend URL (including port) * **Sign-off URL**: Same as Redirect URI Save the configuration.
#### Activate the Application Set the application state to **Active**.
### Configure StifleR for PingIdentity #### Collect Application Values From the PingIdentity application configuration, note the following values for use in StifleR: * AuthAuthority **→** Issuer URL e.g.: (must include trailing slash) * AuthClientId **→** Client ID (GUID) * AuthRedirectUri **→** Same as configured * Dashboard URL **→** https\://\[Full StifleR URL]/# #### StifleR Service Config Editor Run the **StifleR Service Config Editor** and open **Access Settings**. Configure: * Authentication Method: oidc * OIDC Provider: PingIdentity * OIDC Claim Type: groups * OIDC Groups with StifleR Global Admin Access: DefaultStifleRAdmins * OIDC Groups with Stifler Global Read Access: DefaultStifleRRead * OIDC Issuer URL: * OIDC Redirect URL: https\:///api/Account/Callback * OIDC Dashboard URL: Full URL to StifleR Dashboard Save the configuration.
#### Configure Dashboard Authentication On the StifleR Dashboard server, update config.json: * authprovider = 2 (PingIdentity) Save the file.
### Configure RBAC with PingIdentity #### PingIdentity Group for RBAC Create an additional PingIdentity group for RBAC use.
Add users to the group.
#### Create Claim Rule in StifleR In the StifleR Dashboard, go to **Administration → Security → Rules → New Rule**. Configure: * Type: Claim * Claim Type: External * Claim Name: groups * Claim ID: PingIdentity group name
#### Create and Assign Role Go to **Administration → Security → Roles → New Role**. Configure the role name, access area, and allowed operations. Save the role.
Expand the newly created Role add click Add Rule
#### Validate Permissions Log in with a user who belongs to the PingIdentity group. Open the user menu in the top-right corner and verify assigned roles.
# Entra ID integration StifleR can use **Microsoft Entra ID** as its identity provider to authenticate users and determine access to the StifleR Dashboard. Authentication is performed using **OpenID Connect (OIDC)**, while authorization decisions are based on Entra ID security group membership. This integration removes the need for local user management in StifleR and allows access to be governed entirely by Entra ID, using the same identities, groups, and policies already in place across the organization. When a user signs in, Entra ID validates the identity and issues an OIDC token that includes group information. StifleR consumes this information and applies access rules accordingly, ensuring that users only see and manage what they are permitted to. ## Group-Based Access Model Access to StifleR is controlled by mapping Entra ID security groups to StifleR access levels. Common patterns include: * A **read-only group** that allows users to view all Dashboard data without making changes. * An **administrative group** that grants full control over configuration, monitoring, and management features. These groups are defined and maintained in Entra ID and referenced in the StifleR Service Config Editor. This ensures that access rules are applied consistently for all users authenticating through Entra ID. ## Centralized Governance and Compliance Using Microsoft Entra ID as the authentication authority centralizes identity governance for StifleR. All access changes - such as adding users, modifying permissions, or revoking access - are performed in Entra ID and immediately reflected in StifleR at the next login. This approach simplifies administration, improves auditability, and ensures that StifleR access aligns with organizational security, compliance, and Zero Trust requirements. ## Configuration ### Create Entra ID Groups Log in to the **Microsoft Azure Portal**, open **Microsoft Entra ID**, and navigate to **Groups**.
Create the following security groups: * **DefaultStifleRRead** – global read-only access to all StifleR pages * **DefaultStifleRAdmins** – full administrative access Groups must be created as **Security** type.
Add users to each group by opening the group, selecting **Members**, and clicking **Add members**.
*** ### Register the Application Navigate to **App registrations** and either select an existing application or create a new one for StifleR.
*** ### Configure Authentication Open the application and go to **Authentication (Preview)**, then select **Add Redirect URI**.
Choose **Web** as the platform type.
Configure the **Redirect URI** to point to the StifleR Service callback endpoint: https\://\[YourDomain]:9000/api/Account/Callback
*** ### Configure Token Claims Open **Token configuration**.
Add a **Groups claim** and select **Security groups** so that group membership is included in the OIDC token.
*** ### Configure StifleR Service Open **StifleR Service Config Editor** and update the access settings. Set **Authentication Method** to oidc and configure the following: * **"OIDC Provider name"** - Name representing the external OIDC Provider * **"OIDC Claim type"** - String value of External OIDC provider custom application attribute. For EntraID should be "groups", for PingIdentity based on attribute name defined by admin * **"OIDC Groups with StifleR Global Admin Access"** - External OIDC provider security groups that have full admin rights to StifleR. (Define group ID (GUID) instead of name) * **"OIDC Groups with StifleR Global Read Access"** - External OIDC provider security groups have read access to StifleR global data, all locations and all items. (Define group ID (GUID) instead of name) * "**OIDC Issuer URL"**: Ping Identity: should be in format '[https://auth.pingone.eu/\[EnvironmentID\]/as/](https://auth.pingone.eu/%5BEnvironmentID%5D/as/) ' ending with a slash. Entra ID: Should be in format '[https://login.microsoftonline.com/\[TenantID\]/v2.0](https://login.microsoftonline.com/%5BTenantID%5D/v2.0) ' * **"OIDC Client Identifier"** - The unique identifier assigned to your application by the OpenID Connect provider. * **"OIDC Redirect URL"** - The URL in your application where the OpenID Connect provider will send the user after completing authentication. This must match one of the redirect URIs registered with your identity provider.It should be in format https\://\[YourDomain]:9000/api/Account/Callback. * **"OIDC Dashboard URL"** - Full URL to StifleR Dashboard. Should be in format https\://\[YourDomain]/StiflerDashboard/#. * **"OIDC Authentication ticket expiration (minutes)"** - Expiration time in minutes for OpenID Connect authentication ticket. Verify and Save the configuration.
# Remote tools configuration Remote Tools in StifleR provide secure, real-time access to endpoint diagnostics and troubleshooting capabilities directly from the StifleR Dashboard. These tools allow administrators and support teams to inspect and interact with managed devices without requiring direct network access or separate remote access solutions. Available features include file and registry exploration, WMI and event log viewing, log file access (by default we are monitoring Intune and SCCM logs, but you can configure it based on your own needs and preferences), performance counters, resource monitoring, task management, detailed device information, command-line access via CMD and PowerShell, as well as remote assistance and RDP tunneling and much more. Together, these tools enable efficient troubleshooting, monitoring, and support while maintaining centralized control and visibility. *** {% hint style="info" %} Before configuring Remote Tools, ensure that ActionHub is [installed](/stifler/3.0/setup/installation/stifler-actionhub-installation) and available. \ ActionHub is required to enable remote connectivity and functionality for all Remote Tools features. {% endhint %} ## Action hub assignment We provide three options on how to assign action hub so it can be elected for the clients, below we will describe all of three options. ### Area assignment * Navigate to your areas in StifleR dashboard under Networks * Open infrastructure services tab * Press on add relation button * Select your action hub and press OK
### Network group assignment * Navigate to your network groups in StifleR dashboard under Networks * Edit network group where you want to have active Action hub * This will lead you to new page, scroll down until you will see Infrastructure services tab * Open infrastructure services tab * Press on add relation button * Select your action hub and press OK
### Making ActionHub default * Navigate to your Infrastructure services in StifleR dashboard under Administration * Open ActionHub tab (or find your ActionHub in the list) * Press on three dots under actions * Mark ActionHub as default
## Granting permissions ### Rules creation Based on account group where you want to grant permissions for remote tools you can edit and create specific set of permissions. Initially you will need to create a set of rules based on access level. * Navigate to rules in StifleR dashboard under security * Press on new rule button * Fill all the needed information * Press on Create
### Role Creation Based on role specific group members will do have access to specific features of remote tools. * Navigate to roles in StifleR dashboard under security * Press on new rule button * Fill all the needed information and select needed features access * Press on Create
### Assigning rules to roles * Navigate to roles in StifleR dashboard under security * Press on arrow button on preffered role * Press on add rule button * Select preffered rule * Press on Update
## Enabling remote tools By security reasons remote tools are disabled by default, in order to enable them you will need to configure StifleR client configuration and StifleR server configuration. ### Client side configuration * Open StifleR client configuration on client side * \*installation path\*\2Pint Software\StifleR Client\TwoPint.ConfigEditor.Wpf\TwoPint.ConfigEditor.Wpf.exe * Enable advanced options * Navigate to Remote tools specific settings * Enable features based on your preference * Press on verify and save
### Server side configuration * Open StifleR server configuration on client side * \*installation path\*\2Pint Software\StifleR Server\TwoPint.ConfigEditor.WpfTwoPint.ConfigEditor.Wpf.exe * Enable advanced options * Navigate to dashboard settings * Enable show RemoteR features * Press on verify and save
# Windows Server BranchCache Configuration ## Enabling BranchCache on ConfigMgr Distribution Points BranchCache is a Windows feature that enables peer-to-peer content sharing between clients on the same network. When used with Microsoft Configuration Manager (ConfigMgr), BranchCache allows clients to download content from a local peer instead of repeatedly downloading the same content from a remote distribution point (DP). This can significantly reduce WAN bandwidth consumption and improve deployment performance. For BranchCache to function correctly with Configuration Manager, it must be enabled both in **Windows Server** and in the **Configuration Manager distribution point configuration**. In the Configuration Manager console, open the **Administration** workspace and expand **Site Configuration** and select **Servers and Site System Roles**. Select which distribution points you want to enable and open the distribution point **Properties**. Under the "General" tab, choose the option: Enable and configure BranchCache for this distribution point. To allow clients to retrieve BranchCache content from a distribution point, BranchCache must be enabled in the Configuration Manager console. #### Steps 1. Open the **Configuration Manager Console**. 2. Navigate to: Administration → Site Configuration → Servers and Site System Roles 3. Select the server hosting the **Distribution Point** role. 4. Open the **Distribution Point Properties**. 5. On the **General** tab, enable:
Once this option is enabled, Configuration Manager will automatically install the **BranchCache Windows feature** on the distribution point if it is not already installed. ### Enable BranchCache on a Distribution Point Using PowerShell BranchCache can also be enabled through PowerShell when connected to the Configuration Manager environment. {% hint style="info" %} Replace \ with the fully qualified domain name of the distribution point. {% endhint %} ```powershell Set-CMDistributionPoint -EnableBranchCache $true -SiteSystemServerName ``` {% hint style="info" %} If you are using more than one DP, the BranchCache 'Server Secret' is the same on each of them. The 'Server Secret' is stored in the registry: HKLM:\Software\Microsoft\Windows NT\CurrentVersion\PeerDist\SecurityManager\Restricted Value: Seed If you have configured BranchCache functionality using the ConfigMgr UI then the same server secret will be automatically seeded across DPs. {% endhint %} ## Enabling BranchCache in Windows Server BranchCache can also be installed directly in Windows Server using either the graphical interface or PowerShell. ### Using Windows Server Manager 1. Open **Server Manager**. 2. Navigate to **Add Roles and Features**. 3. Select the **BranchCache** feature and install it. ### Using PowerShell ```powershell Install-WindowsFeature -Name BranchCache ``` ## Verify BranchCache Installation You can verify that BranchCache is installed on the distribution point by running the following PowerShell command: ```powershell Get-WindowsFeature | ? name -eq BranchCache ``` If the feature is installed, it will appear in the list with the status **Installed**. ## Modifying the BranchCache Cache Location On a distribution point, you may want to move the BranchCache cache folder to a different disk for performance or capacity reasons. Example: Move the cache to `D:\BranchCache\LocalCache` 1. Create the target directory. 2. Run the following command: ``` netsh br set localcache directory=D:\BranchCache\Localcache ``` ## Modifying the BranchCache Cache Size You can configure the size of the BranchCache cache using the following command: ``` netsh br set cachesize ``` Usage: ``` set cachesize [size=]{DEFAULT|} [[percent=]{TRUE|FALSE}] ``` Examples: ``` set cachesize DEFAULT set cachesize 20971520 set cachesize size=20 percent=TRUE ``` ## Data Deduplication and BranchCache Data Deduplication is a Windows Server feature that reduces storage consumption by identifying and eliminating duplicate blocks of data. When used together with BranchCache, Data Deduplication provides an additional performance advantage. Both technologies use the same hashing algorithm. When Data Deduplication is enabled on a distribution point, the deduplication engine calculates content hashes during its scheduled optimization process. These hashes can then be reused by BranchCache when serving content to clients. This provides two important benefits: * Reduces CPU load on the distribution point during content requests * Avoids potential time-out issues caused by on-demand hash calculations Additionally, Data Deduplication reduces storage usage and network traffic by minimizing redundant data blocks. For these reasons, **2Pint Software strongly recommends enabling Data Deduplication on distribution points used with BranchCache.** ## Enabling Data Deduplication on a Distribution Point The following PowerShell script enables Data Deduplication on a distribution point volume. {% hint style="info" %} Update the `$dedupVolume` variable to match the drive letter used for Configuration Manager content. {% endhint %} ```powershell #Set the drive letter $dedupVolume = "E:" Import-Module ServerManager Add-WindowsFeature -Name FS-Data-Deduplication #Enable Deduplication on the volume Enable-DedupVolume $dedupVolume Set-DedupVolume -Volume $dedupVolume -MinimumFileAgeDays 0 -ExcludeFolder $dedupVolume\SMSPKG, $dedupVolume\SMSPKGSIG, $dedupVolume\SMSSIG$ Write-Output "Starting Dedup Jobs..." $j = Start-DedupJob -Type Optimization -Memory 75 -Priority High -Volume $dedupVolume $j = Start-DedupJob -Type GarbageCollection -Full -Memory 75 -Priority High -Volume $dedupVolume $j = Start-DedupJob -Type Scrubbing -Full -Memory 75 -Priority High -Volume $dedupVolume do { Write-Output "Dedup jobs running. Status:" $state = Get-DedupJob | Sort-Object StartTime -Descending $state | ft if ($state -eq $null) {Write-Output "Completing, please wait..."} sleep -s 5 } while ($state -ne $null) Write-Output "Done DeDuping" Get-DedupStatus | fl * ``` # Delivery optimization configuration Starting with Windows 10, Microsoft introduced [**Delivery Optimization (DO)**](https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization) as a built-in Windows component used to download content from Microsoft services, peers on the local network, or caching servers. Delivery Optimization is commonly used for distributing Windows Updates, Microsoft Store content, and other cloud-delivered packages. Microsoft provides administrators with several methods to manage Delivery Optimization configuration on client devices, including: * **Group Policy** (via Active Directory) * **Microsoft Intune policies** * **Client Settings in Configuration Manager** When StifleR is used to manage content downloads, it is important to ensure that existing Delivery Optimization configuration settings do not conflict with the configuration applied by StifleR. ## How StifleR Manages Delivery Optimization StifleR manages Delivery Optimization settings through the use of [**Templates**](/stifler/3.0/operations-and-features/features-overview/templates). Templates are applied to **Network Groups**, and each Network Group can contain one or more **subnets**. These Network Groups effectively function as **peering boundaries**, allowing StifleR to control how clients share content within a defined network scope. Delivery Optimization itself uses a similar concept called **DO Groups**, which define the scope of peer-to-peer sharing between devices. StifleR templates can automatically configure DO Groups based on the defined Network Groups, ensuring that clients only peer with other devices within the same logical network. Through Templates, StifleR can centrally define Delivery Optimization settings and enforce consistent configuration across clients in the same Network Group. For detailed information about which Delivery Optimization settings can be managed by StifleR, refer to the corresponding configuration reference [table](/stifler/3.0/operations-and-features/overview-and-navigation/devices/stifler-server/templates-detail#delivery-optimization). ## Group Policy considerations Microsoft allows Delivery Optimization settings to be configured using **Group Policy** through Active Directory or **device configuration policies in Intune**. If Delivery Optimization settings are already managed through Group Policy or Intune, they may override or conflict with the settings applied by the StifleR client. This can prevent StifleR from properly managing Delivery Optimization behavior. For this reason, it is recommended to review existing Delivery Optimization policies and remove or disable any settings that may conflict with StifleR’s configuration. Refer to the Delivery Optimization configuration reference [table](/stifler/3.0/operations-and-features/overview-and-navigation/devices/stifler-server/templates-detail#delivery-optimization) to identify which settings are controlled by StifleR. ## Configuration Manager considerations In Configuration Manager environments, Delivery Optimization can also be influenced by Configuration Manager client settings. StifleR manages Delivery Optimization peering groups based on how **Network Groups** are defined within StifleR. To avoid conflicts, Configuration Manager should not automatically assign Delivery Optimization group identifiers. When implementing StifleR in a Configuration Manager environment, ensure the following client setting is **disabled**:
Disabling this setting allows StifleR to fully control the Delivery Optimization group configuration based on its Network Group structure. # Configuring a Beacon Server Prior to configuration, a Beacon server must be installed in your environment. See [StifleR Beacon installation](/stifler/3.0/setup/installation/stifler-beacon-installation) for more information. Once you have validated that the Beacon server is displayed on the Beacons page you can move forward with configuration.
## Adding a Beacon server to a template For a StifleR Client to be made aware of a Beacon server, it must be added to a [Template](/stifler/3.0/operations-and-features/features-overview/templates) which applies to a [Network Group](/stifler/3.0/operations-and-features/overview-and-navigation/network-topology/network-groups) that clients are within. To add a Beacon server to a template, in the StifleR Dashboard, under **Devices** – **StifleR server**, select **Templates**. In the Network Group templates list, find the template you want to modify, and click the edit icon.
In the Network groups templates editor, locate the "Automatic throttling and LEDBAT++ settings" section. In the Beacon field, select the pencil icon. Select the box which appears and a drop down list should open which lists the Beacon servers that have reported into StifleR. Select the Beacon Server you would like to add, and then click the **green check mark** to save the setting.
Once the template is applied and clients are aware of the Beacon server, they will begin measuring their bandwidth. \ The "Measure vs template values" setting includes two options: * **Beacon measure priority –** if set, the StifleR Server will adjust the limits based on new measurements. This makes it possible to automatically bandwidth and override the template. * **Template priority –** if set, the StifleR Server will ignore any beacon measurements and always use whatever is set in the template. **To enable scheduled measurements, change "automatic bandwidth tuning" to value 16** Click the pencil icon to choose which setting you would like to apply. ## Manually executing a measurement Beacons should receive measurements automatically, but you can also execute a measurement manually. To manually execute a Beacon measurement, open the applicable Network Group for the Beacon services by selecting the Network Group in the Network group list.
On the Network Group page, in the "Bandwidth and throttling settings" section, click the **Measure now** link which will force a measurement. After a short time, this measurement should be reflected in the table on the Beacons page.
# Configuring StifleR SQL History Enabling SQL History in StifleR means that all data transfers will be logged to a defined SQL database. This extends the visibility of historical client content downloads, but requires additional components. ## Choosing a database host The SQL History feature requires a SQL database and host. The SQL database can be hosted on a remote SQL server or installed on the StifleR Server. SQL Express can be used, but depending on the number of clients and content downloads, the database size may exceed the 10 GB limit of SQL Express. ## Setting permissions for the SQL database The SQL History feature will attempt to write to the SQL database using the user context in which the StifleR Server service is running. For example, if the StifleR Server service is running as "Local System" (default) then the computer account ($ComputerName) of the StifleR server needs to be granted access to SQL. If the StifleR Server service is running under a service account, the service account will need to be granted access. ### Required SQL permissions The StifleR Server computer or service account will need **db\_creator** permissions to the SQL instance to create and manage the SQL database. ### Enabling SQL History in the StifleR Server configuration file To enable StifleR SQL History, you will need to edit the [StifleR Server Configuration File](broken://pages/nHStlYiqePE9p1g7bKrM) **(StifleR.Service.exe.config)** by setting the **SQLHistory** value to **1**. 
<add key="SQLHistory" value="1"/>
### Configuring the history database configuration string In the same StifleR Server configuration file, you must define the database server, instance name, and database name (optional). See the below example of the connection string you should edit in your .config file: ```xml ``` ## Restarting the StifleR Server service After editing and saving the **StifleR.Service.exe.config** file, for the changes to take effect, restart the "2Pint Software StifleR Server" service. {% hint style="info" %} Important: The StifleR SQL History database will not automatically be created after service restart. The database will be created when a client attempts to download content and reports the download status to the StifleR server. {% endhint %} # Securing StifleR operations with SSL ## Introduction This document provides guidance on how to secure StifleR communications with SSL. Securing StifleR is straightforward, but as with anything involving Microsoft Security and Certificates, you need to get it exactly right or it just won’t play ball. This document provides details around security configuration and describes the process of setting up a certificate for self-hosting SignalR, the communication platform upon which StifleR is built. ### What exactly do we need to secure? There are two components that must be secured: * **SignalR Endpoint Communications -** the StifleR Server service that the clients communicate with (default port 1414). * **StifleR Web API -** the WebAPI service that the Dashboard connects to (default port 9000). {% hint style="info" %} Note: If the StifleR Server service and the StifleR Dashboard are hosted on separate servers, both servers will need their own certificates. {% endhint %} # Prerequisites Certs! We love them. Here's what you need to integrate them with StifleR. ## **Server certificate** Ideally a security certificate can be provided by an internal certificate authority (CA) or a CA on the public Internet. For an internal CA, see [Using a web server certificate](/stifler/3.0/configuration/securing-stifler-operations-with-ssl/using-a-full-iis-certificate) for more information. If it is difficult to acquire a web server certificate, you can use a [self-signed certificate](/stifler/3.0/configuration/securing-stifler-operations-with-ssl/using-iis-to-create-a-self-signed-certificate). {% hint style="info" %} Note: If the StifleR Server service and the StifleR Dashboard are hosted on separate servers, both servers will need their own certificates. {% endhint %} ## **Client certificate** (if using a self-signed certificate) * If using a self-signed certificate, the clients will need their own certificate. # Using a web server certificate Once you go to production – especially public production – you will need an 'official' certificate signed by an internal certificate authority (CA) or one of the global certificate authorities. If you have an internal certificate authority, and have the ability to request a certificate, follow these steps to [Request a web server certificate](/stifler/3.0/configuration/securing-stifler-operations-with-ssl/using-a-full-iis-certificate/requesting-a-web-server-certificate). Self-signed certificates are great for testing under SSL to make sure your application works, but they aren't practical for production apps as the certificate would have to be installed on every machine you'd expect to trust this certificate. If you must use a self-signed certificate, see [Using a self-signed certificate](/stifler/3.0/configuration/securing-stifler-operations-with-ssl/using-iis-to-create-a-self-signed-certificate). # Requesting a web server certificate The process for requesting a new certificate depends on your company policies. This document describes how to request a new web certificate if using an Active Directory Enrollment Policy. To request a web server certificate: 1. Open the local machine certificate snap-in by entering the command: **certlm.msc**. 2. Expand the Personal folder and right-click the Certificates folder. In the context menu, select **All Tasks** - **Request New Certificate...**\ ![](/files/26j0utQmM1wVY9Do04xf) 3. In the "Certificate Enrollment" wizard, at the "Before You Begin" screen, click **Next**. 4. At the "Select Certificate Enrollment Policy" screen, select **Active Directory Enrollment Policy** and then click **Next**. 5. At the "Request Certificates" screen, select the web server certificate template, and click: **More information is required to enroll for this certificate. Click here to configure settings.** 6. At the "Certificates Properties" screen, in the "Alternative name" section, use the Type drop-down and select **DNS**. In the Value field, enter the FQDN of the StifleR server on which the certificate will be installed. You can also add additional values for DNS (CNAME) Aliases. Click **OK** to save the settings.\ ![](/files/h8xBqrk7FFzDoq6hS0TM) 7. Once complete, click **Enroll** and then click **Finish** to close the wizard. 8. You should see the certificate in the certificates store. **Double-click** the certificate and click the **Details** tab. 9. Scroll down and select the **Subject Alternative Name** field. In the value box, you should see the DNS Name you entered earlier. 10. Select the **Thumbprint** field. In the value box, you should see the certificate thumbprint. This can be copied by using the hotkeys **CTRL-C**. It is important to capture this value to add to the StifleR Config file when implementing HTTPS in StifleR. \ ![](/files/UrPxUUn4WUEYL19ApWmP) # Using a self-signed certificate If you don't have a web server certificate which has been issued by an internal or public Certificate Authority, but you'd like to test StifleR with SSL operations, you can create a self-signed certificate. This can be done within the Internet Information Services (IIS) Manager. Once the self-signed certificate is created and clients are configured to trust it, you can follow the steps to [Configure StifleR to use SSL](/stifler/3.0/configuration/securing-stifler-operations-with-ssl/running-signalr-with-ssl). ## Creating the self-signed certificate 1. Open IIS Manager (InetMgr). 2. Select the Computer Name or root. 3. Open the **Server Certificates** link. 4. In the Actions pane, select **Create Self-Signed Certificate**. 5. At the "Specify Friendly Name" dialog box, enter a **friendly name** and select the **Personal** store. Click **OK** to create the certificate. ![](/files/95U9GtDUI2qLl3KEOJ6i) ### Copy the self-signed certificate to the Trusted Root Certification Authorities store Once you have a self-signed certificate, you need one more step to make the certificate trusted so that HTTP clients will accept it on your machine without error. The process involves copying the certificate from the personal store to the trusted machine store: 1. From the Run command execute: **certlm.msc**. 2. Go into **Personal | Certificates** folder and find your certificate. 3. Right-click and copy the certificate, and paste it into the to **Trusted Root Certification Authorities** | **Certificates** folder. ![](/files/IaaT1stFY0YqAgIiGWrQ) Now that you have a self-signed server certificate, you must now install the certificate on your clients so they will trust the server certificate. To do this, you will have to export the self-signed certificate to a file. ## Exporting a self-signed certificate Once you have a self-signed certificate, you can export it so it can be installed on clients: 1. From the Run command execute: **certlm.msc**. 2. Go into **Personal | Certificates** folder and find your certificate. 3. Right-click the certificate, and in the context menu, select **All Tasks** | **Export**. 4. At the "Certificate Export Wizard" click **Next**. 5. At the "Export Private Key" screen, select **Yes, export the private key**, and click **Next.** 6. Proceed through the rest of the wizard and the end result should be a **.PFX** file which can be imported on clients. {% hint style="info" %} Note: In the Certificate Export Wizard, you will be asked to secure the certificate with a group or username or password. If automating the deployment of the certificate, using a group may be easier than a password, so the password is not exposed in whatever command you use to import the certificate on a client. If importing the certificate manually, a password is acceptable. {% endhint %} ## Importing the self-signed certificate on clients For clients to trust the self-signed certificate on the StifleR Server, the exported certificate (.pfx) file will need to be imported into the following client **LocalMachine** certificate stores: * Personal\Certificates (My) * Trusted Root Certificate Authorities\Certificates This can be done by using the certutil.exe -importpfx command or this can also be done via PowerShell using the following command: ``` #imports the certificate to the Personal Certificates (My) store Import-PfxCertificate -FilePath -CertStoreLocation Cert:\LocalMachine\My #imports the certificate to the Trusted Root Certificate Authorities store Import-PfxCertificate -FilePath -CertStoreLocation Cert:\LocalMachine\Root ``` # Configuring StifleR to use SSL With the certificate installed, to switch to SSL for SignalR and Dashboard communications, you will need to do the following: * Modify the StifleR Server configuration settings. * Modify the Dashboard configuration file. * Modify the StifleR Client configuration file. ### StifleR Server Service You'll also need to modify the SignalR URL and Web Service URLS in the[ StifleR Server Configuration File](broken://pages/nHStlYiqePE9p1g7bKrM): ``` ``` This binds SignalR to all IP addresses on Port 1414. You can also specify a specific IP address, but using \* is more portable especially if you set the value as part of a shared configuration file. The [certificate thumbprint](/stifler/3.0/configuration/securing-stifler-operations-with-ssl/finding-the-certhash) will also need to be added to the [StifleR Server Configuration File](broken://pages/nHStlYiqePE9p1g7bKrM): ``` ``` For the StifleR Server to use any changed settings above, the StifleR Server service must be restarted. ### StiflelR Dashboard URL Configuration To configure the web page which will connect to the SignalR service, change the URL in the file [StifleR Dashboard Configuration File](broken://pages/sL3rvzzq7UovRhGxpCfa). The value should reflect the https URLs for the StifleR Server: ``` "controller": "https://StifleRServer.domain.com:9000", "hub": "https://StifleRServer.domain.com:1414" ``` {% hint style="info" %} As with all certificates, make sure that the FQDN that exactly matches the certificate name. If the Dashboard is hosted on the local machine, you cannot use 'localhost', NetBiosName, or IP address. Use only the name to which the certificate is assigned. {% endhint %} ### Clients On new and existing StifleR Clients, the SSL info is set in the [StifleR Client Configuration File](broken://pages/oawEeEGDtdQVU7o0yKF6): ``` ## Using the local certificate store to get the certificate thumbprint 1. Open the local machine certificate snap-in by entering the command: **certlm.msc**. 2. Expand the **Personal** - **Certificates** folder and locate the certificate. 3. Double-click to open the certificate and at the **Details** tab, look for the **Thumbprint** property which contains the hash.
![](/files/5YhLVnepIwHpqo9FNvtW) # StifleR Client access control options This page describes options for controlling StifleR Client access to the StifleR Server. These options are not referring to securing communications such as HTTPS. ## Client AD group membership The StifleR client runs as Local System (NT AUTHORITY\System). If the client and the server are both in the same domain (or a trusted domain)**,** then the client's Local System account uses the computer account credentials to access the StifleR server. If an administrator wants to further limit client access to the StifleR server, an AD group can be used in which clients who are members of the group will be permitted access. To configure the AD group, use the following settings in the [StifleR Server Configuration File](broken://pages/nHStlYiqePE9p1g7bKrM): **RequireAgentGroupMembership** = "1" If the above is set, a second setting, **AgentGroupMembership** must be configured to define the AD group name. As an example: AgentGroupMembership = "2PINT\StifleRClientAccess" {% hint style="info" %} Note: If the client or the server is **not** in a domain, or a trusted domain, then the Local System account attempts to use ANONYMOUS LOGON. This cannot be verified against a group, and would fail if the setting **RequireAgentGroupMembership** is configured. {% endhint %} ## Client certificates If the client population is spread across a number of different domains, or are not domain joined, you can use certificates to control access. To require a client certificate, the setting: **RequireAgentClientCertificate** must be defined in the [StifleR Server Config file](broken://pages/nHStlYiqePE9p1g7bKrM). If enabled, the settings: **CertificateClientThumbprint** and **CertificateRootThumbprint** must also be defined in the configuration file. The 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. {% hint style="info" %} NOTE: Client certificates are not related to web-based communication or HTTPS. They are separate entities and HTTPS does not verify that the client can authenticate as client certificates do. {% endhint %} ## Client token There is a further (less secure) method that can be used if you are unable to use group membership or client certificates. This requires a client ‘token’ value to be configured on the server and client. The setting for the [StifleR Server configuration file](broken://pages/nHStlYiqePE9p1g7bKrM) 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). # Online services 2PintSoftware Online Services (OS) is a cloud-hosted component designed to extend and enhance the capabilities of StifleR. It acts as a supporting service that enables communication with external systems and provides essential backend functionality required for selected StifleR features. Online Services is not required for core StifleR traffic management but is used to enable specific cloud-assisted capabilities. ## Core Functions Currently, 2PintSoftware Online Services provides the following functionality: * **Third-party API integration**\ Enables communication with external services, primarily location-based platforms such as Azure Maps, to support geographic visualization and mapping features within StifleR. * **Licensing telemetry**\ Handles license registration, validation, and telemetry reporting to ensure correct licensing state across StifleR deployments. *** ## Data Transmission and Privacy 2PintSoftware Online Services exchanges a limited and well-defined set of data with 2Pint Software’s cloud infrastructure. This data exchange supports features such as geographic mapping, license validation, and high-level telemetry for StifleR environments. No end-user identity data or content payloads are transmitted. *** ## Data Types Transmitted ### Location Services – Network Geocoding For network-level geolocation, the following data may be transmitted: * Geographic coordinates only, with no associated identifiers. * Coordinates are derived from the client’s best available location estimate, typically provided by Windows Location Services. ### Location Services – Client Geocoding For client-side geolocation, the following data may be transmitted: * Nearby BSSIDs (Wi-Fi access point identifiers) used solely for coordinate translation. * No additional client information, device identifiers, or network metadata is sent. ### Telemetry Data The following telemetry information may be transmitted to Online Services: * SHA256 hash of the license key * SHA256 hash of the StifleR server host name * Product identifier (for example, StifleR) * Number of currently connected clients * Total number of clients observed * StifleR version All telemetry values are designed to support licensing validation and product usage insights only. *** ## Disabling Data Transmission If telemetry or geolocation services are not desired, administrators can disable specific Online Services features through configuration settings. ### Disable Location Services To prevent any location-related data from being transmitted: 1. On the StifleR server, modify the default network creation flags. 2. Disable the following flags: * BSSIDExistingLocation * GeoData This disables both coordinate-based and BSSID-based geocoding requests. ### Disable License Telemetry (Heartbeats) To stop license telemetry (heartbeat communication) from being sent to Online Services: * Disable Online Services heartbeats in the StifleR configuration. Once disabled, no periodic licensing validation or telemetry updates will be transmitted. # CacheR operations ## Adding distribution points Distribution Points in CacheR are currently used to represent availability only. \ To add Distribution Points, open the **StifleR Dashboard** and navigate to **Cache Management**, then **CacheR**, and select **Distribution Points**. If multiple CacheR servers are present, select the CacheR server you want to configure.
Add a new Distribution Point and provide a friendly name and the root URL of the Distribution Point.
Once added, the CacheR Worker service will process the entry. When processing is complete, the Distribution Point status will change to **Available**, confirming that it has been successfully detected and validated.
## Tracking content ### Manually adding CacheTracks (packages) Before manually creating CacheTracks, you must gather several required details. These include the **Package ID or Application ID**, the **Package Version** is the ConfigMgr details that is needed so those values need to be collected from there. And the **Base URL** where the content is hosted. Tools such as [**BCMon**](https://github.com/2pintsoftware/BranchCache/tree/master/BCMon) or the PowerShell script [**Get-ConfigMgrContentLocationFromMP.ps1**](https://github.com/2pintsoftware/ConfigMgr/blob/master/Get-ConfigMgrContentLocationFromMP.ps1) can be used to identify and confirm the correct content URLs.
To add a CacheTrack, navigate to **Cache Management** in the StifleR Dashboard, then **CacheR**, and select **Packages**. Choose the appropriate CacheR server if prompted, then select **Add** to create a new package entry.
Populate all required fields with the collected information and confirm the configuration. {% hint style="danger" %} After clicking OK there might be a small delay, DON’T click again! {% endhint %}
Once the package has been processed, opening the package details should show that all URLs were successfully parsed and validated. At this stage, use the **Download zip file** option to verify that CacheR is functioning correctly and that the zip file is accessible. This download URL is also the address that must be used later for client-side reporting.
Additionally, verify on the CacheR server that the zip file has been created in the designated **zipfiles** directory. ``` \\install path\CacheR\CacheR.Files\ZipFiles ``` ### Manually configuring client side reporting For a client to report its caching status back to CacheR, several values must be provided. These include the **Zip file URL**, which is the relative path shown under **Download File** for the package in the StifleR Dashboard, the **CacheR Secret Key** obtained from the configuration editor, the **CacheR URL**, and the **CacheR Port**, which defaults to **9050**. Client-side reporting is performed using the **Cacher.Client.exe** command-line tool. The syntax requires specifying the CacheR endpoint, port, zip file path, CacheTrack GUID, and the secret key. ``` Cacher.Client.exe ``` Each client must execute this command for every CacheTrack it is expected to report on. To scale this process, it is recommended to distribute and execute these commands using a **Configuration Manager Configuration Item** or an **Intune Remediation Script**, ensuring consistent and automated reporting across devices. ### Automated CacheTrack Management with CacheRCIManager.ps1 For environments using Configuration Manager, the script **CacheRCIManager.ps1** provides a fully automated approach to managing CacheTracks and client-side reporting. This script synchronizes Configuration Manager packages and applications used within one or more Task Sequences into both CacheR and a single Configuration Item (CI). The script treats the specified Task Sequence or Task Sequences as the authoritative source. Any content referenced in the Task Sequences is automatically added to CacheR and the CI. Conversely, content that no longer exists in the Task Sequences is removed from CacheR and the CI by default. This ensures long-term consistency without manual cleanup. As a result, a single Configuration Item is created containing one compliance setting per package or application used in the specified Task Sequences. Each compliance setting runs a lightweight PowerShell detection script that invokes **Cacher.Client.exe**, allowing clients to report their caching status back to the CacheR server. This approach guarantees that CacheR and the Configuration Item remain fully synchronized with Task Sequence changes. After updating a Task Sequence, simply re-run the script to refresh CacheTracks and reporting logic automatically. #### **Prerequisites (must be in place before first run)** | Prerequisite | Details | | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | ConfigurationManager PowerShell module (installed automatically when installing CM Admin Console) | $env:SMS\_ADMIN\_UI\_PATH must exist | | CacheR PowerShell module | Unzip CacheRApi.0.1.0.zip and add the unzipped folder into your PowerShell modules folder. | | AdminService enabled and reachable on the SMS Provider | Semi optional, only used for cleaning up old CI revisions. More housekeeping than an actual requirement. | | A manually created (empty) Configuration Item in ConfigMgr with the exact name given in parameter -DestinationCIName | Script does NOT create the CI for you | | Permissions | Account running the script needs full Control on the CI | #### **Required Parameters** | Parameter | Description | Example | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ | | -SiteCode | SCCM site code | "P01" | | -ProviderMachineName | FQDN of SMS Provider | cm01.contoso.com" | | -SourceTSNames | One or more TS names (exact match) | Windows 11 24H2", "Win11 PreCache" | | -DestinationCIName | Name of the CI that will be managed | “2Pint CacheR Update” | | -CacheRserver | FQDN to CacheR Server | | | -CacheRPort | WebAPI port (default 9050) | 9050 | | -CacheRApiKey | API key configured in CacheR, found in Config Editor tool | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | | -DPFQDN | Full https URL to a Distribution Point that CacheR can reach | | | -SizeInMB | Minimum size of packages to track (default 1 MB) | 50 | | -PrefixToSkip | If a child TS contains content you do not want tracked by CacheR or added to the CI, name it with this prefix (default: SkipPreCache) and it will be automatically excluded. | NoPreCache" | | -IgnoreContentDifferences | Keep packages/apps in CI/CacheR even if they are no longer found in TS | - | #### Typical scheduled execution (example) ``` .\CacheRCIManager.ps1 -CacheRserver https://cacher-01. contoso.com -CacheRApiKey "11111111-2222-3333-4444-555555555555" -CacheRPort 9050 -ProviderMachineName "cm01.contoso.com" -SiteCode "P01" -SourceTSNames "One Task Sequence", "Another Task Sequence", "A third Task Sequence" -DestinationCIName "2Pint CacheR Update" -SizeInMB 20 -DPFQDN "https://dp01.contoso.com" ``` Run this daily (or after every TS change) via Scheduled Task running under a service account with the required rights. # Remote tools features ## Overview Within the Client Details page for a specific client, at the top right of the **Connection information** section, there is a small tool icon, which if clicked, opens a drop down menu which displays the following actions:
**Start RDP Session -** creates an RDP file to execute a Remote Desktop session with the client. **Start a PowerShell session over SignalR -** opens a page which allows remote PowerShell commands to the client. **Start remote Performance Counter session -** opens a page which displays remote Performance Counter information. **Start a remote WMI browsing session -** opens a page which enumerates the WMI database of the remote computer. **View eventlogs over SignalR -** opens a page which displays the Event Logs of the remote client. **Start a Netmon session -**opens a page which displays netmon session on the remote client. ## Remote PowerShell Session StifleR provides the ability to execute a remote PowerShell session using the Dashboard that replicates the full functionality of Windows PowerShell as it would be executed locally. To execute a PowerShell command on the client, type the command into the bottom text box and click the **Execute** button. The output will be displayed in the console output pane.
Within the blue bar towards the top of the screen, there are several quick action buttons which can execute pre-defined common commands. Clicking these buttons will execute the respective command on the remote client. * **Get computer info** * **Test NetConnection** * **Ping** * **Get BC Status** * **Get DO config** * **Flush BranchCache** * **IP config** * **Network stats** * **Flush CCM cache**
## Remote Performance Counter StifleR provides remote access to the performance counter for a single device, allowing administrators to monitor and optimize system performance in real time. The table view allows you to define required categories and set multiple counters at once to analyze performance, compare category data with each other, check live system performance, and search and filter for results and keywords.
## Remote WMI Browsing StifleR provides remote access to WMI (Windows Management Instrumentation) for a single device. The table view allows you to expand the various WMI classes and instances on the remote machine.
## Remote Event Log Viewer The StifleR provides remote access to Event Logs for a single device. In the left pane, select the event log you would like to view, then select the **icon** in the View column. The right pane should expand to enumerate the events. For more text based detail for the specific event, select the **icon** in the View column. The table view allows you to find relevant information quickly by setting custom filters, enabling disabling empty logs, searching for data by any keyword or simply sorting data by required criteria.
## Remote Netmon Session The StifleR provides remote access to Netmon data for a single device.
# Bandwidth management and allocation ## Overview In most corporate environments clients will connect in several different ways depending on location and scenario. Bandwidth control must make allowances for these different scenarios with connected clients on managed networks, roaming clients, and those connecting over VPN. Clients may be on well-connected networks or slow links with or without peers. StifleR must also recognize and cater for situations where the StifleR server cannot be contacted. The StifleR Client can be configured to recognize these different situations and adjust bandwidth allowances accordingly. The following is an overview of the various scenarios: ## Network group types A network group can be of the following types: * Regular * Well connected * VPN Depending on the setting the bandwidth is allocated very differently. Typically a Well Connected network has more than 50Mb/s network bandwidth available to it as it’s less strict on the bandwidth throttling and allows for overconsumption for short periods of time for improved user experience. ## Control options Just because a client is assigned bandwidth does not mean that it will automatically use it. If a Red Leader is assigned a large amount of bandwidth but all content for the download element is available from other peers, there will be no bandwidth used. All bandwidth values below are in Kilobits per second (Kbps). The below table references the different properties within a [template](/stifler/3.0/operations-and-features/overview-and-navigation/devices/stifler-server/templates-detail) which is applied to a network group.
Network Group PropertyDefinition
TypeDefines how bandwidth is controlled, like VPN, Regular, and Well Connected.
LocalInternetBreakoutIf set, downloads from the internet are throttled differently than non-internet downloads. Disabled by default.
TargetBandwidthThe bandwidth assigned to Red Leaders.
InternetBandwidthWhat bandwidth Internet downloads should have when local Internet breakout is set.
LEDBATTargetBandwidthValue to assign Red Leader BITS jobs when LEDBAT has been detected.
NonRedLeaderBITSBandwidthValue set for BITS downloads that are not leader in regular networks.
NonRedLeaderDOBandwidthValue set for DO downloads that are not leader in regular networks.
WellConnectedDOSet on BITS downloads for well connected networks.
WellConnectedBITSSet on DO downloads for well connected networks.
BandwidthTuningHistoric and future use, not used currently.
WellConnectedSplitbandwidthControls how bandwidth is split to clients for well connected networks. Not used for regular networks currently.
### Red Leader and non-leader clients The use of a [Red Leader](/stifler/3.0/operations-and-features/features-overview/client-leader-roles/red-leader) is to improve peering efficiency by allowing a single client to get bytes slightly faster than other clients. It’s a 100% dynamic allocation and does not impact the client being the Red Leader. ## Well-connected network groups In this mode the StifleR client does not allow for sharing bandwidth from the DO pool to the BITS pool and vice versa if only one download technology is actively downloading as the regular or VPN networks do. ### Red Leader bandwidth assignment for well-connected networks On a well-connected network the bandwidth for the Red Leader role is as per the below formula. The value that is the highest of the two wins: * WellConnectedDO and WellConnectedBITS values split by the number of clients downloading for all networks in the network group. * The Target Bandwidth divided by number of networks that are actively downloading (active networks) Whatever value is the highest of above is assigned to the Red Leader only for well-connected networks. > #### Example: > > If there are 4 active networks in the same network group, which has been assigned to use 20 Mbps (target bandwidth). \ > Each Red Leader is assigned bandwidth based on the formula: 20 Mbps / 4 = 5 Mbps, but the WellConnectedDO and WellConnectedBITS values are set to 100 Mbps.\ > Lets say that only 10 clients are downloading content among these 4 networks. This means that the Red Leader will be assigned 100 Mb/10 = 10 Mbps as 10 Mbps is a higher value than 5 Mbps. > > If there were 30 clients downloading content, the 4 Red Leaders would each get 5 Mbps as 100 Mbps/30 = 3.3 Mbps which is less than 5. > > The reason for this logic is to allow fast downloads on well-connected networks regardless of how many clients are connected. ### Non-leader bandwidth assignment in well-connected networks Clients are allocated the bandwidth according to the split setting. If the WellConnectedSplitbandwidth option is set to 1 in the [StifleR Server Config File](broken://pages/nHStlYiqePE9p1g7bKrM), (enabled by default in StifleR 2.10 and above), the bandwidth per client is calculated as: * WellConnectedDOBandwidth value / per number of clients downloading * WellConnectedBITSBandwidth value / per number of clients downloading * Internet value for local Internet Breakup is also calculated as per InternetBandwidth / per number of clients downloading from the Internet. {% hint style="info" %} Note: There is no sharing across the bandwidth pools when a network group is well connected. {% endhint %} If the WellConnectedSplitbandwidth options is not set, bandwidth is assigned to actual values of the WellConnectedDOBandwidth and WellConnectedBITSBandwidth values. ### Internet bandwidth for well-connected networks with Internet breakout Set Bandwidth for Internet can be assigned differently than regular downloads if the network group is set to throttle the Internet traffic differently. This only applies to non Red Leaders. The throttling limits are different for well-connected networks depending if WellConnectedSplitbandwidth is enabled for the network group. If this is enabled, the logic for any non Red Leader is that it gets bandwidth as per the following formula: * Internet bandwidth value / clients running Internet downloads If WellConnectedSplitbandwidth is not set, the value is instead set to the actual value per client, i.e. each client is assigned the InternetBandwidth value as bandwidth for downloads coming from the Internet. ### LEDBAT assignment for Red Leaders in well-connected networks How does this work? The Red Leaders are assigned a special LEDBAT value which is typically allowed to be higher than the regular TargetBandwidth property. Any download job that then has been detected as LEDBAT capable will be allowed to use this value. LEDBAT bandwidth will be assigned to the Red Leader only, and only for BITS jobs. If the download has the return header set for LEDBAT, the running job will be assigned the value from the LEDBATTargetBandwidth setting for the network group. The value is assigned to the Red Leaders same as any other Red Leader bandwidth using the formula: * LEDBATTargetBandwidth / active networks ## Regular network groups In this mode the StifleR client allows for sharing bandwidth from the DO pool to the BITS pool and vice versa if only one download technology is actively downloading. A BITS job can therefore be assigned both the DO and the BITS download policy for a single BITS job. ### Red Leader bandwidth assignment for regular networks Bandwidth for the Red Leaders are assigned as: * TargetBandwidth / number of downloading networks > Example: > > If you have 3 networks but only 2 networks are active, and the TargetBandwidth is set to 18 Mbps. Each of the two Red Leaders on the active networks will be assigned 9 Mbps each. ### Non-leader bandwidth assignment for regular networks Non-leader bandwidth assignment for this type of network are calculated as such: BITS: NonRedLeaderBITSBandwidth is assigned to the client. DO: NonRedLeaderDOBandwidth is assigned to the client. The client is then assigned one value or doubling them up if there is only one download technology active. If both are active, the individual values are used. > Example: > > BITS is assigned 128 Kbps, and DO 128 Kbps. Then if there is only BITS transferring, BITS is then assigned 128 + 128 = 256 Kbps. > > If there is both a BITS job and a DO download, each technology gets 128 Kbps. > > If there is just one DO job, the client gets 256 Kbps, via 128+128. ### Internet bandwidth for regular networks with Internet breakout set Bandwidth for Internet can be assigned differently than regular downloads if the network group is set to throttle the internet traffic differently. This only applies to non Red Leaders. This differs for how it works for well connected networks. WellConnectedSplitbandwidth is not used for regular networks. For regular networks that have Internet breakout enabled, the logic is as per the following formula: * InternetBandwidth / active Internet clients ### LEDBAT bandwidth assignment for regular networks LEDBAT bandwidth will be assigned to the Red Leader only, and only for BITS jobs. Same as for LEDBAT for well-connected networks. If the download has the return header set for LEDBAT, the running job will be assigned the value from the LedbatBandwidth setting from the network group. The value is assigned to the Red Leaders as any other Red Leader bandwidth, using the formula: * LedbatBandwidth / active networks ## VPN network groups VPN networks assign bandwidth differently compared to regular and well-connected networks, as there is no assigned Red Leader. This is because peering is typically not desired or possible on VPN networks. In this mode, the StifleR client allows for sharing bandwidth from the DO pool to the BITS pool and vice versa if only one download technology is actively downloading. Each client is assigned: BITS: The network group target bandwidth / 2 / active clients for the network. DO: The network group target bandwidth / 2 / active clients for the network. The bandwidth is then shared across the download technologies. > #### Examples: > > A network group has 100 Mbps set for a VPN network. There are 10 active (downloading) VPN clients, that are only downloading content using BITS. > > Each client is assigned the following bandwidth: > > BITS is then assigned: 100 / 2 / 10 = 5 Mbps. > > DO is assigned: 100 / 2 / 10 = 5 Mbps. > > As bandwidth is shared for VPN and there is only BITS jobs, the 10 clients assign 5+5 = 10 Mbps per client toward the BITS download. ### Internet bandwidth for VPN networks with local Internet breakout (split tunnel) If the VPN network group has been set for local Internet breakout, any client that has Internet download enabled is assigned the value of the Internet bandwidth assigned to the network group. Typically this is used to set the Internet bandwidth to 0, i.e. unlimited as this download is then using the network that the VPN is accessing from. If breakout is not set, bandwidth for Internet downloads is throttled the same way as any other download. ## Roaming clients Clients that are roaming are clients that are not assigned to a network group but are able to connect to the StifleR server. Bandwidth is assigned for roaming clients from the DefaultRoamingBandwidth configuration value in the local [StifleR Server Configuration file](broken://pages/nHStlYiqePE9p1g7bKrM). If the server sends an updated value, the client will update the local configuration to the new value. 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). > Example: > > If Default RoamingBandwidth is set to 50 Mbps (51200) then the clients would get 25 Mbps for BITS and 25 Mbps for Delivery Optimization. ## Disconnected clients At start up, the StifleR client will automatically set the DefaultDisconnected Bandwidth limits (DO and BITS) values which are defined in the [client configuration file](broken://pages/oawEeEGDtdQVU7o0yKF6). The client's bandwidth settings will then be set as per the following logic: * If the StifleR Server name can be resolved, but is not allowing connections, we assign the disconnected client bandwidth settings as per the [client configuration file](broken://pages/oawEeEGDtdQVU7o0yKF6). * If the server is not resolved using DNS and not reachable, we remove all throttling. # Bandwidth tuning monitoring and control {% hint style="info" %} NOTE: It is worth noting that while High and Low Bandwidth tuning is presently a major part of network optimization it is being complemented more and more by LEDBAT technology. We are getting closer to LEDBAT becoming a main part of the solution for enterprise bandwidth control and you should refer to the [2Pint Software website](https://2pintsoftware.com/) various support and community resources for the latest in this regard. It is an important part of the Microsoft roadmap and is well worth a bit of research. {% endhint %} This section explains the configuration options available for Bandwidth monitoring and how the limits set are then used to adjust parameters for maximum download performance. With each of these detection methods, when an override happens, a warning will be written to the Event Log. Bandwidth tuning is turned on and overall site settings configured on the server through the StifelR.Service.exe.config file. This file also contains the parameters that govern the various site wide settings that control the monitoring intervals and the tuning adjustment values. Please refer to the [StifleR Server settings knowledge base article](https://2pintsoftware.my.site.com/s/topic/0TOP40000005JrdOAE/stifler?language=en_US) for a full explanation of the settings available in this file. StifleR can manage the bandwidth usage based on throughput, either too little or too much being used and adjust settings accordingly. These are enabled on a location (WMI) by setting the BandwidthTuning property, which sets what is to be monitored, the Latency Threshold value which sets when Tuning should be used and the TargetBandwidth value which is the sweet spot for the link. The following BandwidthTuning options are available: * Latency * LowBandwidth * HighBandwidth * LEDBAT * MeasureBandwidth StifleR can monitor and adjust a number of bandwidth related metrics. The bandwidth management system uses a bit flag system so multiple detectors can be used at the same time. i.e. a value of BandwidthTuning that equals 5 enables 1 and 4 but disables item 2 (see below). The server has flags defined it the actual code of the product as follows: ``` Latency = 1, LowBandwidth = 2, HighBandwidth = 4, LEDBAT = 8 Measure Bandwidth = 16 ``` Therefore the value of 7 in the Server StifleRService.exe.config file: `` Enables the following tuning capabilities on the server (site wide): Latency (1) + LowBandwidth (2) + HighBandwidth (4) = 1+ 2+ 4 = 7. If you wanted to only use Latency and HighBandwidth monitoring for the site you would set 1+4 = 5. The same values are used to enable these settings per subnet and are set on the subnets object. ### Latency detection (BandwidthTuning = 1) This configuration determines latency to the target server using a simple ICMP Ping. The round trip time is recorded and stored which can then be used to calculate the average latency for ongoing comparison. To use the feature it must be enabled on the server in the StifleRService.exe.config file (On by default) and then set the bandwidth tuning detection flag and LatencyThreshold value for each subnet that you want to control. ### Low bandwidth usage detection (BandwidthTuning = 2) This detects if the bandwidth being used is lower than a set value. To use the feature it must be enabled on the server in the StifleRService.exe.config file (On by default) and then set the bandwidth tuning detection flag and LowBandwidthThreshold value for a location that you want to control. If this occurs without the latency detection being triggered, it’s most likely a configuration issue, server throttling or other QoS policy in place that artificially limits the allowed bandwidth. BITS has a tendency to be overly cautious on how much bandwidth can be consumed. Please note that it is recommended that this feature be fully tested before use in production as it can consume excess bandwidth unless tightly monitored and controlled. ### High bandwidth usage detection (BandwidthTuning = 4) This feature allows you to detect if the bandwidth being used by BITS is greater than the configured values. The reason for this violation would typically be due to a failure in assigning the desired BITS policy, or an issue with the BITS policy on its own. This may happen for a number of reasons: * Conflicting GPO settings e.g. Active Directory/Policy differences * Invalid security settings (StifleR client not running as Admin or System) * BITS policy corruption * BITS bugs due to inconsistent hotfixes To use the feature it must be enabled on the server in the StifleRService.exe.config file (On by default) and then set the bandwidth tuning detection flag and HighBandwidthThreshold value for the locations at which you want to use the feature. ### LEDBAT (BandwidthTuning=8) Low Extra Delay Background Transport (LEDBAT) is a way to transfer data in the background quickly, and without clogging the network. In order to control LEDBAT settings through StifleR you need to set this flag on the server and then make the configuration changes covered in the next section. ### StifleR LEDBAT Configuration StifleR lets you set a higher/different TargetBandwidth policy when LEDBAT is in play. LEDBAT itself ensures that only available bandwidth is used and if other traffic comes along BITS will automatically back off. True auto-throttling in action! ### Setting up LEDBAT++ with content distribution 1. Enable LEDBAT++ on the content server that will be serving the BITS content (SCCM Distribution Point for example). 2. Set up the LEDBATTargetBandwidth (WMI) for a location/subnet in StifleR (This can be set in the Location Details dashboard or via WMI/PowerShell). `swmi -path 'root\Stifler:Subnets.subnetID="192.168.4.0"' -Arguments @{LEDBATTargetBandwidth = 20480}` 3. Set an IIS custom header to “LEDBAT:true” on the LEDBAT-enabled content server. (see [How to add a custom HTTP response header to a website that is hosted by IIS](https://support.microsoft.com/en-us/help/954002/how-to-add-a-custom-http-response-header-to-a-web-site-that-is-hosted) [)](https://support.microsoft.com/en-us/help/954002/how-to-add-a-custom-http-response-header-to-a-web-site-that-is-hosted) The custom header is picked up by StifleR on the client. 4. If LEDBAT is detected on the client, then StifleR will use LEDBATTargetBandwidth value for that location that has been set on the server. 5. The higher LEDBATTargetBandwidth value is then set as that job has the LEDBAT: true header. 6. If a different (non-LEDBAT aware) job starts, then StifleR will set the regular TargetBandwidth for the location. 7. LEDBAT then takes care of the throttling, and BITS runs at MAX of LEDBATTargetBandwidth. ### Bandwidth measurement – Beacon Server (BandwidthTuning=16) With this bit set it is possible to specify a percentage of maximum bandwidth for a location/subnet as opposed to a hard limit (target bandwidth). It is important to note that this is a percentage of the maximum measured download bandwidth for that location. This value is automatically calculated by the StifleR client agent or may be set manually if required. (MaxBandwidthDownstream) Once this value is set, a second value, PercentOfMaxDownstream is used to set limits for the Red Leader of that subnet/location. How is it calculated? The best (and most accurate) way of working out the bandwidth between two points is to send some content up to a location and record how long it takes. This involves some fancy footwork on the client-side which communicates with the StifleR Beacon Server component. In order to achieve this measurement we use the Open Source iperf tool - - which is ideally suited for this measurement. #### **Beacon Server component** The server-side component (iperf3.exe) can run on any (modern) 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 determine the maximum bandwidth available between the subnet/location and the content source. Typically, you will install this component on a server in a central location (such as an CM Distribution Point) from which your clients obtain the bulk of their content. If you have a central data center 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. #### **Client component** The client initiates the transfer of known chunks of content up to the StifleR Beacon Server and back again. This enables StifleR to build up an accurate picture of the maximum bandwidth (both up and down) that is available at that location. That data is then stored with the subnet information on the server. * This function only runs on the Red Leader at a location * It is run at service startup on the first Red Leader at a new location * It is then run periodically to test and update the setting at various times on a schedule (every six days subject to some other conditions) Only increases in bandwidth are reported as it’s the maximum download bandwidth that needs to be determined. I.e if the first client at a location measures that bandwidth to be 5 Mbps then that will be set as the maximum download bandwidth. If the client then runs a new test and determines that the bandwidth available is now 10 Mbps then the maximum download bandwidth will be increased to that value. If a third test is performed at that location and returns a bandwidth of only 8 Mbps (the network may be busy for instance), nothing will change. Once the maximum download bandwidth is determined and set for that subnet, the second property comes into play – namely the PercentOfMaxDownstream parameter. For example, if the maximum download bandwidth is calculated to be 10 Mbps and the PercentOfMaxDownstream parameter is set at 50%, then the target bandwidth for that subnet is adjusted to 5 Mbps. #### Forcing a Beacon measurement For testing purposes you can use the UpdateMaxBandwidth WMI method to force a client to update the MaxBandwidthDownStream property, which in will turn update the target bandwidth for that subnet. Forcing an update using WMIC: ``` wmic /namespace:\\root\stifler path Subnets.SubnetId="w.x.y.z" call UpdateMaxbandwidth ``` Forcing an update using PowerShell: ``` $Subnet = Get-WmiObject -namespace root\StifleR -Class "Subnets" -Filter "SubnetID='192.168.26.0'" Invoke-WmiMethod -Path $Subnet.__PATH -Name UpdateMaxBandwidth ``` ## Latency auto-tuning management (no Beacon Server) StifleR can be configured to auto adjust the download speed depending on latency from the client to the StifleR server OR the download source. If the source is internal (i.e. on a private network) the source will be used for latency calculations. If the source is external, i.e. the Internet, the StifleR server will be used for latency calculations. ### Sample WMI commands to **e**nable auto latency tuning The following WMI Command will set the TargetBandwidth to 700 Kbps, enable the latency monitoring flag in BandwidthTuning, and set the latency threshold to 70 milliseconds for the subnet 192.168.138.0. ``` wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set TargetBandwidth=700 wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set BandwidthTuning=1 wmic /namespace:\\root\stifler path Subnets.SubnetId="192.168.138.0" set LatencyThreshold=70 ``` The above commands will achieve the following; * Set a TargetBandwidth of 700 Kbps * Typically, all subnets have a TargetBandwidth value set as this is how StifleR knows how much bandwidth each subnet or location is allowed to use. * Enable the first option of bandwidth management * The BandwidthTuning is a bit flag. Setting it to 1 enables the first option, latency. Setting it to 3 would enable the first (1) and the second (2) options etc. Setting the first and third options would be done by setting the value to 5 (1 + 4). Note, this doesn’t actually turn on the tuning itself, as we need a value to tune against first. * The last action is to set the value to tune against * In this case it is set to 70msec. If the latency to this location exceeds 70msec StifleR will lower the bandwidth or if it drops below this threshold then StifleR will try to increase usage. ## Bandwidth tuning adjustment options The information above is mainly related to how to actually turn on the various bandwidth tuning options and set the target counters to maximize network performance. The StifleRService.exe.config file also contains a number of configuration options to control how aggressively the tuning is controlled and changes to bandwidth usage applied. There is a full list of the options with notes available on the [2Pint Software Support Knowledge base](https://2pintsoftware.my.site.com/s/topic/0TOP40000005JrdOAE/stifler?language=en_US) - StifleR Server Settings – but for this section we shall discuss one example – latency. ``` How long before we lower the bandwidth 10000 will lower the bandwidth if latency is over Threshold for this period. Default 10sec = 10000 msec When we lower bandwidth, how much do we lower it by? TargetBandwidth / 1.4 = 40% decrease per interation. If we are below the level, how long before we increase BW again. Default 10sec = 10000 msec. When we increase BW, how aggressive are we? TunedBandwidth = TunedBandwidth + (TargetBandwidth / LatencyWarningIncreaseFactor) ``` Therefore, if the Tuned Bandwidth is 500 Kbps and the target Bandwidth is 2000 Kbps StifleR would increase the Bandwidth by 2000 / 5 = 400, so the new TunedBandwidth figure would be 900 Kbps with a new increase each 10sec by default. Latency will be measured and adjustment made every 10 second period by default. Should the latency fall below or above the target level set for the location, bandwidth usage will be adjusted up or down according to the increase/decrease factors in order to bring things back into tolerance. ## WMI Events on thresholds StifleR creates events in WMI for the following items: 1. Latency threshold exceeded 2. Latency threshold resumed 3. High bandwidth threshold exceeded 4. Low bandwidth threshold exceeded # 2Pint BranchCache guide ## Introduction The aim of this document is to assist Administrators in understanding and implementing Microsoft BranchCache and associated technologies in order to maximize the benefits of this often overlooked Windows Service. This document focusses on Distributed Mode BranchCache over HTTP. This is the most commonly used mode of operation when BranchCache is used for Content Distribution via Microsoft ConfigMgr/WSUS etc. So what is BranchCache? Here’s a nice description from the Microsoft Protocol docs on the subject: “The goal of the Content Caching and Retrieval System is to decrease WAN network use. This is accomplished by caching content that has been retrieved over a WAN link (or any high latency link) from a content server by a set of actors (computers, applications, or people) connected to a local area network (LAN) and making it available for subsequent use within the LAN environment in a secure and effective manner. The overall effect is to reduce WAN traffic and therefore increase application performance.” In other words, it’s WAN accelerator, which caches content locally to avoid unnecessary round trips to the data source by allowing clients on the same subnet to retrieve content from peer systems. \*\*IT DOES NOT DOWNLOAD STUFF\*\* Or: “It makes your network go faster” ### BranchCache Distributed Cache Mode * Limited to a single subnet. So if, for instance you have separate subnets for wired vs wireless clients you will effectively have 2 distributed caches and content may well be copied twice to that location. * High mobility can mean that content can ‘go missing’ if a user has cached content (to a laptop for instance) and then relocates. * Initially requires two copies of content to be stored – one in the content download location and one in the BranchCache cache. (the content can be deleted and still be retrieved from the BranchCache cache) **Basic Operation** * PC1 performs a ‘Get’ Request – but downloads the Identifiers (hash) that *describe* the content. * PC1 performs a local broadcast to see if anyone else has this content. If they do, PC1 will get it locally from peers. If the content is NOT local, PC1 will go back to the server and get the content. Once downloaded, the content is then available to peers on that subnet. * PC2 performs a ‘Get’ Request – but downloads the Identifiers (hash) that *describe* the content. * PC2 performs a local broadcast to see if anyone else has this content. * PC1 has the content, so PC2 will transfer it locally from PC1. **Distributed Cache Mode Communications** {% @mermaid/diagram content="flowchart LR ``` subgraph DCM["Distributed Cache Mode"] direction LR subgraph Remote CS["Content Server/\nDistribution Point"] end subgraph Subnet["Subnet A"] PB["Peer B\nWith Content"] PA["Peer A\n3,8"] PA -->|4| PB PB -->|5| PA PA -->|6| PB PB -->|7| PA end PA -->|1| CS CS -->|2| PA PA -.->|9| CS CS -.->|10| PA end %% Styling classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px classDef server fill:#add8e6,stroke:#333,stroke-width:2px classDef peer fill:#90EE90,stroke:#333,stroke-width:2px classDef subnet fill:#f0f8ff,stroke:#333,stroke-width:2px classDef peernocache fill:#fff0f0,stroke:#333,stroke-width:2px linkStyle 6,7 stroke-width:2px,fill:none,stroke:red; linkStyle 3 stroke-width:4px,fill:none,stroke:green; class CS server class PB peer class Subnet,Remote subnet class PA peernocache" %} ``` **Request Flow** 1. TCP 443\ HTTP(S) GET request for content 2. TCP 443\ Returns content metadata + hashes 3. Checks local cache for content 4. UDP 3702 (Broadcast)\ WS-Discovery broadcast (MC): Searching for peers with content ID 5. UDP 3702 (Unicast)\ WS-Discovery response: Indicates content availability 6. TCP 1337\ Requests content segments 7. TCP 1337\ Sends encrypted content segments 8. Verifies received segments against hashes from server **Fallback**\ If no clients responds with content hashes or if hash verification fails. 9. TCP 443\ Requests Content from source 10. TCP 443\ Sends requested Content ## BranchCache Theory “Buckle up – there aren’t many screen shots.” This section can be a bit ‘dry’, but it’s worth sticking with the clever theory behind BranchCache as it helps you to understand where the heck your data went when you get to play with it. ### BranchCache Versions The first, and one of the most important items to consider and understand before you implement BranchCache is the two different versions. They behave differently, don’t necessarily play well together, and are an important factor in any BranchCache implementation. At the time of writing, BranchCache is available on Windows Server 2008 R2 / Windows 7 Clients and later \- We’ll refer to this as **Version 1 BranchCache** It’s also available on Windows Server 2012/2016 versions, and Windows 8/10/11 clients. \- We’ll refer to this as **Version 2 BranchCache** ### BranchCache ‘Content’ Explained “BranchCache Does Not Care About Files!” The BranchCache Content Server is responsible for slicing up content into chunks. It’s these chunks that are requested and downloaded by BC clients, not files. It works slightly differently (and more efficiently) in Version 2 than Version 1. #### The Hash (or Content Identifier) “No Hash = No Content!” The BranchCache Content Server generates Hashes for content that is requested by clients. This hash, or Content Identifier is then used to locate content from other peer systems. {% hint style="info" %} **Important** BranchCache Content Server will only generate the Hashes for content at the time of the request. It’s fairly fast at doing this, but on a very busy server, with many content requests per second, a ‘Hash Generation ‘queue may form. This can mean that a client system which requests content will not be able to utilize BranchCache as the hash is not available yet, and the client will simply download the content and cannot place it into the BranchCache cache or locate the content on peer systems. Hashes can be pre-generated to mitigate this, and this is explained in a later section. You don’t really need to know this but.. here’s what a BranchCache Hash consists of: **Server Secret** – Shhh. Used as a key in order to create a content-specific hash that is sent to clients. **Hash of Data (Hod)**– the juice, the magic, the stuff dreams are made of. It’s what BranchCache uses to make sense of the files it needs to download. **Segment Secret** – Used as the encryption key to generate the Segment ID (along with the HoD) **Segment ID** – Used to locate the content once the Hash is downloaded {% endhint %} #### Segments and Blocks BranchCache’s currency is Segments. You can think of a segment as a ‘*Unit of Discovery’*. That is to say, it’s what the BranchCache client asks for when it’s on the hunt for requested data once it has the Hash for that content. In V1 - within that segment there are Blocks, which are the ‘*Unit of Download’*. So these are the individual chunks of data that are downloaded once the segment is found. Chopping things up like this means that the network isn’t clogged by these 32Mb segments flying around in one lump. In V2 however it changes quite significantly. Read on. **Windows 7/WS2008R2 (Version 1.0)** *Content* is divided into *Segments,* which is further divided into *Blocks*. A Segment is a Binary string of 32Mb - and the last segment of a file can of course be less than 32Mb unless the content divides into exact 32Mb chunks. The Block Size for Version 1.0 is 64k –again the last block can be smaller for obvious reasons. The important thing to remember here is that if a file has a change at the beginning of the file, with V1.0 content, you would invalidate the entire segment because all of the block sizes are fixed and would therefore change. So a change in a file results in at least a 32Mb download (in files bigger than 32Mb of course!) **Windows 8.x/WS2012 (Version 2.0)** V2.0 does away with these fixes size blocks, because the segment ‘chunking’ algorithms used result in variable block sizes of 32-128k. So we really don’t have the same distinction of Segment and Blocks. V2.0 uses Deduplication algorithms – to determine those block sizes. So in a file change scenario with V2 and its use of variable block sizes, it’s more likely that the blocks later in the file will still be the same, and only those blocks that have changed need to be downloaded. V2 also uses the Deduplication technology introduced in WS2012/16 but this will be covered later in this document, as it’s freaking awesome. Basically duplicate blocks of data are not downloaded by V2 BranchCache which makes for massive savings across files with identical data blocks such as WIM files or Documents etc. ### The BranchCache Caches “Where’s My Cheese?” The BranchCache Cache is a database of content, and/or hashes of content. Simple. BranchCache Maintains two caches, both on the Content Server and Client. It’s important to learn to distinguish between the two. By default, these are located at: **%WINDIR%\ ServiceProfiles\NetworkService\AppData\Local** #### The Publication Cache – **\PeerDistPub** folder The is the **HashCache** – where generated hashes are stored.\* **Content Server –** the Hash Cache is populated is content requests come in to the server. **Client System –** the Hash Cache is usually empty, unless content is injected (imported). *\*If Windows Server Deduplication is enabled, the BranchCache HashCache can be empty, as BranchCache (V2) is designed to utilize the Deduplication Chunk Store.* #### The Republication Cache – \PeerDistRepub folder This is the DataCache – where content is stored (and hashes that were downloaded by the client – but mostly content) **Content Server** – Usually empty (unless the content server itself is a client), as the content server only needs to generate the Hashes of the data. The Content is already stored (as files). **Client System** - The data cache will be populated with downloaded BranchCache content. ### Security Here is a typical BranchCache operation from a security viewpoint. Server authenticates the client and performs authorization checks. Server transmits content information structure to the client only if the client has access. Transfer happens over the accelerated protocol –HTTP/S etc. Client uses content information structure to calculate: -segment id (public) -encryption key (private) Client multicasts the **segment id** to find a peer with the data. Client downloads encrypted blocks from a peer and decrypts them with the **encryption key** Cached data is stored in encrypted form in the BranchCache Cache The above is Out-Of-The-Box behaviour. No further security configuration is required. {% hint style="info" %} Note: Data in the Cache is not encrypted on Windows 7 but is on Windows 8 and above. But on even if it’s not encrypted on Windows 7 you cannot browse this info and need a high privilege account to access it. Data transferred over the wire is encrypted. Data in the Cache is not stored by file but by hash. So even if you know the name of the file you can’t get the data. In order to get to the data, you need to be admin and have the hash which is protected by the login to the IIS server. {% endhint %} ## BranchCache Configuration ### Cache Management The simple rule for cache management is that on Content Servers you need to configure the HashCache, and on Clients it’s the DataCache. So here’s what you can configure with regards to the cache. #### **Location (V1/V2)** You don’t have to accept the defaults for BranchCache cache location – you can move it to another drive for instance. #### **Size (V1/V2)** Size does of course matter in the BranchCache world. Default 5% of disk space for the Data Cache, and 1% for the Hash Cache – on both Content Servers and Clients. {% hint style="info" %} TIP: For servers , you can calculate the size of the Hash Cache that you might need. Hashes are around 1/2000th the size of the original content, so if you know the total content that the server will be providing you can set the cache size accordingly. In a mixed (V1/V2) client environment – bear in mind that you will need double the space as V1 and V2 hashes are different. {% endhint %} **Segment Age (V2 Only)** This applies to the data cache only, and specifies the default age in days for which segments are valid. The default is 28 days and you can increase this to 9999 if you so wish. **BranchCache Cache in Windows 10** Windows 10 clients can now benefit from dynamic cache resizing. This means that you can set a large Data Cache size – safe in the knowledge that the Cache will dynamically shrink if the system experiences a Low Disk Space event. Segments in the cache will be removed based on the ‘last accessed’ date, so that content that is frequently used will be left alone, while the older segments will be removed first.. #### Configuring the Cache Size V1/2 – Using Netsh.exe Specifies the size of the local cache as either a percentage of the size of the hard disk where the cache is located or as an exact number of bytes. Syntax: For the DataCache: ``` Netsh.exe br set cachesize [ size= ]{ DEFAULT | Number } [[percent= ]{ TRUE | FALSE } ] Netsh br set cachesize 123456 (sets the size in bytes) Netsh br set cachesize size=20 percent=TRUE (sets the size in % of disk) ``` For the HashCache: ``` Netsh.exe br set publicationcachesize [ size= ]{ DEFAULT | Number } [[percent= ]{ TRUE | FALSE } ] Netsh br set publicationcachesize 123456 (sets the size in bytes) Netsh br set publicationcachesize size=20 percent=TRUE (sets the size in % of disk) ``` V2 – Using PowerShell Use Get-BCStatus to see the current Cache locations and sizes: ![](/files/7qgMtfABLhLTFdj5cPF8) To configure the HashCache with PowerShell, you need to get the WMI instance, and feed it to the set-bccache cmdlet. See below: ``` Get-CimInstance -ClassName MSFT_NetBranchCacheHashCache -Namespace root\standardcimv2| set-bccache -Percentage 10 ``` To do the same for the DataCache: ``` Get-CimInstance -ClassName MSFT_NetBranchCacheDataCache -Namespace root\standardcimv2| set-bccache -Percentage 50 ``` #### Changing the Cache Locations In some cases you may want to change those default Cache locations – easy peasy: V1/2 Remember that the default location is - **%WINDIR%\ServiceProfiles\NetworkService\AppData\Local\PeerDistRepub** ``` Netsh.exe br set localcache DEFAULT – Sets the DataCache back the the above default Netsh.exe br set localcache directory=C:\BranchCache\DataCache – Sets the DataCache to an alternate location ``` And the HashCache? Remember that the default location is - **%WINDIR%\ServiceProfiles\NetworkService\AppData\Local\PeerDistpub** ``` Netsh.exe br set publicationcache DEFAULT – Sets the HashCache back the the above default Netsh.exe br set publicationcache directory=C:\BranchCache\HashCache – Sets the DataCache to an alternate location ``` V2 In PowerShell it’s a case of supplying the old and new cache locations To change the DataCache location: ``` set-bccache -Path "$ENV:WINDIR\ServiceProfiles\NetworkService\AppData\Local\PeerDistRepub" -MoveTo "C:\DataCache" ``` To change the HashCache location: ``` set-bccache -Path "$ENV:WINDIR\ServiceProfiles\NetworkService\AppData\Local\PeerDistPub" -MoveTo "C:\hashcache" ``` #### Setting the DataCache Segment Age Only available in V2 – in V1 it is set to a default of 28 days. This applies to the data cache only, and specifies the default age in days for which segments are valid. The default is 28 days and you can increase this to 9999 if you so wish. PowerShell – pretty simple ``` Set-BCDataCacheEntryMaxAge –TimeDays 100 ``` ### Pre-Generating Hashes V2 Only (2Pint Software Free Tools can be used for V1) To ensure that BranchCache Hashes are always available to clients (remember, No Hash = No Data), you can use the BranchCache PowerShell cmdlets to pre-generate hashes on the BranchCache Content Server. {% hint style="info" %} Note: If using Data Deduplication in Windows Server 2012/16, the Deduplication service will create the hashes for you. So this configuration will not be required. {% endhint %} To generate hashes on a content server, in this case a Microsoft Configuration Manager Distribution Point: ``` Publish-BCWebContent –Path D:\ SCCMContentLib -Recurse ``` The -Recurse switch forces hash generation for content within folders and subfolders under the root folder in the command. {% hint style="info" %} *Tip: If you are frequently adding content you may want to run this command daily as a scheduled task.* {% endhint %} ### Optimizing BranchCache in a Mixed Client Environment Sometimes you may have V1 and V2 clients within the same subnets. This can be complicated but the rules are as follows. If you do nothing, the worst that can happen is that you will have two downloads of the same content per subnet. One will be shared by V1 clients and one by V2 clients. V1 and V2 clients cannot ‘peer’, because the BranchCache Hash and Databases are different V2 Clients Can however, download V1 hashes. This is called ‘downgrading’ and means that you will only need one download per subnet but you will not be able to take advantage of Deduplication. #### Enabling BranchCache Version Support Using Policy Set the ‘Configure Client BranchCache Version Support’ policy for clients of Windows 8 and above. Set it to ‘Windows Vista with BITS 4.0 installed, Windows 7, or Windows Server 2008 R2.’ The Windows 8/10 clients will then only download V1 hashes. Using PowerShell Enable-BCDowngrading This will set the client into V1 mode. Disable-BCDowngrading Will reset things back to V2 ### Enable BranchCache on Client Systems To enable BranchCache to function on a Windows System, the following items must be configured. The BranchCache Service must be configured for the correct mode (Distributed Mode for the purposes of this document) The Windows Firewall must be configured to allow BranchCache Peer Content Retrieval and Discovery. There are quite a few ways to enable BranchCache in Distributed Mode on clients systems. The most common are described below. #### Using Microsoft Configuration Manager Client Settings From Configuration Manager you can configure some BranchCache settings from within the Client Settings node in the Configuration Manager Console. This configures local policy, and enables BranchCache in distributed mode. You can also configure the data cache size this way, but not the Segment Age setting.
#### Using Group Policy In the Group Policy Management Editor console, expand the following path: Computer Configuration > Policies > Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer, Network, BranchCache. Click BranchCache, and then in the details pane, double-click Turn on BranchCache. The policy setting dialog box opens. In the Turn on BranchCache dialog box, click Enabled, and then click OK. To enable BranchCache distributed cache mode, in the details pane, double-click Set BranchCache Distributed Cache mode. The policy setting dialog box opens. In the Set BranchCache Distributed Cache mode dialog box, click Enabled, and then click OK. ![](/files/QmqT2zQXBxfr0icOtrtP) This method alone does not configure the Windows Firewall for BranchCAche however and this must be performed seperately. #### Configure Windows Firewall with Advanced Security Inbound Traffic Rules In the Group Policy Management console, right-click the BranchCache client computers GPO that you created previously. Click Edit. The Group Policy Management Editor console opens. In the Group Policy Management Editor console, expand the following path: Computer Configuration > Policies > Windows Settings > Security Settings, Windows Firewall with Advanced Security, Windows Firewall with Advanced Security – LDAP…, Inbound Rules. Right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Content Retrieval (Uses HTTP). Click Next. In Predefined Rules, click Next. In Action, ensure that Allow the connection is selected, and then click Finish. **Important** You must select Allow the connection for the BranchCache client to be able to receive traffic on this port. To create the WS-Discovery firewall exception, again right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens. In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Peer Discovery (Uses WSD). Click Next. In Predefined Rules, click Next. In Action, ensure that Allow the connection is selected, and then click Finish. **Important** You must select Allow the connection for the BranchCache client to be able to receive traffic on this port. Repeat the above steps for Outbound rules, i.e allowing the following. ![](/files/DlgQGO4lXCDR0R4g9jfo) #### Using Netsh.exe The below command will set the BranchCache service to distributed mode and also configure the Windows Firewall in one go: ``` Netsh.exe br set service MODE=Distributed ``` #### Using PowerShell The following PowerShell command will set the client to use BranchCache in distributed mode. This will also configure the BranchCache service in distributed mode and also configure the Windows Firewall. ``` Enable-BCDistributed ``` ### Configure BranchCache in Configuration Manager Setting up BranchCache with ConfigMgr is relatively easy. BranchCache can be enabled for all deployment types withing ConfigMgr, and will work seamlessly providing that the Distribution Points are all ’BranchCache Enabled’, and Deployments are BranchCache enabled at creation time. #### Enable BranchCache on ConfigMgr Distribution Points To enable and configure BranchCache on a Distribution Point, it’s a simple as checking the following box on the Distribution Point properties. ![](/files/2p1szugbY3aOsnbT10iv) #### Enable BranchCache for Deployments All BranchCache enabled deployments should be configured to ’download content from distribution point and run locally.’ Additionally: Software Update Deployments: Download Settings Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’ Package Deployments: Distribution Points Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’ Application Deployments: Content Tab on the Deployment Type – complete the checkbox ’Allow clients to share content with other clients on the same subnet’ Task Sequences (Current Branch Only): Distribution Points Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’ ### Testing Downloads via BITS and BranchCache This section applies to ConfigMgr but works equally well without. Just use a different content source for testing. Create and distribute a Package containing some files (small and large to test all scenarios). Then you need to get the Package ID – which looks like XYZ12345.6 (XYZ being the sitecode, and it will only have the .x version stamp if it’s been updated at some point), and a file within the package which you will use as the source for the download. Once you have that, just create your URL and put it into the PowerShell below. Once you execute the script – it will prompt you for credentials, so use a relevant domain account with sufficient rights to download the content.. Then – all being well, BITS will connect to the DP, and download the content. Import-Module BitsTransfer \# URL to file on DP $source = " SMS\_DP\_SMSPKG$/CEN00000.0/filename.exe " \# Local file path here $dest = "C:\Temp" $Job = Start-BitsTransfer *-DisplayName* '2Pint Job' -Authentication Negotiate *-Credential* domain.local\administrator -Source $source \` *-Destination* $dest -TransferType Download -Priority Normal -Asynchronous -RetryInterval 60 while (($Job.JobState -eq "Transferring") -or ($Job.JobState -eq "Connecting") -or ($Job.JobState -eq "TransientError") -or ($Job.JobState -eq "Suspended") ) \` { **sleep** 5;} # Poll for status, sleep for 5 seconds, or perform an action. Switch($Job.JobState) { "Transferred" {Complete-BitsTransfer -BitsJob $Job} "Error" {$Job | **Format-List** } # List the errors. default {$Job | **Format-List** } # Perform corrective action. } Checking the results **On the DP server** – Check the BranchCache Kernel mode perfmon counters for: BranchCache aware HTTP requests Total Hash generations Accepted (if it’s a new file and no other clients have requested it yet) Total Hash Retrievals Accepted The above counters will tell you if BranchCache is functioning, and that your http requests are making it through Note: If are you using De-Duplication on the volume that stores the packages on the DP, you won’t see any Hash creation stats in perfmon because it is likely using the Deduplication chunk store hashes. **On the Client** Check the BITS Event Log – Applications And Services – Microsoft – Windows – BITS-Client-Operational Event 3 – BITS Job is created Event 59 Your file gets added to the BITS job Event 60 – File is copied – you can check to see if the peerProtocalFlags is set (it should be 1 if you are BranchCaching) Event 4 – Job done, and you can see how much was copied from the DP vs Peers ### BITS Optimization and Bandwidth Throttling Although this document describes BranchCache operations, in most Content Distribution scenarios, the Background Intelligent Transfer Service BITS) performs the actual download. BITS is heavily integrated with BranchCache, and can be optimised for BranchCache enabled downloads. BITS Policy there are 2 Group Policies that provide fairly granular control of BITS bandwidth usage during working / non-working days/hours and during scheduled maintenance days/hours. These are the only BITS policies that you should consider using, as they are the most recent and efficient available. TIP:Do NOT use the ConfigMgr Client Setting BITS policy as it is old and not configured for optimal BranchCache downloads. The 2 GPOs can be found under Computer Configuration -> Administrative Templates -> Network -> Background Intelligent Transfer Service 1 Set up a maintenance schedule to limit the maximum network bandwidth used for BITS background transfers 2 Set up a work schedule to limit the maximum network bandwidth used for BITS background transfers #### The Work Schedule This is the general day to day BITSPolicy setting used throughout your network. This policy setting limits the network bandwidth that Background Intelligent Transfer Service (BITS) uses for background transfers during the work and non-work days and hours. The work schedule is defined using a weekly calendar, which consists of days of the week and hours of the day. All hours and days that are not defined in a work schedule are considered non-work hours. If you enable this policy setting, you can set up a schedule for limiting network bandwidth during both work and non-work hours. After the work schedule is defined, you can set the bandwidth usage limits for each of the three BITS background priority levels: high, normal, and low. You can specify a limit to use for background jobs during a work schedule. For example, you can limit the network bandwidth of low priority jobs to 128 Kbps from 8:00 A.M. to 5:00 P.M. on Monday through Friday, and then set the limit to 512 Kbps for non-work hours. If you disable or do not configure this policy setting, BITS uses all available unused bandwidth for background job transfers. ![](/files/ktzD0j2smA0KflhhYSLq) The Work Schedule is shown above. Of particular note, is the checkbox at the top left of the ’Options’ pane, entitled ’Ignore bandwidth limits if the source and destination are on the same subnet’. This box must be checked as it allows BranchCache-enabled BITS transfers between Peers on the same subnet to transfer at higher speed (up to 60Mb/s). If this is not checked, Peer-to-peer transfers will only happen at the current throttled speed. #### The Maintenance Schedule This policy setting limits the network bandwidth that Background Intelligent Transfer Service (BITS) uses for background transfers during the maintenance days and hours. Maintenance schedules further limit the network bandwidth that is used for background transfers. This means that it overrides the work schedule and these values take presence. If you enable this policy setting, you can define a separate set of network bandwidth limits and set up a schedule for the maintenance period. You can specify a limit to use for background jobs during a maintenance schedule. For example, if normal priority jobs are currently limited to 256 Kbps on a work schedule, you can further limit the network bandwidth of normal priority jobs to 20 Kbps from 8:00 A.M. to 10:00 A.M. on a maintenance schedule. If you disable or do not configure this policy setting, the limits defined for work or non-work schedules will be used. The bandwidth limits that are set for the maintenance period supersede any limits defined for work and other schedules. ![](/files/bgQ8Nx8C1rQH06Vqzaja) #### BITS and BranchCache FlashCrowd Events A Flashcrowd event occurs when BITS/BranchCache are clever enough to detect that it’s downloading a segment that has been requested by many other clients. BranchCache generates a message to the BITS service – to the effect that you will see a burst (usually 15) of Events in the BITS event log with an ID of 208. This tells the BITS client to wait’, because someone is downloading the content that is being requested and it may be available soon. The net result of this is that even if you have a ConfigMgr deployment where all of the clients execute the content download at the same time, all is not lost. Tweaks You can also configure BITS Flash-Crowd behavior via the registry so that those back-off intervals can be increased – which you may want to tweak if your clients are on the end of a particularly slow WAN link. There are 3 entries that count are here: HKEY\_LOCAL\_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\ MaximumBackgroundCacheRetries HKEY\_LOCAL\_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\ MaximumForegroundCacheRetries These values determine the number of retries depending on whether the BITS job in question is a FOREGROUND or BACKGROUND priority job. HKEY\_LOCAL\_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\CacheRetryIntervalMsec This next value determines the interval between the retries, so in reality you may want to just edit this, which will increase the overall back-off period. By default, this is set to 1000 (1 second) So you can double the back-off just by changing this to 2000 #### Other BITS Tips 1. When using a speed over 2048 Kbit/s set the policy to use Mb instead of Kb. It just works better. 2. If you are on Windows 7, always apply Fixes an issue where BITS can ignore Policy and goes as fast as it can. 3. BITS stops doing BranchCache if it didn’t get the hash data the first 3 attempts. This is hardcoded. 4. Always use a BITS policy for BranchCache downloads! It just works better.. ### BranchCache and Windows Server Data Deduplication One of the most advance features of BranchCache with V2 was the integration with Data Deduplication in Windows Server 2012/16. With this new innovation, BranchCache can perform deduplication on an actual transfer and on its own Cache storage. In addition, BranchCache will use the Deduplication chunk store for hash retrieval, which saves on processing time and resource. #### What is Data Deduplication? Deduplication is used to improve storage utilization and can also be applied to network data transfers to reduce the number of bytes that must be sent across the wire. In the deduplication process, unique chunks of data, or byte patterns, are identified and stored during a process of analysis. As the analysis continues, other chunks are compared to the stored copy and whenever a match occurs, the redundant chunk is replaced with a small reference that points to the stored chunk. Given that the same byte pattern may occur dozens, hundreds, or even thousands of times (the match frequency is dependent on the chunk size), the amount of data that must be stored or transferred can be greatly reduced. #### Deduplication Evaluation To aid in the evaluation of datasets Microsoft created a portable evaluation tool. When the Deduplication feature is installed, DDPEval.exe is installed to the \Windows\System32\ directory. This tool can be copied and run on Windows 7 or later systems to determine the expected savings that you would get if deduplication was enabled on a particular volume. DDPEval.exe can be run on a Content Server and the output will tell you of the potential savings. Certain types of data are particularly suited to deduplication as there are many common data block within the structure. Examples are .WIM files, Word Documents, Driver Libraries etc. #### Deduplication Configuration **Configure and run DeDuplication on a ConfigMgr Distribution Point** Because BranchCache uses the DeDupe chunk store to get hashes we need to ensure that when Deduplication runs, it is considering all files. You can do this by running the following PowerShell. We don’t want to DeDupe ALL of the folders however. ConfigMgr doesn’t like you to DeDup the Content Source folders (not supported), all we really want to hit is the Content Library itself (the \SCCMContentLib folder at the root of the drive), and we can do this by excluding the other ConfigMgr folders that we don’t want, namely the *SMSPKG,SMSPKGSIG and SMSSIG$ folders* ``` $dedupVolume = "E:" #(set the drive letter here) Set-DedupVolume -Volume $dedupVolume -MinimumFileAgeDays 0 –ExcludeFolder $dedupVolume\SMSPKG, $dedupVolume\SMSPKGSIG, $dedupVolume\SMSSIG$ Write-Output "Starting Dedup Jobs..." $j = Start-DedupJob -Type Optimization -Volume $dedupVolume $j = Start-DedupJob -Type GarbageCollection -Volume $dedupVolume $j = Start-DedupJob -Type Scrubbing -Volume $dedupVolume do { Write-Output "Them Dedup jobs is running. Status:" $state = Get-DedupJob | Sort-Object StartTime -Descending $state | ft if ($state -eq $null) {Write-Output "Completing, please wait..."} sleep -s 5 } while ($state -ne $null) #cls Write-Output "Done DeDuping" Get-DedupStatus | fl * ``` So the above snippet with configure DeDupe to include all files, except those in folders that we excluded. It the runs the necessary Deduplication jobs on the volume and places the hashes in the chunk store ready for BranchCache clients to access. ### Reporting on BranchCache Success Although BranchCache works well in reducing WAN traffic it’s often difficult to tell when it is or isn’t working. Here are some methods of measuring BITS and/or BranchCache performance. #### Event Log The BITS Event Log provides information as to where the BITS download data originated from. Event 4 – on completion of a download will provide this info. #### BranchCache Performance Counters One way to check if BranchCache is being used is to monitor the BranchCache performance counters, these three counters in particular: *Retrieval: Bytes from cache*—This shows how much data is being obtained via BranchCache instead of directly from the source server. *Retrieval: Bytes from server*—This shows how much is being obtained directly from the source server, not from BranchCache. *Retrieval: Bytes served*—This shows how data from the local machine's BranchCache has been sent to other BranchCache clients. This saves other clients from obtaining the data from the original source. {% hint style="info" %} TIP: In Testing, you can reset the BranchCache perfmon counters using the following PowerShell cmdlet: **Reset-BC -ResetPerfCountersOnly** There is a full list of the counters with descriptions here: {% endhint %} #### 2Pint Reporter Toolset This can give you a more graphical representation of a download in real-time. (shown n below) You can download this free tool from ![C:\Users\administrator\Pictures\bits\_bc\_anatomy.png](/files/eXSYP3VelWRszSCNeUsC) ### Summary That’s all for now, hope it was useful. This is very much a work in progress and we plan to add further docs around BranchCache as and when we get the time. Any ideas on what you would like to see next? Ping us over at: ### Appendix A BranchCache Netsh.exe commands: BranchCache PowerShell Cmdlets: MSDN Peer Distribution APIs: # StifleR WMI provider Windows Management Instrumentation (WMI) is a Command and Control (C\&C) infrastructure that is integrated within Windows. It provides three primary capabilities: * Exposing state information regarding a configurable entity * Invoking control methods on a configurable entity * Publishing events from a configurable entity These facilities are a complete instrumentation solution for any Windows application, and multiple system components expose information through the use of WMI providers. This information can be consumed from a multitude of languages and technologies by WMI consumers, using a standard query language (WQL). The StifleR server interface for automation is a WMI Provider In practical terms this means the administrator uses a WMI interface to communicate and control the StifleR server component. The primary advantage to using WMI in favour of other communication technologies that abound is that WMI is a standardized C\&C mechanism which can be consumed by numerous existing C\&C frameworks. Most Windows components expose C\&C information using WMI, and it is preferable that a single C\&C framework is used instead of reinventing a C\&C framework for each individual component. This makes a single C\&C tool suitable for a variety of configurable and controllable entities. Most automation of StifleR is done through the StifleR WMI Provider. This is present under the [\\\\](file:///\\\ROOT\StifleR)[ROOT](file:///\\\ROOT\StifleR)[\\](file:///\\\ROOT\StifleR)[StifleR](file:///\\\ROOT\StifleR) WMI namespace on the StifleR server itself.
### Updating Values StifleR is a multithreaded asynchronous service, which means that the changes done through WMI cannot be guaranteed. A change might return the original value and not the changed value, so keep this in mind when scripting against StifleR. If the returned value does not match the value that you are attempting to write it has not been successful and will have to be retried. After creating or making configuration changes, you should check to ensure that the value you to set has been changed to what is actually running. Some values are checked as part of the function to ensure that the change was successful and will return a failure if not. But some simple value changes have to be verified, as the underlying code runs asynchronously and on multiple threads in order to maximize performance. The reason StifleR has been designed to work this way is because the internal workings are running on multiple threads asynchronously which may or may not have write access to the internal data structures at any given time. Rather than waiting for a lock to be lifted, using precious resources, the data is flushed to free resources. This allows StifleR to support an extreme large number of simultaneous connections. For example, if you are trying to set the TargetBandwidth for a Location, make sure that there is a check for the running value after the Set command and make sure that the value has in fact been updated. ### Listing Method and Instance Parameters ``` Using WMI with the CALL and GET /? parameters will give the following outputs: C:\>wmic /namespace:\\root\stifler path StifleREngine CALL /? Method execution operations. USAGE: CALL [] NOTE: ::= | , The following verb(s)/method(s) are available: ``` | `Call` | `[ In/Out ]Params&type` | `Status` | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------- | | `GetErrorDescription` |

\[IN ]errorcode(uint32)

\[OUT]ReturnValue(string)

| `Implemented` | | `GetErrorDescriptionFromString` |

\[IN ]hexcode(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `ModifyJobs` |

\[IN ]action(string)

\[IN ]force(boolean)

\[IN ]jobName(string)

\[IN ]StifleRTypeName(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `Notify` |

\[IN ]messageLine1(string)

\[IN ]messageLine2(string)

\[IN ]messageLine3(string)

\[IN ]picturePath(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `RunCmdLine` |

\[IN ]arguments(string)

\[IN ]fileName(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `RunPowerShellScript` |

\[IN ]script(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `TestFunction` | `[OUT]ReturnValue(string)` | `Implemented` | | `UpdateRules` |

\[IN ]fileUrl(string)

\[IN ]Target(string)

\[IN ]useBits(boolean)

\[OUT]ReturnValue(string)

| `Implemented` | | `UpdateServerList` |

\[IN ]reconnect(boolean)

\[IN ]ServerList(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | | `WOL` |

\[IN ]MAC(string)

\[IN ]Target(string)

\[OUT]ReturnValue(string)

| `Implemented` | ``` C:\Windows\system32>wmic /namespace:\root\stifler path StifleREngine GET /? Property get operations. USAGE: GET [] [] NOTE: ::= | , The following properties are available: ``` | `Property` | `Type` | `Operation` | | -------------------------- | ----------------- | ----------- | | `ActiveBlueLeaders` | `sint32` | `Read` | | `ActiveNetworks` | `sint32` | `Read` | | `ActiveRedLeaders` | `sint32` | `Read` | | `ClientInfoCompleted` | `sint64` | `Read` | | `ClientInfoInitiated` | `sint64` | `Read` | | `Clients` | `sint32` | `Read` | | `Company` | `string` | `Read` | | `ConnectedUser` | `string` | `Read` | | `Contact` | `string` | | | `DataEngineThreadState` | `string` | `Read` | | `ExpiryDate` | `datetime` | `Read` | | `HubConnectionCompleted` | `sint64` | `Read` | | `HubConnectionInitiated` | `sint64` | `Read` | | `Id` | `sint32` | `Read` | | `JobReporDeltatInitiated` | `sint64` | `Read` | | `JobReportCompleted` | `sint64` | `Read` | | `JobReportDeltaCompleted` | `sint64` | `Read` | | `JobReportInitiated` | `sint64` | `Read` | | `LicensedVersion` | `string` | `Read` | | `Licensee` | `string` | `Read` | | `ListAccess` | `array of string` | `Read` | | `Nodes` | `uint64` | `Read` | | `NumberOfClients` | `sint32` | `Read` | | `RedLeaderRunInfo` | `string` | `Read` | | `RedLeaderSelectionThread` | `string` | `Read` | | `Type` | `string` | `Read` | | `ValidFor` | `string` | `Read` | | `Version` | `string` | `Read` | Some properties will be listed as Operation “Write” which means you can use the SET verb to write to them. To find all items that allows Write, replace GET /? with SET /?. An example how to use the SET operator `wmic /namespace:\\root\stifler path Subnets.SubnetID="192.168.90.44" SET Description=Test` ### Further Reading There used to be a large section in this document devoted to WMI with screen shots and tables explaining each setting in detail. The good news is that this information still exists on the 2Pint Support KB site which you can view if you search for ”StifleR WMIC Command Line Tool” # Backup and recovery This document guides you through a backup and recovery of a StifleR Server. ## Backup Operations StifleR have several components that needs to be backed up in order to do a successful recovery if something happens to the server. The components are: * StifleR Databases * StifleR Configuration File * StifleR License File * StifleR Rules File * Extra scripts ### StifleR Databases Backup of the five StifleR databases can be done either online or offline. The benefit of the online method is that you don’t have to stop the StifleR Server service during backup, but the downside is that it forces you to run a repair job of the database before they can be used in a restore. The offline backup method means stopping the StifleR service during backup, and then start it again after backup has completed. Benefits with this method is that you don’t have to repair the database before a restore. The StifleR databases are using the Extensible Storage Engine (ESE) runtime in Windows (ESENT), and as such are often called ESENT databases. In addition to the core database files, the EDB files, ESE is also using recovery logs which are in the same folder as each database file. By default, the databases are stored in C:\ProgramData\2Pint Software\StifleR\Server\Databases , and while the StifleR databases are not very big, we recommend storing them on data volume rather than the OS volume. ![The five database files in their default location.](/files/-ME0WIJWJzISZjBZHSYH) ![A database file and its recovery log files.](/files/-ME0WIJX8T7cGPzkp20v) {% hint style="info" %} Note: The StifleR databases can be migrated to another drive using [this process](/stifler/3.0/guides/backup-and-recovery/moving-the-stifler-server-databases-to-a-new-drive-on-the-same-server). {% endhint %} ### StifleR Configuration File The StifleR Configuration File (StifleR.Service.exe.config) is located in the StifleR Server installation directory. ### StifleR Rules File The StifleR Rules File is often added to the C:\ProgramData\2Pint Software\StifleR\Rules folder, but can be in any folder as long as the IIS virtual directory knows where it is. ### Extra Scripts Additional custom scripts, like maintenance scripts, utility scripts, and generate location scripts should also be included in the daily backup. ## Backup Maintenance Task We recommend that you automate the StifleR backup by scheduling our backup script to run at least once per day. In the [2Pint GitHub repository](https://github.com/2pintsoftware/StifleRScripting/tree/master/Maintenance), we provide a sample script that can be run in either online or offline mode, and if you select the offline mode, the script takes care of stopping and starting the StifleR Server service before and after the backup. The sample scripts also have sections for backing up additional files, like the rules file, that may be stored outside the normal StifleR installation directories. If that’s the case, simply modify the script to reflect your environment. ## Backup Archiving In addition to daily snapshots of the StifleR VM, or traditional daily file-level backup via your regular backup software, we recommend archiving at least a week worth of backup sets on a different server. The StifleR backups sets are quite small, rarely over 10 GB even in larger environments. ## Client Behavior during Backup and Recovery If the client cannot connect to server, due to networking roaming or other issues, the client will try to connect to the next server in the list. Failing to connect to a valid server eventually causes the client go into a disconnected state during which the bandwidth configure for disconnected mode will be applied. Once the StifleR Server has been restored, clients will automatically check in again, and go back to normal operations. ## Recovery Operations Restoring a StifleR Server is straight forward. If you have been using the offline backup, the restore process is a follow: 1. Make sure to install a new VM with the same server name, disk layout, and OS version 2. Install the version of StifleR you had before. 3. Stop the StifleR service, delete the empty databases, and restore the ones you have in your backup. 4. Restore the Configuration File 5. Restore the Rules file, and recreate the IIS virtual directory 6. Restore any additional scripts, and re-create scheduled tasks etc. 7. Start the StifleR service For an online backup the process is quite similar 1. Make sure to install a new VM with the same server name, disk layout, and OS version 2. Install the version of StifleR you had before. 3. Stop the StifleR service, delete the empty databases, and restore the ones you have in your backup. 4. Repair the StifleR databases using esentutl /p 5. Restore the Configuration File 6. Restore the Rules file, and recreate the IIS virtual directory 7. Restore any additional scripts, and re-create scheduled tasks etc. 8. Start the StifleR service # Moving the StifleR Server Databases to a New Drive on the Same Server ## Summary The 2Pint StifleR Server, by default, stores its databases in the %ProgramData% folder which is typically located on the C: drive. In some cases, an admin might want to move the databases to another drive. The steps below describes the process of migrating the StifleR databases to another folder on the same server. ## Procedure 1. On the server hosting the StifleR server, create a new folder where you would like to store the databases. In this example, the folder will be **D:\StifleRDBs**. 2. **Stop** the "2Pint Software StifleR Server" service. 3. Copy the folder structure from **C:\ProgramData\2Pint Software\StifleR\Server\Databases** to the folder created in step 1, Ex: **D:\StifleRDBs**. 4. To modify the configuration, you will need to edit the **StifleR.Service.exe.config** and **appSettings-override.xml** files. It is recommended to make a backup copy of the file before proceeding. The file is located in the installation directory in which StifleR was installed. 5. Open a text editor as administrator and edit the **StifleR.Service.exe.config** file. 6. In the StifleR.Service.exe.config file, under the **\** line, add the following: ``` ``` 7. **Save** the StifleR.Service.exe.config file then **start** the "2Pint Software StifleR Server" service. 8. Check the **Event Viewer** - **Applications and Services Logs** - **TwoPintSoftware** - **StrifleR.Service** - **Operational** and check for errors. ## Verification 1. Open the StifleR Dashboard and verify that you can logon and verify that the data is available as expected, specifically your Networks. 2. If all looks well, feel free to delete the **Databases** folder under: C:\ProgramData\2Pint Software\StifleR\Server. If not, see the next section to Backout of the change. ## Backout 1. If an error occurred and you need to restore the previous configuration. Stop the **2Pint Software StifleR Server** service. 2. Restore the backup copy of the **StifleR.Service.exe.config** and start the **2Pint Software StifleR Server** service. # Maintenance tasks The StifleR Server(s) needs regular maintenance like any other critical infrastructure to function effectively and continuously. In this section you find an operations guide that the sysadmin or operations team can follow to maintain a StifleR Environment. The guide is divided in to daily, weekly, monthly, and quarterly operation tasks. In general the tasks described in these documents should be implemented into whatever ticketing system that is being used, such as Service Now, Remedy or Zendesk. ## Daily Maintenance Tasks 1. Verify that the nightly backup was successful 2. Check free disk space on all volumes on the StifleR Server (s) 3. Review the StifleR Server Event log 4. Review the StifleR Resource Manager log (if implemented) ## Weekly Maintenance Tasks 1. Review all daily tasks 2. Review and disk space usage on the StifleR Server(s), and compare to previous week to see trends etc. 3. Verify that networks haven’t changed (boundaries etc.) ## Monthly Maintenance Tasks To be added, but these are for preparing for upgrades, and to establish long term trends. Usually scheduled meetings with workplace managers and other team members. ## Quarterly to semi-annual Maintenance Tasks 1. Review the security plan for any needed changes 2. Change accounts and passwords if necessary according to your security plan 3. Review the maintenance schedule for upgrades to the StifleR platform 4. Check StifleR performance to ensure changes have not been made that affect operations 5. Review the disaster recovery plan for any needed changes 6. Perform a site recovery according to the disaster recovery plan in a test lab # Troubleshooting #### Debug Logging Levels For both Client and Server, Debug Logging has 6 levels 1 = Errors Only 2 = Warning 3 = OK 4 = Informative 5 = Debug This is set via the Configuration value: `` {% hint style="warning" %} WARNING – Debug Logging should not be enabled on a production server for anything other than troubleshooting purposes and should only ever be run for a maximum of about 5 minutes at a time before disabling (0) {% endhint %} #### StifleR Server 1. Logs – there are many! 1. Enable at installation using DEBUGLOG=n .msi switch (n Debug levels 1-6 available) 2. Enable after installation by editing the **StifleR.Service.exe.config** file – `` (n Debug levels 1-5 available). Service restart not required 2. StifleR Service events are logged in the Windows Event Log at Event Viewer > Applications and Services Logs > StifleR 3. Verbose logging can be viewed (for a short time only!) through a command window by running the executable directly in Interactive Mode. You must stop the Service first! **TIP** – If you have an installation that does not complete or a service that refuses to start. Fire up the executable in interactive mode and check any error messages that appear. 4. WMI See this guide and the 2Pint KB 5. Dashboards – Lots of information in the Dashboards to help with troubleshooting. The Performance Dashboard in particular gives you some at a glance Server health information 6. Power Shell troubleshooting script (contact 2Pint Support for the latest) #### Dashboards and Access Check You can test access to StifleR using the following URLs – http(s)://FQDN.OF.STIFLER.SERVER:9000/api/test Which will list the group membership and access rights of the current user http(s)://FQDN.OF.STIFLER.SERVER /stiflerdashboard/ce.png Which, if working correctly, will show the .png 2Pint Software Logo image from the dashboard folder. #### StifleR Client 1. Client.log 1. Enable at installation using DEBUGLOG=n .msi switch (n Debug levels 1-6 available) 2. Enable after installation by editing the StifleR.ClientApp.exe.config file – `` (n Debug levels 1-5 available) Service restart not required 2. StifleR Service events are logged in the Windows Event Log at Event Viewer > Applications and Services Logs > StifleR #### BITS Command Line tool >BITSADMIN {% hint style="info" %} NOTE: This is something you should be familiar with if you are testing with BITS technologies associated with 2Pint tech. {% endhint %} #### BranchCache etc 1. CMD Line >netsh br show status all – will get you started 2. Microsoft P2P Reporting – see 2Pint KB for how to enable this feature on your test servers 3. 2Pint Reporting Tools – particularly the BITSBCReporter Command Line Tool 4. PowerShell 5. Windows Performance Monitor 6. 2Pint Software Web site – all manner of tips and tricks # StifleR client command line options This page covers what command line options can be sent to the StifleR client. The StifleR Client executable accepts various command line arguments which can be used for troubleshooting and configuration. When executing most command lines, the /Service switch should be used. /? - Check the manual for command line options. /Service - Simulates running as a service, should always be used otherwise clients exits. /Locale - Displays OS installed language info /IETW - ETWInstaller.InstallETWManifests /UETW - ETWInstaller.UninstallETWManifest /Set - Sets values in config file as in Key=value format /RemoveFilterDriver - removes the StifleRS.sys filter drivers /ResetPolicy removes the BITS & DO Maintenance Policy /Task - Do not run as a service but as triggered from events, client will exit /jobid: - Command line execution for BITS service, used with /Task /LogEventLevel - 0-5 /Log - specifies which log to display * Bandwidth * BITSBranchCache * DeliveryOptimization * Location * MainLoop * Program * SignalR * TypeDetection /Debug - Waiting for debugger - for development purposes only. # BranchCache across subnets ## Overview To support BranchCache across subnets, StifleR uses the [Blue Leader](/stifler/3.0/operations-and-features/features-overview/client-leader-roles/enterprise-environment-blue-leader) feature that is enabled by default when connecting multiple subnets together to form a location. Here are some troubleshooting tips. {% hint style="info" %} **Note:** For the Blue Leader threads to start, you need to have at least 2 subnets linked in a location, and you need to have at least two active clients on each subnet. Until these requirements are met, there is no visibility in the Blue Leader logs. {% endhint %} ## Blue Leader Troubleshooting Checklist 1. Make sure the Blue Leader firewall ports are opened. If you are using TCP 1337 for BranchCache, the Blue Leader port will be TCP 1338. You also need UDP 3703-3705 open in addition to the default UDP 3702 port for BranchCache 2. Make sure the subnets are configured for Low Bandwidth, and linked together via the Location feature in StifleR. 3. Make sure there are at least two active clients on each subnet. 4. For BranchCache OSD support across subnets, the WinPE Firewall must be disabled after the BCEnabler action has run. In your task sequence, add a run command line step that runs the command: **wpeutil disablefirewall**\ For more information about how to implement BranchCache in OSD, check out the [2Pint OSD Toolkit](https://osd.docs.2pintsoftware.com/). ## Intra-VLAN Transfer Logs and flow The same flow can go bi-directional at any given time, i.e. the diagram below show traffic that is requested in Subnet A from Subnet B, but at the same time Subnet B can be requesting the same (or other traffic from Subnet A). ![](/files/-MAX9ww3nOiw8aC9Hij-) ### Verification methods Verify that the clients are working, on the blue leaders, verify that the ports have been bound OK by running the following command: ``` Netstat -aon | findstr / ":3703" ``` That should return a line with the PID as the last entry. Then that PID entry can be used to verify the rest of the ports: ![](/files/-MAWu2rO_pYxCljggH47) The value of 8824 indicates the PID in this example, so we can use that query all the ports used with the following, similar command: ![](/files/-MAWu2rP8wcAZHgVotwA) You can also query the other ports as per the first way: ![](/files/-MAWu2rQpiW261DhhvxH) Then we want to make sure that the port used to proxy the HTTP traffic is bound OK by the HTTP.SYS, in order to do this we need to run the following command: ``` Netstat -aon | findstr / ":1338" ``` Where 1338 is the default port used to bridge BranchCache traffic in StifleR. The following result indicates that the HTTP server has crashed and not recovered, as no port is bound: ![](/files/-MAWu2rRhpeEfx315_jE) This can be the case, even though the UDP ports are bound. StifleR client 1.9.8 and upwards deals with this in a better way and this scenario should not happen. The result should look like this: ![](/files/-MAWu2rST1esSUoU74UL) ### Detection of traffic It can be hard to troubleshoot this, but on the client that requests the data, you should see connections to Blue Leader that is in the same subnet as the requesting client, the following command will list all connections if run on the requesting client: ``` Netstat -aon | findstr / ":1338" ``` The should then return one or several entries pointing to the Blue Leader. #### Which port is BranchCache operating on? You need to both set the URL acl as well as set the right registry value. ``` netsh http show urlacl | findstr /i "0131501b-d67f-491b-9a40-c4bf27bcb4d4" ``` ![](/files/-MAWu2rTm-FtDwH2lATx) ### Hosted Cache Mode Settings Set the ports in the following location: **Computer\HKEY\_LOCAL\_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerDist\HostedCache\Connection** Reg\_Dword: ConnectPort Reg\_Dword: wListenToPort ![](/files/-MAWu2rUMEdhallxF7TB) # Overview StifleR is designed for organizations committed to network optimization.\ It does not simply reduce WAN bandwidth used — it ensures content is delivered intelligently to end users and endpoints from the best, local sources, while also considering overhead to minimize lag and maximize delivery speed. StifleR utilizes Microsoft peer-to-peer methods, but builds in intelligence, visibility, and control. It provides live data, dynamic traffic shaping, and real-time control for IT teams to understand content distribution flows — whether delivering Windows Updates, Office updates, or business applications. Regardless of whether your ecosystem is built on SCCM, Intune, or hybrid, StifleR guarantees that you're not losing business-critical traffic to content delivery. It empowers IT teams to maintain productivity and limit unnecessary network consumption. ## What does it do? StifleR is designed for organizations committed to network optimization.\ It does not simply reduce WAN bandwidth used — it ensures content is delivered intelligently to end users and endpoints from the best, local sources, while also considering overhead to minimize lag and maximize delivery speed. StifleR utilizes Microsoft peer-to-peer methods, but builds in intelligence, visibility, and control. It provides live data, dynamic traffic shaping, and real-time control for IT teams to understand content distribution flows — whether delivering Windows Updates, Office updates, or business applications. Regardless of whether your ecosystem is built on SCCM, Intune, or hybrid, StifleR guarantees that you're not losing business-critical traffic to content delivery. It empowers IT teams to maintain productivity and limit unnecessary network consumption. ## Why do you need it? StifleR is designed for organizations committed to network optimization.\ It does not simply reduce WAN bandwidth used - it ensures content is delivered intelligently to end-users and endpoints from the best, local sources, while also considering overhead to minimize lag and maximize delivery speed. StifleR utilizes Microsoft peer-to-peer methods, but builds in intelligence, visibility, and control. It provides live data, dynamic traffic shaping, and real-time control for IT teams to understand content distribution flows - whether delivering Windows Updates, Office updates, or business applications. Regardless of whether your ecosystem is built on SCCM, Intune, or hybrid, StifleR guarantees that you're not losing business-critical traffic to content delivery. It empowers IT teams to maintain productivity and limit unnecessary network consumption. ## How it works Without StifleR, there’s no control over competing bandwidth for network traffic. Background updates, media streaming, and file synchronizations all degrade time-sensitive business processes like POS transactions, deployments, or security updates. StifleR is the controller.\ It treats content delivery as a control plane and gives IT full visibility into what's moving across the network — and the power to manage it in real time. * Critical traffic is prioritized * Background content is governed As more endpoints run the StifleR client, the network becomes more efficient: instead of each device downloading content from a remote server, they source it from a nearby local endpoint. With StifleR, your network behaves in a predictable, efficient manner — aligned with your organization's business priorities. ## StifleR architecture and operation StifleR functions as an integration layer built on Microsoft’s methods of content delivery, offering a unified, intelligent approach to managing enterprise downloads. It integrates with: * BranchCache: Enhances Windows’ native WAN optimization and peer discovery across subnets. * Delivery Optimization (DO): Improves Microsoft's P2P engine with policy management, group control, and activity reporting. * Configuration Manager Client Peer Cache: Supports peer-based distribution in SCCM and increases efficiency. * LEDBAT: Recognizes and reports on background traffic to ensure critical communications remain unaffected. All communication is enabled through SignalR, Microsoft’s real-time web communication framework, allowing for persistent bi-directional connections, dynamic orchestration, and real-time telemetry. ### Bandwidth measurement — Beacon Server StifleR Beacon Servers are deployed at content sources (like datacenters or distribution points). They serve as reference endpoints that help clients benchmark bandwidth performance. This enables dynamic adjustments based on live network conditions. ### SignalR communication The StifleR server uses SignalR over OWIN (Open Web Interface for .NET) to create reliable, bi-directional communication with clients and dashboards. * Sessions start as HTTP connections and upgrade to WebSockets for persistent messaging. * While deep understanding of SignalR isn’t required for everyday use, it’s helpful for scripting or advanced customizations. Further documentation on SignalR, SSL configuration, and secure operations can be found on the 2Pint Software Knowledge base. ### StifleR rules The StifleR client checks through its queue of active downloads (both BITS and DO) and then prioritizes them according to a locally held XML configuration file (StifleRulez.xml) which contains a set of rules that are configured centrally by the administrator and automatically downloaded by the 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. As an example, Microsoft Maps sync could be set to a low priority, while Windows Update patches would be set to high. Using this rule set, you can effectively control which downloads should be completed ahead of others. All of these configuration settings can be changed centrally at any time with any such changes automatically replicated to your clients in seconds. # Key innovations Microsoft’s native peer-to-peer technologies — like BranchCache, BITS, and Delivery Optimization — are powerful, but lack the fine-grained control needed to fully protect business-critical bandwidth.\ StifleR bridges that gap with deep visibility and dynamic control over how content is delivered across your network. ### Bandwidth control Out of the box, Microsoft’s Background Intelligent Transfer Service (BITS) allows only broad, static control over bandwidth usage based on generic job priority levels. For example, user-initiated Configuration Manager (CM) downloads default to *Foreground Priority*, which consumes all available bandwidth - regardless of the importance of other traffic or policies in place. StifleR steps in to give administrators real power over these transfers: * Per-job bandwidth and priority controls — Override Microsoft defaults and set custom priorities for specific job types, content categories, or delivery scenarios. * Real-time policy enforcement — Adjust transfer settings dynamically through the StifleR agent, down to the individual download level. * Centralized management — Apply and refine policies from a single console across your entire device estate. **Dynamic, latency-aware throttling** Setting a job’s priority isn’t enough when multiple clients are pulling content from a remote data center over limited WAN links. Static bandwidth caps often lead to congestion, bottlenecks, and a degraded user experience. StifleR goes beyond simple limits by: * Monitoring live network latency during transfers. * Automatically adjusting transfer speeds to keep traffic within customizable QoS boundaries. * Prioritizing critical services and ensuring that background downloads never starve business operations. Whether it’s software distribution, updates, or user-driven downloads, StifleR gives you intelligent control over every byte — ensuring high performance for end users and peace of mind for IT. ### Single site download StifleR revolutionizes how content is distributed across distributed networks by introducing intelligent, dynamic leadership roles — Red Leaders and Blue Leaders — to manage downloads efficiently and reduce WAN saturation. Instead of allowing every client in a subnet to simultaneously pull updates or applications from remote servers, StifleR designates a Red Leader — the most suitable client in that subnet — to act as the primary downloader. This client fetches the required content and then redistributes it locally using Microsoft’s native peer-to-peer caching protocols such as BranchCache or Delivery Optimization. This “single-source-per-subnet” approach dramatically minimizes redundant WAN traffic and accelerates delivery times for all clients on the local network. But StifleR doesn’t stop there. In multi-subnet environments, Blue Leaders are elected to coordinate content sharing across subnet boundaries. These Blue Leaders listen for local discovery broadcasts and forward them to their counterparts across the site, enabling cross-subnet peering. The result: content is downloaded once to the site and shared seamlessly between all peers across the LAN — no matter how segmented the local network might be. This model delivers powerful benefits: * Reduction in WAN usage, especially during large-scale deployments or updates. * Faster delivery times by leveraging the fastest, best-connected clients. * Dynamic bandwidth conservation, where non-leader clients throttle back to prevent link saturation. * Complete visibility and control over which clients act as distribution points, all managed in real-time through the StifleR Dashboard. By managing content delivery this way, StifleR ensures that your business-critical bandwidth stays available while maximizing the efficiency of Microsoft’s native content distribution stack. ## Microsoft protocols and how StifleR enhances them StifleR doesn’t rely on its own proprietary data transfer engine. Instead, it enhances and optimizes Microsoft’s native peer-to-peer and content delivery services. By layering intelligent controls on top of these technologies, StifleR delivers superior performance and centralized management — without replacing the underlying mechanisms. ### BranchCache BranchCache is a tried WAN optimization technology embedded in Windows, that reduces the amount of bandwidth consumed by allowing clients within a site to cache and share content locally. Limitations in Microsoft’s native implementation of BranchCache limit its usability in more difficult network configurations due to the reliance on broadcast-based peer discovery. StifleR solves this problem by adding centralized control, and an expanded peer discovery method. Administrators can centrally configure and administer BranchCache peering policies allowing localized content sharing not only within a single subnet, but also across well-connected subnets at a site, extended the local peer-to-peer content exchange. 2Pint Software takes this a step further by developing a tool to leverage the BranchCache functionality in the WinPE space, so that peer caching is utilized during the Operating System Deployment (OSD) phase. This delivers dramatic reductions in build times, and WAN utilization, when PC imaging and refreshing. This is a significant advantage for businesses in a remote or constrained bandwidth location Key Benefits: * Centralized control over BranchCache behavior and peering scope. * Peer-to-peer sharing across subnet boundaries, not just within a single broadcast domain. * Full utilization of BranchCache even in WinPE, improving OSD efficiency and scalability. * Seamless integration into existing Microsoft content distribution workflows. With StifleR, BranchCache becomes more than just a background efficiency tool — it evolves into a strategic asset for fast, bandwidth-aware content delivery across your enterprise. ### Delivery Optimization (DO) Delivery Optimization (DO) is Microsoft’s modern, HTTP-based peer-to-peer content delivery technology designed to reduce network load by sharing content between devices or offloading downloads to a local caching server. It plays a central role in the distribution of Windows Updates, Microsoft Store apps, Intune content, and more — especially in Windows 10 and later. While DO operates largely under the orchestration of Microsoft’s cloud services, StifleR brings local intelligence and control to the process, transforming DO into a fully manageable enterprise-grade solution. What StifleR adds to DO: * Custom peer group management: Define logical, location-aware peering boundaries so content is shared only among the most relevant clients - whether that’s per site, subnet, or organizational unit. * Policy enforcement: Apply consistent configuration across your environment, ensuring Delivery Optimization behaves in line with corporate standards and network constraints. * Real-time Visibility and reporting: Monitor when and where DO is being used, track peer-sharing effectiveness, and validate that content delivery is functioning efficiently — all through the StifleR Dashboard. Key Benefits: * Minimizes WAN usage by maximizing local peer-to-peer content sharing. * Increases efficiency and predictability of DO behavior across varied network environments. * Provides the operational insight and controls that native DO lacks, especially for larger or more distributed organizations. With StifleR managing your DO infrastructure, you gain enterprise-level governance over Microsoft’s peer-assisted delivery platform — unlocking its full potential while safeguarding bandwidth and user productivity. ### Background Intelligent Transfer Service (BITS) Background Intelligent Transfer Service (BITS) is a Windows service that performs background file transfers using idle network bandwidth. It purpose is to minimizes network disruption by throttling downloads so that they don’t interfere with applications or user activity. BITS is useful for pushing content silently in the background, while there are limited native controls - particularly in enterprise scenarios where policies must be consistent, precise, and visible. **What StifleR adds to BITS:** * Centralized bandwidth policy management: Develop bandwidth usage rules across sites, subnets, and network zones that prevent BITS from overwhelming all available bandwidth — especially across limited WAN links. * Granular throttling controls: Go beyond BITS’s default behavior with the ability to set usage thresholds based on content type, time of day, or job priority. * Visibility into job activity: Monitor BITS traffic in real time, giving IT teams the insight they need to adjust policies dynamically and respond proactively to congestion issues. Key benefits: * Prevents low-priority downloads from competing with mission-critical traffic like video calls, POS transactions, or software deployments. * Ensures consistent BITS behavior across diverse networks and client configurations. * Provides the governance and control BITS lacks natively — reducing risk, increasing efficiency. With StifleR acting as the policy and visibility layer for BITS, organizations can fully leverage its strengths while eliminating its blind spots — ensuring content moves efficiently without compromising other key services. ### LEDBAT LEDBAT (Low Extra Delay Background Transport) is Microsoft’s latency-sensitive protocol for background data transfers. It is designed to scale data throughput automatically based on network conditions in real time, using only available bandwidth, and deferring immediately to higher priority traffic as it occurs. LEDBAT can be very beneficial in Configuration Manager distribution points, which require large amounts of content data to be transferred in a way that does not disrupt important and/or critical business activity Native LEDBAT limitations:\ By default, LEDBAT operates silently, with little to no built-in reporting or control. Administrators often lack visibility into which transfers are using LEDBAT or how it's impacting performance. How StifleR enhances LEDBAT functionality: * Transfer-level visibility — StifleR identifies and reports which content transfers are using LEDBAT, providing a clear view of background bandwidth activity. * Performance monitoring — Real-time telemetry shows how LEDBAT behaves across endpoints, helping teams evaluate its effectiveness and tune policies accordingly. * Operational confidence — With full insight into LEDBAT traffic, administrators can trust background transfers to remain non-intrusive and aligned with business priorities. Outcome:\ StifleR transforms LEDBAT from a passive background feature into an actively monitored and controlled component of your enterprise content delivery framework. # Your DeployR guide {% hint style="warning" %} Documentation for DeployR is continually being updated. You may notice frequent changes as content is added and refined. {% endhint %} Welcome to the DeployR documentation site. DeployR is a modern OS deployment platform from 2Pint Software, built to perform bare metal OS deployments using a flexible task sequence-based engine that allows for scale and efficiency. DeployR uses a web-based console for centralized management. DeployR gives the power back to the IT team, allowing complete management of the whole imaging and provisioning lifecycle, whether that is deploying to hundreds of branch offices or in a lab environment. DeployR provides the tools and the framework to do this consistently and accurately.\ \ In this documentation, you will find everything you need in order to properly deploy DeployR into your own environment, from infrastructure considerations and installation through to production deployments. ## Two editions, same platform [DeployR Enterprise](/deployr/setup-deployr-enterprise/prerequisites) is a fully-supported platform with advanced capabilities; [DeployR Community](/deployr/setup-deployr-community/prerequisites) is supported through the community itself. The installation and configuration processes are different between the two: while DeployR Enterprise is designed for the utmost flexibility, DeployR Community is intended for those who need simplicity. Follow the appropriate setup documentation for the edition that you are using. Of course the upgrade process from DeployR Community to DeployR Enterprise is easy, so if you need more advanced capabilities and support from the 2Pint Software experts, just let us know. # Release notes {% updates format="full" %} {% update date="2026-07-29" %} ## DeployR 1.3.2631.2242 * Fixed an issue that prevented upgrading DeployR Community if PowerShell 7.6.4 was already installed (#20172). {% endupdate %} {% update date="2026-07-28" %} ## DeployR 1.3.2631.2234 * Fixed an issue that prevented BitLocker TPM+PIN support from working (#20166) * Fixed an issue that would overwrite changes made to the passcode when upgrading DeployR Community (#20153). * Fixed an issue that could cause the DeployR Community upgrade process to fail when updating 2PXE, causing a rollback (#20164). * Added support for a "SHUTDOWN" finish action when using audit mode (#20139). * Modified the "Register with Autopilot" step to allow configuring the timeout (#20170). * Modified the GeneratePPKG.ps1 script to add additional diagnostic logging (#20162). * Upgraded DeployR Community to included 2PXE 4.0.2630.438. * Updated to .NET 10.0.10 and PowerShell 7.6.4; regenerate your boot images and update media after upgrading to this release. {% endupdate %} {% update date="2026-07-16" %} ## DeployR 1.3.2629.2187 * Fixed an issue that caused driver packs with no tags to be ignored (#20129). * Fixed an issue that could result in local computer PowerShell write access being denied (#20128). * Added a new "Boot" option to the New-DeployRMedia PowerShell cmdlet to create a bootable USB key with no other content (#20136). * Fixed an issue that could cause log files to initially be written to the C: drive before the drive was formatted (#20141). * Updated DeployR Community to include StifleR 3.1.2629.647, which includes the following improvement: * Modified the task sequence editor UI to prevent accidental task sequence deletions (#20137). * StifleR and StifleR Dashboard 3.1.2629.647 are recommended for DeployR Enterprise. * Update DeployR boot images and media after upgrading to this build. {% endupdate %} {% update date="2026-07-03" %} ## DeployR 1.3.2627.2141 * Fixed a compatibility issue with Windows Server 2022 that could cause issues extracting WIM files using PowerShell due to a missing -Index parameter (#20069). * Added logic to write the DISM output from driver injection steps into the DeployR logs folder so that it is captured by the log upload process (#20080). * Fixed an issue that caused the wrong content purpose (e.g. application instead of driver pack) to be assigned when creating content items via PowerShell (#20047). * Added logic to ensure that a bad driver in an OEM driver pack does not cause the task sequence to fail. Instead, a warning will be logged and a copy of the setupapi.offline.log will be copied to the DeployR logs folder so that it gets uploaded for troubleshooting (#20082). * Note that this has been observed with the Dell QxS1250 driver pack; the included NVidia video driver does not properly specify the location of required files referenced in the .INF file. * Improved driver pack selection logic to use product IDs (e.g. the four-character IDs used by Dell and Lenovo). When injecting OEM driver packs via "Install drivers from cloud" the product IDs are automatically matched; when injecting driver packs using content items and "Install drivers" the product IDs can be specified as tags (#20090). * Fixed an issue that caused the Dell driver pack version to be specified twice in the content item name when importing an OEM driver pack (#20046). * Adjusted the DeployR UI in Windows PE to automatically set the focus to the first text field on various wizard panes (#20077). * Added the ability to specify full disk encryption (instead of used space only) in the "Enable BitLocker" step (#20089). * Fixed an issue that resulted in a null SystemAlias value for QEMU VMs; this will now always be set to "QEMU" (#20092). * Added the "WinPE-Dot3Svc" package to Windows PE by default for convenience when using 802.1x authentication (#20095). * Fixed an issue that caused content items to not be filtered correctly when selecting items in the task sequence editor. This requires StifleR 3.1.2627.641 (#20062). * Added support for new Postinit.ps1 and Postauth.ps1 scripts when initializating Windows PE. The existing Preinit.ps1 is called before networking has been initialized; Postinit.ps1 is called after networking has been initialized but before authentication has been performed; Postauth.ps1 is called after authentication is complete (#20096). * Fixed an issue that could result in an SSL error when attepting to communication with the DeployR server after a period of time (e.g. requesting a driver pack after applying an OS) (#20098). * Updated the DeployR Community certificate generation and renewal logic to only generate a certificate when needed. This uses the TwoPint.DeployRCommunity.Configure.exe program, which can be used to renew 2Pint-issued certificates that are close to expiration. These certificates have a 90-day lifespan (#20071). * Updated the DeployR Community installer to include StifleR 3.1.2627.641; upgrading to DeployR Community 1.3.2627.2141 will upgrade StifleR automatically. {% endupdate %} {% update date="2026-06-23" %} ## DeployR 1.3.2626.2093 * This is the initial DeployR 1.3 release, for both DeployR Enterprise and DeployR Community. For DeployR Enterprise, StifleR 3.1 is required. (DeployR Community installs all dependencies automatically.) * Moved to .NET 10.0.9 and PowerShell 7.6.3. For existing DeployR Enterprise installations, these need to be installed manually before installing DeployR 1.3. * Updated DeployR Community to use StifleR 3.1.2626.580 and 2PXE 4.0.2626.404. * After installing an updated StifleR Dashboard, press Control-F5 to refresh the web page to ensure it is using the latest version and not a locally-cached copy. * When upgrading from DeployR 1.1, make sure you select "ServerInstanceAndDb" in the DeployR configuration editor.\ ![](/files/olJIoYTENcO0TT9FI4ez) * Added support for suspending a task sequence in the full OS when using AutoLogon. This can be used by adding the "Suspend task sequence" step. Resume the task sequence by executing the created desktop shortcut. (This is not supported when using any other continuation method.) * Added an "Unlock BitLocker" task sequence step that can be used to retrieve the BitLocker recovery password from either Active Directory or Entra ID to unlock the current OS drive. This is useful in repair situations where the OS is no longer functional and needs to be fixed when already encrypted. (Note that there are specific security delegation requirements to grant the DeployR server rights to retrieve recovery passwords.) * Added support for specifying a BitLocker TPM + PIN protector, as an alternative to the default TPM-only setup. * Added a new "Configure Linux for Entra ID" step that configures Ubuntu 26.04 to log in locally using Entra ID credentials (using the Entra device code flow as implemented by the Linux authd package). * Fixed an issue that could prevent the DeployR task sequence from completing or restarting when in the full OS if an application started a process that did not end; these processes will now be termined so that the task sequence engine shutdown can continue. * Added support for "Windows" or "Linux" tags so that task sequences will be download only in the appropriate boot images. * Added support for a "Hidden" tag that prevents a task sequence from appearing. It can still be used as a nested task sequence or selected through non-UI methods (e.g. Bootstrap.json). * Fixed a bug that caused the Log Viewer application to crash when trying to open a file in Windows PE. * Fixed a bug that caused the progress UI log viewing to not notice when the log file moved from X: to S: during the task sequence execution. * Fixed a bug that could cause an error when trying to duplicate a task sequence. * Fixed issues that could prevent the automatic backup of BitLocker recovery passwords when using the "Enable BitLocker" step. * Fixed a bug that could cause the "Register Autopilot" process to fail when using Autopilot v2 and trying to register the device from Windows PE. * Fixed an issue that could prevent Windows updates from installing when using WSUS due to an 80244010 error. * Fixed a variety of issues in the DeployR Community installer: * DeployR Community 1.2 could not be uninstalled. * PowerShell 7 was not detected correctly, causing it to be redownloaded and reinstalled even if already present. * .NET 10 components were not detected correctly, causing them to be redownloaded and reinstalled even if already present. * Fixed an issue that required the DeployRCommunity installer to be manually elevated; it will now elevate automatically when needed. * Fixed an issue that caused the /layout switch (to pre-download needed content) from working. * Fixed downgrade detection logic. * Ensure that you regenerate boot images and media after upgrading to DeployR 1.3 to get the latest .NET and PowerShell dependencies. * Be sure to check out the [release notes for DeployR 1.2](https://documentation.2pintsoftware.com/deployr/1.2/release-notes) if you have not already reviewed them. {% endupdate %} {% endupdates %} # Prerequisites Windows Server 2022 or higher with the Desktop Experience is recommended for DeployR Community. (Server Core is not currently supported.). For lab use, Windows 11 can be used as well. 4GB of RAM is recommended, with sufficient disk space to hold all of the content that you expect to deploy. 100GB is a recommended minimum, but depending on your specific needs, more may be needed. The computer can be domain-joined or a workgroup machine. Before starting the installation, the following are required: * The TwoPint.DeployRCommunity installer, which can be downloaded from [https://releases.2pintsoftware.com](https://releases.2pintsoftware.com/). * A no-cost license (product key), obtained by registering via * A fully-qualfied domain name (FQDN) registered in DNS (internally or externally, depending on how you plan to access DeployR) that points to the IP address of the computer being used. All other requirements will be automatically handled by the installation process itself. {% hint style="info" %} Note that DeployR Community uses SQLite by default for storage of all the DeployR-related metadata. It can be configured to use SQL Server or SQL Express manually after the installation is completed, but in most cases SQLite is sufficient for the amount of metadata that needs to be stored and retrieved. {% endhint %} # Installation The installation process for DeployR Community is simple: launch the installer, accept the license terms, provide a few configuration details, and let it handle the rest. Extract the TwoPint.DeployRCommunity.exe file from the downloaded .zip file. Run this elevated:
Intially, you will see a splash screen:
Next, you will be shown the license terms. Review these terms, check the box saying "I agree to the license terms and conditions," and click Next to continue.
Finally, configure DeployR Community as required: * Specify the product key that you were provided by e-mail after completing the registration process. * Specify the fully-qualified domain name for this computer. * Choose whether to respond to PXE requests or not. If you have an existing PXE solution (e.g. WDS, Configuration Manager, etc.) you might not want to enable this yet. If you uncheck the "Response to PXE requests" option, the 2PXE service will be installed but it will not respond to boot requests until you enable that option in the "Configure 2PXE" configuration editor app at some later point. * Choose a location to be used for DeployR content or accept the default. By default, all of the content will be placed in "C:\ProgramData\2Pint Software\DeployR" but you can choose another location or drive if you prefer. (This can be moved later by copying it to a new location and then using the "Configure DeployR" configuration editor app to tell it where to find it, but it's easier if you choose the desired location from the start.) Once these are configured, click "Install" to start the installation process.
During the installation process, all the required Microsoft dependencies will automatically be downloaded and installed if they are not already present: * .NET 10 * PowerShell 7.6 * Assessment and Deployment Kit, version 26100.2454 This could take a while, depending on your internet connection speed.
Once those dependencies are installed, the 2Pint Software products that make up DeployR Community are then automatically installed and configured: * StifleR Server, providing infrastructure services to support the other products. * StifleR Dashboard, providing the web-based portal for administering DeployR. * 2PXE, providing iPXE-based PXE booting functionality. * DeployR itself. Once those installations are complete, click the link below "Local administration":
Authenticate to the dashboard if prompted. (You can avoid this prompt when using Edge if you add the domain name to the Local Intranet or Trusted Sites zones in Windows.) Once authenticated, the dashboard will appear:
Clicking on the nodes under "DeployR" will show the pre-created content that is provided with DeployR. If you see a message saying "Service is starting" don't be alarmed; the initialization process can take a few minutes. Refresh the page and you should be able to see a single task sequence, many step defintions, a number of content items, and two boot image definitions. Congratulations, DeployR Community is now installed and configured. See the [Getting Started](/deployr/getting-started/securing)section for next steps. {% hint style="info" %} DeployR Community will be preconfigured with a passcode of "DeployR". This must be entered by anyone attempting to run a DeployR task sequence. This can be changed, or other security methods can be configured, by following the instructions in the [Securing](/deployr/getting-started/securing)section. {% endhint %} --- [Next Page](/llms-full.txt/1)