Troubleshooting High Availability polling health

[support]

As of Passwordstate build 8388, we have introduced a new feature where you can upgrade your High Availability instances directly from within the UI of the primary server.  Below is an example of this, and you'll see that in our current development set up our nodes are red, indicating that are not polling successfully:

 

 

If you are running a build of Passwordstate 9 or above, the High Availability Nodes page has been removed, and your High Availability servers can now be found under the Administration -> Authorized Web Servers page.

 

To troubleshoot why these polling health icons are red, please see the following:

 

Active/Passive Mode:

If you are using Active/Passive HA, the the Passwordstate service on the secondary server will make a call on a regular schedule to the primary site API.  If it can contact it, it will show a successful green icon.

 

Things to check:

• When logged into to your Primary Passwordstate site, check the URL under Administration -> System Settings -> Miscellaneous is correct.
• Ensure the Passwordstate Service on the secondary web server is running
• From your Secondary server, perform a Powershell open port test back to your primary website to ensure no firewalls are blocking access.  Example is test-netconnection passwordstate.com.au -port 443
• From your secondary server, try browsing to the poll test URL by appending /api/highavailability/primarypoll/polltest to your normal Passwordstate URL.  If this works, you will see a Success:True message in the body of the website.  If you do not see this, please investigate if you have load balancers or proxy servers that are blocking this API call, and possibly bypass these devices as a quick test to rule them out.
• Look in the Application Event logs for any errors, and if you find any, but can't work out what they are, submit them to Click Studios support for review (support@clickstudios.com.au)

 

Active/Active Mode:

Active/Active mode works slightly different, and instead it will write the date, time and build number directly to the secondary database, and then when replication occurs this will be displayed in the primary Server UI

 

Things to check:

• Passwordstate service on the secondary web server is running
• Database replication is working
• Look in the Application Event logs for any errors, and if you find any, but can't work out what they are, submit them to Click Studios support for review (support@clickstudios.com.au)

 

**TIP**

One quick way to check replication is working correctly is to do a count of auditing events against both databases.  This SQL query below should be run against both database servers, and they will  and they will be exactly the same if replication is working correctly.

 

Use Passwordstate

Select count(*) from auditing

 

 

Hope this helps!

 

Regards,

Support:)

 

[Mike Powell]

We have just finished setting up Active/Passive HA, where both sites are hosted on-premise but the primary site is using Azure App Proxy for MFA-protected access from the internet. However the API call from the secondary site is not able to navigate the app proxy and fails. Is there any way to provide an internal-only URL for the secondary site to use when reporting back to the primary site?

[support]

Hello Mike,

The only way this would be possible would be to add anothr binding in IIS, and then modify the Base URL field on the screen Administration -> System Settings -> Miscellaneous tab.

By changing the Base URL though, this will be used in different areas of our software i.e. links in emails, when running reports which talk to the API, etc. So this might not be ideal.

 

If you can use an Active/Active setup for SQL and Passwordstate, then this polling does not need to communicate to the API. You can have an active/active using either SQL Basic Availability Groups, Always On Availability Groups, or SQL Clustering.

Regards

Click Studios