Did you know that Click Studios allows you to use your Passwordstate Production License Keys for One (1) non-production instance for Development, Staging or Quality Assurance (QA) purposes? This information is included under section 3.5 Number of Instances in our EULA (End User License Agreement). You can obtain the most up to date version of the EULA here,
The relevant section is reproduced below,
Unless otherwise specified you may install one (1) Passwordstate Instance on systems owned or operated by you or one of your Authorized Users. We allow you to deploy (1) non-production instance for development, staging or QA purposes. No other Passwordstate Instances are permitted, unless Multiple License Sets, the Global License, or the High Availability license options are purchased.
But you may be wondering, how exactly do I get a copy of my production data into a development instance? Well, let’s read on.
Creating your Test Instance
First, you’ll need to decide on what you’re hoping to achieve with this second non-production instance. For the purpose of this blog, we’re setting up a QA Server that matches our production instance. This means it is identical except for its Netbios name, URL for accessing, IP address and DNS entry.
Once we’ve setup our server(s) at the physical / operating system level we’re ready to migrate a copy of our existing Passwordstate instance to our new QA server. Note If your Production instance has the webserver and database on different servers then ideally you would replicate this setup for your QA Server.
The steps you need to follow can be obtained from our website here,
It is important to follow the instructions in the order show above by the Red Circles 1 and 2, e.g., Perform the instructions from Red Circle 1 first and then those from Red Circle 2. You should also ensure you have a backup before beginning the process (just good practice).
Once we’ve followed the instructions, we now have a copy of our production data on our new QA instance.
Important Things to Change
As we’ve now got a replica of our Production Passwordstate instance, with its associated Password Records and Reset jobs, it’s a good idea to prevent the QA instance performing unattended updates on your production data. To do this,
Start the Microsoft Services Desktop Application on your Passwordstate webserver, select the Passwordstate Service, right click on it and select Stop,
you should also set the Properties, Startup type to Disabled as per below and click OK.
This will prevent the Passwordstate Service from starting when you reboot or start the webserver. A full list of the events managed by the Passwordstate Service are;
- Scheduled Password Resets, Discoveries and Heartbeats
- Scheduled Backups
- Sending Email Notifications
- Checking for new Builds
- Sending Audit Log data to Syslog Server
- Synchronizing AD Security Groups
- Sending Scheduled Reports
- Archiving Auditing data
- Removing Time Based Permissions
You should also review the Users and Security Administrators that have access to the QA Instance and adjust these as necessary. Longer term it would probably pay to remove critical Password Records from this instance as well.
As you can see, the process of populating a test Passwordstate instance with production data is straightforward and permitted under our EULA.
If you’d like to share your feedback please send it through to support@clickstudios.com.au.