StifleR
2.6
2.6
  • Start Here - StifleR 2.6
  • StifleR 2.6.x.x
    • StifleR - Release Notes
    • What's New
    • QuickStart Guide
      • Installation
        • Manual Server Installation
        • StifleR Client Installation
        • StifleR Network Locations
        • Example StifleR Rules Definition
    • Planning & Deployment Guide
      • TL;DR version
      • StifleR Overview
        • The StifleR Solution
      • Features Overview
        • Other Features
      • Technical Overview
        • StifleR Standard Features
        • StifleR Enterprise Features
      • Planning Your StifleR Implementation
        • Firewall Ports
        • Supported Clients
        • Networks in StifleR
        • Permissions
      • Installation
        • StifleR Server Installation
        • Dashboards, Client and Beacon Server Installation
        • Post Installation Checks
        • Testing Quick Start Guide
      • Troubleshooting
        • BranchCache across Subnets
      • StifleR Generic Concepts
        • Red Leader
        • Enterprise Environment - Blue Leader
      • Bandwidth Management
        • Bandwidth Tuning Monitoring and Control
      • StifleR WMI Provider
      • StifleR Feature Details
        • StifleR Enterprise Edition Features
      • Further Reading
    • StifleR Operations
      • Maintenance tasks
      • Backup and Recovery
        • Moving the StifleR Server Databases to a New Drive on the Same Server
    • StifleRulez.xml Configuration Guide
      • The Match – TypeData
        • When the Job Title Isn’t Suitable
        • ConfigMgr Specific Rules
      • The Setting - DownloadTypes
        • Delivery Optimization Jobs
      • Sample StifleRulez.xml
    • Securing StifleR Operations with SSL
      • Pre-Requisites
      • Securing the StifleR SignalR Endpoint
        • Binding certificates to SSL Ports for SignalR/StifleR
      • Running SignalR with SSL
      • IIS Configuration
      • Appendix A: Certificates
        • Using IIS to create a self-signed Certificate
        • Using a full IIS Certificate
      • Appendix B:Finding the CertHash
Powered by GitBook
On this page
  • Server and Client
  • Bandwidth Measurement - Beacon Server
  • SignalR Communication
  • StifleR Rules
  • Security
  • Communication Channels
  • User Administrative Access
Export as PDF
  1. StifleR 2.6.x.x
  2. Planning & Deployment Guide

Technical Overview

Server and Client

StifleR consists of two main parts. The StifleR server component and the StifleR clients.

Each StifleR client makes a lightweight connection to the StifleR server and sends up information about the current content download queue. This information is evaluated and the server (dynamically) assigns the most suitable system per Location to be the “Red Leader”. The Red Leader system is then responsible for downloading content and obeying the defined network bandwidth limits for that Location. Other clients at that same Location, that would otherwise also download the content from the remote source, will not download from the remote location but instead will throttle down, wait, and then copy the data locally from the Red Leader and other Peers using Microsoft P2P transfer functions. The end result is that rather than all clients downloading remote content, WAN traffic is limited to between the single Red Leader and the remote content server. Should the current Red Leader system become unavailable, a new Red Leader is automatically selected, which results in uninterrupted, efficient and dynamic workflow.

This functionality also extends to Windows 10 Delivery Optimization groups and respects the Bandwidth administrative settings present under any DO control policy that may be in place.

In StifleR Enterprise, this concept is further enhanced and expanded to the Site level with the introduction of Blue Leaders. Blue Leaders communicate with each other over Subnet boundaries. They pick up local broadcast discovery requests and pass these on to other Blue Leaders which can then broadcast these messages onto their local segment thus allowing the sharing of content with and between all the clients at a multi subnet location. The end result of this infrastructure is that content is downloaded only once over the WAN for an entire remote site with that content then shared directly between Peers on the well connected LAN.

Bandwidth Measurement - Beacon Server

The StifleR Beacon Server component is installed at your file server locations. These then act as known end points to allow the StifleR clients to benchmark bandwidth parameters and set and tune limits accordingly.

SignalR Communication

StifleR is a typical Client – Server application that uses bi-directional communication channels. The Server hosts an OWIN (Open Web Interface for .NET) implementation of Microsoft SignalR. All communication is based on the Microsoft the Microsoft SignalR protocol, a web-sockets based protocol that runs over UDP, initiated first through an HTTP connection which then steps things up to web sockets. StifleR server also uses SignalR to communicate with the endpoint clients and any connected dashboards. Understanding how SignalR works is not mandatory to use StifleR but is required if custom scripting or advanced configuration of StifleR is to be undertaken. Please refer to the 2PintSoftware Website for advanced information on the Microsoft SignalR platform including “SignalR and Connection Management” on the Knowledge Base and the companion document to this guide “Securing StifleR Operations Using SSL” which includes SignalR configuration.

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.

Security

Communication Channels

In order to secure the SignalR communication channels in StifleR we recommend that you use SSL. A full explanation of this can be found in the companion document “Securing StifleR Operations Using SSL”

User Administrative Access

StifleR uses a delegated security model in both WMI and the Web portal. There are several basic security levels:

Global Administrators (Mandatory)

  • Access to all locations and WMI regardless of location rights

  • Only Global Administrators have rights and visibility over roaming clients

Delegated Access

  • Granted by a Global Administrator on the individual Subnet level. Rights to WMI methods only on the allowed subnet or clients in that subnet

Global Read

  • Gives read only rights to ALL locations and statistics. Including WMI

Dashboard Access

  • Access to Dashboard and overview statistics only

Anonymous Read

  • Allows anonymous access. Should be disabled in all but a test environment

PreviousOther FeaturesNextStifleR Standard Features

Last updated 2 years ago