Friday, September 10, 2010
Anu
Advanced users of Windows XP are used to digging around in the Registry looking for ways to tweak performance or push the envelope of Windows' abilities. Provided you back up your Registry before hacking it, no harm usually comes from such endeavors. What about tweaking servers though? What gains can be achieved by making Registry modifications to Windows Server 2003 and its various services such as Terminal Services, Internet Information Services, networking subsystem, and so on? Here are three of my favorite Windows Server Registry tweaks and the reasons you need to know about them. Plus, along the way, we'll learn a bit about the correspondence between the Registry and Group Policy. But please make sure you back up your Registry before you try any of these tweaks, just in case you make a mistake.
Monitor Winlogon Activities with Verbose Status Messages
What's going on when you start up your server?
Windows is notoriously secret about many of its activities, but by enabling verbose messages for the Winlogon service, you can closely monitor what's happening when your server boots up or shuts down, or when you log on or off the machine. Here's how to do it.
First, find the following Registry key:
HKLM\SOFTWARE\Microsoft\ Windows\CurrentVersion\Policies\System
Create a new REG_DWORD value here named verbosestatus and assign it the value 0x01. Now when you log on, log off, start up, or shut down your machine, you should see extra information describing what services are starting and what other activities are taking place on your machine. If you don't see this extra info, check the Registry key above again and see if there is a value named DisableStatusMessages present and if so, set this value to 0x00 or remove it.
Note that enabling verbose status messages for Winlogon requires a reboot.
A Brief Aside on Group Policy
Wait just a minute-- there's an easier way to do this!
If you want to enable verbose logging for a number of machines in a domain, use Group Policy instead of editing the Registry on each machine. Open the Group Policy Object (GPO) that's linked to the organizational unit (OU) where the computer accounts for these machines reside, and configure the following policy:
Computer Configuration\Administrative Templates\System\Verbose vs normal status messages
Also check the following policies:
Computer Configuration\Administrative Templates\System\Remove Boot / Shutdown / Logon / Logoff status messages
You can see that these two policies do the same thing as the two Registry values we looked at previously. That's not surprising--the Administrative Templates section of the machine or user portion of a GPO is basically just a tool for modifying Registry settings on targeted computer and user accounts, and in a domain environment, it's much easier to tweak the Registry by using Group Policy than to use Regedit.
Lightweight Domain Controllers at Branch Office Sites
Windows 2000 Server had some problems with domain controllers at remote sites, particularly when universal groups were used. If the domain controller at your remote site was a global catalog server, it generated a lot of replication traffic over the WAN, which could swamp a slow link from time to time. And if your domain controller wasn't a global catalog server, then users at your site might have experienced slow logons as their universal group memberships were enumerated by a global catalog server at headquarters.
Windows Server 2003 solved all this by allowing domain controllers to cache universal group membership lists; that way, you could reduce WAN traffic by not having to make your remote DC a global catalog server. Plus, you got increased availability because users at your site could still log on even if the link went down.
But there's an alternative to using universal group caching that involves changing the following Registry key on the domain controller at your remote site:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Create a new REG_DWORD value here named IgnoreGCFailures and assign it the value of 0x01. Then reboot your domain controller.
The result? You've essentially turned your domain controller into the Windows Server 2003 equivalent of a Backup Domain Controller (BDC), which was a DC on the old Windows NT 4.0 platform that contained a read-only copy of your accounts database. In other words, the users at your remote site will now be able to log on to this domain controller despite the fact that it isn't a global catalog server, even when your WAN link goes down--and even if they are members of universal groups. The catch, though, is that if you use this hack, then you shouldn't use universal groups, because a security hole can result (users may get access to resources they shouldn't).
Why would you want to do this? Why not just enable universal group caching for the remote site?
The main reason is that configuring this Registry value reduces the hardware requirements for your remote domain controllers (think NT 4.0, where BDCs needed less beefy hardware than your PDC). This can be significant if your company has lots of small sites scattered around the country. For more information regarding this scenario, see this article in the Microsoft Knowledge Base.
Broadcasting Server Descriptions
Finally, here's a lightweight tweak that can really make a difference to your users, especially if you have a number of file servers they need to find and access regularly on the network.
I'm thinking here of the typical mid-sized business that still has four file servers running Windows 2000 Server, two running Windows Server 2003, and maybe even a few still running (eek!) Windows NT 4.0 Server. If you're still one of these shops, and you've run out of drive letters for mapping network drives to shares on your servers using logon scripts, then your users are probably stuck browsing My Network Places to try to find the server they want so they can do their work, and that's brutal. Fortunately, this simple Registry hack will make life a lot easier for them. Look for this key:
HKLM\SYSTEM\CurrentControlSet\ Services\LanmanServer\Parameters
If a REG_SZ value named srvcomment doesn't exist here, create it. Then open the value and enter a text string that describes the server, such as "Accounting File Server." This string will be displayed in the Comment field next to the server name the next time the user browses to this server using My Network Places.
Of course, you could always configure this setting on the server by right-clicking on My Computer, selecting Properties, selecting the Computer Name tab, typing "Accounting File Server" in the Computer Description textbox, and clicking Apply. But what fun is that?
Posted in
0 comments:
Post a Comment