Hi all,

 

Yesterday Microsoft has released Network Monitor version 3.3 the tool for capture and anlyze network traffic.

 

Below a brief description about the new features that version 3.3 introduces and the web link for download it.

 

There was correct any bugs with regard the precedent release and some new features:

 

ü  Now there is the capability to capture traffic from WAN interface and trough Windows 7’s tunnels

 

ü  Hyper-V support

 

ü  Now is possible to add an alias simply with a right click on IP protocol or MAC address

 

ü  Capability to hop as the definition of the data field with right click in the frame field

 

ü  Auto-scroll: during a capture session it is possible tio enable auto-scroll function to view the most recent traffic to analyze

 

ü  Capability to add a comment to a frame

 

 

 

ü  Capability to open file ETL and correlate informationwith event trace in the network

 

ü  A group of parser to increase performances

 

ü  New API extension

 

ü  Experts, on line application that can analyze network traffic (you can find them at link  http://go.microsoft.com/fwlink/?LinkID=133950

 

ü  Download link for Network Monitor 3.3 HERE.

 

 

I want to report a fix, issued by Microsoft about the DNS service in Windows Server 2008.

 

 

This hotfix 953317 has been released to solve a problem recently discovered in the DNS service. The problem is a replica failure of the DNS which occurs when take place in the DNS server primary A high number of changes that activate a full transfer of the area to other DNS servers, that instead they expect a transfer only incremental.

 

 

The problem occurs when the DNS is not integrated in Active Directory. IN THIS CASE IN FACT THE REPLica TO synchronized server shall maintain the DNS between the different DNS server.

 

 

Therefore, if you are using Windows 2008 server as a DNS server, not use the replica if not integrated, PLEASE READ THESE ARTICLES AND, IN THE CASE IN WHICH problems with the DNS, install the fix that Microsoft has been released:

 

Headache Prevention: Install Hotfix 953317 to Prevent DNS Records from Disappearing

 

A primary DNS zone file may not transfer to the secondary DNS servers in Windows Server 2008.

 

One of the biggest battle any network engineer has to fight is constantly dealing with spyware issues on client PCs. One technique that is commonly used to prevent devices from accessing known spyware related sites is using DNS to black hole these domains. In doing this, you create a record on your internal DNS servers for a particular domain so that the server things it is authoritative for that domain. When a client computer using this server for DNS queries that name, the server will be configured to point it to a loopback address of 127.0.0.1 or something like 0.0.0.0. The end result is that the client computers cannot access these malicious sites.

Doing this in DNS is as simple as creating a forward lookup zone for the domain in question. You can get a pretty good listing of some known spyware related domains at http://malwaredomains.com/.

Tanks at the source of this article (Windows Networking.com)

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

 

 

Hi all now it’s possible to download new version of Microsoft Network Monitor (downloadable  here).

 

Microsoft developer team have done hard work to make available in this version the feature that community have request, also have correct many bugs that was present in the precedent version

 

Following there are main news:

 

• Process tracking: now it’s possible to identify applications that send data in the network.  Inside Network Monitor it can view tree-view, the list of processes that generate network traffic.

   

• Rewriting and revision of the engine of catch of traffic that can reduce significantly the frame discarded from Network Monitor.

   

• For ease of reading and interpretation of the conversation is possible now isolate the frame of a single conversation: Just select a frame, please click the right mouse button and select the conversation.

• increasing the number of parser (fully configurable) present in the product: are now present parser for more than 300 different protocols.

   

• best management of parser: given the large number of parser present, only a number of these is loaded for default. It is possible to load the entire set of parser with a simple click on a menu item.

   

 

I believe it is a new version very interesting that it is worth trying.

 

 

You can find more information on the blog of the development team of the product

 

http://blogs.technet.com/netmon

 

 

Cheers Alex

At first I suggest to read a paper that contains an introduction to NAP and instructions for setting up a test lab to deploy NAP with the DHCP enforcement method, downloadable from Microsoft site HERE but one thing the document is missing is how to configure the NAP client in XP SP3.

 

To enable the NAP Client on XP SP3 you need to do the following:

 

1. Start --> Run --> Services.msc

    

2. Change the Network Access Protection Agent service to start automatically

    

3. Start the Network Access Protection Agent service

    

4. Start --> Run --> CMD.exe

    

5. Type netsh nap client set enforcement ID = ##### Admin = "Enable"

    

6. Start --> Run --> GPEdit.msc

    

7. Drill down to Computer Configuration | Administrative Templates | Windows Components | Security Center

    

8. Enable the Security Center

    

9. Start --> Run --> Services.msc

    

10. Start the Security Center service

     

You will need to replace the ##### with the ID based on whichever enforcement method you are using.  You can use the following IDs for the various enforcement methods:

 

• DHCP = 79617

   

• RAS = 79618

   

• IPSec = 79619

   

• TS Gateway = 79621

   

• EAP = 79623