Troubleshooting

2Pint Support KB and Other 2Pint Website Resources

Lots of answers can be found here and you can even ask us questions via the support portal. Don’t be shy we love this stuff and are happy to help.

Debug Logging Levels

For both Client and Server, Debug Logging has 6 levels

1 = Errors Only

2 = Warning

3 = OK

4 = Informative

5 = Debug

6 = Super Verbose

This is set via the Configuration value:

<add key="EnableDebugLog" value="n"/>

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 – <add key="EnableDebugLog" value="n"/> (n Debug levels 1-6 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 – <add key="EnableDebugLog" value="n"/> (n Debug levels 1-6 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

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

Overview

To support BranchCache across subnets, StifleR is using the Blue Leader feature that is enabled by default when connecting multiple subnets together to form a location. Here are some troubleshooting tips.

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. The subnets also have to be configured for Low Bandwidth, subnets set to Well Connected are not supported for the Blue Leader feature. Until these requirements are met, there is no visibility in the Blue Leader logs.

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. Add a run command line action that runs: wpeutil disablefirewall

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

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:

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:

You can also query the other ports as per the first way:

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:

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:

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"

Hosted Cache mode settings

Set in the following location: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PeerDist\HostedCache\Connection

Reg_Dword ConnectPort and ListenToPort