Jump to content

Browser Extension After Database Migration


Recommended Posts

We just migrated our database and web server from one machine to another.


After the migration we are able to login and access passwords, and everything seems to be working correctly. The one thing that isn't working is the Browser extension. The URL has not changed, nor has the SSL certificate. However even after navigating to the passwordstate site and logging in successfully to the new host, we are unable to get the extension to change from red to black.


I checked the database migration and new webserver migration guides and didn't see anything in there about the browser extensions. I checked in the Browser Extensions section of the help site and the settings of my server itself. The only thing I found was below. 

If you need your browser extensions to communicate to a different URL compared to your main Passwordstate URL, please specify it here: (in the format of https://mypasswordstate.com). This must also be the same database you're communicating with, otherwise encryption/decryption will not work with different encryption keys.


Any other suggestions?


Passwordstate Build Number : 8951
Browser Extension API Build Number : 8782
Mobile Client Build Number : 8903
Password Reset Portal Build Number : 8903
Remote Site Locations Build Number : 8903
Link to comment
Share on other sites

When navigating to the normal URL with /api, we get a 500 internal server error. This occurs both if I've logged in and if I have not.


We did a full database backup and restore, decrypted the web.config and copied over the that file from the old server. We also moved across the selfdestruct web.config. What did we miss?


Thank you for your help!

Link to comment
Share on other sites

To confirm, the process you sent me involves importing passwords from a different password manager, Passwordsafe. Should I be treating my original Passwordstate instance as the Passwordsafe source for this example? It looks like this is going to completely rebuild and reimport my passwords from my source server database via this script, rather than a database import. Would I not then have two copies of my passwords lists? And then have to recreate my permissions for each list?



Link to comment
Share on other sites

Hello cjohnston,


The 500 error you reported has nothing to do with importing passwords - a Server 500 error generally means some sort of configuration issue in IIS.


Please contact support as the per the suggestion above, and we will try and figure out the issue with your API.


Click Studios

Link to comment
Share on other sites

We were able to correct the issue with the eagle eyes of the support team.


When we had migrated from one database and web server to the next, we had added another logical drive and moved the Passwordstate databases to that, so our Passwordstate home folder went from D:\ to E:\. Everything else migrated across appropriately, but the AppPools were still pointing in the old locations. Updating those by navigating to IIS > Sites > Expanding the Passwordstate site and finding the three app pools and right clicking on those and selecting properties and changing their physical locations to point to the actual Passwordstate folder location in E:\ then allowed everything to work appropriately (After a website refresh in IIS)


Thank you for everyone's help and support at Passwordstate. Glad we were able to get this resolved!



Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...