Risque Management : Sysadminship

Windows file server performance optimization

Slav — Fri, 24 Apr 2009 06:02:00 GMT

Merge this into the registry, reboot and enjoy increased performance:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"NtfsDisable8dot3NameCreation"=dword:00000001
"NtfsMemoryUsage"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"NumTcbTablePartitions"=dword:00000008

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{INTERFACE NUMBER}]
"TcpAckFrequency"=dword:0000000d

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"PagedPoolSize"=dword:ffffffff
"LargeSystemCache"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Executive]
"AdditionalDelayedWorkerThreads"=dword:00000020
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcXdr\Parameters]
"DefaultNumberOfWorkerThreads"=dword:00000040

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NfsSvr\Parameters]
"OptimalReads"=dword:00000001
"RdWrHandleLifeTime"=dword:0000000a
"RdWrNfsReadHandlesLifeTime"=dword:0000000a
"RdWrNfsHandleLifeTime"=dword:0000003c
"RdWrThreadSleepTime"=dword:0000003c
"SecureHandleLevel"=dword:00000000
"NfsHandlesCacheSizeLowWatermark"=dword:003d08ce
"NfsHandlesCacheSizeMax"=dword:003d0900
"NtfsHandlesCacheSizeLowWatermark"=dword:000249be
"NtfsHandlesCacheSizeMax"=dword:000249f0
"FileHandleCacheSizeInMB"=dword:3de00000
"LockFileHandleCacheInMemory"=dword:00000001
"MaxIcbNfsReadHandlesCacheSize"=dword:00001f40

Also, check the NTFS log size (chkdsk /l) and increase it to 65536 KB in case it isn't already of that size. That covers Windows CIFS and NFS and was tested on 32-bit Windows 2003 (yet I believe W2K8 and 64-bit platforms also can be optimised this way, will test). This comes from the SPEC file server benchmarking results and configuration notes for HP ProLiant DL585 G2 Storage Server.

Check out other systems and results - some interesting information there.

It is a good idea to check the performance before and after changing the system parameters. You don't need to purchase SPEC tests to do that - there are free tools available. Stay tuned for some details, or search away (if your OS of choice is Windows, use "sqlio" as the search criteria).

Disabling Syskey startup password

Slav — Mon, 28 Jan 2008 00:50:00 GMT

So it happened: Windows starts up and asks for a password, and you don't know what that is. Either forgot, or didn't know the password. This is Syskey in action. What to do?

You can try brute forcing the password. Syskey gives unlimited tries. After the first hundred you'll come to the conclusion that brute forcing is overrated. And there are no reliable tools that will help brute forcing Syskey password.

You can forcibly switch Syskey off. The best tool for it is the Offline NT Password & Registry Editor, commonly known as NTPasswd. The bootable Linux-based CD image is just over 3MB, contains many SCSI drivers as read-write NTFS driver, as has intuitive text manu-based UI. It allows disabling Syskey. But there will be side effects:

All locally stored encryption keys will become invalid;
You will not be able to connect to Terminal Services - it's using encryption keys for session security;
IIS-based services (W3SVC, SMTP and depending Exchange services) will not start - parts of Metabase are encrypted, and the keys aren't available;
Any service running not as LocalSystem will not start. You'll need to reset the credentials cache. The easies way is to set the service to run as LocalSystem, and then change again to a service account;
Same applies to scheduled tasks;
All EFS-encrypted data, including that encrypted with the system key, will be permanently lost.

So the system will be severely damaged after it comes back up. Only do this to recover the latest data. If you need more - always back up System state offline. And do not forget test restoration before an incident happens.

Capturing Windows user logon traffic

Slav — Fri, 12 Oct 2007 00:36:00 GMT

I don't need to go into many details about the startup process and importance of analysing it in case of problems. Here's how I do it:

The tools:

Wireshark (http://www.wireshark.org/)
PSTools (http://www.microsoft.com/technet/sysinternals/Utilities/PsTools.mspx)
Windows ResourceKit tools (http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd)

Install the tools accepting all defaults (you should always go with defaults unless you have really good reasons not to - and security through obscurity is not one). Follow the Resource kit documentation to install Autoexnt service, use interactive option.

The most important information that is not in the network traffic capture is the process map - the information that allows to identify what processes are making connections.

I'm using c:\tmp folder for the captures and other files. This is the autoexnt.cmd file:

@echo off
move c:\tmp\capture.cap c:\tmp\captureX.cap
move c:\tmp\capturelog.txt c:\tmp\capturelogX.txt
start /D"C:\Program Files\Wireshark\" tshark.exe -i 2 -w c:\tmp\capture.cap
:loop
cscript //Nologo c:\tmp\now.vbs >> c:\tmp\capturelog.txt
netstat -ano >> c:\tmp\capturelog.txt
pslist >> c:\tmp\capturelog.txt
sleep 1
goto loop

In the tshark command line options, the interface number (the -i option) may be different on your system - use "tshark -D" to list interfaces on your system. I found that in some cases tshark has visibility of all interfaces on the system whereas Wireshark GUI doesn't let you choose the right interface. Now.vbs prints current time with seconds. The whole script is:

WScript.Echo Now

After rebooting the computer and the user logon there will be two windows on the screen - cmd.exe and tshark.exe. Close both -you'll find the traffic capture in the c:\tmp\capture.cap and process/connection lists in c:\tmp\capturelog.txt. That's enough information to do analysis.

The beauty of the approach is that no hubs or switches are involved, and all of it can be done remotely. Evidently, both scripts and the approach can be improved in many ways. Suggestions welcome.

Good principles for sysadmins and solution architects

Slav — Sun, 25 Feb 2007 06:50:00 GMT

Solaris™ Administration Best Practices by Peter Baer Galvin is an old gem. Here's the list: Keep an Eye Peeled and a Wall at Your Back Communicate with Users Help Users Fix It Themselves Use Available Information Know When to Use Strategy and...(read more)