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

Managing Privileged Credentials More Important Than Ever

If your business uses Information Technology then you run the risk of your “accounts”, especially those with higher privileges, being used to exploit your most sensitive information and critical systems.  Unauthorized privileged access gives individuals the power to alter your data, change the configuration of applications and infrastructure and have the potential to cause you irreparable reputational and financial damage.

Historically Cyber Criminals have had their eyes firmly set on your businesses most valuable assets and the monetary value it holds.  This represents a potential revenue stream and can be used to fund future attacks.  To gain access they have utilized an array of tactics including email harvesting, Imposter Message attacks, attached files or website links delivering Malware and Ransomware and Phishing lures.  However, this doesn’t cover the entire online environment… doing business online in 2022 is becoming even more complex.

Global Instability, Hacktivism and Cyber Warfare

The United Nations Under-Secretary-General for Political and Peacebuilding Affairs, Rosemary DiCarlo has said that the Global COVID pandemic’s impact on peace and security has intensified, exacerbating inequality and corruption; breeding misinformation, stigmatization and hate speech; and creating new flashpoints for tension and increased risks of global instability.

An analysis published by risk consultancy Verisk Maplecroft expects this fallout to continue, forecasting that 88 countries in both the developed and developing world are likely to experience more political instability by 2023. This is primarily driven by fading legitimacy of governments and intensifying civil unrest.

Running parallel to this is an increased level of hacktivism, or hacking into systems for politically or socially motivated purposes. Hacktivists perform acts, such as defacing an organizations website and leaking sensitive or commercial in confidence information.  These activities are undertaken with the intent of gaining visibility and disrupting or exposing the inner workings of targeted governments and private organisations.  Sometimes in the name of transparency and the greater public good (not that we endorse this).

And then we have the increased evidence of Nation-State backed Cyber warfare, in the form of a cyber-attacks or series of attacks targeting specific countries. These have the very real potential to wreak havoc on governments and civilian infrastructure, disrupting critical systems, resulting in damage to the state and loss of life.

Recent and ongoing conflicts and instability in Eastern-Europe, South-Central and East Asia are having a real impact on global stability, the security of your digital and physical assets, and ability to maintain normal business operations. Known cyber criminal groups have recently publicly pledged support for some governments and are threatening to conduct campaigns in retaliation for offensives against other governments.  Based on the timing of these campaigns they are likely in support of military offensives.

What Should You Do?

United States, United Kingdom, Canadian, Australian and New Zealand cybersecurity authorities are urging businesses to prepare for and mitigate potential cyber threats including destructive Malware, Ransomware, Distributed Denial of Service (DDoS) attacks, and Cyber Espionage by hardening their cyber defences and performing due diligence in identifying indicators of malicious activity. 

Businesses should prioritise the following activities to help defend against malicious cyber activity:

  1. Apply patches for applications and devices, with internet-facing services the priority.  Continue to monitor for relevant vulnerabilities and security patches and apply these as a high priority.
  1. Implement mitigations against phishing and spear phishing attacks. Disable Microsoft Office based macros by default and limit user privileges.  Ensure staff understand they must report all suspicious emails received, links clicked, or documents opened.
  1. Enforce the use of Complex Passwords and Multifactor Authentication.  Have unique Password Credentials, manage them and assess the level of risk in providing access to privileged accounts or highly confidential password credentials, to your employees.
  1. Secure and monitor Remote Desktop Protocol (RDP).  Bad actors and cyber criminals have methods of identifying and exploiting vulnerable RDP sessions via the Internet to steal identities, credentials and even install / launch Ransomware attacks.
  1. Review logging and detection systems to ensure they are up to date and functioning correctly. Again, prioritize internet-facing and critical network services, ensuring logs are centrally stored.
  1. Socialize Incident Response and Business Continuity Plans. Ensure these are up to date and incorporate responses to network compromises and disruptive or destructive activity such as Ransomware and Malware. Ensure plans are accessible even if systems are down.

Where can Passwordstate Help?

Passwordstate is a secure and flexible Enterprise Password Management System.  It enables your IT and Security staff to access and share sensitive password credentials using Role Based Access Control (RBAC) and with full auditing.  It allows you to,

  • Centralise control of, and allow secure access to, your sensitive credentials,
  • Audit who is accessing your privileged credentials and when are they doing it,
  • Provide access credentials and other information based on an employee’s role,
  • Quickly change passwords when an employee leaves,
  • Ensure critical passwords aren’t being copied, changed or exported for other uses,
  • Manage password resources on discreet networks,
  • Store all passwords securely, and,
  • Access to your passwords when you really need them.

If you don’t have an Enterprise Password Management System (like Passwordstate) you should look at doing your research and trial of a product as a high priority!  Remember, breaches are real and the resultant stolen credentials typically end up in interactive databases making the selection and targeting of individuals and businesses even easier!  Once you’ve selected a product and installed it,

  • Stop reusing passwords and usernames across multiple accounts.  Phishing attacks target Help Desk Staff, Accounts Payable Clerks, Middle Management and IT workers with increased privileges.  Setup password strength policies and generators to create unique, strong passwords every time.
  • Regularly reset your passwords automatically.  Don’t keep the same passwords for ever.  If you’ve got lots of accounts then stagger resets to make it manageable.  Automatically generate and save updated passwords back to your centralized password vault when changing them online.
  • Implement 2 Factor Authentication where it makes sense.  View your accounts as assets and manage them based on risk and impact.  Banking Accounts and System Administrators Privileged Accounts should always have 2FA enabled.  Even if your credentials are compromised others can’t access the account if you use 2FA.

With the increased global instability, hacktivism, cyber threats and cyber warfare, could your business survive if any unmanaged privileged accounts were compromised?  Now isn’t the time to forget about managing your Privileged Credentials.  Managing your Privileged Credentials is now more important than ever.

If you would like to share your feedback, we’d love to hear it.  Just email 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

Sneak Peek of the Updated Mobile App

At the risk of repeating ourselves, the native Mobile Clients for Android and iOS, first introduced in Passwordstate V9 Build 9000, offer substantial flexibility for System Administrators and Users on the move.  These apps are used in a revised architecture, requiring the installation of a Passwordstate App Server, which brokers connectivity between the client device and the Passwordstate instance.

The Apps authenticate using an independent credential set and store password records on the smartphone within an encrypted cache.  All authentication and access of credentials is audited and synced back automatically with Passwordstate on next connection.  This solution only offered simple read only access to authorized password records…until now!   

For the Uninitiated…

For those that haven’t see the app I’ve included a screen capture from my iPhone below.  This shows the Light colour scheme on the left hand side and the Dark colour scheme on the right hand side.  You can select either or choose to match the System Default on your device.

Once you’ve setup the App you can select to either unlock the app using the Unlock With Credentials (using the independent credential set) or Unlock With Biometrics (which will appear if you’ve selected the option to use Biometric Unlock).  From here you are presented with the default home page.

Password Lists Home

The image below shows the Password Lists page, the current system default home page in the App.  We intend on also providing an option of setting the OTP page (what?) as the default in a later build, possibly before the updated app is available in the respective Apple and Google stores.

While this all looks normal in the app, lets select a password list and show some neat enhancements.  The first is editing an existing Password Record.  I’ve selected a Password List on the Password Lists screen, then selected the top Password Record ending in  Now I’ve simply swiped in from the right hand side and the Edit control appears.  I can then go through and edit the required fields and save the record (we’ll explain how to do that further down),

Alternatively, if you discovered you no longer needed that Password Record, you can delete it by swiping-in from the left hand side and the Delete control appears,

And for those that guessed it… that’s right… you can Add a Password Record by clicking on the + sign up the top of the screen (with the green circle around it).

One-Time Passwords

Passwordstate has had the ability to service One-Time Passwords for a number of years.  All that’s required is a Password List to be based on the One-Time Password Authenticator Template.  This allows you to access the OTP codes via our Web Browser Extension.

But what about when you’re away from your computer?  Well, with the introduction of the native Mobile Clients you could have access to your Password Record that was stored in the encrypted cache, and that was it.  You’d still need a separate app, like Google Authenticator, to access the OTP.  But this is really inefficient!  Why have two apps when Passwordstate contains all the information?

With the release of the next version of the Mobile App we now provide mobile access to your OTP records, 

And, what’s more, you can also add new OTP records by pressing the camera icon at the top.  This will open the device’s camera and prompt to Scan the OTP QR Code.  Once scanned it will open up a new Password Record so the other details such as Title, Username, URL, Password etc. can be entered.  As with the Password Records shown above you can both Edit and Delete OTP records by swiping in from the right and left respectively.

Adding New Records

There’s a couple of ways to add a new Password Record via the App.  The first is by scanning a QR Code

Once scanned the App will open the New Password Record screen and require as a minimum the Title, Password and Confirm Password fields to be filled out.  Note, the app will check that the Password and Confirm Password fields match.  The Generate Password button will generate a password and populate both the Password and Confirm Password fields.  The generated password is based on the Password Generator Policy set for the Password List in your Passwordstate instance.  The One Time Password will already be filled out and cycling through every 30 seconds as you’ve scanned the QR code (not showing in the image below).

To save the record press the Tick Icon at the top or the Cross to exit without saving.  On successful saving you receive a Saved pop-up like below,

The second way of adding the record is via the + sign as show in the images under the Password Lists Home section above.  Note if you add a Password Record this way and the Password List isn’t based on the One-Time Password Authenticator template you won’t have the option to scan a One Time Password QR Code.


The new functionality of Adding, Editing, Deleting Password Records, including adding OTP Records via the Mobile App requires a connection back to your Passwordstate Instance.  The functionality is not designed to work just with the offline encrypted cache.  New records are first added to your Passwordstate instance and are then immediately synchronized with your mobile device.

Access to your OTP records however does work offline.  Your encrypted cache will always be populated with your OTP records each time you synchronize with your Passwordstate instance.  This means if you replace your phone you won’t have to set them up from scratch unlike with some other Authenticators.

We’re really excited about the newest version of the Mobile App.  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

Auditing, Archived Events and SQL Management

To ensure transparency of actions, Passwordstate has over 120 audit events, all of which can be used in Scheduled Reports and for real-time alerts.  We ensure the visibility of audit events by providing the default option to display them in the Recent Activity display grid beneath each Password List.  This option can of course be modified by your System / Security Administrators.

All events are available under Administration->Auditing, where you can filter them based on Platform, Instance, Activity, Site, Date range, Password List and Search Criteria.  You can even select visual representations of events under Administration->Auditing Graphs.

Audit Tables

Passwordstate’s audit events are stored in the Passwordstate Database and are held in one of two tables, Auditing or AuditingArchive

All auditing events are initially written to the Auditing table.  From there they are displayed, based on configured options, in each Password List’s Recent Activity display grid.  To ensure your instance can perform satisfactorily, Passwordstate monitors the number of records stored in this table.  Once the number of records exceeds the number you’ve specified in System Settings, the Passwordstate Windows Service will automatically move any excess events to the AuditingArchive table.  The events moved are the oldest entries in the table.

For performance reasons the events stored in AuditingArchive are never referenced from the Passwordstate UI, except when choosing to search for an event and you click the Yes radio button next to Archived Data.

Purge Old Events

From time to time, you may want to clean-up or purge old Auditing events store in the AuditingArchive table.  Passwordstate provides instructions for your Database Administrators on how to do this.  To access these instructions, simply navigate to Administration->Auditing,

and click on Purge Audit Records.  This will open the Purge Auditing Data instructions screen,

This screen displays an example of the Archive_Auditing_By_Month_Age.sql script that is normally located in C:\inetpub\passwordstate\setup\scripts on your Passwordstate webserver.  If you have a different installation directory then you’ll need to look there for the script in your installation path followed by \passwordstate\setup\scripts.

The instructions screen provides steps on how to specify the data for selection, manual archiving outside of Passwordstate and deletion from the AuditingArchive table.

Fine Tune Auditing Settings

You can fine tune the settings relating to the AuditingArchive table under Administration->System Settings->auditing data->Auditing Archive Settings,

Here, you can specify the maximum number of rows to keep in the Auditing table.  The default is 500,000 rows, and you can reduce or increase (not recommended) this number depending on your requirements.  Once the number of rows in your Auditing table reaches this number the oldest rows, in excess of this number, are moved to AuditingArchive.  You can elect to archive all API Auditing data daily at a specified time.  The visibility of Audit data in the Recent Activity display grid is also set here under Miscellaneous Settings.

If you have a Syslog Server or SEIM (Security Event and Incident Management) solution you can send all audit events to it.  Audit entries are checked and sent every minute and you can specify the server name, the Port Number used for communication with the server, the specific Date Formatting to be used for entries and the Protocol used,

The auditing functionality provided by Passwordstate is comprehensive, can be tailored for performance and offers the ability to both export older events to external storage and send events as they are recorded to your Syslog or SEIM solutions.

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