support

Hi tburke, We're working on a document at the moment for this, and I can email you a draft copy now. We will eventually publish this on our web site, and include it in downloads. Regards Click Studios

Hi Marek, No it is not sorry. We do not have the ability to have live replication of the SQLite database. Regards Click Studios

Hi Tbourke, Can you open IIS and check to see if your Windows API is configured similar to my screenshot below? It should look like a website icon, not a folder icon. Can you also look under the Application Pools to ensure there is one for the WinAPI and also who is it running under? Is it Network Service or some other account? Regards, Support

HI tburke, Thanks for confirming, and Anonymous Authentication being enabled is the default for a new install, so you must have disabled it? If you enable Maintenance Mode under a certain account, you need to log back in with that account after the first phase of the upgrade is complete. So disabling Anonymous Authentication here has caused this issue for you, as you could not longer log back in with this 'Forms' account you're referring to. Regards Click Studios

Thanks for your suggestions tburke - we appreciate it.

With the new request access to passwords feature, the approver can only reject or approve a request. It's up to the requestor to set a date and time for when he/she will have access to the record. A customer has requested that the approver should be able to modify that time during the approval process. Regards, Support

Hi Tburke, We generally recommend High Availability for disaster recoveries, as exporting all passwords does not export Private password lists. Unfortunately, we do not have an options in the UI to zip a file or password protect it sorry, so a custom script would be the best way to achieve this:) Regards, Support.

Well this has been a long time in the reply and we're sorry we haven't reported back here earlier about this, but converting Private Password Lists to Shared Password Lists is now disabled by default as of Passwordstate 8. If you need to convert a Private List to a Shared one, please see this forum Post: https://www.clickstudios.com.au/community/index.php?/topic/2398-how-do-i-take-ownership-of-a-private-list/ Regards, Support

Hello. We've just made a change for the next release, and you won't need to manually enter this blank GUID1 string in the file - it will work as expected and do this for you. Regards Click Studios

Hello, Do you have Anonymous Authentication disabled for the site in IIS - this is the only think I can think of where it would present this screen to you, as Passwordstate is detecting your accessing it using a different domain account? You can clear this in the database if you like, by running the following command using SQL Management Studio: USE Passwordstate UPDATE SystemSettings SET MaintenanceModeUserID = '' Rergards Click Studios

Hi tburke, Can you let us know what you see on the screen at the moment? If you enabled maintenance mode before the upgrade started, then you need to log back in with the same account to finish the second phase of the upgrade, which is to upgrade the database? So there are two stages to the upgrade: Upgrade all the files Upgrade the database Thanks Click Studios

Hi tburke, Thanks for pointing this out, and we need to update our documentation here a little bit - what you will need to do is add the following line in your web.config file: <add key="GUID1" value="" /> Once this is done, and browse to the site, you will be prompted to enter your Emergency Access password to register the web server properly. It seems to be adding a duplicate GUID1 setting when doing this, bit does work - we will look into why this is doing this. Sorry for the oversight, and we will update our documentation now. Regards Click Studios

Hello, Yes, we are aware of this issue and have fixed it for the next rounds of releases for broswer extensions. We did not want to release so late in the year, as these new extensions when they automatically update in your browser, will force you to also upgrade Passwordstate if you want to continue using the extensions - there is a dependency change in the API needed here. So we will release these updates at the start of next year. Regards Click Studios

Hi Everyone, Today we have release build 8556, which includes 4 new updates, and 3 bug fixes. Full changelog can be found here - https://www.clickstudios.com.au/passwordstate-changelog.aspx. Regards Click Studios

Hi tburke, It seems you've done everything correctly, but what we have not testing is actually logging into the web site using the /emergency URL. Normally all you should need to do is browse to the base URL, and you will be presented with a screen which says the "server is not authorized" to host Passwordstate. On this screen you can enter your Emergency Access Password, and it will write that GUID1 setting into the file. Did you try browsing the the base URL? you can also delete that GUID1 key from the file again if you like to test the process. Let us know how you go. Regards Click Studios

Hi Scott, Today we have released build 8556 which includes a fix for this. Thanks for bringing it to our attention and you should now be able to successfully upgrade. Please let us know if you have any more issues with this! Regards, Support.

Hi Marek, Yes, this can be an issue when using active/active setup - sorry we did not think of that, and we'll need to add something into our documentation for this. You will need to install the Self Destruct site separately to your main Passwordstate web site, so only the one SQLLite database is used. So if you go to the screen Administration -> System Settings -> Self Destruct Messages, you can follow the instructions there for installing the site. Regards Click Studios

Thanks for the info, and now we understand. We'll need to see what's required here, as we've never looked into this before. Regards Click Studios

Hi Scott, Good news, and we're really sorry we messed you around with this, but we've been able to reproduce the same error you were getting, and have been able to provide a fix for it. We will release a new build in the next few days, and I will post back here again once that new build is available. Sorry again Scott. Regards Click Studios

Hi Scott, Sure, we more than understand. We also cannot share our source code with customers, so we'll need to try and figure this out by sharing the SQL Queries as part of this upgrade function, and see if we can spot any problems with the data. I will put this together for you over the next couple of days, and email you the SQL queries directly. Thanks, and enjoy your vacation. Regards Click Studios

Hello Marek, Thanks for the information, and sorry I missed the build number in your original post as well. I'm really not sure why this is happening for you. I assume they are viewing it before the message expires? The fact that you can paste the ID into the screen means the record still exists in the local SQLite database, so this really does not make any sense. Do you have any email "protection" software which might be modifying the URL at all? Maybe you could test with something like Fidler from Telerik to see if you can see anything obviously when you click on the email link. Regards Click Studios

Hello Marek, In the emails being received, is the URL in those emails also https://mydomain/selfdestruct And can you please tell us what build of Passwordstate you are using? Regards Click Studios

Hi Everyone, We know this is very late to reply but we do have some news about Edge. We recently purchase some support with MS so we could log a call with them for this. After a few weeks of back and forth, we have discovered that the issue is if the Passwordstate web server is on the same subnet as the desktop that runs edge, the extension will not configure. If you host the Passwordstate web server on a different subnet, then the extension works as expected. We are waiting on MS to provide either a reason for this behaviour, or confirm it is a bug with Edge. At this stage we do not think they will admit it is a bug, so moving your Passwordstate server to a different subnet might make this work in the short term. Sorry for late response on this. We had a few cracks at it over the last year, and couldn't work out what we were doing wrong. It turns out there was nothing we could have done at our end:( Regards, Support.

Hi Marek, Could you please look under Administration -> System Settings -> Miscellaneous and see if your Base URL under there is correct? Hopefully this is the cause, but please let me know if it isn't. Regards, Support

Hi tburke, If you had to move the Passwordstate install to a new server, and it wasn't already added into the Authorized Web Servers page, then you will be prompted for your Emergency Access password upon first visit to the new site. Entering a correct emergency password will automatically add the new server to the Authorized servers. Your emergency password can be found and reset under Administration -> Emergency Access, and if you forget this password, you can contact us on support@clickstudios.com.au any time and we can help you recover it. Also, we have some instructions for disaster recovery under Help -> User Manual -> KB Articles. Maybe take a copy of those and keep them outside of Passwordstate in case you ever need them:) All the best and let me know if you need help with anything else! Regards, Support.