Archive for March 27, 2010


Problem

You want to prepare your Active Directory forest and domains for installation of your first Exchange Server.

Solution

Using a graphical user interface

The first phase of the installation is ForestPrep and it needs to be run once on the Schema FSMO domain controller.

  1. Log on to the Schema FSMO forest root domain controller with an account that has both Enterprise Admin and Schema Admin rights.
  2. Prepare the domain controller for a schema update.
  3. Per your corporate standards, create either a global or universal group for the initial Exchange administration delegation. Name the group in a descriptive way like ExchangeRootAdmins.
  4. Insert the Exchange Server CD into the CD-ROM.
  5. On the Start menu, click Run, and type:

6.    <driveletter>:\setup\i386\setup.exe /forestprep

where <driveletter> is the drive letter of your CD-ROM drive. This path may vary for certain versions of Exchange Server such as MSDN or Select versions.

  1. On the Welcome screen, click Next.
  2. On the License Agreement screen, read through the agreement and if you agree, click “I agree” and click Next.
  3. If the Product Identification screen is presented, enter your Exchange Server product key and click Next.
This screen may not appear for certain versions of Exchange Server, such as the MSDN or Select versions.
  1. On the Component Selection screen, verify that the action specified is Forest-Prep, and click Next.
  2. On the Server Administrator Account screen, enter the group created in Step 3 and click Next.
  3. On the Completing the Microsoft Exchange Wizard screen, click Finish.

The second phase is DomainPrep and it needs to be run once for the forest root domain and once for every domain in the forest that will contain mail-enabled objects. Preferably you will run this process on every domain in the forest. You will want to wait for the schema updates from the ForestPrep to replicate prior to starting DomainPrep.

  1. Log on to a machine that is part of the domain with an account that is a member of the Domain Admins group.
  2. Insert the Exchange Server CD into CD-ROM.
  3. On the Start menu, click Run, and then type:

4.    <driveletter>:\setup\i386\setup.exe /domainprep

where <driveletter> is the drive letter of your CD-ROM drive. This path may vary for certain versions of Exchange Server such as MSDN or Select versions.

  1. On the Welcome screen, click Next.
  2. On the License Agreement screen, read through the agreement and if you agree, click “I agree” and click Next.
  3. If presented, on the Product Identification screen, enter your Exchange Server product key and click Next.
This screen may not appear for certain versions of Exchange Server, such as the MSDN or Select versions.
  1. On the Component Selection screen, verify that the action specified is Domain-Prep and click Next.
  2. Depending on how your domain is configured for Pre-Windows 2000 Compatible Access, you may get a pop-up with a message saying “The domain “<domainname>” has been identified as an insecure domain for mail-enabled groups with hidden DL membership. …” If you get this pop-up, click OK.
  3. On the Completing the Microsoft Exchange Wizard screen, click Finish.

Using a command-line interface

You cannot run ForestPrep from the command-line. You can, however, run an unattended DomainPrep. You will need to create an unattended installation configuration file, which is described in “Creating Unattended Installation Files for Exchange and Exchange Service Pack Installations.” For further details on this process, see the Exchange Server 2003 Deployment Guide.

You can load the Exchange schema extensions to your forest before running ForestPrep, allowing you to import the Exchange-specific schema modifications months in advance without needing to specify an organization name as you had to do in Exchange 2000.

Discussion

Microsoft Exchange will not run in an Active Directory forest unless the forest and the domains have been properly prepared. Microsoft did not make the assumption that everyone would use Exchange and therefore did not include all of the Exchange attributes and classes in the base Active Directory schema. The ability to dynamically extend the schema for Active Directory makes it possible for only those people running Exchange to install the Exchange infrastructure.

In addition to schema changes, you have to make security changes to Active Directory and the domain policy, as well as create some basic Exchange infrastructure objects. All of this is completed in the Exchange ForestPrep and DomainPrep processes. Do not confuse these with the Windows 2003 ForestPrep and DomainPrep processes (using the adprep command); the concept is the same but the specific changes are different.

You need to run the ForestPrep process once per forest to make the schema changes, create the Exchange organization structure in the Configuration container, and set up Exchange-specific permissions. The ForestPrep process is also responsible for the initial delegation of Exchange rights to a specific user or group for administrative control. We recommend that you create a security group in your root domain for this delegation. You could use a domain local group in a single domain forest in which you will never create another domain. In a multidomain forest, you must use a global group or a universal group. The group is used to assign rights to objects in the Configuration container. Whether you use a global or universal group is up to youeither will do the job. The ForestPrep process requires the person running the process to be part of both the Enterprise Admins and Schema Admins groups.

You need to run the DomainPrep process in the root domain of the forest and for every domain that will contain mail-enabled objects. Normally, DomainPrep is run on every domain in an Active Directory forest. The process creates Exchange security principals, modifies the domain security policy, creates some Exchange specific infrastructure objects, and assigns permissions to the domain’s Active Directory partition. The DomainPrep process requires the person running the process to be a member of the Domain Admins group of the domain being prepared.

Depending on whether your domain has Pre-Windows 2000 Compatible Access enabled, you may get a scary looking message during the DomainPrep process that tells you your domain is insecure for mail-enabled groups with hidden distribution list membership. Instead of making quick changes to your domain that could break other applications, investigate whether you need that compatibility access. If you do not need the access, by all means lock down the Pre-Windows 2000 Compatible Access group as specified.

Just like any application, there are requirements for the installation of Exchange Server 2003. The requirements are split into forest requirements and machine requirements.

For ForestPrep and DomainPrep, there are no machine requirements. However, the requirements for the forest are:

  • Domain controllers must be running Windows 2000 Server Service Pack 3 or Windows Server 2003.
  • Global catalog servers must be running Windows 2000 Server Service Pack 3 or Windows Server 2003. You should have at least one global catalog server per site that you intend to install Exchange into.
  • DNS and NetBIOS name resolution (typically using WINS) must be properly configured.

Due to the depth of changes made to the overall structure of Active Directory, the ForestPrep process requires Schema Admin and Enterprise Admin rights and the DomainPrep requires Domain Admin rights. This prevents anyone but the centralized administration group responsible for the overall Active Directory forest from initially installing Exchange into the forest.

For a more in-depth discussion of the Exchange Server 2003 deployment requirements, considerations, and the specifics of what the preparation processes do, please see the Exchange Server 2003 Deployment Guide. This is a free download from Microsoft and can be obtained by going to http://www.microsoft.com/exchange/library. You should also review the Exchange Server 2003 Deployment Tools and the Exchange Best Practices Analyzer, available from the same site.

Managing Exchange is a little different from managing most other Microsoft applications. The computer where you run the tools or scripts must be a member of a domain in the forest where the Exchange organization resides. This is true whether you are using a script or the GUI. Exchange doesn’t allow you to select other organizations to manage. This can be troublesome for someone managing multiple Exchange organizations or a mobile worker who moves between sites or companies and likes to run her workstation in workgroup mode instead of being a member of any specific domain.

Permissions are very important and often misunderstood in Exchange. Permissions can be set up very simply or in a very complicated way; it is tough to find a middle ground. The simplest method is to give your Exchange administrators Domain Admin access. This is pretty standard in small companies where the Exchange admins are doing all aspects of administration. But this practice is usually unacceptable in larger companies where separation of duties and more security is required.

Exchange Server has several software prerequisites that must be installed prior to its installation. You must have these prerequisites in place prior to installing Exchange or Exchange will refuse to install. The prerequisites vary by operating system.

Windows 2000 SP3+ prerequisites:

  • Windows Server 2003 Administration Tools Pack (adminpak.msi)
  • Internet Information Services (IIS)
  • World Wide Web (WWW) Publishing Service
  • Simple Mail Transport Protocol (SMTP) Service
  • Network News Transfer Protocol (NNTP) Service

Window Server 2003 requires the Windows 2000 prerequisites plus:

  • .NET Framework
  • ASP.NET

Problem

You want to restrict who can administer your DHCP servers in your domain.

Solution

Using a graphical user interface
  1. Open the Active Directory Users and Computers MMC snap-in.

  2. In the console tree, click Active Directory Users and Computers Domain-Name Users.

  3. In the details pane, click DHCP Administrators.

  4. Click Action Properties Members.

  5. Remove all users and groups you do not want to have administering your DHCP server by clicking their names and then clicking Remove.

  6. To add new DHCP administrators, click Add, provide the user or group name, and then click OK.

  7. Click OK.

Using a command-line interface

Add a member to a group with DSMod by passing the -addmbr option:

	> dsmod group "<GroupDN>" -addmbr "<MemberDN>"

To add a group member with AdMod, use the following syntax:

	> admod -b "<GroupDN>" member:+:"<MemberDN>"

Remove a member from a group with DSMod by passing the -rmmbr option:

	> dsmod group "<GroupDN>" -rmmbr "<MemberDN>"

To remove a group member with AdMod, use the following syntax:

	> admod -b "<GroupDN>" member:-:"<MemberDN>"

Replace the complete membership list with DSMod by passing the -chmbr option:

	> dsmod group "<GroupDN>" -chmbr "<Member1DN Member2DN … >"

To replace the membership of a group with AdMod, use the following two commands:

	> admod b "<GroupDN>" :-
	> admod -b "<GroupDN>" member++::"<Member1DN>;<Member2DN>;<Member3DN>"

Using VBScript
	' This code adds a member to the  
DHCP  
Administrators group.
	' ------ SCRIPT CONFIGURATION ------
	strGroupDN = "<GroupDN>" ' e.g. "cn= 
DHCP Administrators,cn=Users,<DomainDN>
	strMemberDN = "<MemberDN>" ' e.g. cn=jsmith,cn=users,dc=rallencorp,dc=com
	' ------ END CONFIGURATION --------

	set objGroup = GetObject("LDAP://" & strGroupDN)
	' Add a member
	objGroup.Add("LDAP://" & strMemberDN)

	' This code removes a member from the  
DHCP Administrators group.

	set objGroup = GetObject("LDAP://" & strGroupDN)
	objGroup.Remove("LDAP://" & strMemberDN)

Discussion

Windows Server 2003 is better than its predecessors about supporting role separation. Most roles can be assigned independently of one another rather than just making a user a Domain Admin or an Enterprise Admin. This is great for security administrators who want to ensure that users have only enough rights to perform their assigned tasks. For example, a user Fred might need to modify an enterprise-wide object. You could just add Fred to the Enterprise Admin groups to solve the problem. However, Fred now has access to virtually any object in the entire forest and could cause irreparable harm to your network, not to mention compromise all security in place. Instead, you can grant Fred access to just that object.

This can be done in separate ways. One method is the “Delegation of Control” wizard. Another way is that Windows has several built-in groups that are created and populated when specific services are installed. One such group is DHCP Administrators, which is created when the first DHCP server is brought up in a domain. You can control administrative access to the DHCP function of these servers through this group membership.


Problem

You want to permit (i.e., authorize) a DHCP server to process DHCP requests from clients. This is necessary only if the DHCP server is a member of an Active Directory domain.

Solution

Using a graphical user interface

Windows 2000 DHCP servers cannot be authorized with the Windows Server 2003 version of the DHCP snap-in unless the DHCP server has Service Pack 2 or higher installed.
  1. Open the DHCP snap-in.
  2. In the left pane, right-click on DHCP and select Add Server.
  3. Type in the name of the DHCP server you want to target and click OK.
  4. Click on the server entry in the left pane.
  5. Right-click on the server and select Authorize.
If the DHCP server is not a member of an Active Directory domain, you will not see the Authorize option.

Using a command-line interface

The following command authorizes a DHCP server in Active Directory:

> netsh dhcp add server <DHCPServerName> <DHCPServerIP>

This example shows how to authorize the DHCP server named dhcp01.rallencorp.com with IP 192.168.191.15:

> netsh dhcp add server dhcp01.rallencorp.com 192.168.191.15

Using VBScript

‘ The following script prints out the list of

‘ authorized DHCP Servers in Active Directory.

‘ —— SCRIPT CONFIGURATION ——

strForestRootDN = “<ForestRootDN>” ‘ e.g. dc=rallencorp,dc=com

‘ —— END CONFIGURATION ——–

set objCont = GetObject(“LDAP://CN=DhcpRoot,CN=NetServices,CN=Services,” & _

“CN=Configuration,” & strForestRootDN)

colDHCPServers = objCont.GetEx(“dhcpServers”)

for each strDHCPServer in colDHCPServers

Wscript.Echo strDHCPServer

next

Discussion

Windows 2000 and Windows Server 2003based DHCP servers that belong to an Active Directory domain must be authorized before they can give leases to clients. This feature helps reduce the danger of a rogue Windows 2000 or Windows Server 2003 DHCP server that an end user sets up, perhaps even unintentionally.

However, this still doesn’t prevent someone from plugging in a non-Windows DHCP server (e.g., a Linksys router with the DHCP server enabled) and causing clients to receive bad leases. A rogue DHCP server can provide incorrect lease information or deny lease requests altogether, ultimately causing a denial of service for clients on your network.

If the DHCP server service is enabled on a domain controller, it is automatically authorized. A DHCP server that is a member server of an Active Directory domain performs a query in Active Directory to determine whether it is authorized. If it is, it will respond to DHCP requests; if not, it will not respond to requests.

A standalone Windows DHCP server that is not a member of an Active Directory domain sends out a DHCPINFORM message when it first initializes. If an authorized DHCP server responds to the message, the standalone server will not respond to any further DHCP requests. If it does not receive a response from a DHCP server, it will respond to client requests and distribute leases.

DHCP servers are represented in Active Directory as objects of the dhcpClass class, in the cn=NetServices,cn=Services,cn=Configuratation,<ForestRootDN> container. The relative distinguished name of these objects is the IP address of the DHCP server. There is also an object in the same container named cn=dhcpRoot, which is created after the first DHCP server is authorized. It has an attribute named dhcpServers that contains all authorized servers. We enumerated this attribute in the VBScript solution to display all authorized servers.

By default, only members of the Enterprise Admins group can authorize DHCP servers. However, you can delegate the rights to authorize a DHCP server. Do the following to delegate the necessary permissions to a group called DHCP Admins:

  1. Open ADSI Edit from the Support Tools while logged on as a member of the Enterprise Admins group.
  2. In the left pane, expand the Configuration Container CN=Configuration CN=Services CN=NetServices.
  3. Right-click on CN=NetServices and select Properties.
  4. Select the Security tab.
  5. Click the Advanced button.
  6. Click the Add button.
  7. Use the object picker to select the DHCP Admins group.
  8. Check the boxes under “Allow for Create dHCPClass objects” and “Delete dHCPClass objects.”
  9. Click OK until all dialog boxes are closed.
  10. Back in ADSI Edit, right-click on CN=dhcpRoot (if you’ve previously authorized DHCP Servers) and select Properties.
  11. Select the Security tab.
  12. Click the Advanced button.
  13. Click the Add button.
  14. Use the object picker to select the DHCP Admins group.
  15. Check the boxes under Allow for “Write for all properties.”
  16. Click OK until all dialog boxes are closed.

Using a graphical user interface

You can quickly determine whether a DHCP server has been authorized by looking at its server node in the left pane of the DHCP snap-in. If the icon has a little red flag, it isn’t authorized; if the flag is green, it is authorized.

Using a command-line interface

To see the list of authorized servers using the command line, run the following command:

> netsh dhcp show server

Problem

You want to prevent a domain controller from dynamically registering its resource records using DDNS. If you manually register a domain controller’s resource records, you’ll want to prevent those domain controllers from attempting to dynamically register them. If you do not disable them from sending dynamic update requests, you may see annoying error messages on your DNS servers that certain DDNS updates are failing.

Solution

Using a command-line interface
	> reg add HKLM\System\CurrentControlSet\Services\Netlogon\Parameters /v
	UseDynamicDNS /t REG_DWORD /d 0
	The operation completed successfully.

	> net stop netlogon
	The Net Logon service is stopping.
	The Net Logon service was stopped successfully.

	> del %SystemRoot%\system32\config\netlogon.dnb

	> net start netlogon
	The Net Logon service is starting.......
	The Net Logon service was started successfully.

Using VBScript
	' This code prevents a DC from registering resource records dynamically.
	' It must be run directly on the server.

	' Create Registry Value
	const HKLM = &H80000002
	set oReg=GetObject("winmgmts:root\default:StdRegProv")
	strKeyPath = "System\CurrentControlSet\Services\Netlogon\Parameters"
	if oReg.SetDWORDValue(HKLM,strKeyPath,"UseDynamicDNS",1) <> 0 then
	   WScript.Echo "Error creating registry value"
	else
	   WScript.Echo "Created registry value successfully"
	end if

	' Stop Netlogon service
	strService = "Netlogon"
	set objService = GetObject("WinMgmts:root/cimv2:Win32_Service.Name='" & _
	                           strService & "'")
	if objService.StopService <> 0 then
	   WScript.Echo "Error stopping " & strService & " service"
	else
	   WScript.Echo "Stopped " & strService & " service successfully"
	end if

	' Delete netlogon.dnb file
	set WshShell = CreateObject("WScript.Shell")
	set objFSO = CreateObject("Scripting.FileSystemObject")
	set objFile = objFSO.GetFile( _
	                    WshShell.ExpandEnvironmentStrings("%SystemRoot%") _
	                    & "\system32\config\netlogon.dnb" )

	objFile.Delete
	WScript.Echo "Deleted netlogon.dnb successfully"

	' Start Netlogon service
	if objService.StartService <> 0 then
	   WScript.Echo "Error starting " & strService & " service"
	else
	   WScript.Echo "Started " & strService & " service successfully"
	end if

	WScript.Echo
	WScript.Echo "Done"

Discussion

By default, domain controllers attempt to dynamically register their Active Directoryrelated resource records every hour via the NetLogon service. You can prevent a domain controller from doing this by setting the UseDynamicDNS value to 0 under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters. After you set that value, you should stop the NetLogon service, remove the %SystemRoot%\system32\config\netlogon.dnb file, and then restart NetLogon. It is necessary to remove the netlogon.dnb file because it maintains a cache of the resource records that are dynamically updated. This file will get re-created when the NetLogon service restarts.

Problem

You want to manually deregister a domain controller’s resource records.

Solution

Using a command-line interface

With the following nltest command, replace <DomainControllerName> with the FQDN of the domain controller you want to deregister and <DomainDNSName> with the FQDN of the domain of which the domain controller is a member:

	 
> nltest /dsderegdns: 
<DomainControllerName> /dom:<DomainDNSName>

Discussion

When a domain controller is demoted from a domain, it dynamically deregisters its resource records. This is a nice feature of the demotion process because it means you do not have to manually remove all of the resource records or wait for scavenging to remove them. If, however, you have a domain controller that crashes and you do not plan on bringing it back online, you’ll need to remove the records manually or wait for the scavenging process to take place.

You can use the DNS Mgmt MMC snap-in and even the dnscmd.exe utility to manually remove them one by one, or you can use nltest, as shown in the solution.

The /dsderegdns switch also has /DomGUID and /DsaGUID options if you want to delete the records that are based on the domain GUID and DSA GUID, respectively. You need to know the actual GUIDs of the domain and domain controller to use those switches, so if you don’t have them handy, it would be easier to delete them using the DNS Management MMC snap-in.

Problem

You want to manually force registration of a domain controller’s resource records. This may be necessary if you’ve made some configuration changes on your DNS servers to allow your domain controllers to start dynamically registering resource records.

Solution

Using a command-line interface
	> nltest /dsregdns /server:<DomainControllerName>

Discussion

The Windows Server 2003 version of nltest provides a /dsregdns switch that allows you to force registration of the domain-controller-specific resource records. You can also force reregistration of its resource records by restarting the NetLogon service on the domain controller. The NetLogon service automatically attempts to reregister a domain controller’s resource records every hour, so if you can wait that long, you do not need to use nltest.

Problem

You want to enable DNS debug logging to troubleshoot issues related to DNS queries or updates.

Solution

Using a graphical user interface
  1. From the Administrative Tools, open the DNS Management snap-in.

  2. Connect to the DNS Server you want to modify. In the left pane, right-click on DNS and select “Connect to DNS Server.” Select “The following computer” and enter the target server name. Click OK.

  3. Right-click on the server and select Properties.

  4. Click on the Debug Logging tab (or the Logging tab in Windows 2000).

  5. Select what you want to log and the location of the logfile (in Windows 2000, the logfile location is hardcoded to %systemroot%\system32\dns\dns.log).

  6. Click OK.

Using a command-line interface

Use the following four commands to enable debug logging. For the log level, you have to add together the event codes you want logged and specify the result in hex. The available event codes can be found in Table 14-3.

	> dnscmd <ServerName> /Config /LogLevel <EventFlagSumInHex>

Use the following command to specify the location of the logfile:

	> dnscmd <ServerName> /Config /LogFilePath <DirectoryAndFilePath>

Use the following command to log only entries that pertain to certain IP addresses:

	> dnscmd <ServerName> /Config /LogIPFilterList <IPAddress1>[,<IPAddress2>…]

Use the following command to specify the maximum logfile size:

	> dnscmd <ServerName> /Config /LogFileMaxSize <NumberOfBytesInHex>

Use the following command to disable debug logging:

	> dnscmd <ServerName> /Config /LogLevel 0

Using VBScript
	' This code enables  
DNS debug logging.
	' ------ SCRIPT CONFIGURATION -------
	strServer = "<ServerName>" ' e.g. dc1
	' The log level must be in decimal, not hex like dnscmd
	intLogLevel = <EventFlagSumInDecimal> ' e.g. 65535
	arrFilterList = Array("<IPAddress1>") ' e.g. 192.168.1.12
	strFilePath = <DirectoryAndFilePath> ' e.g. c:\dnslog.txt
	intFileSize = <NumberOfBytesInDecimal> ' e.g. 50000000
	' ------ END CONFIGURATION ---------

	set objDNS = GetObject("winMgmts:\\" & strServer & "\root\MicrosoftDNS")
	set objDNSServer = objDNS.Get("MicrosoftDNS_Server.Name="".""")
	objDNSServer.LogLevel = intLogLevel
	objDNSServer.LogIPFilterList = arrFilterList

	 
objDNSServer. 
LogFilePath = strFilePath
	objDNSServer.LogFileMaxSize = intFileSize
	objDNSServer.Put_
	WScript.Echo "Enabled DNS  
Debug Logging on " & strServer

	' To disable  
debug logging, set the intLogLevel variable to 0

Discussion

With the DNS Server debug log, you can record all DNS operations received and initiated by the server, including queries, updates, zone transfers, etc. If you need to troubleshoot a particular host, you can use the LogIPFilterList setting in dnscmd or the WMI DNS Provider to restrict the log to operations performed only for or by that host.

The most important debug log setting is the log level. With the DNS snap-in, you can select from a list of available options. With Windows Server 2003, the DNS snap-in provides an intuitive interface for selecting the required options. On Windows 2000, you are presented with a list of checkboxes and you have to figure out which ones need to be used in conjunction with one another. You have a similar issue with CLI and VBScript solutions, where you need to determine what log level you want to set.

Table contains all of the event codes with their hexadecimal and decimal values.

Table . DNS debug logging event codes
Hexadecimal value Decimal value Descriptions
0x0 0 No logging. This is the default.
0x1 1 Query transactions.
0x10 16 Notifications transactions.
0x20 32 Update transactions.
0xFE 254 Nonquery transactions.
0x100 256 Question packets.
0x200 512 Answer packets.
0x1000 4096 Send packets.
0x2000 8192 Receive packets.
0x4000 16384 UDP packets.
0x8000 32768 TCP packets.
0xFFFF 65535 All packets.
0x10000 65536 AD write transactions.
0x20000 131072 AD update transactions.
0x1000000 16777216 Full packets.
0x80000000 2147483648 Write-through transactions.

DNS debug logging can come in handy if you want to look at the dynamic update requests a particular DNS Server is processing. For example, if a client or DHCP server is attempting to dynamically register records, you can enable the Update Transactions log category on the DNS Server you think should be processing the updates. If you don’t see any update transactions, this can indicate that another server is processing the dynamic update requests.

Problem

You want to clear the DNS cache. The DNS cache contains resource records that are cached by the server or workstation for a period of time in memory so that repeated requests for the same record can be returned immediately. There are two types of DNS cache. One pertains to the cache on the Windows DNS client resolver (this can refer to both server and workstation operating systems when they are requesting DNS information from a server), and the other refers to the cache used by the Microsoft DNS server software.

Solution

To flush the client resolver cache, use the following command:

	 
>  
ipconfig /flushdns

To flush the DNS server cache, use any of the following solutions.

Using a graphical user interface
  1. Open the DNS Management snap-in.

  2. Right-click on DNS in the left pane and select “Connect to DNS Server.”

  3. Enter the server you want to connect to and click Enter.

  4. Right-click on the server and select Clear Cache.

Using a command-line interface

The following command will clear the cache on <DNSServerName>. You can leave out the <DNSServerName> parameter to simply run the command against the local server:

	> dnscmd <DNSServerName> /clearcache

Using VBScript
	' This code clears the DNS server cache on the specified server.
	' ------ SCRIPT CONFIGURATION ------
	strServer = "<DNSServerName>" ' e.g. dc1.rallencorp.com
	' ------ END CONFIGURATION --------

	set objDNS = GetObject("winmgmts:\\" & strServer & "\root\MicrosoftDNS")
	set objDNSServer = objDNS.Get("MicrosoftDNS_Server.Name="".""")
	set objDNSCache = objDNS.Get("MicrosoftDNS_Cache.ContainerName=""..Cache""" & _
	                             ",DnsServerName=""" & objDNSServer.Name & _
	                             """,Name=""..Cache""")
	objDNSCache.ClearCache
	WScript.Echo "Cleared server cache"

Discussion

The client resolver cache is populated whenever a DNS lookup is performed on a workstation or server (e.g., with nslookup). It’s important to remember that this cache will store both positive DNS responses as well as negative ones. For example, if lost network connectivity causes DNS queries for an external resource like a mail server to fail, those queries will continue to fail until the cache refreshes: the queries have been negatively cached.

The second type of cache is in place only on Microsoft DNS servers. It is a cache of all DNS requests that the server has made while processing queries from various clients. You can view this cache by browsing the Cached Lookups folder for a server in the DNS Management snap-in. This folder is not shown by default, so you’ll need to select Advanced from the View menu.

With both the client and server cache, records are removed from the cache after the record’s TTL value expires. The TTL is used to age records so that clients and servers will request an updated copy of the record at a later point in order to receive any changes that may have occurred.

Problem

You want to modify the DNS Server settings.

Solution

Using a graphical user interface
  1. Open the DNS Management snap-in.

  2. If an entry for the DNS server you want to connect to does not exist, right-click on DNS in the left pane and select “Connect to DNS Server.” Select “This computer” or “The following computer,” then enter the server you want to connect to (if applicable) and click OK.

  3. Right-click on the server and select Properties.

  4. There will be several tabs you can choose from to edit the server settings.

  5. Click OK to commit the changes after you’ve completed your modifications.

Using a command-line interface

With the following command, replace <Setting> with the name of the setting to modify and <Value> with the value to set:

	> dnscmd <DNSServerName> /config /<Setting> <Value>

The following command enables the EnableDnsSec setting on dns01:

	> dnscmd dns01 /config /EnableDnsSec 1

The following command disables the NoTcp setting on the local host:

	> dnscmd /config /NoTcp 0

The following command sets the DsPollingInterval setting to 60 on dns02:

	> dnscmd dns02 /config /DsPollingInterval 60

For the complete list of settings, run dnscmd /config from the command-line.

Using VBScript
	set objDNS = GetObject("winMgmts:root\MicrosoftDNS")
	set objDNSServer = objDNS.Get("MicrosoftDNS_Server.Name="".""")
	objDNSServer.<Setting> = <Value> ' e.g. objDNSServer.AllowUpdate = TRUE
	objDNSServer.Put_

Discussion

The Microsoft DNS server supports a variety of settings to configure everything from scavenging and forwarders to logging. With the DNS Management snap-in, the settings are spread over several tabs in the Properties property page. You can get a list of these settings by simply running dnscmd /config from a command line. For the CLI and VBScript solutions, the setting names are nearly identical. In the VBScript solution, be sure to call the Put_ method after you are done configuring settings in order for the changes to take effect.