support

ISSUE: You may find that you are getting an alert from Passwordstate stating that you have excessive auditing records. By default, Passwordstate should move auditing records from the primary "Auditing" table into the "AuditingArchive" table in SQL. If your system is failing to do this, please consider the following: Check 1: First check that the Passwordstate Service is running on your web server. The Windows Service is the tool that moves the data across to the archiving table and the service needs to be running. Check 2: Check your Archiving settings under System Settings and confirm you do not have the maximum number of rows set to 0. 0 means the Service will never move data to the Auditing table. 500,000 is the default value, and is suitable for most environments. Also, check the Schedule on this same page, and ensure your Passwordstate web server is Powered up at the time of this schedule: Check 3: Look in your Application Event logs on your Passwordstate webserver and look for any errors related to the Passwordstate Windows Service. If you find any but are unsure what they mean, please send these to Click Studios Support for analysis: https://www.clickstudios.com.au/support.aspx If you find errors that mention "Violation of PRIMARY KEY constraint 'PK_AuditingArchive'. .AuditingArchive'. The duplicate key value is xxxx" like the screenshot below, we'll need to truncate the Archiving table (instructions below) Take a full backup of your database before doing this, and keep that database just in case you need to access the old auditing data at some stage in the future. Ie, you could restore that database to a test server if needed. You could possibly export the data and put it into an excel spreadsheet, but if your “AuditingArchive” table has more than a million rows, Excel won’t be able to cope with this. If you want to find out how many rows you have in the AuditingArchive table before deleting everything, please run this script in SQL Management Studio tools, when connected to your Passwordstate database server: USE Passwordstate SELECT COUNT(*) FROM AuditingArchive To delete everything from this table, please run this command: USE Passwordstate TRUNCATE TABLE AuditingArchive Now restart your Passwordstate Windows Service on your web server and wait one day. This should then move excessive entries from the “Auditing” table into the “AuditingArchive” table. Regards, Support

Thanks Nick. You can actually specify your own logo now, but not the other items you've mentioned. Regards Click Studios

Hi Sharon, You are welcome to log a support call with us if you have an active annual support license: https://www.clickstudios.com.au/support.aspx Alternatively, try backing up Passwordstate manually, and the perform an upgrade to the latest build, and try running through the backup documentation again. It could possibly be a bug in the build you are running: https://forums.clickstudios.com.au/topic/13911-manual-backup-using-sql-management-studio-tools/ Regards, Support

Hi Alan, Could you try the report "What permissions exist for all shared password records (enumerated permissions report)?" to see if it gives you what you need? This can be found on the screen Administration -> Reporting. Regards Click Studios

Topic: In this forum post we'll describe how you can update multiple records with the same password, by using a Password Reset Dependency and a Powershell API script. Passwordstate has the ability to copy and link password records between two Password Lists, but this means everything with these two records is identical, including the username. If you have some requirement to have the same password to log into two different systems, but with different usernames, this forum post will guide you how to do this. First, let's take a look at these two Password Records. Our goal here is to trigger a reset on "Passwordstate Service Account" record, and then have our API script automatically update the "Passwordstate Sharepoint Account" password to be the same value. Take note of the PasswordID for this second record: Now, let's browse to the Powershell Password Resets page: Add a new Blank Script: And then click on this new script to open the editor. Paste in the code of your choice. The code in this screenshot below will be copied in at the end of this post for your reference. In the screenshot below, you can see you have a number of Variables you can insert into your script. These values are pulled directly from the master Password Record, and in this example, I'll be using the [NewPassword] variable. This just means, when the password for the master record is reset through the User Interface, then that new password it is reset to will be passed to your script: We'll now add in a new Password Reset Dependency on the master record: Click the Add Dependency button: And select the Custom Script you wrote. Also, ignore the Windows Account Dependency type, and Save this config: The Master Password now has "1" dependency, and triggering a Password Reset on this master record will proceed as per normal and queue up the reset. In this example, it's also going to reset the password for the account in Active Directory: Once the master password has successfully reset, it will trigger your Powershell API Script, which in turn triggers a new password reset on the Sharepoint account: And the end result of the two successful Password Resets, means these two separate accounts, will have the same password: Powershell Code to Update an Existing Password, using the Standard API (Requires API Key) $PasswordstateUrl = "https://passwordstate.clickdemo.com" # Define values for the Password List in below array $Body = @{ PasswordID = "1045" Password = [NewPassword] } # Convert Array to Json $jsonData = $Body | ConvertTo-Json # Execute the command $FullUrl = "$PasswordstateUrl/api/passwords" Invoke-Restmethod -Method Put -Uri $FullUrl -ContentType "application/json" -Body $jsonData -Header @{ "APIKey" = "8c5423d3e9a7bf6ad6cf8e457392b3d6" } Regards, Support

Hello, Do you use any Load Balancers, reverse proxies, or proxy servers? Apart from these devices causing this sort of issue, we've had no other reports of this. If you do not use any of these devices, maybe have a look at the Application Event log on your web server, to see if there are any entries at the times you get logged out. Regards Click Studios

Hi Guys, Have you considered using our One-Time Password option instead? This can be used with different Apps, and has a generic name for you. Regards Click Studios

Hello Daniel, Thanks for your request, but unfortunately what you are asking is not technically possible with our agent, and would require some sort of third party gateway like teamviewer, etc for that to work. Management have decided previously that we do not intend to provide that sort of service. Regards Click Studios

Hello Mathias, We do not have the concept of private folders, so we believe you mean a Private Password List? When searching for Password Lists, you must use the System Wide API Key, which can be set on the screen Administration -> System Settings -> API Keys. Alternatively, you can use the Windows Integrated API, and this does not require the use of API Keys - you will receive the same level of access in the WinAPI, as you do in the UI. Regards Click Studios

Hi Paul, Yes it can - just needs a different URL specified at install time. Regards Click Studios

Hello Richard, Yes, you are correct with your feedback above - it does not look like Microsofr Edge supports launching from the Windows Login screen. We've been testing this, and we can launch just about anything here i.e. Chrome, Notepad, etc, but Edge will simply not launch. We've still have no had any responses to our developer support tickets either. As soon as Microsoft support this, then we can support it in our Credential Provider as well. Regards Click Studios

Issue: If using Passwordstate Build 9435 or higher, and trying to import some passwords through the Tools -> Import Passwords menu, you may see and error as per below screenshot: Fix: Go to Administration -> System Settings -> Miscellaneous, and check the Base URL at the top of this page. This URL must be the exact URl you use to access Passwordstate. Sometimes users may have this set using HTTP, but it should always be HTTPS. If this doesn't fix the issue, try bypassing your Load Balancer or Proxy if you have one. Regards, Support

Hello Everyone, Today we have released build 9471. For full details, please refer to our changelog here https://www.clickstudios.com.au/passwordstate-changelog.aspx Regards Click Studios

Hello, Just letting you know that we have released build 9471 today, with the updated feature mentioned above. Regards Click Studios

Hello, Just letting you know that we have released build 9471 today, with the updated feature mentioned above. Regards Click Studios

Hello Matteo, Passwordstate works just fine when in a workgroup environment. This slowness must be a networking issue of some type, so can you please work with your networking team to determine the root cause i.e. check DNS, trace routes, firewalls, etc. Regards Click Studios

Hi Hans, Yes, that is be design, as we do not support 'All Users and Security Groups' for permissions to Password Folders and Password Lists - and this is what the permissions on Templates is primarily used for i.e. to copy those permissions to Password Lists. Regards Click Studios

Hi Hans, I've just tested this, and we do not support clickable URL's in our User Acceptance Policy unfortunately, so this must have been in there for a while for you. We assume you must be on an older build of Passwordstate, as we also do not have a right-click option - atleast when using Chrome on Windows. Regards Click Studios

Hi Will, Thanks very much for sharing this with the community - we really appreciate it Regards Click Studios

Hi Fabian, We did have an issue with the 'Report Site Issue' from the browser extension itself for a while. So could you please log a support ticket here https://www.clickstudios.com.au/support.aspx, explaining the issues you are having, and we will look into them. Can you confirm if you also see the issue in Chrome, or is it only Firefox? Thanks Click Studios

Issue: You see symptoms like the Browser extension not connecting after an upgrade, and it remains red in colour no matter how many times you log in. Cause and Fix: This issue is caused by an Application Pool in IIS being stopped. As part of the upgrade process, all App Pools are stopped to allow the install files to be replaced on disk. After the install files have been replaced, the App Pools should all automatically restart. We have seen a handful of customers where the PasswordstateApps App Pool is stopped, and an example of this is below - If you see this, please start the App Pool and this should fix the issue: Regards, Support.

Hi Jordi, Can you please log a support ticket via the following page on our web site https://www.clickstudios.com.au/support.aspx and provide the following health information about your web server by running the following script for us - https://forums.clickstudios.com.au/topic/2518-passwordstate-support-information-script/ Regards Click Studios

Hello Jordi, This sounds like you have database connectivity issues, which is a bit strange considering you finished the initial setup which creates all the tables. In the web.config file, you will see the database credentials being used here. Can you test them using SQL Server Management Studio? Since we're also not sure if all the tables have been created, and data added, it might be worth resetting the installation and starting again. You can do that by following these instructions - https://forums.clickstudios.com.au/topic/1663-resetting-the-passwordstate-setup-process/ Regards Click Studios

Hi, Just letting you know we've finished for the next release - due in about a week or two - see changes below.

Hi, Just letting you know we've finished for the next release - due in about a week or two - see changes below.