Troubleshoot HA Polling Issues

We’ve recently had a few technical support calls querying how to diagnose High Availability issues.  To make things easier, with identifying the health of all Passwordstate Servers, we included the health status under the Authorized Web Servers screen in Passwordstate 9.0 Build 9000.  This uses a traffic light approach of “green is good”, “red needs investigation”.

So, if your HA server shows a status of red what do you do next?

Recap on HA Implementations

To start with let’s recap on Passwordstate’s High Availability offerings.  The following logical diagram shows 2 variations of Passwordstate with High Availability.  The solution, as depicted by the Green Dot 1, is an Active / Passive implementation.  This allows the Passwordstate High Availability instance to be enabled, and will provide read only access to requests in the event of an issue with the Passwordstate Primary Instance.  All access events are audited and synced with the Passwordstate Primary Instance once recovered.

The solution, as depicted by the Blue Dot 2,shows an Active / Active implementation.  This requires a Load Balancer redirecting the End User’s Passwordstate traffic to either the Passwordstate Primary Instance or the Passwordstate Secondary Instance.  This offering allows users to update data in both the Primary and Secondary instances of Passwordstate.  It requires Basic Availability Groups, or Always On Availability Groups to be implemented in Microsoft SQL Server Standard and above.

Your High Availability Server along with your Primary Server will show up on the Authorized Web Servers page.  This page is available at Administration->Authorized Web Servers and details the Polling Health, Last Poll Time, Server Role and HA Mode along with the Install Path.  Our test environment is shown in the screenshot below;  

Note the Host Names must be entered in their NETBIOS name format not FQDN (Fully Qualified Domain Name).

High Availability: Active-Passive Implementation

When running your Passwordstate High Availability model in Active / Passive mode your HA Server will initiate the polling.  It does this through the Passwordstate Windows Service attempting to contact the Primary instance’s API.  When it successfully connects to the API it will complete the poll and your Primary instance will record the Polling Health status as green for your HA Server.

If your Polling Health status isn’t showing as “green is good” you’ll need to investigate the cause.  The first thing you can check is if the API is functional.  To do this try creating a password using the password generator icon in the top right-hand side of your Passwordstate User Interface;

When clicking on the password generator a password should be generated in the dialog box as shown above.  If this works successfully then the API is functioning correctly.

You can also check if the connection to your API is functioning correctly by opening a web browser and typing in the URL for your Passwordstate instance with the following appended to the URL /api/highavailability/primarypoll/polltest.  If the connection is successful, you’ll see the following result;

If the connection fails, in this example because the Application Pool wasn’t running, you’ll see an error message like;

It does this via a GET request to the specified Uri (URL) as an asynchronous operation.  For more information on the GET request please see .

Connection issues are always caused by issues with an incorrectly configured Load Balancer, Reverse Proxy or Firewall issues between the two Passwordstate instances.  You can also check the Authorized Webserver Host Names are the Netbios names and not the FQDN.

High Availability: Active-Active Implementation

When running your Passwordstate High Availability model in Active / Active mode your High Availability Server (secondary instance) writes its Polling Health status directly into the Passwordstate Database.  As with Active / Passive implementations this will then show the Polling Health status as green for your HA Server. 

Again, the biggest issue we find with a Passwordstate instance not correctly participating in an Active / Active HA implementation is incorrectly configured Firewalls or your Passwordstate Windows Service isn’t started. Again, check the Authorized Webserver Host Names are the Netbios names and not the FQDN.

Knowing where to look when you experience HA Polling Issues is straightforward.  Unfortunately Click Studios can’t tell you how to resolve your Load Balancer, Reverse Proxy or Firewall issues as the number of suppliers for these is huge and growing. You will need to log a call with the vendor responsible for the equipment if you are unable to identify and resolve the issue.

Got feedback?  We’d love to hear it!  Send it through to

Where Can You Upload Documents in Passwordstate?

One of the key remits, or areas for active consideration for our development team, is the flexibility of use of Passwordstate. Since its first release, way back in August 2004, our developers have continually looked at how they can add flexibility and value to the core concept of secure password management.

Back in August 2020 we published a blog entry that gave suggestions on what else can be recorded in Passwordstate.  From Credit Card details, to Software Licenses and SSL Certificates.  If you haven’t read that blog entry the link is here

But what if you need to add documents, such as Operating Procedures, Process Documentation, Contract details etc.  Where can you add those, so that the documentation is located logically right alongside the information or credentials, that you’ve chosen to protect with Passwordstate?

Password Lists and Records

The first areas that documents can be added to is both at the Password List and Password Record levels. 

We have customers that add policy or ownership documentation to each Shared Password List, outlining who the business or IT owner is for the Password List, the functional roles allowed access to the list and who to contact when requesting changes be made.  Don’t forget, the Password List may not hold traditional Password Records.  As an example, it may function as a “light” contract management database, holding all software contracts for a particular business unit.  

Likewise, we have customers that add documents to individual Password Records, this can be a process or guideline document that states what a particular credential can be used for.  Alternatively, using the “light” contracts management database angle above, it may hold the contract details such as period of coverage, service level agreements and contact numbers for a single contract.

To add a document to a Password List simply click on the Password List then Documents then Add Document;

and when adding documents to a Password Record, click on the action icon next to the record, select View Documents and Add Document;

In both examples you’re then prompted with the Add New Document dialog.  Just fill in the File Name and Description and the use the Select button to open File Explorer, select the file you want to add and click Open, and the Save;

Your document is now added against either the Password List or Password Record depending on where you’ve decided to upload it. 


The next area you can add documents to is Hosts.  This is especially useful for Process and Work Instructions that are specific for certain servers. 

For instance, you may have an application server with temperamental services that requires special attention every time a Microsoft update is applied (we’ve all experienced this haven’t we).  While it would be nice for those application vendors to improve the resiliency of their software it sometimes takes them years.  In the mean time you could add a document reminding your System Admins to restart the badly behaving service or restart a series of them in a particular order.

To add a document to a Host, simply select the Host in question and click on the Add Document as per the screen shot below;

This will bring up the same Add Document dialog previously shown.  Again, simply fill in the File Name and Description and the use the Select button to open File Explorer, select the file you want to add and click Open and then Save.

What Do Lots of Password Lists and Hosts Need?

If you read the heading above then you’ll know where this is headed – that’s right, Folders. If you’ve got lots and lots of Password Lists or Hosts then you really should be making your life easier by organising them.  This is where Folders are essential, they allow you to logically organise Password Lists and Hosts into meaningful collections.

And you’ll have guessed what you can do with Folders as well.  That’s right, you can add documents to Folders.  But why would you want to do this?  Let’s use the example that you’ve got your High Availability systems distributed across geographically dispersed Data Centres.  When it comes to patching you may have procedures to only patch certain servers in each data centre on specific days.  This can be summarized in a document at the Folder Level.  Or you may have a process instruction that states system reboots for particular systems requires coordination with a key business stakeholder.

Again, the process is the same for adding the documents as it is with Hosts, Password Lists and Password Records.

How Do You Restrict This?

Firstly, only those users that have been granted access to those specific Password Lists, Password Records, Hosts and Folders have access to add Documents to those objects.  Secondly you can enable or disable documents being uploaded, limit the size of the documents being uploaded and restrict uploaded documents to specific extensions by navigating to Administration->System Settings->miscellaneous as per the screenshot below;

Note: you can also link off to external systems containing documentation by using the External Links feature on Folders and Hosts.  This may be a useful method of linking to documentation stored with SharePoint or a Wiki based system;

Adding documents to Passwordstate can be extremely beneficial, you really just need to think how can I make this work for me.  As always, if you’ve got any feedback you’d like to share please send it to

Self Destruct Messaging Implementations

Passwordstate includes a Self Destruct Messaging portal as part of the core software.  Self Destruct Messaging typically allows you to send emails or messages within an application, containing content considered to be highly confidential, to be viewed for a specified period of time.

In the case of Passwordstate’s Self Destruct Messages, the content that you share is stored only within the Self Destruct Messaging portal.  Access to be able to send Self Destruct Messages relating to a Password Record is permissions based and you can control both the ‘Time to Live’ and number of times the data or Password Record can be viewed.

How are Self Destruct Messages Sent

In this example we’ll use a scenario where we want to temporarily share a password record with a contractor that doesn’t normally have access to Passwordstate.  The Self Destruct Messaging portal we are using is the embedded implementation, meaning it is automatically included as part of your Passwordstate website and can be access by appending /selfdestruct to your Passwordstate URL.  The version of Passwordstate used in this example is V9 Build 9300.

To share the Password Record with the contractor we simply, click on the Action Menu next to the record and select Send Self Destruct Message;

This brings up the Self Destruct Message Screen where we can compose our message.  We specify the period of time the message is alive for and the number of times it can be viewed.  Both these fields are drop down lists where you can select from predefined options.  Once complete click Next;

Next, we enter the contractor’s email address, change the subject line as appropriate and click Next,

In this case we’re using Passphrase Protection, so we’ll need to set the Passphrase and advise the contractor what that is (in a separate email) and then click Send Message,

The contractor now receives the following email,

To access the details of the Password Record, the contractor will need to click on the URL, noting the ‘Time to Live’ for the Self Destruct Message is 30 min from the email being sent.  This will bring up the Self Destruct Message portal screen requiring authentication using the Passphrase separately emailed to them and then clicking Next,

The Self Destruct Message is then displayed (I’ve redacted the details in the image below),

The person that sent the Self Destruct Message will receive an email confirming when the message has been viewed by the recipient.

Self Destruct Messaging Implementations

The example used above is based on the embedded implementation, which is part of your existing Passwordstate instance.  The Self Destruct Messages under this model can only be used where you can also access your Passwordstate website.  This means that if your Passwordstate instance isn’t internet facing then you’ll also not be able to share Self Destruct Messages over the internet.

You can however implement the Self Destruct Message portal a couple of other ways.

  • The first, using a Push\Pull implementation.  This works by sending messages from your core Passwordstate website to a Microsoft SQLite database.  When the customer accesses the Self Destruct website, it reads the Self Destruct Message directly from that SQLite database and the message is deleted when they are finished with it.  This implementation doesn’t require any open ports to your Passwordstate website, or your Passwordstate database and requires no management of the SQLite database.  It enables the hosting of your Self Destruct Messaging website in a DMZ.  To configure this option, you’ll need to specify the URL for the site and generate an Encryption Key.  Instructions are located under the Administration Tab->System Settings->self destruct messages->Push\Pull Deployment Self Destruct Install Guide button.
  • The Second, is via your AppServer hosted within your DMZ.  This implementation requires you to connect to the AppServer to read the Self Destruct Messages.  This method doesn’t use the SQLite DB. Instead, it uses connectivity back to the Passwordstate database, hosted on your internal network. A port, typically the SQL port 1433 needs to be open.  If you are already using the AppServer as internet facing, in order to sync with your Mobile Apps on Smartphones, it makes sense to use this.  However, you should perform an internal risk assessment to ensure the solution meets your requirements.

There are multiple implementations available for the Self Destruct Messaging Portal and you are encouraged to select the model that best suits your organizational requirements. 

As always, if you’ve got any feedback you’d like to share please send it to

New Upgrade Process

With the release of Passwordstate V9 Build 9300 we’ve changed the way that Passwordstate is upgraded.  The old In-Place Upgrade Capability is deprecated and no longer functions for any previous build of Passwordstate.  If you try to perform an In-Place Upgrade, on builds prior to 9300, you’ll receive the following error message;

Upgrade error detected – It appears the file /upgrades/ is corrupt. Please delete this file and then restart the upgrade process again.

This is by design as the In-Place Upgrade Capability has been blocked by Click Studios.  Build 9300 removes the In-Place Upgrade Capability and all upgrades are now performed by our new Common Software Installation Process.

What is CSIP

The new Common Software Installation Process, or CSIP for short, uses InstallAware’s Windows Installer software as the engine for upgrading your Passwordstate instances.  It uses code developed by Click Studios to accurately detect aspects of your configuration, ensuring the deployment of the correct assemblies that your instance needs when upgrading.

CSIP handles both new installations as well as upgrades to existing installations.  There are two flavours currently available from our website and Content Delivery Network (CDN), 

  • For customers already using Passwordstate V9 the correct download is the one available underneath the Passwordstate 9 (Build 9300) header.
  • For customers upgrading from a build earlier than 8995 the correct download is the one available underneath the Passwordstate 8 (Build 8995) header.

Check the Checksum First!

We strongly recommend comparing the checksum of the downloaded file against the checksum information published on our website at the time you download the file.  Each time a new build is released the checksum value will be different and you should confirm it against the value published on our site.

In the example below I’ve downloaded the CSIP package for an existing V9 installation and have compared the checksum value to ensure the download hasn’t been tampered with;

Performing an Upgrade

The process of upgrading is very straightforward.  But before you do, please ensure you’ve read the Upgrade Instructions document.  The link for this is located at the bottom of  

Once you’ve read this, and taken any steps required, simply extract the contents of the downloaded ZIP file and run the passwordstate.exe as an Administrator on your Passwordstate webserver.  This will perform various checks and you will be prompted to click the checkbox to confirm a backup has been taken of the Passwordstate folder and database (LHS of image below).  Please make sure you have a successful backup of these and then click Next

You’ll now be presented with the License Agreement Screen (RHS of image below).  Take the time to review the License Agreement and if you want to accept the terms of the license agreement click the checkbox.  Now you can click Next to begin the upgrade.

This will present you with the image below (LHS) stating that CSIP is now ready to configure Passwordstate on this computer (webserver).  Click Next and the upgrade will commence (RHS).

When CSIP has completed installing your upgraded files you will be presented with confirmation that the first phase of the upgrade has completed.  You are then requested to log into your Passwordstate instance, and complete the database upgrade phase.  This process is exactly the same as in previous builds of Passwordstate.  Click Finish to close CSIP.

The upgrade of the core product really is that simple.  As always, if you’ve got any feedback you’d like to share please send it to

Linking Multiple Websites to One Password Credential

Our Technical Support Team recently assisted a customer with an issue related to form-filling credentials for a website where the website redirects to a secondary page.  This can happen when the primary URL for the website redirects the user to another URL for part of the login process. 

Example: Microsoft Advertising

The example we’re using for this is Microsoft’s Advertising login.  The primary URL we’re using takes us to the username webpage of automatically form-fills the email address as our username;

However, the password webpage is located at and because of this the Browser Extension doesn’t correctly form-fill the password;

Linking Multiple Website URLs

To fix this we need to add in the additional URL for the credentials in Passwordstate.  To do this, login to Passwordstate, select the Password Record and using the Action icon select Link Account to Multiple Web Site URLs;

From there you’ll need to add in the additional URL, in this case as the URL above is ;

Once this is saved, you’ll either need to logout and then back into you Browser Extension, or alternatively wait at least a minute before retrying.  Once you’ve done that credentials in our example now correctly form-fill on both screens.  The Enter Password Screen is shown now form-filling below;

As always, if you’ve got any feedback you’d like to share please send it to

Dipping the Big Toe in the Water – Trialling Scheduled Password Resets

We were having this discussion the other day about “dipping your toe into the water” and one of the new hires in our Technical Support Team had never heard the saying before.  So… the hunt was on during lunch to find the history of the saying.  According to it’s a metaphor that means “to try something new or start a new project cautiously without over-commitment or too much risk.  It dates from the late 20th century and derives from the obvious allusion of dipping a toe into water to test the temperature”.

Or another way to look at it, is to “start doing something slowly and carefully, because you’re not sure whether it will be successful or whether you will like it”.  That sounds like a great angle for trialling scheduled password resets in your organization.

What are Scheduled Password Resets

Scheduled Passwords Resets are part of the Privileged Account Management (PAM) functionality provided in the core Passwordstate product.  It enables customers to perform on-demand or scheduled password resets across multiple different systems and platforms. It uses a flexible and extensible design, through the use of PowerShell scripts, to allow password resets across your IT Infrastructure and Business Systems.

But why is this so desirable?  As an example, let’s work on the basis that you’ve got a couple of hundred PCs in your business.  Each of these has a Local Account.  As part of a best practice approach, the credentials for each of these Local Accounts should be unique and reset periodically, in accordance with your organization’s password management policy. 

That’s a lot of effort when you have to manually logon to each PC, reset the password and record the details in your password management system.  Passwordstate allows you to record the accounts for all these hosts, perform an initial reset on the account to allow it to be managed and then schedule regular password resets for the Local Account.

What you need before you get started

The only real prerequisites for performing automated password resets on local accounts, is to enable PowerShell Remoting and have a Shared Password List that has been setup with the Enable Password Resets setting selected.

PowerShell Remoting is enabled by default for Windows Server 2016 and above but not for Windows 10 Clients.  You can enable it via group policy as per the following article by TechRepublic (as an example)

To enable PowerShell remoting on some test machines, login to each of them and start PowerShell, choosing to Run as administrator, and execute enable-psremoting -force as per the screenshot below;

Next, you’ll need import the required PCs or Servers into Passwordstate.  To do this you’ll need to setup a Host Discovery job to scan Active Directory and import the hosts on into Passwordstate automatically.  The example below shows a Host Discovery job for Windows 10, 8 and 7.  To setup a Host Discovery Job navigate to Hosts->Host Discovery Jobs->Add Discovery Job and Add a new Discovery Job like the screenshot below;

Note you’ll need to have a Privileged Account Credential which should be a member of the Domain Users Security Group so it can read Active Directory for the information relating to the hosts you are discovering.  We have a comprehensive video, showing how to set up a Host Discovery job, available from our YouTube Channel here

Discover your Local Accounts

Now that you’ve discovered all of the target PCs, Passwordstate can begin scanning them for you and adding in any Local Accounts, as individual Password Records into a specific Password List.  This can also set them up for automatic resets when it adds the account into Passwordstate if you choose, or you can do this at a later date. 

In our example we’ll setup a Windows Local Admin Accounts discovery job by navigating to Tools->Account Discovery and Add a new Discovery Job by clicking on the Select Discovery Job Type to Add… and select Windows Local Admin Accounts as per the screenshot below;

The discovery job in the example above is creating Password Records for all Local Accounts in the shared Password List Workstation Accounts.  However, the discovery job is set for Enabled for Heartbeats only at this stage as per the screenshot below;

There is also a video on how to setup your Account Discoveries here

Note, with all discovery jobs, you can choose to run them in Simulation Mode, which performs the scan and reports back what it finds via email without adding any of the results into your Passwordstate instance.  That’s how the 2 jobs in the examples for this blog have been setup.  It’s a great way of initially building confidence in the process before making changes to production machines.

Setup a Trial Password Reset Job

Now you’re ready to dip that proverbial big toe in the water.  To do this you’ll run your Host Discovery job as normal, not in simulation mode, to import all the hosts that you’re interrogating for Local Accounts. 

Next you need to run the Windows Local Admin Accounts discovery job. Again, not in simulation mode and making sure you haven’t selected the Enabled for Resets tick box.  This will discover all the Windows Local Accounts against the target hosts you’ve imported and add them into the specified Password List, in this example Workstation Accounts.

At this stage no passwords are reset, as Enabled for Resets hasn’t been ticked.  Now simply edit the Password Records, for a select number of hosts, and tick the Enabled for Resets box and save the record.  Passwordstate will now reach out to those hosts and reset the password with the newly generated password recorded in Passwordstate.

You can now logon using the Local Account on each of those hosts, using the password that’s recorded in Passwordstate, to confirm the process has worked as expected.  Once you are comfortable that the process worked as expected you can perform the Bulk Update Password Reset Options from the List Administrator Actions dialog beneath the Password Record Display Grid.  You can now search for the password records to update, choose the fields to update tab, select the Managed Account, tick the box to Enable Password Resets Option for all these accounts and select Save.

Additional Information

Documentation on both the Host Discovery and Account Discovery jobs can be located in your Passwordstate instance here;

Help->User Manual->Hosts->Hosts Home Screen->View Host Discovery Jobs, and,

Help->User Manual->Passwords->Tools Menu->Accounts Discovery

As always, if you’ve got any feedback you’d like to share please send it to

Configuring the Brute Force IP Lockout Feature

Brute Force Attacks use a process of trial-and-error to guess the right credentials.  The attack works by using repeated sequential attempts to try and guess your username and password combination and force their way into your private accounts.  While considered an old attack method it’s still effective and popular with Cyber Criminals as it can result in relatively quick results depending on the length and complexity of your passwords.

Brute Force Attacks come in many unsavoury flavours and include;

Simple Brute Force Attacks: Where the attempt is to logically guess your credentials without the use of software tools or other means.

Dictionary Attacks: Where targeted accounts are subjected to repeated attempts of gaining access based on dictionaries containing known passwords.  Dictionary attacks are considered one of the most basic tools used in brute force attacks.

Reverse Brute Force Attacks: This style of attack starts with a password and then millions of usernames are searched through until a match is found. The starting point is usually by referencing leaked passwords available as a result of data breaches.

Credential Stuffing:  Is where Username and Password combinations that have worked for one website are retried against other websites the targeted individual may use.

Does Passwordstate Protect Against Brute Force Attacks

Yes, Passwordstate has a number of options for Blocking Brute Force Attacks to your Passwordstate webserver.  The first is located under Administration->System Settings->authentication options->Web Authentication Options.  Here you can specify the number of permitted failed login attempts before Passwordstate locks out the IP Address for the active session as per the screenshot below;  

You can also delay the returned error message by the specified number of seconds.  This makes it harder for Cyber Criminals to identify if the account actually exists (so they can harvest valid account details), or if the password supplied is simply incorrect.

The next option is to configure X-Forwarded-For support.  X-Forwarded-For is a standard header for identifying the originating IP address of a client connecting to a web server through a Firewall, HTTP proxy or load balancer.  When configured, in Passwordstate and your upstream devices, it enables you to lock-out the IP address of the computer the user is logged into and not the upstream device such as the Firewall.  Note your upstream device also needs to be configured for X-Forwarded-For support.

To tell Passwordstate you have configured your device for X-Forwarded-For support, navigate to Administration->System Settings->proxy & syslog servers-> X-Forwarded-For Support and enter the IP Addresses of trusted devices as per the screenshot below;

Note as of Passwordstate V9 Build 9117, we have added in an additional feature that takes the username into consideration when locking out an IP Address.  In these examples, it means that 3 unsuccessful login attempts, from the same user/IP address will lock their IP Address out if they were accessing your site from behind a device that isn’t configured for X-Forwarded-For Support.

Some users have been incorrectly Locked Out

This can happen if you set too aggressive a target for failed logins.  It’s a fine balancing act between not penalizing users when they incorrectly enter their details and preventing Brute Force attacks.  Every organization should consider the risk and impact and set the number of failed logins accordingly.

However, if a user’s IP address has been incorrectly blocked you can remove the blocked IP address by navigating to Administration->Brute Force Blocked IPs and select the Action icon next to the incorrectly blocked IP and click on Remove Blocked IP Address as per the screenshot below;

Make Brute Force Attacks Harder

Even though you can apply the settings outlined above there are still some prudent steps you can take to make it harder for a Brute Force Attacks. 

The first of these is to always use strong passwords.  Remember dictionary attacks using a list of common passwords, or a hybrid brute force attack that performs small changes to words by adding numbers or changing the letter case, are likely to succeed in some cases.  You need strong passwords to make their life harder.  Secondly, use 2FA where it makes sense.  Two-factor authentication can prevent Cyber Criminals from gaining access to your accounts.  It makes it nearly impossible for them to gain access to an account via a Brute Force Attack.

Have feedback, then we’d love to hear it via

Base Passwordstate Installation in Azure and AWS

­­­­­­Passwordstate is marketed as an on-premise web based solution for Enterprise Password Management.  However, “on-premise” doesn’t really mean it has to be based out of a physical bricks and mortar location.  On premise really means from a “location” where you’re in control of network access to the product, can configure the physical or virtual resources that service the product, and are responsible for granting permissions to known individuals and groups to be able to access the data stored within Passwordstate.

Based on this you can, if you choose to, host Passwordstate within a Cloud Service where that Cloud Service provides an extension to your own network, account directory and credentials.  Click Studios has tested and supports hosting of Passwordstate within both Azure and AWS.

The installation for Passwordstate is pretty much the same regardless of where you install it.  The majority of the changes relate to the configuration of the cloud platform.  This Blog will show you the key setup areas required to host Passwordstate on these platforms.

Hosting Passwordstate on Microsoft Azure

The specifics of your Passwordstate server will be dependent on your workload and the number of Users and Credentials stored within Passwordstate.  The System Requirements can be located here and apply to both on-premise and virtual implementations.  As an indication our own Azure based instance has the following characteristics.

You have a number of options when it comes to SQL Server for your Azure hosted Passwordstate instance.  If you’ve simply provisioned an Azure Windows Server, and want to host your web and database server on the same machine, you can follow the standard installation instructions, located on the Documentation page on our website here  Alternatively, you may want to take advantage of the other services available within Azure such as the Azure SQL.  Azure SQL is Microsoft’s fully managed cloud relational database service that shares the same code base as their traditional SQL Server offerings.

One key point with setting up Passwordstate in Azure is that our installer is unable to create the blank database, used during setup of Passwordstate, if you have elected to use Azure SQL.  You are also unable to use the SQL Management Studio Tools as per our installation instructions.  Instead, you’ll need to login to Azure and create the blank database in Azure SQL by navigating to SQL Databases:

Now create a new database by clicking on Create and then Create SQL database,

This will take you to the Create SQL Database.  Set the Database name to passwordstate and choose an existing Azure SQL Server to host this database.  If you do not have an existing SQL Server in Azure you’ll need to create one and assign a Server Admin.  Take note of the Server Admin details as you’ll need these credentials to connect with SQL Management Studio Tools in one of the following steps.

Next, you’ll need to create a local SQL account called Passwordstate_user.  To do this right Click Master Database and select New Query.  Then copy and paste the following into the window and click Execute:

CREATE LOGIN passwordstate_user WITH password='<choose a password>’


Now, you’ll need to assign db_owner rights for the passwordstate_user account to the Passwordstate database you’ve previously created.  To do this right click on the Passwordstate database, select New Query and run the following;

CREATE USER passwordstate_user FOR LOGIN passwordstate_user WITH DEFAULT_SCHEMA=[dbo]


EXEC sp_addrolemember ‘db_owner’, ‘passwordstate_user’;


Now when you install Passwordstate, for the Database Setting make sure to select the second tab connect to blank database and choose Microsoft Azure, entering your Azure SQL Database Server Name, SQL Server Instance Name, Database Name, and the passwordstate_user account and password you created.  Passwordstate will then proceed to populate the created database and the install will then finish as normal.

Hosting Passwordstate on AWS

When it comes to the database requirements for Passwordstate hosted in AWS you can select the database engine to be SQL Server Express, SE (Standard Edition) or EE (Enterprise Edition) depending on your requirements.  You’ll need to create a Database Instance in AWS  when logged in to the AWS console, and select Services and click on RDS as per the image below;

This allows you to create the RDS based on your choice of either SQL Server Express, SE or EE.  Click on Get Started Now, and then select the Database Engine that best suits your requirements.  In the example below I’ve selected the SQLExpress 2019 version;

Next, create a DB instance identifier name of anything you like.  In the example we’ve called it passwordstate.  Then create a Master username that you will use to administer this instance.  By default, the username is admin.  Take note of the password you are setting for this account:

Next on the Connectivity screen ensure you select ‘Yes’ for Public Access – This will allow you to connect to your RDS database instance from anywhere,

You should now be able to create your database.  Once it’s created, you can now connect to it using SQL Management Studio Tools.  This official Amazon guide shows how to find your connection details, and establish a connection:

Once you are connected, you will be able to use the SMSS tools to create the empty database, and a SQL account used to connection between the Passwordstate website and the AWS RDS database.  To do this right click on Databases and select New Database,

Call the database “passwordstate” and click OK,

Next, expand Security, right click on Logins and select New Login,

Select the account type as SQL Server authentication, and set the Login name to be passwordstate_user.  Now choose a strong password and click OK,

Now select the User Mapping menu, and assign the db_owner rights to the passwordstate database.  Click OK to save this,

Now when you install Passwordstate, for the Database Setting make sure to select the second tab connect to blank database and choose Amazon RDS, entering your Amazon instance in the Database Server Name field, Database Name, and the passwordstate_user account and password you created. 

Passwordstate will then proceed to populate the created database and the install will then finish as normal.

Migrating Existing Passwordstate Instances to the Cloud

The above details can also be used when migrating from an on-premise instance to the cloud.  Just remember to follow the documentation, located under Passwordstate General Administration here, the documents you want are Moving Passwordstate To A New Database Server and Moving Passwordstate To A New Web Server and theinstructions need to be performed in that order.  Finally, please remember to migrate them before decommissioning your existing instance.

Have feedback, then we’d love to hear it via

Performance Improvements – How to Troubleshoot and Resolve Issues

From time to time we receive support requests from customers having performance issues with Passwordstate.  In a significant number of cases the issues contributing to, or even the direct cause of the performance issues, are related to configuration or environmental considerations within a customer’s network.

To begin with, let’s recap on a set of very simplified installations.  The following image outlines 2 different Passwordstate installations that are typically encountered by our Technical Support Team;

The top of the image above shows a simple Passwordstate instance, with the webserver and database installed on the same Windows Server.  This could be either a physical or virtual server.  In this example the customers client PCs are connected via Wi-Fi to a simple Switch with in-built Wi-Fi.   

The bottom of the image shows a larger setup, with a dedicated Passwordstate webserver, deployed in High Availability mode and stack of virtual servers.  In this example the webserver and database servers are installed on separate Windows Servers and all members in the example are connected over a traditional ethernet network.  The Passwordstate webservers site behind a load balancer. 

In all instances, when a user has been authenticated and navigates to a screen in Passwordstate, their web browser is rendered based on the HTML for the screen they are accessing on the webserver, validated by the permissions they have been assigned as recorded in the SQL database, and the results of the SQL query for the data they are requesting.  This by necessity requires multiple interactions (queries and responses) between the webserver and SQL database before the results are rendered in the user’s web browser.    

Common Performance Issue Symptoms

Using the 2 typical implementations above, we are on occasion advised that users are experiencing performance issues.  These can typically be broken down into the following types of performance issues;

  • Overall responsiveness in Passwordstate
  • Slowness in navigating through Folders and Password Lists
  • Passwordstate sessions abruptly terminated
  • Features not working correctly or at all

There is some duplication between the underlying causes for the above and a number of these can, when aggregated, result in a significant impact to performance of your Passwordstate implementation.     

Examples of Approach to Issue Identification and Resolution

The following are examples of approaches toward identifying the underlying cause of the performance issues and resolving these. 

Overall Responsiveness:  The overall responsiveness in Passwordstate can depend on a number of factors.  This includes;

  • network connectivity between the client PC, Passwordstate webserver and SQL database
  • it can be affected by the number of Folders and Password Lists on the Passwords Tab and Folders and Nodes on the Hosts Tab
  • misconfiguration of any Load Balancers and Reverse Proxies
  • excessive number of entries in the auditing table

To test and resolve these, it’s recommended to;

  • confirm the issue with responsiveness is widespread or confined to only some users
  • verify there are no inherent network connectivity issues between the clients PC, the Passwordstate webserver and SQL database
  • test local authentication as opposed to Cloud based SAML authentication
  • develop and test a User Account Policy that applies Load on Demand and Node Capping
  • review and remove unnecessary Folders and empty Password Lists
  • reduce the size of your auditing table to less than 500,000 entries by archiving
  • bypass the Load Balancers and/or Reverse Proxies.  If this resolves the issue please liaise with the vendor supporting these

Slow Navigation with Passwordstate:  This is usually affected by the number of Folders and Password Lists on the Passwords Tab and Folders and Nodes on the Hosts Tab.  As an example, on the Passwords Tab you have a folder hierarchy with 1000 Folders and underneath each of these a number of Password Lists.  By default, when you navigate to the Passwords Tab the underlying query will validate your access to view and then retrieve the details of the 1000 folders, along with the Password Lists contained within these folders.  This produces a substantial amount of data that will then need to be rendered within your web browser.  It can also be affected by;

  • setting the password records display grid to a very large number of records
  • poorly behaved Anti-Virus software

To test and resolve these, it’s recommended to;

  • again, confirm if the issue is widespread or confined to some users
  • set your Password Records display grid to no more than 10 records
  • use the Search capability to locate the Password Record rather than browsing through Folders, Password Lists and long display grids
  • use a User Account Policy that applies Load on Demand and Node Capping
  • review and remove unnecessary Folders and empty Password Lists
  • test if your Anti-Virus software is the cause by temporarily setting exclusions on the Passwordstate folder structure on your webserver.  You can also temporarily disable the AV software to test this.  Please note if this resolves the issue you should enable your AV software and remove any exclusions before contacting the vendor for a permanent fix.

Passwordstate sessions abruptly terminated:  This is usually caused by either badly behaved Anti-Virus software or Windows Patching having installed patches that require a subsequent reboot.  Windows patching has in some cases caused Passwordstate sessions to intermittently fail.    Some Anti-Virus Software products are known to kill sessions in IIS with the following types of error being reported in Passwordstate Error Console screen;

  • It appears the user’s session in IIS has been prematurely ended, causing the following error
  • Object variable or With block variable not set
  • Error Code = Incorrect syntax near the keyword ‘DEFAULT’
  • Error Code = Thread was being aborted
  • ApplyScreenCustomisations
  • There was an issue validating both the AuthToken session variable and cookie
  • The parameterized query
  • Specified argument was out of the range of valid values in conjunction with ApplyScreenCustomisations()

Some Reverse Proxies and Load Balancers can also cause these errors.  In order to rule these out please bypass them and monitor the Error Console.

Features not working correctly:  The single biggest cause of Passwordstate features, such as Self-Destruct Messages, Password Reset Portal, API issues, SAML Authentication and HA polling not working correctly is misconfigured Load Balancers and Reverse Proxies.  To determine if these are negatively impacting on the functioning of Passwordstate please bypass them and retest.

By working through some basic troubleshooting steps you can usually find what is causing the underlying performance issues with your instance.  If you are still experiencing issues after having worked through the above, or there are other errors being reported in the Error Console then please send these through to for assistance.

Once again if you have feedback, we’d love to hear it via

Mitigating The Need for Internet Access

Mobile Client support, introduced back in Passwordstate 6.2 (2013), enabled access to your password credentials from iOS, Android, Windows Phones and Blackberry devices.  Its primary focus was providing remote access to managed credentials while away from your normal place of work, be it your day-to-day PC or LAN, or while out of the physical office. 

The architecture required a Mobile Gateway, installed on either your main Passwordstate webserver, or optionally, on a separate webserver hosted in your DMZ (Demilitarized Zone) talking back to your main Passwordstate instance. Once configured within Passwordstate, all that was required was a supported mobile device, capable of HTML5 rendering via its web browser.  Users would effectively login to Passwordstate, via the Mobile Gateway using their UserName and the preconfigured PIN. 

Under this architecture a user would access credentials live against their Passwordstate instance.  The implications being that network coverage using either, a WiFi connection for access inside your network, or cellular connection for access outside of your network, was required.  If there wasn’t an active network connection, you couldn’t talk to the Passwordstate instance, and you couldn’t access your credentials.    

Replacement under Version 9

The approach to mobile device access under V9 has been completely redesigned and the original Mobile Client support, as it existed under Version 6.0 through 8.9, has been deprecated. 

The new architecture requires the installation of a Passwordstate App Server.  This replaces the previous Mobile Gateway and is an extensible platform for future requirements.  Under the new architecture the App Server brokers the connectivity between the client device and the Passwordstate instance.  The App Server can again be installed on your main Passwordstate instance, or on a webserver within your DMZ.

The smartphone clients are now purpose-built iOS and Android apps, that authenticate using an independent credential set.  The smartphone apps allow for storing password records that a user is authorized to access, locally on the smartphone, within an encrypted cache.  Security has been increased, and also allows the option for using the biometric capability of the smartphone, when accessing the data within the encrypted cache.  All authentication and access of credentials is audited and synced back automatically with Passwordstate on next connection.    

Advantages of the new Architecture

From a usability perspective the primary benefit of the new architecture is that all the password credentials, and only those that the user has been authorized access to, can now be stored in an offline encrypted cache on their device.  This effectively provides the user with access to the credentials anywhere, anytime and regardless of the need for an active network connection. 

This cache is valid for the number of days set at Specify the number of days the user can access their offline cache before they need to re-authenticate again to the Passwordstate App Server.  This is set globally under Administration->System Settings->mobile access options->Mobile App Settings or individually under Administration->User Accounts-> “select a user” ->Edit User Details->Mobile Access Options.  The latter option overriding the global setting for that user. 

Please note that every time the user performs a sync within the Mobile App the time to live for the offline cache will be reset back to the specified number of days for that user.

From a security perspective the biggest benefit is that you potentially no longer need to have your Passwordstate Server running the “mobile gateway” internet facing.  As long as your staff have internal network access to the Passwordstate App Server, and can resync their offline encrypted cache before it is due to be wiped, then you potentially no longer need Passwordstate to be internet facing. 

Note that this currently only applies to the use of the Mobile App.

Levels of Security on the Mobile App

There are a number of levels of security associated with the use of the Mobile App, ranging from the length of time an offline cache can remain valid, the password strength for each user’s Master Password, protection against brute force dictionary and Man-in-the middle attacks,

Add to this the previously mentioned biometric capability of most current smartphones and access to the offline cache is kept secure.

How to Source and Install the App Server

To source and install the App Server you need to be on Passwordstate Version 9.  Simply navigate to Administration->System Settings->mobile access options and click on the Download App Server Installer.  Both the installer file and install guide are sourced from your existing Passwordstate Installation and the file is located under \inetpub\Passwordstate\downloads,

If you don’t have V9 installed then you’ll first need to perform a Manual Upgrade to Version 9.  Instruction for this can be found at and is located under Upgrade Instructions on the page.

The use of the Passwordstate App Server and native iOS and Android apps can mitigate the risk of having your Passwordstate instance internet facing in some use cases.  Each organization should look at their usage requirements and perform internal risk assessments to ensure their design, risks and associated mitigating factors are appropriate for their business.

Once again if you have feedback, we’d love to hear it via