support

Hey Buckit, We we take a look and see if this will be a simple change. If it is we'll include it in a future build. Regards, Support

Hey Buckit, We actually moved away from this model a while ago because it's not considered best practice to have the same password for admin accounts on all devices. Not only this but it was deemed to be more logical to have a one to one relationship for the scenario that some of the passwords didn't reset successfully. We understand where you are coming from completely, but to change this back again would be a complete rewrite of our password reset system. With these Linux.Unix systems, do the local accounts you are trying to manage on them have the ability to SSH into the device? Sorry if this has been asked before in a previous thread (this is a different support guy here). If so I think it's possible to manage the accounts without the need to set a privileged account. Regards, Support.

Thanks for the vote Greg. We'll consider this request when we next work on feature development for our extensions. Regards Click Studios

Hi Buckit, Thanks for your request. At this stage we're not sure this is something we would like to implement, as it goes against best practice fur using unique passwords across your hosts. It would also required a complete redesign of our Password Reset Engine, Account Heartbeats, Remote Site Locations, Reporting, API, etc, etc. Regards Click Studios

Hi Kevin, We believe the only way this would be possible would be via our API, but unfortunately we've never tackled something like this. Hopefully someone in the community has strong linux scripting skills, to point you in the right direction. Regards Click Studios

Thanks

Hi Jimmy, Thanks for your patience with this, and we do need to apologize - this is an issue with our code, checking that xml file as you mentioned. I'm not sure why I didn't see this in testing - possibly it was cached somewhere. We've fixed this for the next release, which means you will obviously need to perform a manual upgrade when this new release is available. We're not sure when the next release is yet, but it could be 2 to 4 weeks again. Again, thanks for your patience, and sorry again. Regards Click Studios

Hi Jimmy, We'''ll schedule an Internet outage at the office tomorrow, and see if we can replicate your issue again - it's currently 7pm in Australia. We'll let you know what we find. Regards Click Studios

Hi Jimmy, I pointed you to the correct part of the Security Administrator's manual - I certainly didn't expect you to read all 180 pages. For SQL Server, if you want Passwordstate to backup the database, then yes this is required - either for scheduled backups, or backups just prior to upgrades. Or you can check the option to say you don't want to backup the database, and you can manage this separately yourself. We try and give customers options for these sort of things, and let them decide what's best for their environment. Possibly because this is a "secure" environment, the manual method I outlined might be the best option for you. Regards Click Studios

Sorry Jimmy - we'll need to correct that reference of the message at the top of the screen, as it is out dated - we didn't realise it was still in there. If you are wanting to configure this backup account, we have whats fully required in the Security Administrators manual. You can find this under the Help Menu, and then look in the Backups and Upgrades section. Did you want to do the manual upgrade for now, and then you can explore the backup account permissions required after? Regards Click Studios

Hi Jimmy, I'm not sure what build you're upgrading from, but new Build Numbers are not shown at the top of the screen anymore - they will be added into the Notification Center on a schedule. If you go to the screen Administration -> Backups and Upgrades, and click on the 'Upgrade Now' button, you will see the NewBuildNo change being reported on this screen. Regards Click Studios

Hi Jimmy, During the upgrade, we need to stop the Passwordstate Windows Service, extract and overwrite all the files, then restart the Passwordstate Windows Service. This is what we use the backup account for - on the screen Administration -> Backups and Upgrades. If you don't want to configure this, then you can instead use that Manual Upgrade method I mentioned. I hope this clarifies. Regards Click Studios

Hi Jimmy, Yes, I meant the backup account in this instance. With our pages, they are all pre-compiled code, with some files being obfuscated. So there are no security concerns over these NTFS permissions. Let us know if the manual upgrade method works out for you, and we'll do some further testing to see if we can replicate your issue. Regards Click Studios

Hi therealdj, At this stage we do not believe it's possibly to make these sessions full screen. The remote sessions are embedded in an iframe, and to make them go full screen would mean we'd need to disconnect the session, and then reconnect. We'll have another think to see if there are any other options for this. You can also collapse the vertical divider between the remote session and the Hosts Navigation Tree, and this will give you a little more screen real-estate. And sorry, it is not possible to record the client based sessions - there's no way we know of to hook into these client's screen and record the activity - sorry. Regards Click Studios

No offence at all Buckit - we have a pretty dry/sarcastic sense of humour in Australia. Sometimes we need to re-read our own post to ensure we haven't accidentally insulted someone

Hi Buckit, Our In-Place Upgrade feature requires you to specify an account which has permissions to overwrite the files in the Passwordstate folder - so we "impersonate" this account in code to update files. I was suggested to look at the NTFS permissions, as this might explain Jimmy's error. I would have thought using the same password across many hosts would be worse than NTFS permissions in compiled code Regards Click Studios

Hi Everyone, Today we have release build 8334, which includes 2 new features, 3 updates, and 4 bug fixes. Full changelog can be found here - https://www.clickstudios.com.au/passwordstate-changelog.aspx. Regards Click Studios

Hi All, We only added the command in Build 8325, so we won't know if this makes any difference until the next upgrade: 'The follow command for any TLS restrictions ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 'Required if only TLS 1.2 is enabled Regards Click Studios

Hi Jimmy, Sorry you're having some issues with this. I've just done some testing, but cannot seem to reproduce this - I disabled the network card for the test. We use the method of placing the passwordstate_upgrade.zip file in the /upgrades folder for every release, as we test the upgrade process before releasing - obviously we don't want to download from the Internet in this instance, as we haven't uploaded the new file yet. I've just done a code review, and it's possible that there is a different error which is causing our code to redirect to this page you are seeing. Can you try the following: 1. Make sure the Passwordstate folder, and everything beneath it, has Modify or Full NTFS permissions for the NETWORK SERVICE account 2. Now use the instructions '5. Manual Upgrade Instructions' in the following document - https://www.clickstudios.com.au/downloads/version8/Upgrade_Instructions.pdf Regards Click Studios

Hi Geek It Up, Can you let us know if this happens again in future upgrades - we added some code in the latest release to see if it will fix this issue in subsequent upgrades? We're not sure if it will work at this stage, because we cannot seem to reproduce this TLS issue ourselves. Regards Click Studios

No problems - thanks. Click Studios

Hi Buckit, Sorry, we do not have an easy method to achieve what you're wanting here. The only thing we can think of is to use our API to reset multiple accounts at once, using the same password. But like you mentioned, it's not generally recommended. Regards Click Studios

Hi Azkabahn, We've seen many screenshots from customers where they have different dimension images. For now, can you just resize it to what you need? Regards Click Studios

Hello , Thanks for your request, but we do have some customers who like different image sizes, so you would need to adjust these images yourself. On the screen where you upload, there is the following instructions which should help: 1. Images must be of png, gif or jpg format 2. Images must be 20x20 pixles in size, or less 3. The file names of the images must be unique. Regards Click Studios

Hi Findus, Yes they can, and the SQL Server Replication will take care of this - changes in the DB are replicated almost immediately between the two SQL Servers. Regards Click Studios