Sarge

No, the self-destruct message data is stored in a SQLLite database on the Self-Destruct web server, Passwordstate web server pushes data to it. If you round robin to two nodes (or more), one of them will get the data (say, self-destruct server1) , while the one the user hits to access the data (self-destruct server2) won't have it. All self-destruct data needs to go to a single node, hence why an Active/Cold setup works.

Sort of, if you have the load balancers capable of doing it. Self Destruct uses its own SQL-Lite database where it stores the shared messages/credentials pushed to it by the main Passwordstate website. We have our Self Destruct web sites installed on the same web nodes as Passwordstate, bound to a seperate IP address. Our load balancers then direct all traffic for the self destruct HA URL to node 1 unless that node is offline. This way the self destruct messages are always available until the node is offline. It's HA in an Active/Cold configuration. In a disaster we still maintain our Self Destruct capabilities - we just have to re-create self destruct messages since the load balancers will instead be redirecting self destruct traffic to node 2. SQL-Lite supports replication, so hopefully in a future build there is Active/Active support for self destruct. The same Active/Cold setup can be achieved with the browser based gateway, and in theory the reset portal - but I'm still working on the reset portal HA.

This request seems akin to a "CREATOR OWNER" equivalent setting, where the user creating the list can control it - which can already be achieved with the following administrative setting "When a new Shared Password List is created, apply the following permission to the user who created the list:"

Related:

Access can be gained via Administration > Password Folders.

Agreed. I think this goes right down to the password resets as well. Install WSL on Server 2016/2019 and use the native tools for running the scripts rather than modules (IE: Posh-SSH etc)

Same for the Google Auth 2FA. The Microsoft Authenticator app supports push notifications, just needs to be implemented on Passwordstate end.

Check that this is actually occurring. For the "Passwordstate" and "Passwordstate-Gateway" service. Majority of the time I do an IPU the service for Passwordstate doesn't actually stop, so I manually stop it and carry on with the upgrade - I've not performed an upgrade since having the gateway in place, so can't confirm if it occurs with the Passwordstate-Gateway service as well.

That would depend on how Passwordstate has been configured in your environment. If all password list permissions are linked to a password list template then it would be as simple as adjusting the permissions on the password list template to include your user group (and/or user account). You can also navigate to Administration > Password Lists. From here you can use the drop down menu next to each password list to view, and assign permissions (Assuming permissions aren't linked to a password list template). Whoever configured the application may also have granted the first account created during the OOBE access to all passwords.

Ideally yes. It should be an option at setup - If you plan to run in HA, would you rather status 200 and dynamic pages, or 503 and static pages? If the user chooses 503 and static pages, then your setup installer would configure the attached. If the user chooses 200 and dynamic pages, then leave it as it currently is. How this could be retrofitted to existing installs I'm not sure.

Yes, but some load balances can't check for string matches on the page - only status codes. You should still be able to do that through IIS. https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httperrors/ Or networks team has accidentally misconfigured something, trust relationship of the web node to the domain controllers has been isolated, or someone did something on one of the nodes they shouldn't have. This issue would extend to maintenance mode as well - enter a web node into maintenance mode, it still returns status 200 - thus load balancers don't know to send traffic to the other node. Again, 503 would be the correct code to return here.

Azure aside, its an issue with the application in HA configuration. If one of the web nodes can't get a connection to the database for whatever reason then the health checks continue to work as the application still returns a HTTP status 200 - even though it can't reach the database. If Passwordstate deems it can't connect to the database it should be returning a status code 503 instead of 200, that way when the load balances perform their health checks they'll get hit with a 503 status code and redirect traffic to the web node that is returning status 200. As it stands, users hit the load balances, get directed to a web node that returns status 200, only to be greeted with the application saying database isn't accessible.

While our Browser Based Gateway is working, when our users do are yet to trust the SSL Cert and use the "Test SSL Certificate" link, they receive a page with nothing other than "Not Found" rather than the expected ssltest.html page.

This is an excellent point and I hadn't considered it for our own HA implementation. We use F5s across two DCs rather than having Passwordstate in Azure, but we'd have the same issue. A 503 should be thrown, with a custom error page detailing the exact nature of the failure. IE: "Application is up, database is down". Suggest this be moved to feature requests for implementation.