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.
We recommend when deploying 2Pint software in your environment, to initially validate against your UAT or QA environment before rolling out in production.
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:
Order of installation
For a standard StifleR implementation, the recommended order for deploying and configuring each component is as follows:
Install StifleR Server – Core engine managing all operations.
Install StifleR Dashboard – 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.
Install Action HUB – Dynamic, real-time actions across the StifleR ecosystem.
Install Beacon – Gathers telemetry and identifies active subnets.
Install StifleR Client – Client that monitors network activity, reports and enforces policies.
Install WMI Agent (optional) – Agent that replaces traditional WMI.
Install CacheR (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.
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.
As well as BranchCache, StifleR can utilize download jobs which use Microsoft's Delivery Optimization (DO) peering technology.
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":
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.
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 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.
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.
Last updated