I recently encountered a problem creating new logins with SQL Server. Something that has worked for years suddenly stopped with the following error:
Password validation failed. The password does not meet Windows policy requirements because it is too short.
Since SQL Server was using Windows local security policy I went and checked that at Security Settings > Account Policies > Password Policy in Local Security Policy (available under Administrative Tools in Control Panel or by opening secpol.msc). As expected, these contained setting that I was not expecting, which were probably changed from the network by a system administrator.
However, I wanted to be able to enter shorter passwords, like 8 characters instead of 10, but this was disabled. Even if I was running as administrator, the option of changing this was disabled.
It is however still possible to modify these settings even if you cannot do it from the management console. You can do it from a command prompt as administrator.
Hits for this post: 1731
- Open a command prompt running as administrator
- Run the following command to export the settings to a file. In my example, the target path is c:\temp\local.cfg, but it can be anything.
secedit /export /cfg c:\temp\local.cfg
- Edit the file with notepad or another editor. The file is an INI file with sections and key-value pairs. The password settings are available under the [System Access] section. For changing the minimum length of the passwords modify the MinimumPasswordLength key.
- Save the file and run the following command to import the settings from the modified file.
secedit /configure /db %windir%\security\local.sdb /cfg c:\temp\local.cfg /areas SECURITYPOLICY
- Close and open the Local Security Policy console again and check the settings.
I have recently upgraded my SSD disk to a newer and larger one. To avoid the hassle of re-installing everything (I have a lot of things to install) I cloned the disk. Everything worked fine. No problems with the operating system and the applications, except for Visual Studio. Though I could start, edit, build, run, etc. some things just did not work.
When I opened a solution with both C++ and .NET projects I noticed that the C++ projects took a lot to initialize. When I say a lot I mean minutes, many minutes. That didn’t seem right, but I had patience. However, after they finally passed the Initializing phase I noticed that it was no possible to select the configuration and target for the solution to build. The combos were disabled and nothing was displayed there. I could actually build, but it was the last selected configuration and target that were built. I tried deleting generated files (such as the .suo file) and after that, the last selections appeared in those combos, but they where still disabled.
Then I noticed that the properties window was not able to show anything, whether it was the properties of the project, a file or a reference. Everything was very slow. I could edit, but sometimes it took seconds for the text to show up. When I checked the resource monitor, it turned out that Visual Studio was using 17-18% of my CPU.
Finally, I noticed a warning when I closed the solution:
The .sdf file was not present in the specified location. So then I figured it must be a problem with Microsoft SQL Server Compact. Therefore I downloaded the kit from the download center and installed it again. That worked like a charm. Visual Studio was able to create the missing .sdf file, the Visual C++ projects loaded very fast and all other symptoms disappeared.
My conclusion was that cloning the hard-disk didn’t work well for SQL Server Compact. But the problem is that Visual Studio doesn’t react well when this component is missing. It should display the warning about it when it fails to create the file, not when you close the solution.
Hits for this post: 18099