support

It's odd that the order of the installs can break things, but at at least it's a relatively easy fix

Hi Geoff, Thanks for your request and we'll see if we can come up with something for this. The main design issue I think we'll have is that we don't want one popup window on top of another i.e. Add Host screen on top of Add Password screen. Possibly we could just add the Host if not found based on what you type into the textbox, but there may be certain fields that need changing for the Host i.e. Operating System. We'll have a think for what's possible here. Regards Click Studios

Hello Achim, Thanks for your feature request and interest in our software. Unfortunately we do not have any language translation at this time. It is something we would like to work on, but it’s an incredible amount of work to change all pages in Passwordstate, in addition to the translation files themselves – and we rarely get requests for this. We do have many customers throughout Europe in different languages using our software, so we do hope you can still make use of our software without the language translation. Regards Click Studios

Issue: We've had a few reports of customers who have not been able to sync AD Security Groups, or possibly not able to add users into the system from Active Directory. Symptoms: Some symptoms you may see is when adding in a AD Security Group, it will not enumerate the members. Or possibly you might be presented with a Error page in Passwordstate saying it cannot query Active Directory. Possible Cause: By default, Passwordstate only requires an account that has "Domain User" privileges in AD to be able to sync objects, however if you have hardened Active Directory to minimize the visibility of containers for certain users, you may need to elevate the permissions for your Privileged Account. How to Test: As a temporary test, add your Passwordstate Privileged Account to the "Domain Administrators" security group in Active Directory. If this resolves the issue, then this indicates it's a permission issue. How to Fix: Unfortunately every AD environment that has been hardened can be different, so it's difficult to say exactly where the issue lies. Normally when companies harden AD they may remove the ability for the "Authenticated Users" on certain containers to hide them, but some applications built with standard .NET code can have issues with this, including some of Microsoft's. We would suggest you check permissions for each container starting with Users and Computers, and confirm whether or not the Authenticated Users has read access, as per below screenshot: Next, you should check any other container that you have computers or user accounts stored in for the same permissions above, and this will include and nested containers, as the problem may be caused at any level. Finally check the top level domain and then depending on the results, you can do one of a few things: Restore the default AD permissions to allow Authenticated users to have read access to all containers where you have users or computers, and also ensure the permissions filter down to all nested objects - We realize this may not be possible. Give your Privileged Account Read access on all containers, and ensure permissions filter down to all nested objects Elevate the permissions of your Privileged Account to one of the built in AD Security Groups. Suggestions are: Account Operators, Administrators, Domain Administrators or Pre-Windows 2000 Compatible Access More Information: You may possibly run into the same sort of issues in Passwordstate, when attempting to let Passwordstate reset a password for an Account in AD. For most accounts in a domain, the privileged account Passwordstate uses should only need to be a member of “Account Operators” built in security group to be able to reset the passwords. However, this won’t allow the account to reset passwords for higher privileged accounts like Domain Administrators, or Enterprise Administrators. To reset passwords for accounts like these, the privileged account must also be a member of one of the Administrator Groups, either “Administrators” or “Domain Administrators”. This is by design from Microsoft, because if you can reset a domain Administrator password, then you effectively can use that account to perform domain admin tasks, so why not just make it a member of the Domain Admins in the first place? There are ways to set granular password reset permissions on account attributes, which will allow an account with less privileges to reset a domain admin password. We would not like to provide advice on this though as you can imagine it could be different for every domain. So summary, your privileged account should be a member of "Account Operators" group for all normal password resets, or “Administrators” to reset passwords for any Administrator type account. To mitigate against the risk of having these high privileges for your account, you can configure your privileged account to reset its own password on a regular basis in Passwordstate. Just link it to a password record from within the Privileged account screen, and set it to reset as often as you like. If you still find you cannot perform sync's/ resets, please contact Click Studios on support@clickstudios.com.au and if we have any more current information about this, we will let you know. Regards, Support.

Purpose: This post outlines the process you need to follow, to grant someone access to the Remote Session Launcher, without them having the need to know the password. An example could be you have a contractor coming on site, and you want them to connect to machines and perform work, but you do knot want them knowing the password they are using to connect. If you are not familiar with how to set up the Remote Session Launcher, please see this in depth Forum Post - https://www.clickstudios.com.au/community/index.php?/topic/2110-how-to-set-up-the-remote-session-launcher-passwordstate-8/ 1. Under the Passwords tab, add a new Password Record that has an account that has permissions to connect into machines on your network. The following example is an Active Directory account which can connect to any Windows Server or Desktop. **Note, you do not grant the contractor permissions to see or use this Password Record: 2. Under Hosts tab -> Hosts Home, create a new Remote Session Credential, and link it to the existing Password Record you just created: 3. Grant your Contractor access to the remote session Credential you have just created in step 2 above: 4. Under the Hosts tab, grant the user access to the Folder of your choice, which has the machines added into it: 5. The user will now be able to choose a Host of their choice, and click the Auto Launch button. This will use the Remote Session Credential to establish a connection to the remote host, and the contractor will not have access to the password that they have connected in with: Regards, Support Click Studios

Hi Craig, The following two documents will help with the move: https://www.clickstudios.com.au/documentation/move-new-database-server.html https://www.clickstudios.com.au/documentation/move-new-web-server.html Regards Click Studios

If you have run into any issues with your normal Passwordstate accounts, and cannot log in, you can use an Emergency Access account to gain access back to the Administration area. This will allow you to fix the issue and restore Passwordstate back to a working environment. To log in with your emergency access password, you'll need to append /emergency to your Passwordstate URL, and enter the Emergency Password which you set during your initial install. An example of an Emergency Access URL is https://passwordstate.clickstudios.com.au/emergency. If you have forgotten your Emergency password, Click Studios can help you recover it, but you'll need to provide us some information. Please send this information to support@clickstudios.com.au requesting assistance to recover the password. **Note** If we do not have you listed as a contact, then we will need to get approval from one of our contacts, or your line manager to help you recover this password. Please CC in your Passwordstate Administrators and/or your Manager in your email as a form of authorization. 1. Provide a copy of your web.config file, which is located in your Passwordstate installation directory – default location is C:\inetpub\passwordstate on your web server. Note, if your web.config file is encrypted, you'll need to first decrypt it before sending through. How do you know if it's decrypted? Please see here: https://forums.clickstudios.com.au/topic/2699-encrypting-and-decrypting-the-webconfig-file/ 2. Using SQL Management Studio Tools, connect to your Passwordstate database server and run the following query: USE Passwordstate SELECT EA_Password, Secret3, Secret4 FROM SystemSettings Copy the output of this query and email it to Click Studios Once we have received your information, we will email you back your Emergency Access Password. We then recommend changing it once you have fixed your system, under Administration -> Emergency Access. Regards, Click Studios Support

Purpose: This post will guide you through the process of installing IIS on your web server. Applies to: Windows Server 2008, Server 2012, Server 2016 How to I do this? Log into your web server as an Administrator, and launch the Server Manager utility by entering servermanager in the 'Run' prompt Click Add roles and features Choose Role-based or feature-based installation and click Next Choose your web server from the Server Pool and click Next Select Web Server (IIS) Click Add Features and then click Next Click Next Click Next Select the following Role Services and click Next: Common HTTP Features Static Content Default Document HTTP Errors Application Development ASP.NET (or ASP.NET 4.5 on Server 2012 and Windows 8) .NET Extensibility (or .NET Extensibility 4.5 on Server 2012 and Windows 8) ISAPI Extensions ISAPI Filters Security Windows Authentication Request Filtering Performance Static Content Compression Click Install Click Close

Step 1: On your web server, open your c:\inetpub\passwordstate\web.config file. Take note of the username and password inside the connection string: Step 2: Open SQL Management Studio Tools, and enter your database server name, choose "SQL Server Authentication" and enter in the username and password you found in the web.config file If you get an error, then either the passwordstate_user account does not have db_owner rights to your database, or the password is incorrect. To fix this, connect to your database server using another account that has permissions, and confirm passwordstate_user has the correct permissions, and possibly set the password in SQL to match what is in your web.config file.

Step 1: Ensure you have prerequisites set up for your web server and hosts, as per this forum post (Once off process) Step 2: Add new Password Record configured as follows: Screen 1: Ensure you configure the below 5 options correctly and enter in the password for the account. If you configure an Expiry Date it will automatically change the password in Passwordstate and on the Host when that date is reached. Screen 2: Ensure you select the appropriate Privileged Account and the Reset Windows Password reset script. Also confirm the Password Reset Schedule is enabled if you want the password to automatically change when the Expiry Date occurs Screen 3: Confirm the Validate Password for Windows Account validation script is selected

To enable Passwordstate to reset passwords for accounts on remote hosts in your environment, you must ensure you have the following prerequisites set up: Web server and remote host requirements - https://www.clickstudios.com.au/downloads/version9/Passwordstate_Privileged_Account_Management_Manual.pdf In the Passwordstate user interface: Hosts need to be added in under the Hosts tab -> Hosts Home -> View All Hosts Records screen Some systems require a Privileged Account to perform the password reset on the remote host. To determine if you need to set up a Privileged Account, check Section 7 of this guide: https://www.clickstudios.com.au/downloads/version9/Passwordstate_Privileged_Account_Management_Manual.pdf A Password List that is configured for Password Resets (Screenshot below of this setting when creating or editing a Password List) Quick Information About Privileged Accounts: After creating a privileged account, for security reasons only the person who created it is granted access to use it. If you find you create a Password Record, but cannot see the Privileged Account that you thought was already in the system, go back into the Administration -> Privileged Account screen and confirm you have access to it (any any other user in Passwordstate that you need) Screenshot below shows where this can be configured:

If you're new to Passwordstate, this video should help you install it for the first time:

Purpose: You need to find out where Passwordstate is installed for troubleshooting purposes How do I do this? Log into Passwordstate as a Security Administrator, and click Administration. The About screen will tell you your Web Server, which is where Passwordstate is installed: If you now log into your Web Server, open IIS and select your Passwordstate web site. Click Basic Settings and this tells you the physical path to the install. The default path for the Passwordstate installation is C:\inetpub\Passwordstate.

Passwordstate has a web front end, and a database back end, and it is important to know what versions these are on for troubleshooting purposes. If you are in a situation where you can't access Passwordstate through the User Interface, below are the methods to check your versions. To check the Web installation version: 1. On your web server, open the properties of the file c:\inetpub\passwordstate\bin\passwordstate.exe (pre build 9708) or c:\inetpub\passwordstate\WindowsService\Passwordstate.exe (Build 9708 and above) 2. Click on the Details tab, and the ‘File Version’ field shows the build you have installed To check the Database for version Number: 1. Using SQL Server Management Studio, connect to your database server and run the following query: Use Passwordstate Select BuildNo from SystemSettings

If you run into any issues during the install of Passwordstate, you can retry setting it up by following the instructions below. The instructions differ slightly depending on if you are running Passwordstate 8, or Passwordstate 9. Using SQL Server Management Studio, delete the passwordstate database, and passwordstate_user SQL Account as per the screenshots below If using Passwordstate 9, copy the file c:\inetpub\passwordstate\setup\scripts\master_files\web.config.install to the location c:\inetpub\passwordstate. Rename the file to web.config (You should delete any existing web.config file before renaming to avoid errors). Skip to Step 4 If using Passwordstate 8, copy the file c:\inetpub\passwordstate\setup\scripts\master_files\web.config to the location c:\inetpub\passwordstate, overwriting the file which exists there If the file c:\inetpub\passwordstate\setup\Setup_Progress.txt exists, please delete it Now point your browser the URL you specified during the initial install, and run through the initial set up process again. Regards, Support

As of Build 7646, there is now some new information present on your Administration screen - If you need to get further information about the account used to connect to your database, the web.config file lists this information. The web.config file can be found in the install directory of Passwordstate on your Web Server, where the default path is c:\inetpub\passwordstate. In the screenshot below, I've highlighted Database Server, Database Name, SQL user who has permissions to the database and the password for this user: If you find that your web.config file is unreadable, this is because someone has deliberately encrypted the file. This is just a good security Practice. To learn how to decrypt the file to make it readable, please see this forum post: https://forums.clickstudios.com.au/topic/2699-encrypting-and-decrypting-the-webconfig-file/ Regards, Support

This topic will discuss how to take the default web.config file from a new Passwordstate installation, and configure it so the web site can communicate with your existing Passwordstate database. This document should only ever be needed if you have a server crash, and do not have a backup of your web.config file. There are 3 areas in the web.config file which need to be modified, and they are: The database connection string The SetupStage key And the Secret1 and Secret2 keys (Note: these secrets are not relevant if you are using a build of Passwordstate prior to 7580 - see section below if you are not sure what build you're currently running) Determine Current Passwordstate Build Number Using SQL Server Management Studio, make a connection to your database server and execute the following query: USE Passwordstate SELECT BuildNo FROM [systemSettings] It is in the next section you need to know your Build Number, so you know whether the Secret1 and Secret2 keys are required or not. Modify Web.Config File The following settings need to be updated in the PasswordstateConnectionString Data Source - this is the host name of your database server. If you have a specific Instance Name for you SQL install as well, this will need to be appended i.e. HostName\SQLExpress User ID - this should be passwordstate_user The password for the passwordstate_user SQL account (if you are not sure of what this password would be, there are instructions below on how to reset this) The SetupStage key needs to be set to "Setup Complete" If you are using Build 7580 or above, you will need to copy the Secret1 and Secret2 values across from the encryption keys which you would have been asked previously to export. Note: if you do not have these secrets, it is not possible to recover your system. If you are using a build earlier than 7580, you must delete these two Secrets from the web.config file. Reset Password for Passwordstate_User SQL Account Open SQL Management Studio and make a connection to your database server Browse to the Security -> Logins section, and double click on the passwordstate_user SQL Account Reset the password based on the following two screenshots Authorized Web Server You are now able to point your browser to the URL of your Passwordstate web site. When you do, it will tell you the server is not "authorized" to host the Passwordstate application. You can use your Emergency Access login to fix this. If you do not know this account password, then follow on screen instructions so Click Studios can help you recover this account.

Maintenance Mode To streamline the upgrade process, we have introduced a new feature called Maintenance Mode as of build 7476. This can be accessed from the upgrades screen, and it will notify your users that their session will end at a specific time, and they should save their work and exit Passwordstate. The Security Administrator who initiated this Maintenance Mode can monitor how many users are connected to Passwordstate, and when there are no active users, he or she can then proceed safely with the upgrade. No one will be able to log back into Passwordstate until the Maintenance mode has ended. This will automatically switch off after a successful upgrade, or the Security Administrator can manually turn it off if required. Here’s some steps on how to enable Maintenance Mode: When a new build is available, either drill into it via the Passwordstate home page notification, or go to Administration -> Backups and Upgrades -> Upgrade Now -> Enable Maintenance Mode Specify how long before all users sessions are terminated, and click Enable Maintenance Mode button At this stage you will see how many active users are currently connected to Passwordstate, and they will each get a pop up notification on their screen as follows: As they begin logging out, they will drop out of this list. If the time runs out, and there are still active users, they will be automatically logged out of Passwordstate. Something to be aware of, if a user simply closes their browser, instead of clicking the Log Out button within Passwordstate, this does not end their session gracefully. They will appear “active� until the System Setting “Inactivity Time Out� value takes effect. In other words, it may appear that they are logged on, when they are not. One way to forcefully boot all users after the Maintenance Time Out period has expired, is to restart your site in IIS. If any user attempts to log back into Passwordstate whilst Maintenance Mode is active, they will be presented with a message saying Passwordstate is in Maintenance Mode and to contact Security Administrators for more information. As mentioned previously, the Maintenance Mode will automatically switch off once you have completed a successful upgrade. Users will be able to log back in again, and continue on with their work. If, for some reason you need to back out of the upgrade, and would like to manually switch off maintenance mode, you can do so by visiting the Administration home page. Simply click this button and Passwordstate returns to normal. It is also recommended to restart your Passwordstate site in IIS and restart the Passwordstate service on your web server after doing this: In future versions, we will be expanding the Maintenance Mode to give you greater flexibility and control. **Edit 8th December 2015** As of Build 7507, you can now Enable or Disable Maintenance mode at any given time from the Root of the Administration area. You no longer need to be performing an upgrade to enable this mode: **Edit 9th May 2016** As of Build 7641, there is a new link available indicating your system is in Maintenance Mode. Clicking this link will take you directly to the Administration area where you can disable Maintenance Mode. We have also highlighted int in RED to make it more visible.

To change to Passwordstate URL, there are a few things that are required to be completed: 1. Ensure you have a functioning DNS entry for the new URL as per below screenshot: 2. On your Web server, modify the bindings in IIS like screenshot below to match the URL you set in DNS. Using port 443 means you don't have to append the port number to the end of your URL, which makes for an easier URL to remember" 3. If you are using the Self-Signed Certificate that Passwordstate installs, you will need to create a new one with Powershell, using the below instructions. If you would prefer to set up a internal Certificate Authority, and generate a more secure certificate to use on your Passwordstate website, please see this forum post: https://www.clickstudios.com.au/community/index.php?/topic/2934-how-to-set-up-a-internal-certificate-authority/. This forum post describes how to generate a certificate from an internal Certificate Authority: https://www.clickstudios.com.au/community/index.php?/topic/1952-generate-a-new-certificate-from-active-directory-certificate-authority/ Creating a new Self Signed Certificate: 1. On your web server, open Powershell ISE "As Administrator" 2. Ensure Powershell is at least version 4.0, but 5.0 is preferred. Type $host into console and run the script to see what version you are running. If you have to upgrade please use this link: https://www.microsoft.com/en-us/download/details.aspx?id=50395 3. Copy the following code into your Powershell ISE console, and change the URL in the second line to be your new URL - run the script and it will create a new certificate for you. # Begin script $URL = "sandbox.halox.net" $PowershellVersion = $host.version.Major # Create the SSL Certificate, using different commands depending on which version of Powershell is installed. Preferably Powershell 5, as this allows us to set a longer expiry date on the certificate if ($PowershellVersion -eq '4') { $cert = New-SelfSignedCertificate -DnsName $URL -CertStoreLocation Cert:\LocalMachine\My } if ($PowershellVersion -eq '5') { $StartDate = '01/01/' + (Get-Date).Year $EndDate = '01/01/' + (Get-Date).AddYears(5).Year $cert = New-SelfSignedCertificate -DnsName $URL -CertStoreLocation Cert:\LocalMachine\My -FriendlyName $URL -NotBefore $StartDate -NotAfter $EndDate } $rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store -ArgumentList Root, LocalMachine $rootStore.Open("MaxAllowed") $rootStore.Add($cert) $rootStore.Close() 4. Now in IIS, go to the bindings for the site, double-click on the https binding, and select the new certificate you just created from the drop-down list 5. Back in Passwordstate, go to the screen Administration -> System Settings -> Miscellaneous tab, and update the "Specify the Base URL used in any emails generated by Passwordstate" field you see here with the new URL so all the links in the emails sent out are accurate, and various other functionality works as well. Regards, Support

Hi abj, Thanks for mentioning this - we weren't aware of it. In version 7 there is no need to run the Windows Service under the identity of an account any more - just thought we would mention it in case you weren't aware. Regards Click Studios

When using the Active Directory Integrated version of Passwordstate, your browser should pass through your domain credentials from the currently logged in user to the web server, and you should not be prompted to enter your username and password. If you are, the following could be possible causes: Suggestion 1 The Passwordstate web site should be detected as being in the 'Local Intranet' security zone. If it is not, you can add your Passwordstate URL under Control Panel -> Internet Options -> Security Tab -> Local Intranet -> Sites. The option for 'User Authentication' should also be set to 'Automatic logon only in Intranet zone'. You can apply the URL to all machine son your network via Group Policy instead: If you need to quickly check that the URL is in your Local Intranet zone, run the following Powershell code: $(get-item "HKCU:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey").property. If using Firefox, it does this by design. To fix this, please try the following: Open Firefox, and type about:config in the URL bar Search for network:automatic Double click network.automatic-ntlm-auth.trusted-uris and enter your full Passwordstate URL. (Screenshot below for reference) Restart your browse and Single Sign on should now work Suggestion 2 Ensure that the DNS entry you have created for your Passwordstate URL is a CNAME DNS entry, and not a A record. Suggestion 3 Something else which has affected a few customers in the past is the order of authentication 'providers' in IIS for the Windows Authentication. By changing the following setting, helped prevent the web site prompting for authentication: Open IIS and select the Passwordstate web site Open the "Authentication" property under the "IIS" header Click the "Windows Authentication" item and click "Providers" Try moving NTLM to the top, then restart IIS, or reboot the server Suggestion 4 Using host files for name resolution does not work with using Windows Authentication in IIS. You need to use DNS for name resolution. Suggestion 5 You need to be logged on with a domain account, not a local account on a desktop or server. If accessing Passwordstate from a Mac or Linux machine, you cannot prevent this prompt as Single Sign on will not work. Possibly you could consider enabling Anonymous Authentication on your Passwordstate website, which means users need to enter their username and password to access the system. Suggestion 6 Believe it or not, sometimes a reboot of the web server after upgrades has helped quite a number of customers. Suggestion 7 If you do not have a CName DNS record already for your Passwordstate URL, please create one and that should help. An example of a CNAME DNS record can be found in this forum post: https://forums.clickstudios.com.au/topic/1465-changing-the-passwordstate-url/ Regards Click Studios

After you have installed Passwordstate, it's possible you may get a blank screen when you access the site, or a very generic error about an Internal Server error has occurred. This can sometimes occur when you have installed Internet Information Services (IIS) after you have installed the .NET Framework version 4.5. The Passwordstate installer can also install IIS for you if it isn't already installed. If you get this error, you can try the following to resolve it: Open an Command Prompt as an Administrator Type CD C:\Windows\Microsoft.NET\Framework\v4.0.30319 or C:\Windows\Microsoft.NET\Framework64\v4.0.30319 depending on our operating system version Now type aspnet_regiis -i After ASP.NET has been re-registered, ensure the Passwordstate Application Pool in IIS is set to 'Integrated Managed Pipeline Mode', and then restart IIS (you need to open the Internet Information Services (IIS) Manager tool to do this Now open your browser and point it back to the Passwordstate web site You may need to do this for both the 32bit and 64bit versions on the Framework directories above if you still experience issues. This has help a few customers in the past, and we hope you find this information useful. Regards Click Studios

We've had some feedback from customers that Passwordstate can be a little slow at times when browsing around the site, so we've put together some suggestions which may help. ***UPDATE 6th December 2018*** If you are still receiving poor performance, please refer to this new forum post to which will show you how to run a custom script to query your environment. This will help our support troubleshoot your issue quicker: https://www.clickstudios.com.au/community/index.php?/topic/2518-passwordstate-support-information-script/ ***UPDATE 19th July 2017*** Coming in Passwordstate 8, our next major version due to be release by the end of July 2017, is a new feature called "Load on Demand". This new setting allows the Navigation tree to only load the portion of the tree structure that you expand. This significantly reduces that amount of HTML that needs to be returned to your browser from the web server, and feedback on this new feature so far has been that this has greatly helps users that have a lot of Folders and Passwords in their navigation tree. You can turn on Load on Demand under your own personal preferences, as per below screenshot: ***UPDATE 9th DECEMBER 2016*** I've put this update at the top of this post, as we've now released a new build of Passwordstate, Build 7817, which includes some optimizations for the navigation tree. This is probably the most important piece of information in this thread and if you aren't on build 7817 or higher, we recommend upgrading if you've noticed performance issues. You should notice a significant difference in load times when launching Passwordstate, and improvements when working in the navigation tree if you upgrade to this build. Below is a video demonstrating the improvements in this build, and please take note of the new search functionality and option in Preferences to make Passwordstate faster:) Click Studios Base Line Testing and Performance Suggestions: Firstly, we'll detail the sort of performance we see in our development environment, so you can compare to your own. Recommended System Requirements Preferably Dual-Core 1.6Ghz or higher 2 GB Ram 100 MB of disk space for web install 50 MB of disk space for database (smaller initially), plus room for SQL backups. Allow for 10 MB of disk space per user per year Passwordstate will operate in a virtualised environment (Hyper-V or VMWare) Expected Performance We use virtual machines in our environment, with the web server being on one virtual machine, and the database on another. Each machine only has one processor assigned to it, with a minimum of 2GB of memory Clicking between different Password Lists - 1.5 to 2 seconds Refreshing the browser screen (F5) - about 3 seconds on average Restarting IIS and refreshing the browser - about 7 seconds on average (restarting IIS is similar to rebooting your server) Performance Suggestions If you are accessing your web server over a slow link, this will cause delays Certain Anti-Virus software installed on the Passwordstate Web Server or clients can also cause delays - as it scans HTTP requests and content. Possibly setting temporary exclusions in your AV software may help for the C:\inetpub\Passwordstate folder and all sub folders, and possibly the w3wp.exe process. This isn't a long term fix and your AV vendor will need to resolve their issue. Normally the biggest contributor to slowness is lack of available memory on your web server. We recommend to keep at least 1GB of memory available at all times, and memory usage will fluctuate depending on how many concurrent user sessions there are on your web server You can turn of charts on the screen so these do not need to load. Each user can turn off the charts, or you can use a User Account Policy for this for multiple users at once - If you need help with this please log a support call to Click Studios Try and limit the number of records you display in the Passwords grid. Where possible, try and use paging and the search feature, as the more records you display, the more HTML rendering is required Some customers have seen poor performance when using various 'Desktop' based anti-virus solutions on their web servers. Some of these products are not intended for web servers, and you can temporarily disable to see if it makes any difference In Internet Information Services Manager, click on the Passwordstate web site, then on Compression and disable Dynamic Compress. Restart the web site after this In Internet Information Services Manager, open the 'Advanced Settings' for the Passwordstate Application Pool, and ensure Idle Time-out (Process Model) and Regular Time Interval (Recycling) are set to 0. If the application pool is recycled at any stage, this would cause the initial session to Passwordstate to be slow If using SQL Server Express, ensure AUTO_CLOSE is disabled for the Passwordstate database In Windows Server, ensure Indexing is disabled on the drives where SQL Server and Passwordstate are installed We've also had one customer which had almost 1000 Password Lists/Folders present in the Navigation Tree on the left hand side. This can cause performance issues, due the amount of HTML it needs to rendered - not only for the Navigation Tree itself, but also for all the images. Unfortunately there's not a lot we can do when there is this much HTML to render, and we worked with the customer to provide recommendations for reducing the amount of Password Lists displayed **Update - As of Build 7580, there is now an option under Preferences -> Home Page called "Hide all Password List/Folders in the Navigation Tree". Setting this option and using the search feature will speed up the rendering of the page (Video below describes this in more detail) We've also had one instance of virtual machines with AMD processors causing performance issues, but we cannot confirm this ourselves If you RDP directly into your Passwordstate web server, what is the performance like then? This will help isolate if there is an issue between the desktop computer and the Passwordstate web server Passwordstate installs with approximately 500 default Bad Passwords, but it is possible to import more into the system. The below table outlines the expected performance for different ranges of imported Bad Passwords: Video of how to apply User Interface Optimizations Regards Click Studios

Whilst it's not entirely necessary to encrypt the database connection strings within the web.config file, it is recommended so the SQL Account credentials used to access the Passwordstate database is encrypted and unreadable from anyone who can read the file system on your web server. To encrypt the database connections string, please follow these instructions: Encrypt Connection String Open a command prompt and change to the v4.0.30319 .Net Framework folder (normally found under C:\Windows\Microsoft.NET\Framework\v4.0.30319) Type the following: aspnet_regiis.exe -pef "connectionStrings" "c:\inetpub\passwordstate" (change the path if you've installed Passwordstate to a different location) Decrypt Connection String Open a command prompt and change to the v4.0.30319 .Net Framework folder folder (normally found under C:\Windows\Microsoft.NET\Framework\v4.0.30319) Type the following: aspnet_regiis.exe -pdf "connectionStrings" "c:\inetpub\passwordstate" (change the path if you've installed Passwordstate to a different location) Regards Click Studios

When using the Active Directory Integrated version of Passwordstate, your browser should pass through your domain credentials to the web server, and you should not be prompted to enter your username and password. If you are getting a prompt, the following could be possible causes: Suggestion 1 If using Internet Explorer, check the Passwordstate web site is being detected in the 'Local Intranet' security zone, and the option for 'User Authentication' is set to 'Automatic logon only in Intranet zone'. You may need to add the URL of the site to a group policy which forces Internet Explorer to detect the site is in the intranet zone. Alternatively, each user can add this manually in Internet Explorer via the Internet Options -> Security Tab: If using Firefox, it does this by design. To fix this, please do the following: In Firefox, type about:config into the URL field In the search box, paste in network.negotiate-auth.trusted-uris Double click network.negotiate-auth.trusted-uris and enter your Passwordstate URL, and ensure there is no / on the end, so the URL should look something like https://passwordstate.com Click OK, and restart Firefox Suggestion 2 Something else which has affected a few customers in the past is the order of authentication 'providers' in IIS for the Windows Authentication. By changing the following setting, helped prevent the web site prompting for authentication: Open IIS and select the Passwordstate web site Open the "Authentication" property under the "IIS" header Click the "Windows Authentication" item and click "Providers" Try moving NTLM to the top, then restart IIS, or reboot the server Suggestion 3 Using host files for name resolution does not work with using Windows Authentication in IIS. You need to use DNS for name resolution. Suggestion 4 Believe it or not, sometimes a reboot of the web server after upgrades has helped quite a number of cutomers. Regards Click Studios