Concepts of the Tool

 

Incorrect delegation

 

System Administrators use DNS delegations to assign the authority for a DNS sub domain to a set of DNS servers. These delegations help administrators implement a DNS infrastructure that is scalable, flexible, and easy to administer.

 

Incorrect delegation is a common problem with DNS structures. This can occur when the authority for a DNS subdomain has been delegated to a particular DNS server that either does not exist, or does not have authority over the subdomain.

 

Incorrect delegation problems are compounded when other DNS issues are present in a DNS infrastructure. For example, if DNS domain information is not identical on all authoritative DNS servers, data returned from the servers may differ, leading to intermittent name resolution difficulties. In another scenario, if a Mail Exchange (MX) record exists but the corresponding glue record is missing, then e-mail delivery to that domain may be erratic.

 

Prior to the development of DNSLint, the nslookup utility was frequently used to diagnose and troubleshoot these types of DNS issues. Nslookup allows users to manually traverse a DNS infrastructure, inspecting the various DNS records. However, DNSLint offers quicker verification that record-level data is correct.

 

For more information about DNS, see DNS or Concepts in Microsoft Management Console Help.

 

For more information about troubleshooting DNS, see the chapter Troubleshooting DNS in the Networking Guide of the Windows Server 2003 Resource Kit.

 

Common Active Directory DNS Problems

 

Verifying a particular set of DNS records on multiple DNS servers can help diagnose and fix problems caused by missing or incorrect DNS records.

 

For example, when clients are experiencing problems logging on to the domain, verifying that the SRV records that clients use to find LDAP and Kerberos servers are available and accurate, can help determine if DNS is a cause of the problem.

 

Another scenario example is where you receive reports that customers are having problems accessing your Web site on the Internet. It would be nice to have a tool that quickly checks all the DNS records that are involved with the Web farm on all of the DNS servers that are supposed to have these records. You could quickly determine if there are missing or incorrect DNS records that may be related to the problem.

 

In a third example, you could be experiencing problems with e-mail delivery. You can send e-mail, but you are not receiving e-mail. Name resolution could be the problem? To confirm this theory or eliminate it as a possibility, you need to check all of the DNS records on all of the DNS servers that are used to resolve the IP address of the e-mail server.

 

System Requirements

 

DNSLint runs on a source computer and acts on a target computer. The target computer can be the same computer as the source computer, or it can be a different computer.

 

Source Computer Requirements

 

• Windows 2000, Windows XP, or Windows Server 2003

   

Target Computer Requirements

 

• The target computer's domain must be registered with an accredited domain registrar, or running DNS in a private namespace.

   

 

Sample Usage

 

dnslint /d fourthcoffee.com

 

dnslint /ad /s 10.193.36.201

 

dnslint /ql my_dns_list.txt

 

dnslint /ql autocreate

 

dnslint /v /d fourthcoffee.com

 

dnslint /r newfile /d fourthcoffee.com

 

dnslint /y /d fourthcoffee.com

 

dnslint /no_open /d fourthcoffee.com

 

dnslint /s 10.193.36.201 /d labs.fourthcoffee.com

 

Download here from source…

 

The Domain Name System (DNS) is an Internet standard for mapping Internet computer names (called “host names”) to numerical Internet Protocol addresses (called “IP addresses”). The DNS server contains a database of all of the host names for a domain.

 

 

Active Directory uses DNS to locate the domain controllers in a domain.

 

 

Note: Incorrect configuration of DNS is the #1 cause of problems with Active Directory. If DNS is configured incorrectly, domain controllers will not be able to locate each other for replication. Client computers will not find their domain controller(s), and users will not be able to log on.

UMove moves all DNS settings

 

Because DNS is critical for Active Directory, UMove is careful to move all DNS settings from the source computer to the destination computer. This includes the following:

 

 

• Client DNS settings

   

• Server DNS settings

   

• Server DNS zone data files (Windowssystem32dns*)

   

• Hosts and lmhosts text files (Windowssystem32driversetc*)

   

By moving all DNS settings, UMove prevents potential DNS errors due to differences in the DNS settings between the old and new computers.

 

 

Types of moves

 

When doing an emergency move or a planned move, the DNS settings will carry over transparently to the new computer. The only issue is re-registering dynamic DNS records written more than 7 days ago (see below).

 

 

When doing a test move, you need to consider additional issues (see below).

 

 

Troubleshooting DNS Problems

 

Use the console commands ping and nslookup to test connectivity with DNS. To avoid confusion due to negative caching by the DNS Client service, you may want to temporarily turn that service off while troubleshooting DNS. (Exception: If your server depends on DHCP you must leave the DNS Client service turned on.)

 

 

netlogon.dns

 

To assist you in troubleshooting DNS problems, upon each boot the domain controller will write a copy of its desired DNS records to a text file. The text file is named C:WindowsSystem32confignetlogon.dns. You can inspect this file (use NOTEPAD.EXE) in order to verify that your DNS server contains the correct A, PTR, and SRV records for the domain controller.

 

 

If your DNS server does not contain the records listed in netlogon.dns, you need to find the cause and correct it. If you are using dynamic DNS updates, you need to investigate why the domain controller failed to update the dynamic records (for example, the NIC has the wrong DNS client IP address). If you are using static DNS, you may need to manually recreate the necessary A, PTR, and SRV records.

 

 

The DNSLint Utility (this tool be worth will be explained in the next post)

The DNSLint is a great tool that can be used to diagnose DNS errors. On the moved domain controller type the command
dnslint /ad 127.0.0.1 /s localhost /v

 

 

Immediate re-registration of DNS records

 

If you see errors in the Event Log due to problems with locating a domain controller in DNS that has failed to dynamically register its DNS address, and you do not want to wait 5-10 minutes for automatic re-registration, you can force the domain controller to immediately register its IP address with the DNS server. Type the following console commands:

 

 

ipconfig /flushdns
ipconfig /registerdns
nltest /dsregdns

 

 

The ipconfig command will tell the computer to send ("register") its DNS A and PTR records with the DNS server. The nltest command will register the SRV records. The SRV records are used to locate domain controllers.

 

 

ipconfig is a built-in utility. nltest is part of the Windows Support Tools, located on the Windows Server CD.

 

 

Restoring DNS from a backup more than 7 days old

 

Many DNS zones use dynamic updates. When a computer boots that is a member of a dynamic DNS zone it will write its IP address and host name to the DNS server. (This is called “registering with DNS”.) The computer will send an update when it boots, and again periodically - typically once per day. Domain controllers will send dynamic updates to the DNS server just like other computers.

 

 

The DNS server will erase stale records if they are not updated after (typically) 7 days.

 

 

If you restore the DNS server database from a backup that is more than 7 days old, and if the DNS server on that computer has dynamic DNS zones, upon booting the DNS server will immediately erase all the dynamic records. This is because the DNS server checks the timestamp of each dynamic DNS record when it boots (and periodically thereafter). If the timestamp is older than the aging interval (default 7 days), the DNS record is erased.

 

 

During the initial boot with a newly loaded Active Directory you may see some spurious errors in the Event Log regarding the inability to locate a domain controller or the Global Catalog. These error messages are temporary and can be ignored. Each domain controller will attempt to dynamically re-register its IP address every 5-10 minutes until it succeeds.

 

 

The first registration attempt may fail because the DNS server has not yet fetched the DNS zone records from AD. This can happen if you use integrated DNS zones. (see below). This is normal, and the next registration attempt should succeed.

 

 

Error: The DNS Service cannot load integrated DNS Zones from AD

 

By default each DNS zone database is stored in C:WindowsSystem32DNS* as a simple text file. When creating a DNS zone you have the option to instead store the DNS zone inside of Active Directory as an AD object. A DNS zone stored in AD is called an “integrated” DNS zone.

 

 

If you use integrated DNS zones, and you are using dynamic DNS registration, there is a circular dependency between DNS and AD that can cause a delay of up to 30 minutes during the initial boot. The reason for the delay is that DNS needs to contact AD to fetch its zone records, but AD will refuse to accept requests until it can register its IP address with DNS. But DNS will refuse to honor AD's registration request because DNS has not loaded the zone records yet from AD. The result is a circular deadlock. The DNS service will report (via the DNS Event Log) that it is unable to load the integrated DNS zones from Active Directory.

 

 

Within 30 minutes AD will recognize the problem and start without DNS, breaking the deadlock. If you do not want to wait for 30 minutes, you can manually stop and restart the DNS service. This will break the deadlock. (The deadlock will not happen on subsequent boots. This is because DNS will cache the AD-integrated zone records and use them on subsequent boots.)

 

 

If you stop and restart the DNS service, also stop and restart the DNS Client service. The DNS Client service caches results from the DNS service. This includes “negative” results where an address is not found. To avoid confusion during troubleshooting of DNS, when you restart the DNS service you should restart the DNS Client service also. This will prevent “negative” caching from confusing your troubleshooting.

 

 

For the best results when troubleshooting DNS you should turn off the DNS Client service. You can leave the DNS Client service turned off as long as your server does not use client DHCP. (Client DHCP depends on Client DNS.)

 

 

Test move: Not moving all DNS servers

 

If you are not moving all the DNS servers to your test lab, you must reconfigure DNS so that the test domain controller(s) can continue to locate each other and so that test client computers can locate the domain controllers.

 

 

Test move: Creating a dummy root DNS zone

 

Your test lab will be isolated from the rest of the network. This means that DNS queries for external zones outside of the test lab will time out. Some Microsoft components will attempt to access external DNS zones, such as microsoft.com. Because the DNS server cannot forward these requests, they will time out, causing irritating delays.

 

 

To avoid delays due to timeouts for external DNS zones, you can create a dummy root DNS zone on the DNS server in your test lab. This will cause the DNS server to immediately fail external lookup requests instead of trying to forward them (and timing out).

 

 

To create a dummy root DNS zone use the following procedure:

 

 

1. Start the DNS MMC snap-in: Click on Administrative Tools -> DNS.

    

2. Right-click Forward lookup zones, then click New Zone.

    

3. When the New Zone Wizard starts, click Next.

    

4. Click Primary, clear the checkbox Store the zone in Active Directory so that it is not checked, and then click Next.

    

5. In the Zone Name box, type a single dot (.), and then click Next.

    

6. Click Create a new file with this file name and type root.dns (default), and click Next.

    

7. Click Do not allow dynamic updates (default) and click Next. Then click Finish.

    

Do this procedure on the “topmost” DNS server in your test lab.

 

 

For more information

 

For more information on how to configure DNS please refer to these Microsoft Knowledge Base articles:

 

 

• Setting Up the Domain Name System for Active Directory (Q237675)

   

• Frequently Asked Questions About Windows 2000 and Windows Server 2003 DNS (Q291382)

   

• How to Verify That SRV DNS Records Have Been Created for a Domain Controller (Q816587)

   

• How to Create a New Zone on a DNS Server in Windows Server 2003 (Q323445)

   

• How to Configure DNS Dynamic Update in Windows Server 2003 (Q816592)

   

• Best Practices for DNS Client Settings in Windows 2000 Server and Windows Server 2003 (Q825036)

   

• How to Replace the Current Primary DNS Server with a new Primary DNS Server in Windows Server 2003 (Q323383)

   

 

 

Thank you from the source

 

 

Utools.com

 

 

Microsoft has published this article (last review at March 25, 2008) that  describes the best practices and the troubleshooting information for the MSI Utility for Microsoft Application Virtualization (MSI Utility).

 

 This article also describes the error messages that you may receive when you run the MSI Utility in an interactive session and in a non interactive session. It should be better to read this article to better know MSI utility because it so great tool for deploy and distribute applications.

 

If you want to read all KB article you can find it at Micorosoft site with aArticle ID: 949050

One of the common problems that an Exchange administrator has to deal with is the failure of outbound external messages to be delivered. This will cause complaints from the senders and can cause issues with the server itself.

As a minimum you should keep an eye on the queues, as this can indicate whether there is a problem. There are monitoring tools within Exchange that can alert you to messages in the queues, but watch the thresholds carefully or you will get false positives.

Collecting the Evidence

There are a number of bits of information that you can collect which help with diagnosing problems.

• The Non-Delivery Report (NDR)
  This is the most important item as it will show the SMTP diagnostic code. If the users are complaining, ask them to send you the complete NDR so that you can see what the server reported as the problem.
• Message Tracking Logs.
  Exchange can track what it did with the message. This needs to be enabled before the problem, and as it has such a low overhead, it is a good idea to have it running all the time, retaining at least 30 days worth of logs.
• SMTP Diag tool.
  This is a download from Microsoft and can tell you loads about the SMTP status as seen by the Exchange server.
  http://www.microsoft.com/downloads/details.aspx?FamilyID=BC1881C7-925D-4A29-BD42-71E8563C80A9&displaylang=en
• SMTP Logs.
  The logs that the SMTP server creates are limited but can show if the connection was made. Enable the logging in ESM, Servers, <your server>, Protocols, SMTP. Right click on the SMTP Virtual Server and choose Properties. The logging settings are on the first tab.