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.

Deploy Windows Offloaded Data Transfers

Applies To: Windows Server 2012 R2, Windows Server 2012

Prerequisites

To use ODX, your environment must meet the following hardware and software requirements.

Hardware requirements

To use ODX, your storage arrays must meet the following requirements:

• Be certified as compatible with Windows Offloaded Data Transfer (ODX) on Windows Server 2012
• Support cross-storage array ODX. To support ODX between storage arrays, the copy manager for the storage arrays must support cross-storage array ODX, and the storage arrays must be from the same vendor
• Be connected by using one of the following protocols:
  
  • iSCSI
  • Fibre Channel
  • Fibre Channel over Ethernet
  • Serial Attached SCSI (SAS)
• Use one of the following configurations:
  
  • One server with one storage array
  • One server with two storage arrays
  • Two servers with one storage array
  • Two servers with two storage arrays

Software requirements

To use ODX, your environment must support the following:

• The computer initiating the data transfer must be running Windows Server 2012 R2, Windows Server 2012, Windows 8.1, or Windows 8.
• File system filter drivers such as antivirus and encryption programs need to opt-in to ODX. ODX is not supported by the following file system filter drivers:
  
  • Data Deduplication
  • BitLocker Drive Encryption
• Files must be on an unencrypted basic partition. Storage Spaces and dynamic volumes are not supported.
• Files must be on a volume that is formatted by using NTFS. ReFS and FAT are not supported. Files can be directly transferred to or from this volume, or from one of the following containers:
  
  • A virtual hard disk (VHD) that uses the .vhd or .vhdx format
  • A file share that uses the SMB protocol
• The files must be 256 KB or larger. Smaller files are transferred by using a traditional (non-ODX) file transfer operation.
• The application that performs the data transfer must be written to support ODX. The following currently support ODX:
  
  • Hyper-V management operations that transfer large amounts of data at one time, such as creating a fixed size VHD, merging a snapshot, or converting VHDs.
  • File Explorer
  • Copy commands in Windows PowerShell
  • Copy commands in the Windows command prompt (including Robocopy)
• Files should not be highly fragmented. Transfers of highly fragmented files will have reduced performance.

Hyper-V Requirements

To use ODX with virtual machines on a server running Hyper-V, the virtual machines need to access storage from an ODX-capable storage array. You can achieve this by using any of the following approaches.

• Store the VHD on an ODX-capable iSCSI LUN.
• Assign ODX-capable iSCSI LUNs to the virtual machine's iSCSI initiator.
• Assign ODX-capable Fibre Channel LUNs to the virtual machine's virtual Fibre Channel adapter.
• Connect the host or virtual machine to an SMB file share on another computer that is hosted on an ODX-capable storage array.

Step 1: Gather storage array information

Before deploying ODX, gather the following information about the copy manager (operating system) of the storage array:

• What is the name and version of the copy manager?
• Does the copy manager support ODX?
• Does the copy manager support an ODX operation across multiple storage arrays from the same vendor?
• What is the default inactive timer value? This specifies how long the copy manager waits to invalidate the idle token after the timer expiration.
• What is the maximum token capacity of the copy manager?
• What is the optimal transfer size? This tells Windows how to send Read and Write commands that are optimally sized for the storage array.

Step 2: Validate file system filter drivers

To use ODX, validate all the file system filter drivers on all servers that are hosting the storage support ODX.
To validate the opt-in status of file system filter drivers, use the following procedure:

To validate file system filter driver opt-in status

1. On each server on which you want to use ODX, list all of the file system filter drivers that are attached to the volume on which you want to enable ODX. To do so, open a Windows PowerShell session as an administrator, and then type the following command, where is the drive letter of the volume:
   

   Fltmc instances -v 
   

2. For each filter driver listed, query the registry to determine whether the filter driver has opted-in to ODX support. To do so, type the following command for each filter previously listed, and replace with the name of the filter.
   

   Get-ItemProperty hklm:\system\currentcontrolset\services\ -Name "SupportedFeatures"
   

3. If the SupportedFeatures registry value equals 3, the filter driver supports ODX. If the value is not 3, contact the file system filter driver vendor for an ODX-compatible version.

Step 3: Establish a performance baseline

To establish a performance baseline, use the following procedures to disable ODX on the server and create a System Performance Report during a representative data transfer.

Disable ODX

To establish a baseline of non-offloaded data transfer performance, first disable ODX on the server by following these steps:

To disable ODX on the server

1. Open a Windows PowerShell session as an administrator.
2. Check whether ODX is currently enabled (it is by default) by verifying that the FilterSupportedFeaturesMode value in the registry equals 0. To do so, type the following command:
   

   Get-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode"
   

3. Disable ODX support. To do so, type the following command:
   

   Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" -Value 1
   

Create a System Performance Report during a data transfer

To record the baseline performance of data transfers, use Performance Monitor to record system performance during a represenative data transfer. To do so, follow these steps:

To create a System Performance Report

1. In Server Manager, on the Tools menu, click Performance Monitor.
2. Initiate a large data transfer that is representative of the workload you want to accelerate and that is within or between the storage arrays that support ODX.
3. Start the System Performance data collector set. To do so, expand Data Collector Sets, expand System, right-click System Performance, and then click Start. Performance Monitor will collect data for 60 seconds.
4. Expand Reports, expand System, expand System Performance, and then click the most recent report.
5. Review the System Performance Report, and take note of the following counters:
   

   • CPU Utilization (in the Resource Overview section)
   • Network Utilization (in the Resource Overview section)
   • Disk Bytes/sec (in the Disk section, under Physical Disk)

Step 4: Test ODX performance

After you establish a baseline of system performance during traditional data transfers, use the following procedures to enable ODX on the server and test offloaded data transfers:

Enable ODX

To enable ODX on the server, follow these steps:

To enable ODX

1. Open a Windows PowerShell session as an administrator.
2. Type the following command:
   

   Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" -Value 0
   

Verify ODX performance

After ODX is enabled, create a System Performance Report during a large offloaded data transfer (see the Create a System Performance Report during a data transfer section earlier in this topic for the procedure).
When you evaluate the performance of offloaded data transfers, you should see the following differences from the baseline that you created when ODX was disabled:

• CPU utilization should be much lower (only slightly higher than prior to the data transfer). This shows that the server did not need to manage the data transfer.
• Network utilization should be much lower (only slightly higher than prior to the data transfer). This shows that the data transfer bypassed the server.
• Disk Bytes/sec should be much higher. This reflects increased performance from direct transfers within an array or within the SAN.

After you verify ODX performance, periodically create another System Performance Report during offloaded data transfers to confirm that ODX is still operating as expected. If any performance degradation is detected, contact Microsoft Customer Support and the storage array vendor.

Tip
You can use the following command in a Windows PowerShell session to display a list of storage subsystems that support ODX and use a storage management provider. This command does not display storage subsystems that use the Storage Management Initiative Specification (SMI-S) protocol. Get-OffloadDataTransferSetting | Get-StorageSubSystem

Appendix: Deployment checklist

Use the following checklist to confirm that you completed all the steps for the deployment.

	Deploying Windows Offloaded Data Transfers Checklist
	Check the Windows Offloaded Data Transfers prerequisites.
	Gather storage array information.
	Validate the file system filter drivers.
	Establish a performance baseline.
	Test the ODX performance.

SQL : The transaction manager has disabled its support for remote/network transactions

Solution:

Make sure that the "Distribute Transaction Coordinator" Service is running on both database and client. Also make sure you check "Network DTC Access", "Allow Remote Client", "Allow Inbound/Outbound" and "Enable TIP".
To enable Network DTC Access for MS DTC transactions

1. Open the Component Services snap-in.
   To open Component Services, click Start. In the search box, type dcomcnfg, and then press ENTER.
2. Expand the console tree to locate the DTC (for example, Local DTC) for which you want to enable Network MS DTC Access.
3. On the Action menu, click Properties.
4. Click the Security tab and make the following changes: In Security Settings, select the Network DTC Access check box.
   In Transaction Manager Communication, select the Allow Inbound and Allow Outbound check boxes.

Installing and Configuring MPIO

This section explains how to install and configure Microsoft Multipath I/O (MPIO) on Windows Server 2008 R2.

Install MPIO on Windows Server 2008 R2

MPIO is an optional feature in Windows Server 2008 R2, and is not installed by default. To install MPIO on your server running Windows Server 2008 R2, perform the following steps.

To add MPIO on a server running Windows Server 2008 R2

1. Open Server Manager. To open Server Manager, click Start, point to Administrative Tools, and then click Server Manager.
   
2. In the Server Manager tree, click Features.
   
3. In the Features area, click Add Features.
   
4. In the Add Features Wizard, on the Select Features page, select the Multipath I/O check box, and then click Next.
   
5. On the Confirm Installation Selections page, click Install.
   
6. When the installation has completed, on the Installation Results page, click Close. When prompted to restart the computer, click Yes.
   
7. After restarting the computer, the computer finalizes the MPIO installation.
   
8. Click Close.
   

MPIO configuration and DSM installation

When MPIO is installed, the Microsoft device-specific module (DSM) is also installed, as well as an MPIO control panel. The control panel can be used to do the following:

• Configure MPIO functionality
  
• Install additional storage DSMs
  
• Create MPIO configuration reports
  

Open the MPIO control panel

Open the MPIO control panel either by using the Windows Server 2008 R2 Control Panel or by using Administrative Tools.

To open the MPIO control panel by using the Windows Server 2008 R2 Control Panel

1. On the Windows Server 2008 R2 desktop, click Start, click Control Panel, and then in the Views list, click Large Icons.
   
2. Click MPIO.
   
3. On the User Account Control page, click Continue.
   

To open the MPIO control panel by using Administrative Tools

1. On the Windows Server 2008 R2 desktop, click Start, point to Administrative Tools, and then click MPIO.
   
2. On the User Account Control page, click Continue.
   

The MPIO control panel opens to the Properties dialog box.

Note
To access the MPIO control panel on Server Core installations, open a command prompt and type MPIOCPL.EXE.

MPIO Properties dialog box

The MPIO Properties dialog box has four tabs:

• MPIO Devices   By default, this tab is selected. This tab displays the hardware IDs of the devices that are managed by MPIO whenever they are present. It is based on a hardware ID (for example, a vendor plus product string) that matches an ID that is maintained by MPIO in the MPIOSupportedDeviceList, which every DSM specifies in its Information File (INF) at the time of installation.
  
  To specify another MPIO device, on the MPIO Devices tab, click Add.
  
  

  Note

  In the Add MPIO Support dialog box, the vendor ID (VID) and product ID (PID) that are needed are provided by the storage provider, and are specific to each type of hardware. You can list the VID and PID for storage that are already connected to the server by using the mpclaim tool at the command prompt. The hardware ID is an 8-character VID plus a 16-character PID. This combination is sometimes referred to as a VID/PID. For more information about the mpclaim tool, see Referencing MPCLAIM Examples.

• Discover Multi-Paths   Use this tab to run an algorithm for every device instance that is present on the system and determine if multiple instances actually represent the same Logical Unit Number (LUN) through different paths. For such devices found, their hardware IDs are presented to the administrator for use with MPIO (which includes Microsoft DSM support). You can also use this tab to add Device IDs for Fibre Channel devices that use the Microsoft DSM.
  
  

  Note
  Devices that are connected by using Microsoft Internet SCSI (iSCSI) are not displayed on the Discover Multi-Paths tab.

• DSM Install   This tab can be used for installing DSMs that are provided by the storage independent hardware vendor (IHV).
  
  Many storage arrays that are SPC-3 compliant will work by using the MPIO Microsoft DSM. Some storage array partners also provide their own DSMs to use with the MPIO architecture.
  
  

  Note
  We recommend using vendor installation software to install the vendor’s DSM. If the vendor does not have a DSM setup tool, you can alternatively install the vendor’s DSM by using the DSM Install tab on the MPIO control panel.

• Configuration Snapshot   This tab allows you to save the current Microsoft Multipath I/O (MPIO) configuration to a text file that you can review for troubleshooting or comparison purposes at a later time.
  
  The report includes information on the device-specific module (DSM) that is being used, the number of paths, and the path state.
  
  You can also save this configuration at a command prompt by using the mpclaim command. For information about how to use mpclaim, in an elevated command prompt, type run mpcliam /?. For more information, see Referencing MPCLAIM Examples.
  

Claim iSCSI-attached devices for use with MPIO

Note
This process causes the Microsoft DSM to claim all iSCSI-attached devices regardless of their vendor ID and product ID settings. For information about how to control this behavior on an individual VID/PID basis, see Referencing MPCLAIM Examples.

To claim an iSCSI-attached device for use with MPIO

1. Open the MPIO control panel, and then click the Discover Multi-Paths tab.
   
2. Select the Add support for iSCSI devices check box, and then click Add. When prompted to restart the computer, click Yes.
   
3. When the computer restarts, the MPIO Devices tab lists the additional hardware ID “MSFT2005iSCSIBusType_0x9.” When this hardware ID is listed, all iSCSI bus attached devices will be claimed by the Microsoft DSM.
   

Configure the load-balancing policy setting for a Logical Unit Number (LUN)

MPIO LUN load balancing is integrated with Disk Management. To configure MPIO LUN load balancing, open the Disk Management graphical user interface.

Note
Before you can configure the load-balancing policy setting by using Disk Management, the device must first be claimed by MPIO. If you need to preselect a policy setting for disks that are not yet present, see Referencing MPCLAIM Examples.

To configure the load-balancing policy setting for a LUN

1. Open Disk Management. To open Disk Management, on the Windows desktop, click Start; in the Start Search field, type diskmgmt.msc; and then, in the Programs list, click diskmgmt.
   
2. Right-click the disk for which you want to change the policy setting, and then click Properties.
   
3. On the MPIO tab, in the Select the MPIO policy list, click the load-balancing policy setting that you want.
   
4. If desired, click Details to view additional information about the currently configured DSM.
   

   Note
   When using a DSM other than a Microsoft DSM, the DSM vendor may use a separate interface to manage these policies.

   
   

   Note
   For information about DSM timer counters, see Configuring MPIO Timers.

   
   

Configure the MPIO Failback policy setting

If you use the Failover Only load-balancing policy setting, MPIO failback allows the configuration of a preferred I/O path to the storage, and allows automatic failback to be the preferred path if desired.
Consider the following scenario:

• The computer that is running Windows Server 2008 R2 is configured by using MPIO and has two connections to storage, Path A and Path B.
  
• Path A is configured as the active/optimized path, and is set as the preferred path.
  
• Path B is configured as a standby path.
  

If Path A fails, Path B is used. If Path A recovers thereafter, Path A becomes the active path again, and Path B is set to standby again.

To configure the preferred path setting

1. Open Disk Management. To open Disk Management, on the Windows desktop, click Start; in the Start Search field, type diskmgmt.msc; and then, in the Programs list, click diskmgmt.
   
2. Right-click the disk for which you want to change the policy setting, and then click Properties.
   
3. On the MPIO tab, double-click the path that you want to designate as a preferred path.
   

   Note
   The setting only works with the Failover Only MPIO policy setting.

   
   
4. Select the Preferred check box, and then click OK.
   

Install MPIO on Server Core installations of Windows Server 2008 R2

Because the Server Core installation of Windows Server 2008 R2 does not include the Server Manager interface, you must install MPIO by using a command prompt. Until you enable MPIO by using the DISM tool, you cannot use the mpclaim command.
Open a command prompt to run the following commands. After typing a command, press ENTER.

 

Task	Command
Determine which features are currently installed	Dism /online /get-features
Enable MPIO	Dism /online /enable-feature:MultipathIo Important When using DISM to enable or disable features, the feature name is case-sensitive.
Disable MPIO	Dism /online /disable-feature:MultipathIo
Manage the MPIO configuration after MPIO is enabled	mpclaim
Access the MPIO control panel (new in Windows Server 2008 R2)	MPIOCPL.exe

To enable Windows PowerShell™ on a Server Core installation, you must enable the following features by using these commands at an administrator command prompt:
dism /online /enable-feature:NetFx2-ServerCore
dism /online /enable-feature:NetFx2-W0W64_
dism /online /enable-feature:MicrosoftWindowsPowerShell_
dism /online /enable-feature:MicrosoftWindowsPowerShell-W0W64