Password is "too recent to change"

We have a "wizard" that deploys and configures a SQL 2005 instance for our
application. Among other things, it resets the SA password to a strong
password that is unknown to the client.
It works fine except now with installations on Vista. When the password is
set by the script it gets an error stating "Password Validation Failed. The
password for the user is too recent to change."
I've never had this problem before. We need to get around it but I see no
settings in SQL to adjust that. I also don't see any settings in Local
Policies for Vista that require a password exists for a certain amount of
time.
Anyone run into this yet and/or have a suggestion to solve it?
--
MazThe password policy that generates this message is called Minimum password
age - x days - you cannot change the password within x days from last
change. The default value on Vista probably differs from the one on your
previous OS.
Thanks
Laurentiu Cristofor [MSFT]
Software Development Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Spicy Mikey" <Maz@.newsgroups.nospam> wrote in message
news:A921C953-A780-4C94-9497-94993579BB31@.microsoft.com...
> We have a "wizard" that deploys and configures a SQL 2005 instance for our
> application. Among other things, it resets the SA password to a strong
> password that is unknown to the client.
> It works fine except now with installations on Vista. When the password
> is
> set by the script it gets an error stating "Password Validation Failed.
> The
> password for the user is too recent to change."
> I've never had this problem before. We need to get around it but I see no
> settings in SQL to adjust that. I also don't see any settings in Local
> Policies for Vista that require a password exists for a certain amount of
> time.
> Anyone run into this yet and/or have a suggestion to solve it?
> --
> Maz|||I agree with that assessment. The question, unfortunately, still stands; ho
w
do we change it? More specifically, how do we change it programatically?
These are turn key setups. The customer will have no expertise in this
matter. We need to do this from our application wizard.
Since these are policy settings, I'm concerned it cannot be changed through
any software interface. Also, this is a SQL Server login and password not a
Windows password. Not sure why SQL is enforcing that OS rule.
Regardless, here's the dilema. Our wizard initially installs SQL Server
with a generic SA password using a command line install. After that step
completes, the password and other security settings are altered and this
instance is taken over by the applications setup wizard. We do a two step
process because sometimes there are problems getting SQL installed and manua
l
intervention is required. It is good to have the option of giving someone
the "install" SA password without needing to reveal the final operational SA
password which is a secret and embedded in the app.
Does anyone know how to change this policy back to zero programatically OR
any thought on how to do this install without risking exposing the SA
password?
My gut feeling is we're screwed by another somewhat arbitrary change
implemented by MSFT without consideration of the impacts to it's software
partners. Someone prove me wrong please? I'd love to be able to appologize
for jumping to that conclusion.
Maz
"Laurentiu Cristofor [MSFT]" wrote:

> The password policy that generates this message is called Minimum password
> age - x days - you cannot change the password within x days from last
> change. The default value on Vista probably differs from the one on your
> previous OS.
> Thanks
> --
> Laurentiu Cristofor [MSFT]
> Software Development Engineer
> SQL Server Engine
> http://blogs.msdn.com/lcris/
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Spicy Mikey" <Maz@.newsgroups.nospam> wrote in message
> news:A921C953-A780-4C94-9497-94993579BB31@.microsoft.com...
>
>|||Hold on. Microsoft had to fix a lot of the default open security holes.
While that can cause problems, they also gave us the tools to deal with the
issue.
Run this T-SQL command
ALTER LOGIN <yourloginname> WITH CHECK_POLICY = OFF
and it will stop checking the OS or domain password policy for SQL Server.
I woud recommend setting it back on after making all the changes.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Spicy Mikey" <Maz@.newsgroups.nospam> wrote in message
news:912129B0-B3BC-4986-905B-2A6031EEA9DF@.microsoft.com...[vbcol=seagreen]
>I agree with that assessment. The question, unfortunately, still stands;
>how
> do we change it? More specifically, how do we change it programatically?
> These are turn key setups. The customer will have no expertise in this
> matter. We need to do this from our application wizard.
> Since these are policy settings, I'm concerned it cannot be changed
> through
> any software interface. Also, this is a SQL Server login and password not
> a
> Windows password. Not sure why SQL is enforcing that OS rule.
> Regardless, here's the dilema. Our wizard initially installs SQL Server
> with a generic SA password using a command line install. After that step
> completes, the password and other security settings are altered and this
> instance is taken over by the applications setup wizard. We do a two
> step
> process because sometimes there are problems getting SQL installed and
> manual
> intervention is required. It is good to have the option of giving someone
> the "install" SA password without needing to reveal the final operational
> SA
> password which is a secret and embedded in the app.
> Does anyone know how to change this policy back to zero programatically OR
> any thought on how to do this install without risking exposing the SA
> password?
> My gut feeling is we're screwed by another somewhat arbitrary change
> implemented by MSFT without consideration of the impacts to it's software
> partners. Someone prove me wrong please? I'd love to be able to
> appologize
> for jumping to that conclusion.
> --
> Maz
>
> "Laurentiu Cristofor [MSFT]" wrote:
>|||Thanks Geoff. You are correct and I happily appologize to MSFT for jumping
to conclusions
I looked into Check_Policy. It's a a new parm and isn't supported in the
older DMO (which is how this routine was written). However, it was easy to
modify the function using TSQL and it worked perfectly.
Thanks again for that help. Hope this helps someone else moving to Vista.
Maz
"Geoff N. Hiten" wrote:

> Hold on. Microsoft had to fix a lot of the default open security holes.
> While that can cause problems, they also gave us the tools to deal with th
e
> issue.
> Run this T-SQL command
> ALTER LOGIN <yourloginname> WITH CHECK_POLICY = OFF
> and it will stop checking the OS or domain password policy for SQL Server.
> I woud recommend setting it back on after making all the changes.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Spicy Mikey" <Maz@.newsgroups.nospam> wrote in message
> news:912129B0-B3BC-4986-905B-2A6031EEA9DF@.microsoft.com...
>|||Geoff,
Maybe you can help with this related issue.
The lockout policy is set at 3 attempts in some period of time. Do you know,
other than the CHECK_POLICY = OFF method, to change this setting and do you
know what the period of time that SQL2005 is using?
Thanks
Chris
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:ucQ%23J%234VHHA.4568@.TK2MSFTNGP02.phx.gbl...
> Hold on. Microsoft had to fix a lot of the default open security holes.
> While that can cause problems, they also gave us the tools to deal with
> the issue.
> Run this T-SQL command
> ALTER LOGIN <yourloginname> WITH CHECK_POLICY = OFF
> and it will stop checking the OS or domain password policy for SQL Server.
> I woud recommend setting it back on after making all the changes.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Spicy Mikey" <Maz@.newsgroups.nospam> wrote in message
> news:912129B0-B3BC-4986-905B-2A6031EEA9DF@.microsoft.com...
>|||The password policy is inherited from either the local machine policy or the
OU domain-level group pollicy. Setting CHECK_POLICY off and back on will
unlock the account.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:e0bSzibWHHA.4188@.TK2MSFTNGP06.phx.gbl...
> Geoff,
> Maybe you can help with this related issue.
> The lockout policy is set at 3 attempts in some period of time. Do you
> know, other than the CHECK_POLICY = OFF method, to change this setting and
> do you know what the period of time that SQL2005 is using?
> Thanks
> Chris
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:ucQ%23J%234VHHA.4568@.TK2MSFTNGP02.phx.gbl...
>|||There is an UNLOCK option in ALTER LOGIN for unlocking locked out logins.
See http://msdn2.microsoft.com/en-us/library/ms189828.aspx.
Thanks
Laurentiu Cristofor [MSFT]
Software Development Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OpDDDScWHHA.1036@.TK2MSFTNGP03.phx.gbl...
> The password policy is inherited from either the local machine policy or
> the OU domain-level group pollicy. Setting CHECK_POLICY off and back on
> will unlock the account.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
> news:e0bSzibWHHA.4188@.TK2MSFTNGP06.phx.gbl...
>|||Laurentiu,
Previous experience had shown that this did not seem to work. Feb 2007 BOL
seems to have more relevant information about any restrictions.
Chris
"Laurentiu Cristofor [MSFT]" <Laurentiu.Cristofor@.nospam.com> wrote in
message news:%23ZkBGcfWHHA.3332@.TK2MSFTNGP04.phx.gbl...
> There is an UNLOCK option in ALTER LOGIN for unlocking locked out logins.
> See http://msdn2.microsoft.com/en-us/library/ms189828.aspx.
> Thanks
> --
> Laurentiu Cristofor [MSFT]
> Software Development Engineer
> SQL Server Engine
> http://blogs.msdn.com/lcris/
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:OpDDDScWHHA.1036@.TK2MSFTNGP03.phx.gbl...
>|||If you are hitting the Windows 2003 issue mentioned in the BOL link below,
then installing the last Service Pack for Windows 2003 should address the
problem. If you are seeing some other problem with UNLOCK, let us know.
Thanks
Laurentiu Cristofor [MSFT]
Software Development Engineer
SQL Server Engine
http://blogs.msdn.com/lcris/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:%237A8lOoWHHA.4636@.TK2MSFTNGP02.phx.gbl...
> Laurentiu,
> Previous experience had shown that this did not seem to work. Feb 2007 BOL
> seems to have more relevant information about any restrictions.
> Chris
> "Laurentiu Cristofor [MSFT]" <Laurentiu.Cristofor@.nospam.com> wrote in
> message news:%23ZkBGcfWHHA.3332@.TK2MSFTNGP04.phx.gbl...
>