Sunday, October 24, 2010
Thursday, October 21, 2010
Configuring Disk Quotas in Windows 2003
| What disk quotas are, when they should be used, and how to configure them in Windows 2003. |
Looking for a means to manage the amount of network storage space users receive? Disk Quotas are the way to go. In this article we will look at what disk quotas are, when they should be used, and how to configure them in Windows 2003.
About Disk Quotas
Unfortunately, in Windows NT Disk Quotas didn’t exist, which was much to the disappointment of Windows Administrators. Along came Windows 2000 and with the introduction of Disk Quotas it meant Administrators had the ability to track and control user disk usage. The only problem was that they didn’t really have a sufficient way of managing disk quotas. Scripting, reporting and remote usage methods were somewhat limited and ambiguous. Windows 2003 offers better all round functionality and easier enterprise-wide disk quota manageability.
Disk quotas are used in conjunction with NTFS, Group Policy and Active Directory technology. NTFS is the file system on which disk quotas can be set, Group Policy is what is used to set disk quotas on a specific set of users and computers, and Active Directory is used to gather a list of users to which the disk quota group policy will be set. It is important to note that disk quotas can only be used with NTFS; setting them up on FAT or FAT32 drives is not possible.
Disk quotas are configured on a per volume basis and cannot be set on a file or folder level. Each volume would have its individual settings which do not affect any other volumes. You may have a single disk partitioned into two volumes (drives C and D for example) with each having their own quota settings. Disk quotas can also be configured on a per user basis and different groups of users can have different limits set. Administrators are the only ones to whom a disk quota does not apply; by default there are no limits for an Administrator.
There are numerous reasons you may wish to make use of disk quotas. Based on the requirements of your organization you might choose to configure disk quotas if you have a restricted amount of disk space on a specific server, a limited number of servers, or perhaps the need to monitor user disk space usage without actually enforcing a quota. You might be wondering why you’d want to just monitor user disk space usage. Well, let’s say you have a fileserver set up with multiple users in your organization using it everyday to store temporary files. As time goes by and perhaps people forget to delete the files from the server, the amount of available disk space will continue to decrease. If nothing is done about it then users will be denied the right to add more files on the server (until some old files are removed). By monitoring user disk space usage with Microsoft’s disk quotas, you can be notified of when space is running out and then increase the allocated space on the server accordingly or notify your users that they need to delete their files from the server. Additionally, setting a quota warning level will allow for a system event log to be written for your review.
Setting a Group Policy
The most practical means of configuring disk quotas on a large scale would be through a domain-level group policy. This will configure the settings automatically on any of the volumes you wish to have disk quotas enabled, saving you the need to have to configure each volume independently.
Open the Group Policy Object Editor (gpedit.msc) and navigate to Computer Configuration > Administrative Templates > System > Disk Quotas. On the right hand pane you will see a list of policies that can be applied. Double click the “Default Quota Limit and Warning Level Properties” setting.
Figure 1: The Default Quota Limit and Warning Level Properties Dialog
The default quota limit is the maximum amount of space assigned per default quota, whereas the warning level is the amount of space at which a warning is triggered. Normally 90-95% of the total value is a good limit to set as a warning.
Now configure any other settings you wish to be applied by selecting them from the right hand pane. To have your changes applied immediately you can enable the “Disk Quota Policy Processing” policy and choose “Process Even If The Group Policy Objects Have Not Changed” from Administrative Templates > System > Group Policy.
Figure 2: The Disk Quota Policy Processing Dialog
You may also want to manually force a group policy update using the gpupdate utility. Simply go to Start > Run and type gpupdate followed by the return key. This will refresh both the computer and user policies.
Whatever changes you make in the group policy will be reflected on the Quota properties tab of each volume you wish to configure in your domain. The options will appear grayed out and non-editable.
Configuring Disk Quotas and Disk Quota Entries
Using the Computer Management console, you can configure disk quotas for a local or remote volume from a central location. To open Computer Management, you have three choices; either right click My Computer and select Manage, type compmgmt.msc in the Run bar or select Computer Management from the Administrative Tools folder.
Select which computer you wish to manage from the root node. To select a remote machine right click the “Computer Management” node, select “Connect to another computer…” and choose the computer you wish to manage. Now, navigate to Storage > Disk Management and select the volume you want to configure from the right hand pane and open the properties dialog. Click the Quota tab and enable the options you want to be enforced.
Figure 3: The Disk Quota Properties Dialog
The traffic lights icon at the top indicate the status of the disk quota; red means quotas are disabled, orange signifies a changeover is taking place (while it rebuilds the disk information), and green means disk quotas are enabled. A textual representation of the status is shown on the right of the image.
Check “Deny disk space to users exceeding quota limit” to have Windows restrict users from adding more data to their allocated disk space when the quota limit has been reached. Users will be unable to add more data until some space is freed up.
As you can see from Figure 3 above, the quota limit for new users is greyed out. This is because we have already set it from the group policy, which overrides any customizable settings on the quota tab of a volume. In this case we have limited the user’s disk space to 500MB and set a warning level to 450MB.
You may choose not to limit disk usage and just enable quotas to track disk space usage on a per volume basis by leaving the “Deny disk space to users exceeding quota limit” checkbox unchecked and logging a warning when a user exceeds the warning level defined as part of the quota limit. Whenever a user exceeds this limit a Warning event log will be written to the Application Event Log and shown in the Event Viewer.
Figure 4: A warning event log for disk quotas
As per http://support.microsoft.com/kb/915182 there is a known issue in the pre service pack version of Windows 2003 in that the Warning event log is incorrectly shown as an Information log in Event Viewer. In the Quota Entries application however, it is correctly displayed as a Warning.
When you press the Apply button on the Disk Quota Properties Dialog you are notified that the volume will be rescanned to update the statistics and that this operation may take several minutes. Simply press OK to continue and have disk quotas enabled on that volume.
Quota Entries
Click the Quota Entries button on the Disk Quota Properties Dialog to view a list of individual disk quota entries. From this section you can create, delete and manage quota entries for specific users or groups. If a user requires more space than others then you can set this from here.
Go to Quota > New Quota Entry and the Active Directory User Picker will appear. Choose a user from Active Directory and press OK. You will be given the option to limit disk space and set a warning level or not limit disk usage at all.
Figure 5: Adding a new quota entry
Once you have chosen your preferred settings, press OK and the user will be added to the list. You can monitor a user’s disk usage by looking at the properties of each of the columns. ‘Status’ indicates whether the user is within their limit, if a warning has been logged or if the limit has been exceeded; the icon will change accordingly.
Figure 6: Viewing a list of Quota Entries
Conclusion
This article has given you an overview of Disk Quotas in Windows 2003. We’ve looked at why they would be used and how to configure them.Some Administrators will find they won’t need to utilize Disk Quotas, but for those who do I have no doubt that you will find them very useful indeed.
Using NSLOOKUP for DNS Server diagnosis
| The DNS protocol has been around for decades and is a stable and reliable protocol. Even so, DNS does occasionally have problems. PING is a great tool for DNS server diagnosis, and I tend to use it quite frequently myself. However, sometimes PING just doesn’t give you enough information about the problem at hand. When you need more information about a DNS problem than what PING provides you with, you can always turn to the NSLOOKUP command. In this article, I will show you how to use NSLOOKUP. | |
The DNS protocol has been around for decades and is a stable and reliable protocol. Even so, DNS does occasionally have problems. These problems might stem from a loss of connectivity, an invalid DNS record, or a number of other issues. When a DNS server doesn’t behave in the way that it is expected to, many people turn to the PING command for help. PING is a great tool for DNS server diagnosis, and I tend to use it quite frequently myself. However, sometimes PING just doesn’t give you enough information about the problem at hand. When you need more information about a DNS problem than what PING provides you with, you can always turn to the NSLOOKUP command. NSLOOKUP is a built in DNS diagnostic utility that’s available to both Windows and UNIX Administrators. In this article, I will show you how to use NSLOOKUP.
The Basics
NSLOOKUP has a fairly rich syntax and can be a bit confusing for those who have not worked with DNS a great deal. Therefore, I want to start out by showing you some of the basics. Although NSLOOKUP exists in both UNIX and Windows, there are some differences in the way that it behaves in the two operating systems. For the purposes of this article, I will be using the Windows version.
The first thing that you need to understand about NSLOOKUP is that when you use the NSLOOKUP command, it assumes that you are querying a local domain on your private network. You can query an external domain, but NSLOOKUP will try to search for the domain internally first. For example, the brienposey.com domain is external to my network. If I perform an NSLOOKUP against brienposey.com, NSLOOKUP returns the information that’s shown in Figure A.
Figure A: This is what happens when NSLOOKUP queries an external domain
If you look at the figure, you will see that there are non existent domain error messages for the IP addresses 147.100.100.34 and 147.100.100.5. These are the addresses of my internal DNS servers. Below this information however is the non authoritative answer. This means that my DNS server queried an external DNS server in an effort to resolve the IP address associated with the brienposey.com domain.
Now, let’s take a look at what happens when you query an internal domain. One of the local domains on my private network is production.com. If I perform an NSLOOKUP against production.com, I get the results shown in Figure B.
Figure B: This is what it looks like when I query an internal domain
If you look at the top portion of this screen, you will notice that I’m getting the exact same non-existent domain error messages as I got when I queried an external domain. At first, this may seem puzzling. The reason why I got this error message was because I performed an NSLOOKUP outside of the NSLOOKUP shell. I will talk more about the NSLOOKUP shell in the next section. For now though, you need to know that you can enter the NSLOOKUP command by itself. When you do, you will see the familiar non-existent domain error messages, but you will then be taken to the NSLOOKUP prompt (the > sign). From there you can enter various NSLOOKUP commands. When you are done, you can use the EXIT command to return to the command prompt.
The other thing that you should notice about Figure B is the bottom portion of the output. Beneath the reference to production.com is a string of IP addresses. These are the IP addresses of all of the domain controllers within the domain. I should also point out that if multiple IP addresses are assigned to a single server then all of the server’s IP addresses will be displayed by NSLOOKUP.
The NSLOOKUP Shell
Now that I have shown you how to use the NSLOOKUP command to see the IP address or addresses associated with the domain, let’s do something a little bit more useful. One of the things that you can do with NSLOOKUP is to look up a specific type of DNS record. A good example of this is an MX record.
In case you aren’t yet familiar with all of the intricacies of DNS, the MX record points to the organization’s mail server. For example, suppose that someone wanted to send an E-mail message to you, one of the first things that their mail server would have to do is to resolve your domain’s IP address. However, a normal address resolution won’t usually work for this purpose. In Figure A, you saw that when I ran a DNS query against the brienposey.com domain, the domain resolved to the address 24.235.10.4. Keep in mind though, that this is the IP address of the server that hosts my Web site, not the address of my mail server. If someone wanted to send me an E-mail message their E-mail client would have to resolve the IP address of my domain’s mail server. This is where the MX record comes into play. The MX record is a record on a domain’s DNS server that specifies the IP address of the domain’s mail server.
As you can see, the MX record is rather important. Suppose however that your domain was having trouble receiving E-mail and you suspected that a DNS server issue was to blame. You could use NSLOOKUP to confirm that the domain does indeed have an MX record and that the MX record is pointed to the correct IP address.
Earlier I briefly mentioned that you could work within the NSLOOKUP shell. To troubleshoot an MX record problem, you pretty much have to work within this shell. Therefore, you would start the process by entering the NSLOOKUP command at the command prompt.
Once the NSLOOKUP shell is open, you will need to tell NSLOOKUP which DNS server you want to query. To do so, enter the SERVER command, followed by the DNS server’s IP address. You can also enter the server’s fully qualified domain name (assuming that it can be resolved) as an alternative to the server’s IP address.
Now that you have specified a DNS server for NSLOOKUP to use, you can query domains without receiving the non-existent domain error messages that you saw earlier (as long as you remain within the NSLOOKUP shell). To do so, you would simply type the domain name that you want to query. For example, if you look at Figure C, you can see where I have specified a particular DNS server and then queried an external and an internal domain.
Figure C: The error messages go away if you specify a DNS server
Now, let’s get back to the business of looking up a domain’s MX record. To do so, you need to issue a command that tells NSLOOKUP to query based on MX records. The command that you will have to use is:
SET QUERY=MX
Issuing this command by itself won’t give you any information about the domain’s MX record though. For that you have to actually query the domain by entering the domain name. If you look at Figure D, you will see that I have specified an MX query and then entered the production.com domain name. NSLOOKUP now returns a wealth of information pertaining to my domain’s MX record.
Figure D: When an MX query is specified, you can get a wealth of information about your domain’s MX record
Conclusion
As you can see, NSLOOKUP can provide you with a wealth of DNS server diagnostic information. However, NSLOOKUP is not limited to providing the types of information that I have discussed. The NSLOOKUP shell is actually a fairly rich interface with a rather large command set. You can view a list of the available commands and their syntax by entering a question mark at the NSLOOKUP prompt (note: you can not use NSLOOKUP /? to view the command set).
Monitoring and Troubleshooting Using Event Logs
| This article reviews best practices for working with Windows event logs including how to interpret event messages, how to configure event logs, how to search and filter events, how to view events on remote systems, and how to use EventCombMT.exe and other tools to monitor events on multiple systems. | |
|
Figure 1: Example of an event.
Finding More Information About an Event
If an event contains a link and you click on it, a dialog box opens warning you that information about the event will be sent to Microsoft to see if they have more information available concerning the event:
Figure 2: Sending event information to Microsoft.
Clicking Yes opens the Help and Support Center and checks to see if there is any more information about the event that may be helpful. Figure 3 shows a typical response:
Figure 3: Additional help concerning the event.
How many times have you been frustrated by the lack of helpful information available this way concerning some obscure event? In the example above, the additional help provided is that “this error could be caused by either a high load on the domain controller or the failure of other domain controller services” and the suggested remedy is to “restart the DNS Server service” and check the event log for anything else that happened at the same time and could be a clue. In other words, its like the old mantra “when all else fails, try rebooting.” Where can you find more help?
Altair Technologies maintains a helpful site called EventID.net where users can search for additional information about obscure Windows events to help you interpret them. This site is community-based, meaning that users post their comments concerning events to create a community database that can then be searched by others. If you search EventID.net for information about the above event (source = DNS, event ID = 4004) the following is displayed:
Figure 4: Searching EventID.net for more information about event ID 4004 for DNS.
The really useful feature is under Details, where you can click the link “Comments and links for event id 4004 from source DNS” to see comments posted by other users:
Figure 5: Comments on event ID 4004 for DNS posted by users of EventID.net
The last comment is particularly useful as it indicates MS is aware of why this event occurs and suggests it can usually be safely ignored. Help and Support never told us that!
Configuring Event Logs
One of the first things you should do after you install a new Windows system is configure the event logs on that system. This is particularly important for servers where event logs can provide critical information to help you troubleshoot when things go wrong. Before we look at how to configure event logs, we need some background information on the different logs available, and Table 1 provides this below:
| Event log | Log file | Function | Availability |
| Application log | AppEvent.evt | Records events as determined by each software vendor | All Windows systems |
| Security log | SecEvent.evt | Records events based on how audit policy is configured | All Windows systems |
| System log | SysEvent.evt | Records events for Windows operating system components | All Windows systems |
| Directory Service log | NTDS.evt | Records events for Active Directory | Domain controllers only |
| DNS Server log | DnsEvent.evt | Records events for DNS servers and name resolution | DNS servers only |
| File Replication Service log | NtFrs.evt | Records events for domain controller replication | Domain controllers only |
Table 1: Summary of Windows event logs
By default all event logs are:
- Stored in the %Windir%\system32\config folder
- Have a maximum size of 16 MB (Windows Server 2003) or 512 KB (Windows 2000/XP)
- Overwrite events more than 7 days old
Figure 6: Default configuration of DNS Server event log on a Windows Server 2003 DNS server.
Before you put your new Windows server into production, you should decide if these default settings are appropriate. Suggested best practices for configuring event logs on servers include the following:
- Increase the size of each event log to at least 50 MB. Since a typical event is about half a kilobyte in size, this means you’ll be able to store 100,000 events in each log. Note that the maximum supported size of each event log is about 300 MB. If your system drive has insufficient space for your event logs, you can move them to a separate volume by editing the subkey for each log under the HKLM\SYSTEM\CurrentControlSet\Services\Eventlog using Registry Editor, see Microsoft Knowledge Base article 315417 for more information.
- Change the overwrite behavior for the Security log to Do Not Overwrite Events if your enterprise is a high security environment. That way if the Security log fills up the system will shut down to ensure that no events in the Security log are lost. If you do this, make sure you also archive and then clear your Security log regularly to prevent such a shutdown from occurring unexpectedly.
- Change the overwrite behavior for the other event logs to Overwrite Events As Needed so that no overwriting occurs until the entire log becomes full. Again, be sure to regularly archive and clear your event logs to prevent the log from filling up and losing events because of overwrites.
If you have a number of computers and are running Active Directory on your network, you can also use Group Policy to configure event log settings. These settings are found under Computer Configuration/Windows Settings/Security Settings/Event Log in Group Policy Object Editor:
Figure 7: Group Policy settings for configuring event logs.
Searching and Filtering Events
While scrolling through the Event console lets you easily examine the most recent events that have been logged on your system, this quickly becomes impractical on busy systems where event logs are tens of megabytes in size. If you’re looking for instances of a particular kind of event however, you can use the Find and Filter options to speed things up.
Say you want to find all instances of Event ID 4004 in the DNS Server log as shown previously in Figure 1 above. To use the Find feature to accomplish this, right-click on the DNS Server log and select View --> Find, then fill in the Event ID and log name in the Find box:
Figure 8: Finding instances of Event ID 4004 in the DNS Server log.
Click the Find Next button and the first instances of this event is displayed in Event Viewer:
Figure 9: An instance of Event ID 4004 displayed in Event Viewer.
Then click Find Next to display the next instance of this event, and so on.
The frustrating thing about this approach is that the Find interface is not built directly into the Event Viewer window. So let’s try a different approach and use Filter instead. Right-click the DNS Server log again and select View --> Filter, then fill in the Event ID in the Filter tab of the DNS Server Properties sheet:
Figure 10: Filtering the DNS Server log for Event ID 4004.
Click OK and Event Viewer and the only events displayed in the DNS Server log are those having Event ID 4004:
Figure 11: All instances of Event ID 4004 are displayed.
From this information we could conclude that this was only a transient problem that happened a couple of weeks ago when we rebooted the DNS server.
Viewing Events on Remote Systems
Event Viewer also lets you connect to remote systems to view their event logs. The procedure is simple: right-click on the root (top) node in the console tree of Event Viewer and select Connect To Another Computer:
Figure 12: Connecting to a remote computer to view its event logs.
Then either type the name (NetBIOS or FQDN) of the remote computer or click Browse to find it in Active Directory. Click OK to connect:
Figure 13: Can’t connect to a remote computer to view event logs.
Oops, can’t connect! And the error message is cryptic. What went wrong? Typically this error message either indicates one of the following:
- You are not logged on with an account that has local Administrator access to the remote machine (a Domain Admins account should work).
- The Remote Registry service is not running or has been disabled on the remote machine.
Correct the situation and you should be able to connect to the remote machine and view its event logs.
Using EventCombMT.exe
In a previous article on WindowsSecurity.com we looked at the Account Lockout and Management Tools (ALTools.exe) download from Microsoft. One of these tools is EventCombMT.exe, which can be used to consolidate event logs from multiple computers into a single location for analysis. To use this tool double-click on EventCombMT.exe in the folder where you installed it, then specify the domain, servers, and kinds of events you want to find. For example, say you want to find all W32Time events on two servers (TEST230 and TEST235) in the testtwo.local domain:
Figure 14: Using EventCombMT to search for W32Time events on two servers.
Click Search and when the operation is finished a folder will open up displaying the results files generated:
Figure 15: Results files generated by our EventCombMT search.
Double-clicking on one of the two server files displays a comma-delimited list of W32Time events for that server:
Figure 16: Comma-delimited list of W32Time events on server TEST230.
You could then import these files into Excel to consolidate them for further analysis. EventCombMT also has a number of built-in queries you can use for common tasks like searching for locked-out accounts:
Figure 17: Searching for locked-out accounts using EventCombMT.
