Page Comparison

1. Change the Bastion Log Level

2. Restart the Bastion Service 

3. Replicate the issue 

4. Collect the log Bastion_<date>.log and the Dumps folder from the relevant date

5. Collect the Bastion.xml

6. Revert back to the old Bastion.xml

7. Restart the Bastion Service or follow this guide to update settings without restart

Checklist to Gather the Correct Logs for Troubleshooting

1. Get the user names and exact times involved.

2. Make sure you know which logs are relevant and you take them. Often this means your Bastion logs and Filter logs. Sometimes logs from other components are required too.

3. Logs for the correct time of the event: make sure that they show the specified time and usernames. If not, get the logs that match the times that the user specified or ask them if there were other times with the same issue.

4. Filter/Product Logs: Make sure the times specified are covered by the logs. Also check that the user specified is mentioned in the logs.

   1. If you see in the logs that the client didn’t manage to connect to the server, then the username may not appear in Filter logs. But if you see some “200 OK” responses then it did manage to connect to the server.

   2. [LAC] If you see this text in logs then traffic did reach the Bastion: “X-MS-Server-Fqdn Bastion”.
      [LAC Also look for the Lyncdiscover (start) request for the user in the LAC logs.
      E.g. /?sipuri=sip:bill@microsoft.com

   3. [TP] If you see this text in logs then traffic did reach the Bastion: “X-Bastion-FQDN”. Look for this response headers in the .har file when opened in Chrome: Headers/Response Headers tab

   4. If the filter logs don’t include the above information check to see if the Bastion has more than one channel (each with their own logs) or more than one Bastion server. When reproducing the issue you may wish to request that the customer shut down other Bastion servers so all traffic comes to the server that’s being watched.

To include the device logs, follow these steps.