If the script runs only during the password change, we could even add it to every installation, like a bug fix.
That might sound risky. As alternative we can limit the fix impact to new installations only, and document how to apply it manually to existing installations.
May I say… “OUCH” ?
After a small nano tour I applied the document edit but the size of the bug is… Not that small, to say the least.
So update should be flawless. fully automated and less-sysadmin-error-prone, IMVHO…
I’m afraid that’s not easily possible in this case.
There are admins (like me) that are used to the “bug”, using the default Windows password policy for their Windows clients users. If we fully automate the update, users suddenly need to enter a special char at next password change without getting an information to do so. Horrible support scenario…
The manual update procedure are 3 steps, I think it’s not that error-prone.
I think it’s a good compromise to have the password script ready in any case but don’t change existing installations. For new installations the script is applied automatically so they never see the bug, old installations are unchanged to avoid password change problems but a manual procedure is available to fix the bug.
If we just wrote it to the docs, all admins would have to apply the fix manually and we have no automatism at all.
I don’t see a better solution to cover all these cases.