Hi John, You mentioned that you didn't move your GP to a new SQL instance.. .but the have you kept the same ODBC connection to your server from the GP clients ? any changes in the server name in the ODBC connection will disrupt the actual password encryption... the GP pwd is stored in the database tables with an encryption based on the server name that's in the ODBC connection of the GP client... I solved this problem by using a canonical ALIAS in the DNS... so even after moving the SQL databases to a new server instance, the name remains the same and points to the new system in the DNS. No changes in the ODBC entry. As for the password lock, this is due to the AD policy that you enforced for some of your users in GP.. if the enforced policy is enabled, than SQL server security will align on the domain AD GPO for pwd policies regarding the strength, complexity and expiration of the password. You can decide to not use this option, but than your users will never get forced to change their password. Another way to handle this outside of the SQL security / Domain policy, would be to use the Rockton Software GP Toolbox, as it includes a password manager that allows you to do pretty much the same thing. As for the password reset to all users, GP Powers Tools (aka SDT) would allow you to globally reset all the user's password in GP and set a new password for everyone, then force them to change it at the next login. This saved me during our last upgrade, as for some strange reasons the trick with the ODBC server Alias didn't worked for some users (not all, some had no issues).
↧