Microsoft's Hyper-V Server 2008 R2 is a great product. It is free, it has small disk footprint (< 4 GB) and you can control every aspect of it from another computer with Management Console. Or to be more precise, every aspect except for one.
If you decide to make standalone Hyper-V Server install (without adding it to domain), you have small problem with password selection. Every password needs to pass complexity requirements. While those requirements are not too harsh, they are quite annoying if all that you want to make is test installation with your common password (and everybody has one of those).
Everybody who installed Windows Server knows solution - just use Local Security Policy. It will not work here since MMC is not supported on Hyper-V Server 2008 R2 and Local Security Policy is probably only MMC snap-in that cannot be used on remote computer.
Rescue comes with secedit.exe. Whole purpose of this command is to export and import security policies, but in unfriendly manner.
First step is to export our current policy:
secedit /export /cfg X:\new.cfg The task has completed successfully. See log %windir%\security\logs\scesrv.log for detail info.
I would recommend putting this file on USB or network drive since Hyper-V Server 2008 R2 doesn't include unicode text editor (notepad.exe works only with ANSI). Once you do manage to open file in normal editor, you will be presented with good old INI format. We are interested in PasswordComplexity value within [System Access] section.
MinimumPasswordAge = 0
MaximumPasswordAge = 39
MinimumPasswordLength = 0
PasswordComplexity = 1
PasswordHistorySize = 0
Value should be changed to 0 in order to disable complexity check.
After this edit, it is time to go back to our server and perform configuration:
secedit /configure /db C:\Windows\security\new.sdb /cfg X:\new.cfg /areas SECURITYPOLICY
The task has completed successfully.
See log %windir%\security\logs\scesrv.log for detail info.
There are no restrictions on location of your security database, but I like to place it in C:\Windows\security. It seems like logical location to me.
Areas parameter controls which security areas will be configured. While one could import all areas with this, there are two reasons why this should be avoided. First reason would be that, by default, you cannot import everything - Hyper-V server will return error since some settings are non-existent there. Second one is just plain common sense. Why would you risk stability of your system by importing stuff that you never intentionally wanted to change?
Once this operation is completed, you can press
17 thoughts to “Disabling Password Complexity Requirements on Hyper-V Server 2008 R2”
Thanks for the post!
Thanks for these steps! Works quite well also in standard Server 2008 R2 to change the greyed-out setting of password complexity.
Two added tips…
1. I was able to install Notepad2 to replace Notepad via copying to the \\machinename\c$ share.
2. I still didn’t want to worry about password expiration: I found this command on a blog…
net accounts /MINPWAGE:0
http://unquietwiki.blogspot.com/2010/05/poking-around-with-hyper-v-server-r2.html Followup post
Very helpful. Thanks!!
net accounts MINPWAGE:0 sets minimum password age. I would suggest that instead you consider
net accounts MAXPWAGE:value
to set the Maximum Password age. The value can be 1-999. Maybe hex value ffff would work as well. Have not tried.
you can set the Password to never expire:
net accounts MAXPWAGE:unlimited
Does this fix still work?
What editor are you guys using? I tried “EDIT.COM” and it doesn’t work right. Opening it locally from another server on the network or remotely with File>open.
I have another HyperV server that this fix worked on. This new server has the latest patches, this trick isn’t working. There are also edb.log etc files in the c:\windows\security\database folder. (Not in my other server)
I’m getting an “error opening file” I tried using Notepad 2, and that looks WAY different. Password Complexity isn’t listed in that format.
Error in c:\windows\security\logs\scesrv.log
Tuesday, March 27, 2012 1:51:22 AM
Error 1208: An extended error has occurred.
Error opening c:\sec\newer.cfg.
—-Configuration engine was initialized with one or more errors.—-
—-Un-initialize configuration engine…
Thanks for your help.
This still works.
I personally use notepad.
got “an extended error has occurred” when importing the new.cfg file into the /db
into the log i found a “can’t open file” message, maybe a right management on c:\ root directory
solved by creating c:\temp ( with the command MK TEMP ) dir and storing the new.cfg file into it
nevermind, i was wrong, error is still present :(
FYI, you don’t need the “USB” thing; notepad can do Unicode just fine in Win2008 and Win2012. I did it all remotely from an RDP session. I ran “secedit /export /cfg c:\secedit.config.txt”, then used notepad to change the “PasswordComplexity = 1” to be “PasswordComplexity = 0” in the file. Finally, I ran “secedit /configure /db c:\tmp.db /cfg c:\secedit.config.txt /areas SECURITYPOLICY” to apply the change; I deleted the “tmp.db” file afterwards too.
Oh, and one tip: password expiration is incredibly frustrating on Hyper-V. This will turn it off for the indicated user: WMIC USERACCOUNT WHERE “Name=’username_here'” SET PasswordExpires=FALSE
Perhaps it’s of no grim consequeces if one just leaves the required line in [System Access] section and
afterwards. Worked in my Windows Server 2012 Standard. And, yes, you can edit the config file in the native notepad, at least in 2012.
P.S. Medo, you’re the awesomest! TechNet seemed to have had no idea about secedit before you got there with your answer.
P.P.S. Interestingly enough, TN doesn’t seem to have it now either.
As the poster above mentioned, this is my script
“[System Access]” | out-file c:\delete.cfg
“PasswordComplexity = 0” | out-file c:\delete.cfg -append
“[Version]” | out-file c:\delete.cfg -append
‘signature=”$CHICAGO$”‘ | out-file c:\delete.cfg -append
secedit /configure /db C:\Windows\security\new.sdb /cfg c:\delete.cfg /areas SECURITYPOLICY
Great post – CLI approach works on Hyper-V 2012 R2, which is what I needed. Thanks!