support

Hi Jan, Unfortunately it's not possible to run the report for one group only. Once the full report is exported, we'd recommend just doing some filtering in Excel. Regards Click Studios

Hello tester22, We might need to look at the health of your system, and cannot request that on public forums. If you have an active maintenance contract for our software, could you please log your support request via the following page - https://www.clickstudios.com.au/support.aspx Thanks Click Studios

Hello Nicholas, Unfortunately you cannot use our RADIUS authentication option for this, as it only supports the PAP protocol, and not CHAP. For Azure Authentication, you can use SAML Authentication, and all authentication is handed off to Azure, and supports whatever authentication is configured there. Instructions for configuring SAML can be found in the Security Administrators Menu, under the Help menu in Passwordstate. Regards Click Studios

Hello Javilia, Please see our response on your other forum post where you asked the same question - https://forums.clickstudios.com.au/topic/14088-upgrading-to-passwordstate-9-from-version-6-7-or-8 Regards Click Studios

Okay thanks. We'll need to do some testing to see if we can replicate this issue. If you change the port number back to 1433 for now, then you won't need to specify this during the intitial setup. Once you have everything running, you can change the port number again, and then edit the database connection string in the web.config file. The format would be HOSTNAME,PORTNUMBER\SQLEXPRESS Regards Click Studios

Hello, In theory, what you have should work. Is it possible you have a space before the port number on your screen - it sort of looks like it, but possibly we're just misreading the screenshot. Regards Click Studios

Hello Scott, We no longer provide direct downloads for our browser extensions, and instead you must get them from the appropriate authorised store. Once installed, you can make copies of all the folder/files that are installed, if you like. Regards Click Studios

Hi SZU, I'm going to paste the email we sent to you below for this, which may help other users when configuring backups: Hi SZU, Unfortunately with the new backups, we are now using Powershell to help improve security and add extra functionality, but the requirements from Microsoft for this are quite complex and difficult to cater for every different type of set up. For this reason when using a local account we can’t connect to another machine using a second local account. There’s a couple of things you could try to fix this: Move SQL Express to your web server, as this will work Disable the database backup portion schedule a database backup outside of Passwordstate. We can provide the Powershell code if needed to help with this, possibly you could put this into t Windows Scheduled task or alternatively if you have other backup means maybe use those instead? The idea with our local account documentation is to back up everything to the local webserver, and then you would use some other process to copy the backups to a separate location. I hope this helps, and please let me know if you have any questions about this? Regards, Support

Hello Forrest, We generally recommend just using the Expiry Date field on Password records for this, and you can create a scheduled report to let you know the certificate will soon be expiring. You can even upload your certificates into Passwordstate, and they are also encrypted in the DB. Regards Click Studios

Hello mUser, With that System Setting, did you just chnage this? If so, can you please try recycle the PasswordstateApps Application Pool in IIS to see if that helps. Regards Click Studios

We've just responded to this forum post in an email, but hopefully this response also helps out other users in the same situation - Please email Click Studios to request the domain migration documents. We will try to publish these on our Click Studio Documentation Page as soon as we can. Hi AwesomeDuke, Thanks for your email, and please see below for answers to your questions: To migrate across all your users, and all of the passwords permissions, you will effectively need to move your database from the old domain to the new domain. This will migrate all passwords, users and permissions etc. You will then need add in the new user accounts, and clone the permissions from the old account to the new account. Below is a complete process we give to our customers when migrating Passwordstate to a new domain. Please let me know if this will be okay for you? On your old Passwordstate website, follow Step 1 of the attached one of the attached documents (either domain trust or no domain trust) which adds in the new domain Move the web server to the new domain and install build 8995: https://www.clickstudios.com.au/downloads/version9/Move_New_Web_Server.pdf Move the database using these instructions: https://www.clickstudios.com.au/downloads/version9/Move_New_Database_Server.pdf Log into the new website, It will prompt you to upgrade the database to 8995, which is an automated process. Follow step 2 of one of the attached documents to begin cloning permissions for all user accounts At this stage you should have Build 8995 running, and all users can log in with their new accounts and should be able to see everything. You can now perform a upgrade to the latest build of Passwordstate 9, by following Section 3 in this document: https://www.clickstudios.com.au/downloads/version9/Upgrade_Instructions.pdf Please keep the old environment running until you can confirm 100% that your users are happy using the new environment. Hope all goes well and please let us know if you run into any issues:) Regards, Support

Hello JJ, No, we do not think that would be possible do to the order in which the scripts are run, they would need to be edited, etc. Regards Click Studios

Okay thanks. It definitely seems like there is something on your system which is blocking execution of our PowerShell scripts with our installers, and we're not sure what it could be now. We are making some changes to the installer today, to force the use of the 64bit version of PowerShell, so we might need to try that when it's ready, to see if this works for you. Regards Click Studios

Hello JJ, We've had reports that the 32bit version of PowerShell i.e. C:\Windows\SysWOW64 does report one error like in the screenshot below. Does yours do the same as below? Also, we assume your language in Windows is set to English?

Hi JJ, Thanks, and there something strange going on where our PowerShell scripts are just not being executed for some reason, and we cannot seem to replicate this in any of our environments. Could you also do something else for us, so we can try and troubleshoot this issue: Let us know what version of the operating system you are using, and whether it is 32bit or 64bit Let us know what version of PowerShell and .NET Framework you have installed And from the run command in Windows, can you try pasting the two separate commands below, and let us know if any of these versions of PowerShell are blocked or not: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe Thanks very much Click Studios

Or do you possible have some Anti-Virus software which is blocking our PowerShell scripts? We had one customer reporting Kaspersky was blocking it. Regards Click Studios

Can you please open a command prompt for us, and type powershell.exe - can you let us know what this does? Thanks Click Studios

Hello, Yes, this is a new security feature in version 9. Regards Click Studios

Hello, Can you please check if there is an IP Address blocked on the following screen on my first screenshot below? More than likely it will be the IP address of one of your network devices, instead of the client machine. So as per screenshot 2 below, you will need to configure your network device, and Passwordstate, for X-Forwarded Support, so the correct IP Address is detected. Regards Click Studios

Hello JJMicro, Can you tell us if you have done any hardening on your web server? With our installer/upgrader, we do use some custom PowerShell scripts to perform various tasks, and we've been made recently aware by a couple of customers that these PowerShell scripts are not executing, due to server hardening. We're going to try and replicate this ourselves today, and work on a fix if we can. We will post back here once we have more information. Regards Click Studios

Hello 404, Please always refer to our latest documentation on the following page, if you get any 404 for old links - https://www.clickstudios.com.au/documentation/. You will find the new upgrade document on this page also. Regards Click Studios

Excellent - thanks for letting us know

Sorry about that - please try again. Also, all our latest documentation can always be found here https://www.clickstudios.com.au/documentation Regards Click Studios

Thanks for letting us know. And to confirm for other customers, you can use the same port numbers in different web sites, as long as differnet URLs are used. Or you can use the same URLs, but you need different port numbers. Regards Click Studios