This message was deleted.
# citrix-vad
s
This message was deleted.
j
That’s actually a great request for bis-f @Matthias Schlimm
n
I was more looking for a proactive scenario... I know how to resolve it once I see that the trust is broken.
j
If it’s in bis-f (for example) it would be pretty proactive I’d imagine....check and fix on boot - hell you could powershell that and throw it in as a custom script relatively quickly too 🤔
n
I do disable password changes in my master image (PVS). This only happens when a device sits powered off for a long time. There's a chance we had a GPO set to disable accounts that haven't checked in within xx days.
m
@James Kindon discuss this in the past here https://github.com/EUCweb/BIS-F/issues/99
n
It looks like that was never added to BIS-F? I assume because of the credential storage. I wouldn't want to put that in my image, either, and I'm not sure that encrypting the creds would work correctly.
m
What scenario are you in where the machine loses trust? Machine account passwords don't expire, do you have something cleaning up their objects from the domain if they don't log in?
j
@Matthias Schlimm ah i hadn't seen that there before, guess it makes more sense to write your own custom script with secure credentials and get BIS-F to execute it via the custom folders
m
I also experience this behaviour in several customer VDI szenarios. Some VDIs are loosing trust relationship over time - even when they are powered on. From my site all is configured correct. I did not find a way to fix this by target side (reset-machineaccount, test-computersecurechannel), the only way i get rid of it is running a task on the pvs server to reset the PWD of all VDIs weekly. @Matthias Schlimm @Jonathan Pitre would be very interested in further tests, I run both cmds as local admin, as well as service user - nothing worked via Script. Logging on to the machine an run these comands manually works fine.
also if the TRS is lost all commands using domain credentials by script fail..
n
These particular devices had not booted since last September, I believe. I don't see any GPOs cleaning this up, so I'm not sure what happened with them. All I know is that I had to reset the machines in AD to get them functional again.
r
You could adjust the Domain member: Maximum machine account password age in GPO. Depending on how the secuirty measuremnts are handled in your enviroment.
Well to prevent that from happening
m
it’s the client that initiates the change though, and it won’t do it until it can talk to the domain. 30 days is just the time at which it first tries.
“There’s a chance we had a GPO set to disable accounts that haven’t checked in within xx days.” That would do it. The only other way this would happen is if the machines were left on for over 30 days, the password changed, and then they rebooted. Non persistent machines would the try the old password in the registry and fail.
r
Good link man.