Database Management post Build 9493

On 7th April 2022 Click Studios released Passwordstate Build 9493 which supported the storing of Unicode characters in the Passwordstate Database.  The change to Unicode ensures the unique representation for every character, no matter the language. Unicode forms the foundation for the representation of languages and symbols in operating systems.

Prior to Build 9493 Passwordstate’s character encoding used Extended ASCII.  The first time a V9 upgrade is performed, from Build 9471 (or earlier), to Build 9493 (or later), it will upgrade the database to Unicode format as a once only operation. 

What Are The Implications?

Customers should be aware that during the upgrade the Passwordstate SQL Database and transaction logfile will increase in size by approx. 300% to 400%.  You’ll need to ensure there is adequate free space available before you start the upgrade, and the location used for your backups can support the additional size of the backups.

If you’ve previously capped the Autogrowth of your Passwordstate database then it’s recommended you temporarily set this to either Unlimited growth, or set the Maximum File Size by multiplying the existing size by a factor of 6 (allowing for additional contingency).  This will need to be done for both the database and the logfile.

To confirm if you’ve capped Autogrowth, or to set the Maximum File Size, start Microsoft SQ Server Management Studio and select the passwordstate database.  Right click on the database and select Properties.  From the Database Properties box click on Files, select the first entry.  If the Autogrowth/Maxsize column shows Unlimited at the end then Autogrowth is uncapped.  If it shows Limited to… then it has been capped.  To change the settings simply click on the box containing and change the settings as indicated in the image below

Don’t forget to check both the entries and adjust them if necessary.

Shrinking The Database

Once the Passwordstate upgrade has been completed successfully you can shrink down the database and logfile.  Please note, you won’t be able to obtain the same file size you had originally.  Unicode requires more space to store characters than Extended ASCII. 

The easiest and quickest way to shrink your database and logfile is to do the following,

  • Start Microsoft SQ Server Management Studio,
  • Select the passwordstate database and right-click,
  • Select New Query,
  • Enter DBCC SHRINKDATABASE (Passwordstate)
  • Click the Execute button

When the query has finished executing, you’ll see results in the format shown in the green box below.  Note the figures will be different based on your database and logfile,

Alternatively, you can shrink the database and the logfiles from within SQL Management Studio Tools User Interface without executing a SQL Query.  Please see section 15 of this guide if you’d like to follow this method

Share your feedback by emailing it through to

Troubleshooting Mobile App Error: Connection Failed

Way back in February this year (it seems like only a couple of days ago) we published a blog post on Troubleshooting Passwordstate App Server/Mobile App Connections.  The focus of that post was ensuring there was data to synchronize, checking the user had access, generating the QR code and making sure the URL and Public Key were correct.  You can access that blog post here

The focus of this blog post is different, in it focuses on troubleshooting the App Error Connection failed message.  This can appear when attempting to scan the QR code into the Mobile App,

But before we start, it’s worthwhile doing a recap on the communications flow between your Mobile App, the App Server and your Passwordstate instance.

Mobile Communication via the App Server

The diagram below offers a high level logical view of the communications flow between a Mobile App and your Passwordstate implementation.  There are two models in the diagram.  The first on the top (green communications lines), shows a Passwordstate instance where the Passwordstate Webserver, Database and App Server are all located on the same box.

The second on the bottom (orange communications lines), shows a Passwordstate instance where the Passwordstate Webserver, Database and App Servers are all located on separate servers.  There are other options such as hosting your App Server, with the Mobile App functional Role, in your DMZ enabling it to be internet facing.  However, the principle of the communications flow between the Mobile app, the App Server and your Passwordstate instance remains essentially the same.

Do you need to Update your software?

To confirm in an update is required to either the App Server or your Mobile App please refer to the following;

  1. Refer to the Upgrades Dependency Matrix in  This will identify if an upgrade is required.  If it is, then follow the instructions under Section 6 App Server Upgrade Instructions.  Once you have upgraded you can test scanning the QR code again.
  • Navigate to either the Play store, or the Apple store to see if there are updates for your device’s Passwordstate Mobile App.  If a new version exists then download and install it.  Again, once you have upgraded you can test scanning the QR code again.

Is your App Server Reachable?

To test to see if your App Server is reachable is straightforward.  This tests the communications from your Mobile App through to the App Server running your Mobile App functional Role.  To do this open the bowser on your Android or iOS Smartphone and enter the App Server URL that is specified in Passwordstate under Administration->System Settings->mobile access options->Mobile App URL and Security

If the App Server is reachable from your smartphone, you’ll see a “200 | Status OK” message like below; 

If you don’t see the “200 | Status OK” message then your App Server URL is not reachable from the smartphone.  This will more than likely be a network related issue (before all the Network Admins start complaining – I used to be one.  Sometimes it is a network related issue).  This can include Firewall or Wi-Fi configuration, or DNS blocking the access.

Confirm your App Server Settings

If you still aren’t able to connect, you’ll need to check your App Server Settings.  The first item to check is that the App Server name is set correctly under Administration->Authorized Web Servers,

The name must be in Netbios format and not specified in FQDN (Fully Qualified Domain Name) format.  If you don’t see your App Server in the display grid on this page then you’ll need to add it by clicking on Add beneath the display grid. 

If the App Server already exists you can check the Functional Roles for that App Server include Mobile App.  To do this click on the name of the App Server and ensure the checkbox for Mobile App is ticked as per the image below,

Check your App Server Web.config File

Next you can check that your App Server’s web.config file is correct.  To do this use Notepad to open the correct web.config file located in C:\inetpub\PasswordstateAppServer.  Look in the <appSettings> section for the following line,

<add key=”SetupStage” value=”Setup Complete” />

If it exists, then someone has accidently added this text into the file. You should delete it and confirm the settings look similar to the image below,

then save your Web.config file, and in IIS, restart the Passwordstate App Server website.  Now you can try the process of scanning in the QR code again.

By following these steps, the majority of issues causing a connection failure can be easily resolved. 

Share your feedback by emailing it through to

Authorized Webserver Functional Roles

Part of the new functionality introduced in Passwordstate Build 9493 is the concept of using Functional Roles.  Functional Roles are supersets of functionality, that are designed, packaged and can be operated independently of your Primary Passwordstate instance.  It provides the ability to offload specific functional workloads from your Passwordstate instance to other webservers.  

To do this it uses the App Server architecture introduced in V9.  The App Server was designed as an extensible platform with the first example of implementing a Functional Role being for our Mobile App connectivity.  As of Build 9493 this has been extended to 7 main roles.  This can be especially useful if you need to offload intensive processing associated with one of these roles to another webserver in your farm.

New Functionality for Authorized Webservers

Under Administration->Authorized Web Servers you can now choose to install multiple App Server instances and assign each of these one or more functional roles.  The roles that can be assigned are;

  • Standard API
  • Windows Integrated API
  • Browser Extensions
  • Remote Site Locations Agent
  • Password Reset Portal
  • Self Destruct Messages

It’s always good practice to add your Authorized Webserver entry prior to installing the App Server on the new webserver.  Once your Passwordstate instance has successfully polled a new App Server it will turn the Polling Health status to green and specify the correct Install Path.  To define a new webserver with a Functional Role, simply click on Add as per the screen below;

This will take you to the Add New Authorized Web Server screen showing the fields to be filled out;

Enter the NetBIOS name for the Web Server Host Name, select the Server Role of App Server and select one or more of the Functional Roles you wish to assign to this instance of the App Server.  Note if offloading Functional Roles to another webserver;

  • they should only be with a Server Role of App Server,
  • should be deselected from your Primary Server (to avoid confusion and inconsistent results), and,
  • Your Primary Server and High Availability Server (if implemented) should always be set the same.

To instal the App Server on the nominated webserver you can download PasswordstateAppServer.exe from within Passwordstate by navigating to Administration->System Settings->Mobile Access Options and click on the Download App Server Installer button.  I’d also highly recommend you first review the Installation and Administration Guide to ensure you’re using the very latest information.  The guide can be accessed via the App Server Install Guide button and is also located on our website here

Ensure the Correct URLs are set for Functional Roles

When you offload a Functional Role to another webserver it’s important to ensure you update the URL required for that new webserver;

  • For the Standard API, this is specified in your scripts
  • For the Windows Integrated API, this is specified in your scripts
  • For the Browser Extensions, this is specified under Administration->Browser Extension Settings-> Browser Extension Settings
  • For the Remote Site Locations Agent, this is specified under the specific settings for each Remote Site Location.  To find these navigate to Administration->Remote Site Administration->Remote Site Locations
  • For the Password Reset Portal, this is specified under Administration->Password Reset Portal Administration->System Settings->miscellaneous
  • For the Self Destruct Messages, this is specified under Administration->System Settings->self destruct messages

Please Note, when offloading the Remote Site Locations Agent to an App Server, it will source the upgrade files from that server instead of your core Passwordstate instance when it auto-updates.

Secure Your App Servers

Don’t forget to ensure you encrypt the Web.config file for each App Server instance you deploy.  You’ll need to encrypt both the Database Connection String and the appSettings Section.  For information on how to do this please refer to  Remember you’re encrypting the Web.config file located in c:\inetpub\PasswordstateAppServer.  Again, if you have a different installation directory then you’ll need to look there for the Web.config file.

If you would like to share your feedback, we’d love to hear it.  Just email it through to

Custom Operating Systems linked to Hosts

A couple of weeks ago we published a blog article on how to create Custom Account Types and Scripts .  This week’s blog article builds on that with running through how to add custom Operating Systems and linking these to Hosts.

Adding a Custom Operating System

In our previous blog you’ll have created a Custom Account Type by navigating to Administration->Images and Account Types. 

Now we’ll add a custom Operating System as well.  To do this we’ll navigate to Administration->Host Types & Operating Systems and click on View Operating Systems as shown below, 

This will take you to the screen showing all the Operating Systems, Host Types and AD Attributes.  From here we’ll add the new Operating System by clicking on Add Operating System,

now we’ll specify the Host Type, in our case Linux, and type in the name of the Operating System we’ll add.  In this example we’ll add in GeckoLinux (based on the openSUSE distribution it’s great for out-of-the-box usability on the desktop),

Note, we’ve set the AD Attribute to ‘na’ as the Linux host isn’t added to Active Directory as we’re not interested in scanning AD to import these hosts via discovery jobs in this example.  Once completed we’ll click on Save.

Adding a New Host

Next, we’ll add in a host manually under the Hosts Tab and tag the host with the Custom Operating System entry we created.  To do this we navigate to Hosts and click on Add Host.  This will open the Add New Host screen.  Here we specify the Host Name (GeckoLinux_01), select the Host Type (Linux) and choose GeckoLinux from the drop down list,

We’ll also specify the connection type of SSH and the port number of 22 before clicking on Save.

Then Specify the Credentials, and Reset Scripts

When you Add New Password record for connection to the host, you can select the Account Type of Linux and then start typing in the Host Name (GeckoLinux_01) and it will populate the field correctly.  We’ve also added the Username (Root) and supplied the Password,

then moving reset options tab, the Password Reset Script has been populated correctly with the reset script to be used.  Then simply click on Save to save the Password Record.

If you would like to share your feedback, we’d love to hear it.  Just email it through to

Migrating Passwordstate and Upgrading at the same time!

Click Studios provides extensive documentation for our customers.  This covers everything from User and Security Administrator Manuals, Installation Instructions, instructions on how perform upgrades and General Administration tasks.

The approach we use for our documentation is to include everything, and I do mean everything.  We even get the occasional complaint that some of the documentation is too long.  But that’s okay!  Experienced Passwordstate Security Administrators can get to choose what they want to read.  The approach we use means that while the documentation can be long, it can also be used as reference for less experienced Administrators and those new to Passwordstate.

Those wanting to jump straight-in can find our documentation page here and those wanting to navigate to it via our website menus can find it here,

How do I Move Passwordstate & Upgrade at the same time?

A common support request we receive, is how do you move Passwordstate to a new server and also upgrade it to the latest version.  This is actually a very simple process that we already cater for in our documentation.

First, you’ll need to decide if you’re moving just your Passwordstate Webserver or are you moving the Passwordstate Database as well?  If you are moving the Database then this move must happen first.  This documentation can be located here or for those wanting to navigate via our website menus, it’s located here,

By following these instructions in this document, you will effectively;

  • Ensure your new Database Server has Microsoft SQL installed, and,
  • Your database has been moved.

Once you’ve followed the documentation to move your Passwordstate Database (or if not moving it at all) you’re ready to move your Passwordstate Webserver. This documentation can be located here or for those wanting to navigate via our website menus, it’s located here,

Again, by following these instructions in this document, you will effectively;

  • Have Installed the correct Build of Passwordstate.  This will be either,
    • Initially Build 8995 (If your current version of Passwordstate is less than Build 8995), and,
    • Then upgraded to the latest V9 Build (if your current Build is 8995 or higher)
  • Copied the entire ConnectionStrings and AppSettings sections from your existing Web.config file into the new website.  If your settings are encrypted you must have decrypted them before copying them, and,
  • Encrypt your new Web.config’s ConnectionStrings and AppSettings sections as this is best practice and highly recommended.

Other Instructions to Consider

If you are upgrading from a version prior to V9 you may want to also consider the following;

Configuring the built-in backup capability using either a Domain Account using Network Shares or Local Folders, or, using a Local Windows Account with Local Folder.  These can be found by navigating via our website menus here,

Or, directly here for number 1 in the green circle above, or for number 2 in the red circle above.

Give our documentation a try.  We think you’ll find it’s easy to understand, straight forward and will help you perform the tasks you need to.  If you would like to share your feedback, we’d love to hear it.  Just email it through to

Custom Account Types and Scripts

Passwordstate uses PowerShell scripting as the extensible platform for PAM, or Privileged Account Management.  The PowerShell scripts provided with Passwordstate enable Account Discovery, Password Resets and on-demand or scheduled validation (Heartbeats) to confirm that accounts are being managed through our solution.  For more information on what types of systems can be discovered, reset and validated please refer to our website here .

Where the strength of our PAM solution is evident is through the flexibility and extensibility of the PowerShell scripts.  In the event, that some infrastructure components or business systems in your environment aren’t covered by the large number of default scripts we provide, you can simply copy one of our scripts and modify it for your requirements.

Add your Custom Account Type

As an example, we’ll create a new Account Type, set it to having Password Resets performed against it and associate it with a custom image.

To do this, navigate to Administration->Images and Account Types and click on Add beneath the Images and Account Types display grid.  This will bring up the Add New Account Type screen shown below. 

In our example, we’re going to give it an Account Type Name of Test, ensure the Managed radio button Yes is selected, we’ve clicked on Select and chosen a custom image to upload called Padlock.png and then clicked the Save button.

Add a Password Reset Script

Next, we’re going to setup a Password Reset Script for the Test Account Type.  To do this, navigate to Administration->PowerShell Scripts and click on the Password Resets button.  This will take you to the Password Reset Scripts page.  Now click on Add New Script underneath the display grid and you’ll be presented with the Add Password Reset Script screen below;

Here we’ll add a Script Name of For Test Account Type and a Description of Test and select Create Blank Script from the Create Script Contents From drop down list, then click Save.

Edit the PowerShell Script

Now we can edit the newly created Script by navigating to Administration->PowerShell Scripts and click on the Password Resets button.  Again, this will take you to the Password Reset Scripts page.  Next, we’ll locate the Script Name For Test Account Type and click on the Script Name which is actually a hyperlink,

This will open the Edit Password Reset Script editor, allowing you to insert your code and choose from Host, Dependency and Password Fields to insert into your code as appropriate.  In the example we are inserting the fields of OldPassword and NewPassword,

Once completed click on the Save button.

Password Records using Custom Account Type and Reset Script

Now when you add new password records, on the password details tab you can select the Custom Account type (in our example Test) from the Account Type drop down list and select the Managed Account check boxes for Enabled for Resets and Enabled for Heartbeats,

And on the reset options tab, select the correct reset script (in our example For Test Account Type) from the Password Reset Script drop down list,

When passwords are changed for these records, either manually or as a scheduled task, Passwordstate will reach across to the target system using the Password Reset Script and change the password on those systems.

This is of course a simple example of what needs to be done.  In reality you would create Password Validation and Password Reset scripts and the PowerShell coding required can end up being quite complex.  A best practice approach would see these scripts being developed and tested outside of Passwordstate.  Once they are working as expected and have been through your organizations Change Management processes they can be included as per the instructions in this blog.

If you would like to share your feedback, we’d love to hear it.  Just email it through to

Troubleshooting Passwordstate App Server/Mobile App Connections

The Mobile Clients introduced in Passwordstate V9 are purpose-built iOS and Android apps.  These authenticate using an independent credential set and allow the secure storing of password records locally on the smartphone, within an encrypted cache. 

You can use the biometric capability of your smartphone to access the data within this cache and all authentication / access of credentials is audited and synced with your Passwordstate instance on the next connection.  We have some exciting news about upcoming features in these apps…but that’s for a future blog.

In the meantime, if you find you have issues in connecting via the App Server or in Synchronizing entries between Passwordstate and the App we’ve produced this troubleshooting blog article for you.    

Ensure there is data to Synchronize…

Interested Passwordstate users have gone to the respective Apple and Google Play stores and downloaded the Apps.  Everything seems to be working and then you start getting support calls related to some users being unable to connect or synchronize credentials to devices. 

The first thing you may want to check is your Password Lists are enabled for Mobile Access.  This is a default setting when you grant a user access to a Password List and is controlled under Administration->System Settings->mobile access options->Mobile App Settings->When adding new permissions to Password Lists, enabled Mobile Access by default being set to Yes

You can confirm If they have access by viewing the Password List Permissions, and should see a tick under Mobile Access for the user in question, 

Note that the default setting can be individually selected or deselected when adding permissions to a Password List.  This is done by right clicking on the Password List, selecting View Permissions, and then selecting Grant New Permissions and clicking on the No radio button, 

The Mobile Access Permissions on Password Lists can also be modified in bulk by navigating to Administration->Password Lists->Perform Bulk Processing…->Mobile Access Bulk Permissions.

If this all appears to be correct then you may want to check the user has been granted access to use the Mobile Native App feature.

…Check the user has been granted Access…

You can control which Users or Security Groups have access to the Mobile Native App feature by navigating to Administration->Feature Access->mobile and clicking on the Set Permissions button,

This works exactly the same as other permissions screens.  If they haven’t been granted access, simply search for and add the appropriate Security Group (preferred) or User with the >> button and click Save,

You’ve now checked they have been granted access to the Mobile Native App and have Data to be Synchronized.

Generate your APP Server QR Code and Password

If the Users are still unable to connect to the App Server or are unable to synchronize data you can try getting them to clear their existing Master Password, supply a new one and generate a new QR Code.

To do this have the user login to Passwordstate and click on Preferences->Preferences->mobile access options->Mobile App Settings and click on the Clear button.  They need to then type in a new Master Password and once done click Save,

This will generate a new QR Code which they’ll need to scan when re-pairing their mobile app.  When re-pairing please ensure the username they are supplying is the one specified under Mobile App Username:.  If this is a domain account the format will be Domain Name\Mobile App UsernameThe password is the new Mobile App Master Password they have just set, not their Domain password.

Make sure your URL and Public Key are correct

If you have recently changed your Base URL for the App Server or updated the SSL Certificate, you’ll need to ensure the settings under Administration->System Settings->mobile access options->Mobile App URL and Security have been updated.  If either of these have changed, you’ll need to ensure the URL under Specify the URL for your Passwordstate App Server installation is correct, then click on the Generate New App Pairing Secret,click on the Clear and then Query button to obtain the Public Key for the App Server’s SSL Certificate.  Once done click Save,

If when clicking Query you receive an error message or the Public Key box doesn’t populate then there is an issue with the App Server URL, your DNS or Firewall settings.

When successful, you’ll now need to have each user regenerate their APP Server QR Code and Master Password and re-pair their mobile app as per the previous section.

IIS, DNS and Port Settings

If you are still having issues with connecting to the App Server then you should also check on the following;

  • Check that your HTTPS binding in IIS (Internet Information Services) has the same URL you have set under Administration->System Settings->mobile access options->Mobile App URL and Security
  • Make sure your DNS entry is set correctly for the App Server URL, and it is pointing to the correct server.  To check this, you can run CMD.exe as an Administrator and type nslookup followed by the FQDN (fully Qualified Domain Name) of the App Server
  • Confirm the port you are using for the App Server URL is open. By default it uses port 443 but you should confirm that is the port specified in your IIS binding.  If you have a HA implementation, and are using a SQL Listener as part of SQL Replication between database servers, then the port must be open on both SQL Servers
  • Ensure the App Server can communicate to the Passwordstate Database.  Login to the Server hosting the App Server, Start PowerShell as an Administrator and type Test-NetConnection followed by the FQDN of the server followed by -Port 1433.  This will return the IP addresses and a TCPTest Succeeded: True if successful.
  • Test that you can reach the App Server URL from your Smartphone.  Type the App Server URL into your Smartphone browser and you should see a 200 | Status OK message on the page.  This means the Smartphone can successfully reach the App Server.  Any other result indicates the App Server URL is not reachable.  You may want to try this test via the business WIFI network and via your Smartphone Carrier’s network if the App Server is internet facing.

By working through these steps, you should be able to troubleshoot the reason why users are unable to connect or synchronize data and resolve the issue for them.

Got feedback you want to share?  Email it through to

Troubleshooting AD Password Resets Performed via the Portal

The intent of our Password Reset Portal, is to remove unnecessary interaction by Help Desk staff and Systems Administrators when users need to reset their Active Directory Users Accounts.  The portal is aimed at making users self-sufficient at the process, ensuring they can reset the account when they need to, and allow support staff to focus on higher value tasks.

Error: Password Doesn’t Match the Policy

But what happens when the process doesn’t seem to be working?  We recently assisted a customer with a scenario where the users couldn’t seem to match the Password Policy no matter how often they tried.  They attempted to troubleshoot this by generating a password in Passwordstate however this wasn’t being accepted either.  So where do you start to troubleshoot AD Password Resets performed via the Password Reset Portal? 

To start off with let’s use an example of a Password Policy and Failed Reset Message.  This is configured under Administration->Password Reset Portal Administration->Password Policies,

Note: You can set the Failed Reset Message wording so that it’s consistent with the language used within your organization.

Password Reset Portal Process

At a high level, the process that is used within the Password Reset Portal is;

  1. When a user resets their AD password, the characteristics of that password must adhere to the Password Policy that has been defined.  For the sake of this blog the Password Policy is the Default Policy and is the same for all fields as we’ve set in the previous image.  Again, this is set by navigating to Administration->Password Reset Portal Administration->Password Policies,
  2. As the user types in the new password, the Portal page will report on what characteristics are required to set a password.  These must match the policy and feedback is provided live as they type in the new password,
  3. Once all requirements are satisfied the Password Reset Portal will attempt to reach out to Active Directory to reset the password.  At this stage, if your Domain Password Requirements as specified in your Domain Group Policy have further complexities, then the user’s new password will be evaluated against these further complexities.

If the Password Reset is rejected with the Failed Reset Message in the image above, then it is most likely the error you are seeing is coming from your Domain and not the Password Reset Portal.

Settings that Impact on Portal Resets

There are a number of settings that can impact on the Password Reset Portal successfully resetting a user’s password. 

The first is located in a group policy setting.  Open your Group Policy Editor and navigate to Local Computer Policy->Computer Configuration->Windows Settings->Security Settings->Account Policies->Password Policy and look for a Policy setting stating the Minimum password age

The Minimum password age of 1 day is the default setting.  It is used to prevent repeated resets until a favourite password can be cycled back in again.  You’ll need to consider the risks associated in changing this default, and if acceptable you can relax this setting and enable multiple password resets per day by changing the Security Setting to ‘0’,

The next setting that can impact on successfully resetting the password is if your permissions associated with impersonation aren’t correct.  To check this, you’ll need to launch the Local Security Policy editor by running secpol.msc.  From there you’ll need to navigate to Security Settings->Local Policies->User Rights Assignment and review the permissions that are set for Impersonate a client after authentication.  These should be set to the following as per the screenshot below.

  • Local Service
  • Network Service
  • Administrators
  • IIS_Iusers
  • Service

And lastly, it’s possible that you may have a fine grain policy set in Group Policy, that takes precedence over your Standard Password Group Policy. 

This may have been set with a Minimum password age set to something greater than 1, or, may have stricter password complexity requirements.  To check if you have a fine grain policy set up you’ll need to logon to one of your Active Directory Domain Controllers, open the Active Directory Administrative Centre and navigate to System->Password Settings Container as per the image below,

If there is a policy show in the area outlined by the green box above then please check the settings.  If you’re unsure you may want to refer to the person that is applying the policy.

Privileged Account Credential Permissions

One final thing you can check is to confirm the Privileged Account Credential, that you have specified for the Password Reset Portal, has sufficient permissions to reset the AD Accounts.  The Privileged Account Credential is set under Administration->Password Reset Portal Administration-> Privileged Account Credentials

This should be a member of the Account Operators Security Group.  If it isn’t working you can temporarily test with as a member of the Domain Admins Security Group.

Got feedback you want to share?  Email it through to

Stopping and Restarting your Passwordstate Instance

We’ve recently had a number of enquiries around the best way of Stopping and Restarting Passwordstate.  Most of these enquiries have been related to businesses getting ready to test their Annual DR (Disaster Recovery) and BCP (Business Continuity Plans).

With this scenario in mind, we’ll establish for the sake of the blog entry, that we’re talking about a Passwordstate Primary Instance with HA (High Availability) instance in an Active / Passive configuration.  It is assumed that the HA instance is on a separate network with associated infrastructure enabling it to be contactable as required.

The image above represents a simplified logical view for this blog entry.  The webserver and database servers are installed on separate Windows Servers and all members in the example are connected over a traditional diverse pathed ethernet networks.  The Passwordstate webservers site behind a load balancer.

What Needs to Be Stopped?

The premise for this blog is you want to ensure your High Availability Instance is running and can be pointed to in the event your Primary instance is non-functional.  In order to test this, you need to effectively stop your Primary instance and then test your HA instance is functioning.  But how do you do this?

You could simply shutdown the Primary instance webserver.  Or you could follow shutdown the Primary Instance Passwordstate Windows Service and IIS (Internet Information Services) Site.  The Passwordstate Windows Service is used to perform all background tasks for the website, which typically includes;

  • Sending email notifications,
  • Sending out scheduled reports,
  • Performing scheduled password resets, heartbeats and discovery jobs,
  • Checking for new builds online,
  • Removing expiring access to passwords, and,
  • Sending auditing data from you HA server to your primary server (in Active/Passive HA configuration)

However, simply shutting down the Passwordstate Windows Service is not enough.  This will only stop the scheduled actions listed above. You’ll also need to Stop the Passwordstate IIS Site to prevent people form being able to login to Passwordstate and access Credentials via the API or via our Browser Extensions.

How do I stop the Windows Service and IIS Site?

There are a couple of ways of stopping the Passwordstate Windows Service.  The first is via Windows Services App.  Simply start the Services App, Search down the list of services for Passwordstate Service, right click on the service and select Stop as per the image below; 

Alternatively, you could fire up the Windows CMD Shell as an Administrator and type in Net Stop “Passwordstate Service” and hit enter as per the image below;

Next, you’ll need to stop the Passwordstate IIS website.  To do this you’ll need to start the Internet Information Services (IIS Manager) App on your webserver.  Expand the sites folder, select Passwordstate and click on Stop under Manage Website as per the image below;

This instance of Passwordstate is now effectively stopped and will not service logins, credential access via API or Browser Extensions and no scheduled background actions will run.

How do my Load balancers monitor the availability of Passwordstate?

If you were using a High Availability instance of Passwordstate, that is running in Active/Active mode, then it’s possible that you have a load balancer in front of both of your sites.  Typically, your load balancer should automatically fail over to a working site, if one of them became unavailable.

Passwordstate has a dedicated page that your load balancers can monitor, to confirm if it is running successfully, and this page is called “keepalive”.  This is designed to provide a return code of 200 if a Passwordstate instance is up and running.  The keepalive page your load balancer should periodically check is <your Passwordstate URL> with ‘/keepalive’ appended to the URL.

You may be tempted to use your normal Passwordstate login URL but you shouldn’t.  The reason for this is you may have Anonymous Authentication disabled for your Passwordstate login page.  If so ten this may return results that your load balancer may interpret as a failure triggering a failover when it isn’t required.  Many Load Balancers don’t like pages that redirect and your primary URL will redirect to different login pages, depending on the type of authentication you have set.

The Keep Alive page is always set to use Anonymous Authentication and it will never redirect.

How to restart the Windows Service and IIS Site?

Once you’ve finished your testing simply start the Internet Information Services (IIS Manager) App on your webserver, expand the sites folder, select Passwordstate and click on Start under Manage Website as per the image below;

Then start either the Services App searching for the Passwordstate Service, right click on the service and select Start as per the image below;

Or fire up the Windows CMD Shell as an Administrator and type in Net Start “Passwordstate Service” and hit enter as per the image below;

That’s all there is to it.  As outlined above you have a number of methods of effectively shutting down a Passwordstate instance for DR and BCP testing.

If you have feedback and are unsure where to send it?  Send it through to

Browser Extensions, Options when Saving and Ignored URLs

Back in November 2020 we published a Blog article called Ignored URLs and Browser Extensions.  The focus of that article was on how to promote strong password generation, encourage users to use Passwordstate and understand the options presented when saving a password record.  You can find the previous article here

Since then, we’ve updated the Browser Extensions, the dialogs and the buttons that are presented.  This blog article is about the changes that we’ve made since the previous article above.

Changes to the Add Site to Passwordstate Dialog

When navigating to a website, one that you don’t have any saved credentials for, on logging in you will be prompted to Add Site to Passwordstate?  The image below shows the new Browser Extension dialog on the Left (Green Arrows) and the old Browser Extension on the Right (Red Arrows).

The first obvious change is the old CloseIgnore and Save options (Right, Red Arrows) have been replaced with Later, Never and Save options (Left, Green Arrows).  Note, I’ve removed the username from the images of both Extensions.

The reasoning behind the changed labels on the buttons was to make it clear what action was taken when clicking on each button;

  • Later (was Close):  This will simply close the Add Site to Passwordstate dialog and take no further action.  When you next login to that site you’ll be prompted once again to Add Site to Passwordstate.
  • Never (was Ignore): This was the button wording that confused many customers.  When clicking Ignore in the old Browser Extension, you weren’t telling the Browser Extension to ignore the add request this time.  You were telling Passwordstate to create an Ignored URL for that website and never prompt to add a record for that websiteever again!  This wording has been changed to Never to make it clear you never want to save the credentials for that site (which creates an Ignored URL entry).
  • Save (was Save):  You get the idea here.

Update Password Dialog

Once you’ve added the record, it’s a good idea to periodically change the passwords for your websites.  When you change the password on the website the Browser Extension will prompt you to Update Password as per the image below;

You have two options presented, Later and Update;

  • Later:  Again, this will simply close the Update Password dialog and take no further action.
  • Update: This will update the password record with the new password.

Don’t forget, the Generate Password screen from the Browser Extension is a great way of generating complex passwords for your website logins.  And you don’t need to remember them when using the Browser Extension.

Visual Indicator for Ignored URLs

First of all, lets cover off on the colors that the Browser Extension could be showing.  The image below is a composite image showing these colors;

  • Red Icon:  This means the Browser Extension isn’t logged into your Passwordstate Instance and you cannot access Password Records.
  • Blue Icon: This means the website you are currently visiting has an Ignored URL.
  • Black Icon: This means the website you are currently visiting is accessible by Passwordstate.  You can save credentials for this site to your Password List.  If the icon has a red badge with number in it, then there is already a password record that you can access for this website.  Any more than 3 password records will be displayed as 3+ in the badge.

Taking this further you can see that the website I have navigated to has turned the Browser Extension icon blue, and by clicking on the Browser Extension you can see there are 4 Ignored URLs that apply to the website.

If you have inadvertently set an Ignored URL, typically by clicking on the Ignore button, you can click on the arrow on the Right Hand Side of the Ignored URLs and then click on the X next to the URL you wish to remove as per the image below;

This will now allow you to save a password record for the site as normal.  Note you can only delete personally set Ignored URLs, not global Ignored URLs.  Alternatively, you can remove any personal Ignored URLs from within the Passwordstate UI by navigating to Preferences Menu->Preferences->browser extension->ignored URLs.

If you have feedback and are unsure where to send it?  Send it through to