Outlook 2010 runs in Safe Mode after Update

In Outlook 2010, all of my options were reset to their defaults and when I change them, the changes don't stick. As soon as I close Outlook and restart it, everything is back to its default.

This is caused by installing KB3114409 - it causes Outlook to run in Safe mode, which uses the default settings. Your customizations aren't lost, they just aren't being used when Outlook is in Safe mode.
Microsoft removed the update, so users who haven't installed the December updates yet won't be affected. Users who are affected have two choices to fix this: uninstall KB3114409 or set a registry key to disable Safe mode.
To set the registry key:

1. Open the Registry editor by pressing Windows key + R
2. Type regedit in the Open: field. Then click Ok.
3. Browse to HKEY_LOCAL_MACHINE\Software\Microsoft\Office\14.0\Outlook\Security\ key on the left side of the Registry Editor
4. If any key in the path is missing, you'll need to create it. Right click on the last key, choose New > Key and type the missing key name.
5. Right click on Security key and choose New, and then DWORD Value.
6. Type DisableSafeMode, and then press Enter.
7. Right-click on DisableSafeMode, and then click Modify.
   
8. In the Value data box, type 1, and then click OK.
9. If you have 64bit Windows and 32bit Office, also add DisableSafeMode, Value: 1 to this key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Outlook\Security\
10. Restart Outlook or reboot the computer.

If you don't want to edit the registry, you can use this reg file: DisableSafeMode.reg DisableSafeMode.reg for Outlook 32 bit on Windows 64-bit

Uninstall KB3114409

To uninstall updates, open Control Panel, then find Programs & Features. Click on View Installed Updates on the left. Type KB3114409 in the Search Updates field. Select it and click Uninstall. 

How to change the default keep-alive time-out value in Internet Explorer

SUMMARY

This article describes how to change the default HTTP keep-alive value in Microsoft Internet Explorer.

When Internet Explorer establishes a persistent HTTP connection with a Web server (by using Connection: Keep-Alive headers), Internet Explorer reuses the same TCP/IP socket that was used to receive the initial request until the socket is idle for one minute. After the connection is idle for one minute, Internet Explorer resets the connection. A new TCP/IP socket is used to receive additional requests. You may want to change the HTTP KeepAliveTimeout value in Internet Explorer.

If either the client browser (Internet Explorer) or the Web server has a lower KeepAlive value, it is the limiting factor. For example, if the client has a two-minute timeout, and the Web server has a one-minute timeout, the maximum timeout is one minute. Either the client or the server can be the limiting factor.

By default, Internet Explorer has a

KeepAliveTimeout

value of one minute and an additional limiting factor (

ServerInfoTimeout

) of two minutes. Either setting can cause Internet Explorer to reset the socket.

MORE INFORMATION

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

You may have to increase the default time-out value for persistent HTTP connections in Internet Explorer if you are using a Web program that must communicate with Internet Explorer over the same TCP/IP socket after one idle minute. To change the default time-out value for persistent HTTP connections in Internet Explorer, add a DWORD value that is named

KeepAliveTimeout

to the following registry key, and then set its value data to the time (in milliseconds) that you want Internet Explorer to wait before resetting an idle connection:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings

To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following key in the registry:
   HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type KeepAliveTimeout, and then press ENTER.
5. On the Edit menu, click Modify.
6. Type the appropriate time-out value (in milliseconds), and then click OK. For example, to set the time-out value to two minutes, type 120000.
7. Restart Internet Explorer.

If you set the

KeepAliveTimeout

value to less than 60,000 (one minute), you may have problems communicating with Web servers that require persistent HTTP connections. For example, you may receive a "Page cannot be displayed" error message.

If you must have a

KeepAliveTimeout

value higher than 120000 (two minutes), you must create an additional registry key and set its value equal to the

KeepAliveTimeout

value that you want. The additional registry key is

ServerInfoTimeout

. It is a DWORD with a value (in milliseconds) and in the same location as

KeepAliveTimeout

.

For example, to use a three-minute

KeepAliveTimeout

value, you must create the following registry keys:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings

KeepAliveTimeout DWORD value 180000 (in milliseconds)
ServerInfoTimeout DWORD value 180000 (in milliseconds)

By default, HTTP 1.1 is enabled in Internet Explorer except when you establish an HTTP connection through a proxy server. When HTTP 1.1 is enabled, HTTP connections remain open (or persistent) by default until the connection is idle for one minute or until the value that is specified by the

KeepAliveTimeout

value in the registry is reached. You can modify HTTP 1.1 settings in Internet Explorer by using the Advanced tab in the Internet Options dialog box.

How to setup user rights/permissions for Backup Exec Service Account (BESA)

Solution

SymHelp can assist in verifying permissions and the Backup Exec Exchange account.

1. The password for the Backup Exec System Logon Account (Configuration and Settings | Logon Accounts | Manage Logon Accounts or, pre-Backup Exec 2012, Network | Logon accounts) and/or the Backup Exec Service Account (BESA) (Configuration and Settings | Backup Exec Services | Edit Credentials or, pre-Backup Exec 2012, Tools | Backup Exec services | Services Credentials) need to match the password set in Active Directory.
2. Check all the basic Backup Exec permissions, this can be done with Group Policy Management Console on a domain controller or Local Security Policy on the Media server.  If the Local Policies are locked out by a Group Policy, the permissions will need to be added with the Group Policy Management Console at the domain controller.

• Act as part of the operating system  
• Backup files and directories
• Create a token object
• Log on as a batch job
• Log on as a service 
• Manage auditing and security log (BE 2010 R3 and later)
• Restore files and directories
• Take ownership of files and other objects

 Directions:

Local policy:

• On the local machine Press the Windows logo key + R to open the RUN dialogue
• Type gpedit.msc in the text box, and then click OK or press ENTER
• Browse to "\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment" and add the user to each policy listed above

Group Policy Manager:

• On the Domain controller Press the Windows logo key + R to open the RUN dialogue 
• Type gpmc.msc in the text box, and then click OK or press ENTER
• Right click and select Edit... for the group policy the machine is in.
• Browse to \Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment and add the user to each policy listed above

The Backup Exec account must have following permissions for backing up Exchange:
1. The account must be an Exchange Full Administrator (Exchange 2003), Exchange Organization Administrator (Exchange 2007), and Organization Management (Exchange 2010) at the top level of Exchange.
2. The account must be a Domain Administrator. (Recommended, ensure that Domain Admins is a member of the Local Administrator's group on the Exchange Server)
3. The account must have an active mailbox on the Exchange Server.
4. The account must have received an e-mail via the mailbox.
5. The account must have sent an e-mail via the mailbox.
6. The account must be named so that it is unique within 5 characters. (Refer to the TechNote below for steps to test this).
7. The account must be visible to the Global Address List, not hidden.
8. Make sure the default system logon account of Backup Exec and Backup Exec Service Account are the same.
How to confirm that an Exchange mailbox name is unique within the Exchange organization when configuring Backup Exec to back up Exchange mailboxes
 000025976

From Backup Exec console Click Network -> Logon Account, ensure that a System Logon Account is present.  If not create a System Logon Account by clicking the System Account button.

For assistance on this task:   http://www.symantec.com/docs/TECH85944

How to reconfigure an _msdcs subdomain to a forest-wide DNS application directory partition when you upgrade from Windows 2000 to Windows Server 2003

SUMMARY

This step-by-step article describes how to make the forest-wide locator records under the _msdcs.ForestName DNS zone available on every DNS server in the forest when you upgrade domain controllers that are running the DNS Server service from Microsoft Windows 2000 to Microsoft Windows Server 2003.

Background information

Windows 2000 behavior

When a server that is running Microsoft Windows 2000 is promoted as the first domain controller in a new Active Directory directory service forest, the Windows 2000 Active Directory Installation Wizard (Dcpromo.exe) creates a DNS forward lookup zone that is named after the first domain in the forest (ForestName), and it creates a subdomain and names it _msdcs.ForestName. For example, if your Active Directory forest name is reskit.com, the Installation Wizard creates the reskit.com DNS zone and the _msdcs.reskit.com subdomain as a child of the forest root domain zone.

The forest domain zone hosts the DNS resource records for each Active Directory domain controller in the domain. The _msdcs.ForestName subdomain hosts the domain controller locator DNS resource records for all the domain controllers in an Active Directory forest. It is also used to locate domain controllers that have specific roles in the Active Directory domain or in the Active Directory forest, and to locate a domain controller by searching for its GUID when a domain has been renamed.

Windows Server 2003 behavior

When the DNS root domain of a new Active Directory forest is created on a Windows Server 2003-based domain controller, two DNS zones are automatically created. One zone is created for the forest root domain; this zone is replicated between all domain controllers in that domain. The other zone is created for the _msdcs.ForestName subdomain; this zone is stored in the forest-wide DNS application directory partition. This partition replicates to all Windows Server 2003-based domain controllers in the forest that are running the Windows Server 2003 DNS Server service.

Upgrading domain controllers from Windows 2000 to Windows Server 2003

If you upgrade from Windows 2000 to Windows Server 2003, your DNS zone configuration is not modified, and the _msdcs.ForestName zone is stored on your Windows Server 2003-based domain controller in one of the following ways:

• Case 1: The _msdcs.ForestName zone is a subdomain of your Active Directory-integrated forest root DNS zone, and the secondary _msdcs.ForestName zones are stored in your child domains (if child domains are present).
• Case 2: The _msdcs.ForestName is a subdomain of your Active Directory-integrated forest root DNS zone.

After all the DNS servers in the forest root domain are running the Windows Server 2003 DNS Server service, configure your ForestName zone to be stored in an Active Directory-integrated domain-wide application partition. Similarly, configure your DNS records for the _msdcs.ForestName domain name to be stored in a separate _msdcs.ForestName zone that you store in an Active Directory-integrated forest-wide application partition.

Case 1: Configure the domain-wide _msdcs.ForestName zone to the forest-wide DNS application directory partition

1. In the DNS console, right-click the _msdcs.ForestName zone, and then click Properties.
2. On the General tab, note the current zone replication type, and then do one of the following:
   • If the type is not the forest-wide replication scope, click Change, and then go to step 3.
   • If the type is the forest-wide replication scope, skip this step, and then go to step 4.
3. Select the forest-wide replication scope for the zone.
4. Delete any secondary _msdcs.ForestName zones that are stored in your child domains.

Notes

• To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins security group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using the Secondary Logon service command to perform this procedure. You can access this command through the built-in Runas.exe command.
• When you change the storage of a zone from the domain partition to an application directory partition (for example, after you promote a new Windows Server 2003-based domain controller in an existing Windows 2000 domain), the domain controller that holds the domain naming master role must be running Windows Server 2003 for the DNS application directory partitions to exist. If you receive an error when you change the storage of a zone from the domain partition to an application directory partition, transfer the domain naming master role to a domain controller that is running Windows Server 2003, create the default DNS application directory partitions, and then try again.
• After the new forest-wide zone is propagated to the application partition of all the DNS servers in the forest, delete the previous secondary zone. To delete the zone, right-click the zone in the DNS console, and then click Delete.
• The zone replication type change is made one time per forest; however, you must delete the secondary zones from each DNS server individually.

Case 2: Configure the Windows 2000 _msdcs subdomain to a Windows Server 2003 zone that is stored in the forest-wide DNS application directory partition

The following steps assume that the DNS zones for the Active Directory forest root domain were created during the promotion of a Windows 2000-based domain controller, and that all domain controllers in the forest root domain that host the DNS server have been upgraded to Windows Server 2003.

The following is a summary of the procedure that you use to configure the subdomain. This procedure is described in detail after the notes.

1. Configure the primary DNS server setting in the network connections of all domain controllers in your forest with the IP address of a single root domain controller.
2. Create the _msdcs zone for the Active Directory forest name, and then store the _msdcs.ForestName zone in the DNS forest-wide application directory partition.
3. Force replication.
4. Delete the old _msdcs subdomain.
5. Return the primary DNS server setting in the network connections of all domain controllers in your forest to their previous settings.

Notes

• By default, only members of the Enterprise Admins security group can create a DNS application directory partition.
• When you change the storage of a zone from the domain partition to an application directory partition (for example, after you promote a new Windows Server 2003-based domain controller in an existing Windows 2000 domain), the domain controller that holds the domain naming master role must be running Windows Server 2003 for the DNS application directory partitions to exist. If you receive an error when you change the storage of a zone from the domain partition to an application directory partition, transfer the domain naming master role to a domain controller that is running Windows Server 2003, create the default DNS application directory partitions, and then try again.

To register the required records to the single root domain controller, restart the Net Logon service on all the domain controllers. The replication works correctly if the replication window is not less than the default DNS Time to Live (TTL) entry. To restart the Net Logon service, follow these steps:

1. Click Start, click Run, type cmd in the Open box, and then press ENTER.
2. At the command prompt, type the following command, and then press ENTER:
   net stop netlogon
3. Type net start netlogon, and then press ENTER.

If your _msdcs subdomain is still not populated, or if the TTL is smaller than the replication window, follow these steps to configure the _msdcs subdomain to a zone that is stored in the forest-wide DNS application partition:

1. On all the domain controllers in the forest, modify the network connection configuration on all domain controllers to point to a single DNS Server:
   1. Click Start, click Control Panel, click Network and Internet Connections, and then click Network Connections.
   2. Right-click the network connection that you want to configure, and then click Properties.
   3. On the General tab (for a local area connection), click Internet Protocol (TCP/IP), and then click Properties.
   4. Confirm that Use the following DNS server addresses is enabled.
   5. Make a note of the existing IP address that appears in the Preferred DNS server box. (You will need this address in a later step in this procedure.)
   6. In the Preferred DNS server box, type the IP address of a single root domain controller that is running the DNS Server service.
   7. Click OK.
   Note For large deployments, you may want to create a script to configure the IP address of a single root domain controller as the Preferred DNS server setting on all the domain controllers.
   
   Important You must use the same IP address of a single root domain controller for all domain controllers in the forest. The purpose of this configuration is to make sure that all domain controllers in the forest register their DNS resource records in copies of the same _msdcs.ForestName zone.
2. Log on to the Windows Server 2003-based root domain controller by using an account that is a member of the Enterprise Admins security group.
3. Verify that a Windows Server 2003-based domain controller holds the domain naming master role.
4. Verify that all DNS servers that currently host the _msdcs.ForestName subdomain in primary zones are running Windows Server 2003.
5. Start the DNS console. To do this, click Start, click Run, type dnsmgmt.msc, and then click OK.
6. In the DNS console, right-click Forward Lookup Zones, and then click New Zone. Click Next
7. On the Zone Type page in the New Zone Wizard, click Primary zone, and then click to select the Store the zone in Active Directory check box. Click Next
8. On the Active Directory Zone Replication Scope page, click To all DNS servers in the Active Directory forest ForestName.
9. On the Zone Name page, in the Zone Name box, type _msdcs.ForestName.
10. Complete the wizard by accepting all the default options.
    
    The zone is created, and the Net Logon service populates the zone with the _msdcs.ForestName resource records for the local domain controller.
11. The zone will now replicate to all other DNS servers in the replication scope by using the replication schedules and paths that are configured in the forest, or you can force replication. To force replication, use Active Directory Sites and Services, or use the Repadmin.exe tool:
    • To use Active Directory Sites and Services:
      1. Open Active Directory Sites and Services.
      2. In the console tree, click NTDS Settings for the server that you want to force replication from.
      3. In the details pane, right-click the connection that you want to replicate directory information over, and then click Replicate Now.
    • To use the Repadmin.exe tool:
      1. With the Support Tools installed, open a command prompt.
      2. At the command prompt, type the following, and then press ENTER:
         repadmin /syncall
         This will synchronize all the directory partitions.
12. Delete the old _msdcs subdomain from the zone where it was created before you upgraded. To do this:
    1. Open the DNS console.
    2. In the console tree, expand the zone that contains the _msdcs subdomain.
    3. Right-click the _msdcs subdomain folder, and then click Delete.
    Note This step is not mandatory because the DNS Server service will use the new _msdcs zone to answer any queries for names that start with _msdcs. Microsoft recommends that you delete the old _msdcs subdomain to maintain a more orderly DNS database.
13. After replication is confirmed for all the domain controllers in the forest, perform the following network connection configuration on all the domain controllers in the forest:
    1. Click Start, click Control Panel, click Network and Internet Connections, and then click Network Connections.
    2. Right-click the network connection that you want to configure, and then click Properties.
    3. On the General tab (for a local area connection), click Internet Protocol (TCP/IP), and then click Properties.
    4. Confirm that Use the following DNS server addresses is selected, and in the Preferred DNS server box, type the IP address that was used previously (that is, the one that you noted in step 1e).
    5. Click OK.

Note In Windows Server 2003 SP1, when you create a new forward lookup zone that is already under an existing zone, the wizard automatically creates a new delegation under the existing zone.

DNS: Domain subfolders missing from forward lookup zone

SYMPTOMS

When you open the forward lookup zone in the Domain Name System (DNS) Microsoft Management Console (MMC) snap-in, the following subdomains may be missing:

• _msdcs
• _sites
• _tcp
• _udp

This problem may occur if the zone is either Active Directory-Integrated or Standard Primary. Additionally, the forward lookup zone is being used to store SRV records for Active Directory.

When this problem occurs, the following event is logged:

Type: Warning
Event: 5782
Source: NETLOGON
Category: None
Computer: ComputerName
Event Msg: Dynamic registration or deregistration of one or more DNS records failed with the following error: No DNS servers configured for local system
Data: 7C 26 00 00

CAUSE

On a multi-homed server, DNS dynamic update protocol registration may have been turned off (disabled) on the internal network adapter. The same problem occurs on a server that has a single network adapter and DNS dynamic update protocol turned off.

RESOLUTION

To turn on DNS dynamic update protocol on the affected network adapter, follow these steps:

1. On the desktop, right-click My Network Places, and then click Properties.
2. Right-click the internal network adapter, and then click Properties.
3. Click TCP/IP, and then click Properties.
4. Click the Advanced button.
5. Click the DNS tab, and then click to select the Register this connection's addresses in DNS check box at the bottom of the tab.
6. Click OK until the Network Properties dialog box is closed.
7. Click Start, click Run, type cmd, and then press ENTER.
8. At a command prompt, stop and restart the Netlogon service and initiate the registration of the network adapter in DNS. To do this, use the following command-line statements:
   • net stop netlogon
   • net start netlogon
   • ipconfig /registerdns

If the previous steps do not resolve this problem, you may have to remove DNS and reinstall it. To remove DNS, follow these steps:

1. Right-click My Network Places, and then click Properties.
2. In the Network and Dial-Up Connections window on the Advanced menu, click Optional Networking Components.
3. In the Windows Optional Networking Components Wizard, click to select Networking Services, and then click Details.
4. In the Networking Services window, click to clear the box next to Domain Name System (DNS) check box, click OK, and then click Next. This removes DNS.

Before you reinstall DNS, delete the following files:

• Cache.dns-which is located in %systemroot%\Winnt\System32\DNS
• Netlogon.dns-which is located in %systemroot%\Winnt\System32\Config
• Netlogon.dnb-which is located in %systemroot%\Winnt\System32\Config

To reinstall DNS, follow these steps:

1. Right-click My Network Places, and then click Properties.
2. In the Network and Dial-Up Connections window on the Advanced menu click Optional Networking Components.
3. In the Windows Optional Networking Components Wizard, click to select the Networking Services check box, and then click Details.
4. In the Networking Services dialog box, click to select the Domain Name System (DNS) check box, click OK, and then click Next.
5. Insert the operating system installation disc when you are prompted, click OK, and DNS is reinstalled.
6. Restart the computer.

To reconfigure the DNS server and re-create the Forward and Reverse Lookup Zones, see the articles listed in the "More Information" section.

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

MORE INFORMATION

Other possible causes of this problem are the following:

• The value for Load zone data on startup on the Advanced tab in the DNS server properties is set to From registry instead of From Active Directory and registry. To resolve this problem, reset the value, and then restart the server.
• The value of the following registry subkey is 0:
  HKEY_LOCAL_MACHINE\CurrentControlSet\Services\Netlogon\Parameters\UseDynamicUpdates
• The filter display limit for the zone is smaller than the number of records in the zone. To resolve this problem, follow these steps:
  1. Click Start, click Run, type dnsmgmt.msc in the Open box, and then click OK.
  2. In the Dnsmgmt dialog box, expand ServerName, and then expand Forward Lookup Zones.
  3. Click the zone, click the View menu, and then click Filter.
  4. Click the Display Limit tab.
  5. Set the display limit to a number that is larger than the number of records in your zone.
• The forward lookup zone was created by using the wrong name or was accidentally deleted. To re-create the zone, follow these steps:
  1. Make sure that the internal network adapter (and external network adapter if there is one) point to the server IP for DNS resolution in the TCP/IP Properties dialog box.
  2. In the DNS MMC, right-click the server object, and then click New Zone. The New Zone Wizard starts. Under Zone Type, click Active Directory Integrated. On the next page, click Forward Lookup Zone, and then type a domain name (for example, domain.com).
  3. Expand the Forward Lookup Zones folder, right-click the zone, and then click Properties.
  4. On the General tab, make sure that Only secure updates is selected in the Allow Updates? list (this is the default setting). Click OK, and then close the DNS MMC.
  5. At a command prompt, restart the Netlogon service by using the following command line:
     • net stop netlogon
     • net start netlogon
     • ipconfig /registerdns
  Verify that the zone file now has the following subdomains:
  • _msdcs
  • _sites
  • _tcp
  • _udp

Verifying Your Basic DNS Configuration

If you use a third-party DNS server to support Active Directory, you must perform configuration tasks manually, and doing so, you might cause common configuration errors that prevent DNS and Active Directory from working properly. The following sections describe tests that you can perform to verify that your DNS server is working properly, that the forward and reverse lookup zones are properly configured, and that DNS can support Active Directory.
If you use either the Configure DNS Server wizard or the Active Directory Installation wizard to install your Windows 2000 DNS server, most configuration tasks are performed automatically and you can avoid many common configuration errors, but you might still want to perform the tests in this section.
Before checking anything else, check the event log for errors. For more information about Event Viewer, see "Troubleshooting Tools" earlier in this chapter.

Verifying That Your DNS Server Can Answer Queries

Use the following process to verify that your DNS server is started and can answer queries.

• Make sure that your server has basic network connectivity. For more information about verifying basic network connectivity, see "Checking the DNS Server for Problems" later in this chapter.
  
• Make sure that the server can answer both simple and recursive queries from the Monitoring tab in the DNS console. For more information about the Monitoring tab, see "Troubleshooting Tools" earlier in this chapter.
  
• From a client, use Nslookup to look up a domain name and the name of a host in the domain. For more information about using Nslookup, see "Troubleshooting Tools" earlier in this chapter.
  
• On the server, run netdiag to make sure the server is working properly and that the resource records Netlogon needs are registered on a DNS server. For more information about Netdiag, see "Troubleshooting Tools" earlier in this chapter.
  
• Make sure that the server can reach a root server by typing the following:
  nslookup
  server < IP address of server >
  set querytype=NS
  .
  
• Make sure that there is an A and PTR resource record configured for the server. For information about PTR resource records, see "Testing for Reverse Lookup Zones and PTR Records" later in this chapter.
  

------------

Verifying That the Forward Lookup Zone Is Properly Configured

After you create a forward lookup zone, you can use Nslookup to make sure it is properly configured and to test its integrity to host Active Directory. To start Nslookup, type the following
Nslookup server < IP address of server on which you created zone > set querytype=any
Nslookup starts. If the resolver cannot locate a PTR resource record for the server, you see an error message, but you are still able to perform the tests in this section.
To verify the zone is responding correctly, simulate a zone transfer by typing the following:
ls -d < domain name >
If the server is configured to restrict zone transfers, you might see an error message in Event Viewer. (For more information about Event Viewer, see "Troubleshooting Tools" earlier in this chapter.) Otherwise, you see a list of all the records in the domain.
Next, query for the SOA record by typing the following and pressing ENTER:
< domain name >
If your server is configured correctly, you see an SOA record. The SOA record includes a "primary name server" field. To verify that the primary name server has registered an NS record, type the following:
set type=ns < domain name >
If your server is configured correctly, you see an NS record for the name server.
Make sure that the authoritative name server listed in the NS record can be contacted to request queries by typing the following:
server
Next, query the server for any name for which it is authoritative.
If these tests are successful, the NS record points to the correct hostname, and the hostname has the correct IP address associated with it.

-------------

Testing for Reverse Lookup Zones and PTR Resource Records

You do not need reverse lookup zones and PTR resource records for Active Directory to function. However, you need them if you want clients to be able to resolve FQDNs from IP addresses. Also, PTR resource records are commonly used by some applications for security purposes, to verify the identity of the client.
You do not need to have the reverse lookup zones and PTR resource records on your own servers; instead, another DNS server can contain these zones.
After you have configured your reverse lookup zones and PTR resource records, manually examine them in the DNS console. A reverse lookup zone must exist for each subnet, and the parent reverse lookup zone must have a delegation to your reverse lookup zone. For example, if you have a private root and the subnets 172.32.16.x and 172.32.17.x, the private root can host all reverse lookup zones, or it can contain the reverse lookup zone 172.32.x and delegate the reverse lookup zones 172.32.16.x and 172.32.17.x to other servers. Also, PTR resource records must exist for all the computers in your network. For more information about adding a reverse lookup zone, see "Adding a Reverse Lookup Zone" earlier in this chapter.
You can also use Nslookup to verify that the reverse lookup zones and PTR resource records are configured correctly.
To make sure your reverse lookup zones and PTR resource records are configured correctly

1. Start Nslookup by typing Nslookup at the command prompt and then pressing ENTER.
   
2. Switch to the server you want to query by typing the following:
   server < Server IP Address >
   
3. Enter the IP address of the computer whose PTR resource record you want to verify, and then press ENTER.
   If the reverse lookup zone and PTR resource record are configured correctly, Nslookup returns the name of the computer.
   
4. To quit Nslookup, type exit and then press ENTER.
   

-------------

Verifying Your DNS Configuration After Installing Active Directory

When you use third-party DNS servers to support Active Directory, you can verify the registration of domain controller locator resource records. If the server does not support dynamic update, you need to add these records manually.
The Netlogon service creates a log file that contains all the locator resource records and places the log file in the following location:
% SystemRoot %\System32\Config\Netlogon.dns
You can check this file to find out which locator resource records are created for the domain controller.
The locator resource records are stored in a text file, compliant with RFC specifications. If your server is configured correctly, you see the LDAP SRV record for the domain controller:
_ldap._tcp. IN SRV < priority > < weight > 389 < domain controller name >
For example:
_ldap._tcp.reskit.com. IN SRV 0 0 389 dc1.reskit.com
Next, use the Nslookup command-line tool to verify that the domain controller registered the SRV resource records that were listed in Netlogon.dns.
Note
During the following test, if you have not configured a reverse lookup zone and PTR resource record for the DNS server you are querying, you might see several time-outs. This is not a problem.
To verify that SRV resource records are registered for the domain controller

1. At the command prompt, type nslookup and then press ENTER.
   
2. To set the DNS query type to filter for SRV records only, type set type=SRV and then press ENTER.
   
3. To send a query for the registered SRV record for a domain controller in your Active Directory domain, type _ ldap._tcp. < Active Directory domain name > and then press ENTER.
   
4. You should see the SRV records listed in Netlogon.dns. If you do not, SRV resource records might not be registered for the domain controller.
   

The following example shows a full Nslookup session, used to verify SRV resource records that are registered for locating two domain controllers on a network. In this example, the two domain controllers (DC1 and DC2) are registered for the domain noam.reskit.com.

C:\>nslookup
Default Server: dc1.noam.reskit.com
Address: 10.0.0.14
> set type=SRV
> _ldap._tcp.noam.reskit.com
Server: dc1.noam.reskit.com
Address: 10.0.0.14
_ldap._tcp.noam.reskit.com SRV service location:
priority = 0
weight = 0
port = 389
svr hostname = dc1.noam.reskit.com
_ldap._tcp.noam.reskit.com SRV service location:
priority = 0
weight = 0
port = 389
svr hostname = dc2.noam.reskit.com
dc1.noam.reskit.com internet address = 10.0.0.14

dc2.noam.reskit.com internet address = 10.0.0.15

DHCP: The server should be configured to register DNS records on behalf of DHCPv4 clients

Applies To: Windows Server 2008 R2, Windows Server 2012

This topic is intended to address a specific issue identified by a Best Practices Analyzer scan. You should apply the information in this topic only to computers that have had the Dynamic Host Configuration Protocol Best Practices Analyzer run against them and are experiencing the issue addressed by this topic. For more information about best practices and scans, see Best Practices Analyzer (http://go.microsoft.com/fwlink/?LinkId=122786).

 

Operating System	Windows Server 2008 R2, Windows Server 2012
Product/Feature	Dynamic Host Configuration Protocol (DHCP)
Severity	Warning
Category	Configuration

Issue

DNS registrations of IPv4 client computers from the DHCP server have been disabled.

Impact

The DHCP server will not register DHCPv4 client names in DNS resulting in the inability to connect to these client computers using hostnames unless the client computers are themselves registering DNS records..

Resolution

Configure client computers to register with DNS or use the DHCP MMC configure dynamic DNS update on the DHCP server for DHCPv4.

Domain Name System (DNS) client computers can use dynamic update to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations and use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address.
Membership in Administrators, or equivalent, is the minimum required to complete this procedure

To configure DHCP clients to register with DNS

1. At the DHCP client computer, Click Start, click Run, in Search programs and files type ncpa.cpl, and then press ENTER.
   
2. Right-click the applicable network connection, click Properties, click Internet Protocol Version 4 (TCP/IPv4) and then click Properties.
   
3. Click Advanced, click DNS, check Register this connection’s addresses in DNS and then click OK.
   

Membership in the Administrators or DHCP Administrators group is the minimum required to complete this procedure.

To enable dynamic DNS updates

1. At the DHCP Server, click Start, point to Administrative Tools and then click DHCP.
   
2. In the console tree, expand the applicable DHCP server, expand IPv4, right-click the applicable scope and then click Properties.
   
3. Click DNS, check Enable DNS dynamic updates according to the settings below: and then click OK.
   

Additional references

For updated detailed IT pro information about DHCP, see the Windows Server 2008 R2 documentation on the Microsoft TechNet Web site.