support

Thanks for letting us know statc.

Hi statc, Thanks very much, and you can download the update from here - https://www.clickstudios.com.au/downloads/temp/PasswordstateWindowsService_Build8942.zip. Instructions are: Download the file and extract it to a temp location Stop the Passwordstate Windows Service Replace the file above in the folder c:\inetpub\passwordstate\bin Restart the Windows Service This is a fix for the scheduled backups only, and the fix for the manual backup in the UI will also be included in the next release. Regards Click Studios

Hi statc, Thanks very much for this, and you've actually found a bug for us. We've had on more than one occasion where customers specified their backup folder to be with inside the Passwordstate folder, and we were trying to exclude .zip files from the backup because it was causing an infinite loop under this circumstance. We've now fixed this for the next release (due in a couple of weeks), and we can report back here once that release is available. Or if you are currently using Build 8942, we can provide you an updated copy of the Windows Service with this fix in it - let us know if you would like that, or are okay to wait. Regards Click Studios

Thanks Sam.

Hi Sam, Thanks for the feedback. We generally use our forums to guage interest, instead of emailing our entire customer base - for whom the majority are not MSP's. We take your point about future customers though. Regards Click Studios

Hi Sam, As we've discussed, we have not said we will not integrate with Connectwise. As per all feature requests, we have to prioritize them based on interest from our customers. Integrating with another solution is not a trivial process, so if there is enough interest from the community we will definitely consider it. Regards Click Studios

Thanks Hatface13 for posting this, we really appreciate it and we hope it helps someone else out too. Regards, Support

Hi Guys, We have this coming in V9, with a native app for iOS and Android. Regards Click Studios

Hi Guys, We've had this feature for a little while now - sorry we did not update this forum post. Please see screenshot below. Regards Click Studios

Hi Guys, We've had this feature for a little while now - sorry we did not update this forum post. Please see screenshot below. Regards Click Studios

Maybe we could also exclude Password Lists where the 'Provide a Reason' is checked, but this might upset quite a few of our other customers. Probably best to log a feature request to see how many customers are interested in needing to provide a reason for logging into a web site. Regards Click Studios

Hello, The browser extensions have been designed to be as simple as possible, without the requirement for user input. As you're the first customer to request this, would you be able to log a feature request in the 'Feature Requests' sections of this forum, and this will allow us to prioritize based on the voting system we have. Unfortunately you cannot restrict users in the Browser Extension, but not in the UI. If you've been given access to a Password List, it will be available in both. With your second query, it looks like you've found a bug for us, as only Password Lists with the URL field selected should be used in the Browser Extensions. I've logged this to be fixed in the next release, and thanks again for reporting it. We'll post back here once the new release is available. Regards Click Studios

Hi KC_BREC, This is be design for our browser extension, and certain Password List settings are only applicable in the UI, and not in other modules like the Browser Extensions. Regards Click Studios

Hi Robb, There can also be restrictions in AD as to how frequently users are allowed to reset their passwords - a lot of customers run into this issue when testing the portal, as they're testing multiple resets. Below is a screenshot of this from Fine Grained Password Policies - can you check that out? Regards Click Studios

Hi Kevin, It is our understanding that all the administrator passwords are stored in Active Directory in unecrypted format, whereas in Passwordstate we obviously encrypt all that data. With our PAM solution, you also do not require Domain Admin rights to do this - you only need local administrator rights on each machine to do this. Majority of our customers use Security Groups, to add a domain Security Group into the Local Administrator's group. Sorry, we do not have any advice on the bitlocker question, except that you can add your own PowerShell scripts into Passwordstate, and associate them as 'Dependent' processes to password reset records. So you would need to investigate if you could write your own PowerShell script for this purpose. We hope this helps. Regards Click Studios

Hi Robb, Sorry, we do not have HA for the Password Reset Portal - only the core Passwordstate install. Regards Click Studios

Hi Rob, Only the High Availability instances of Passwordstate will show on the screen Administration -> High Availability Nodes. So your primary server should never show here. What dictates HA from a Passwordstate perspective is the 'PassiveNode' key you see in the web.config file, which is located in the root of the Passwordstate folder. Your primary server should always have this set to False, but your HA Server can have this set to either True (read-only), or Active (Read-Write). To use Active for your HA Instance, your SQL Server's need to support this as well i.e. not use Transactional Replication, but instead use Basic Availability Groups, Always On Availability Groups, or Clustering. So you need to change one server so this PassiveNode key is set to False, and then restart your Passwordstate Windows Service - otherwise this Service will not perform it's basic functionality. We are also changing this in V9, so that the PassiveNode key is no longer used, and this setting is controlled via the UI instead. I hope this helps. Regards Click Studios

Hi serverihorho, Just a quick update on this and as of 8942 we have included some new functionality for this, and the email address will not synchronise to the verification data if it is updated in AD. To upgrade, please follow one of the sections in this document: https://www.clickstudios.com.au/downloads/version8/Upgrade_Instructions.pdf Regards, Support

Hi GBS-IT, Just a quick update on this and as of 8942 we have included some new functionality for this, and the email address will not synchronise to the verification data if it is updated in AD. To upgrade, please follow one of the sections in this document: https://www.clickstudios.com.au/downloads/version8/Upgrade_Instructions.pdf Regards, Support

Hi Everyone, Today we have release build 8942 which includes 5 updated and 4 bug fixes. Full changelog can be found here - https://www.clickstudios.com.au/passwordstate-changelog.aspx. Regards Click Studios

Hi KTP, We don't specifically have logs for folders for this, only Password Lists and Password Records. If you go to the screen Administration -> Auditing, you can query all of the auditing we have in the system. You can also go to the screen Administration -> Password Lists, and see if you can find your Passsword List here - possibly someone has deleted the List, or maybe moved it into a Folder you have not been given access to. Regards Click Studios

Hi Kevin, Thanks for your enquiry. The majority of our customer's have replaced the use of LAPS with built in functionality of Passwordstate, as it is more secure by default. Did you instead want to look at our Account Discovery Jobs (Windows Local Admin Accounts) to see if this is a better solution for you, as it would reduce the need for you to write your own scripts based on your requirements above? Basically you need to import all your Host records first, which can be done with another Discovery Job under the Hosts tab. Then you can create that Account Discovery Job I mentioned. Regards Click Studios

Issue: https://www.clickstudios.com.au/documentation/move-new-web-server.aspx A customer has reported to us that when sending Self Destruct Messages, when using Office 365 as a email server, they were getting the following error: Text version of Error Data: Error: Transaction Failed. The server response was: 5.2.0 STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; Failed to process message due to permanent exception with message Cannot submit message. Fix: Google for this error returns results saying you may not be able to send from one email address and authorize it to be sent via a second email address. This is possibly a bug with Office365 SMTP as of June 2020. In Passwordstate, Under System Setting, change this setting to the option in the screenshot below. This should fix this issue: Regards, Support

Hi Daniel B, Under Administration -> Password List Templates, you can unlink the template from this menu option: Also, maybe consider these options under Administration -> System Settings -> Password List Options: We hope this helps, Regards, Support.

Symptoms A couple of customers have reported an 'Internal Server Error' when making calls to the Windows Integrated API (WinAPI) after upgrade to build 8925 or Higher. Cause Lack of NTFS Permissions. The Passwordstate Folder, and all nested files/folders needs Modify permissions for the account being used on the Passwordstate Application Pool in IIS. This is generally the NETWORK SERVICE account, but could also be a Managed Service Account Prior to the upgrade being initiated, Passwordstate was not put in Maintenance Mode - and calls were being made to the API during the upgrade process Resolution Manually delete the following files, as the upgrade process was not able to do this: c:\inetpub\passwordstate\winapi\bin\passwordstateapi.dll c:\inetpub\passwordstate\winapi\bin\passwordstateapi.dll.config c:\inetpub\passwordstate\winapi\bin\passwordstateapi.xml