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.
[System Access] 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