This is the best resource kit I have seen since the box set was released for Windows 2000.  This book is worth buying as it is a great resource to have on all things Windows Vista.  Among the 1500+ pages of goodness are several chapters dedicated to networking topics and to network troubleshooting on Windows Vista.  The CD that accompanies the book includes many useful tools, scripts and resources.

If you are an old hand at networking and troubleshooting network issues you might be thinking that you can get by without another resource kit on your shelves.  Maybe you can.  But...this book contains information on most of the new technologies built into Windows Vista that you haven't read about in past resource kits from Microsoft.  LOTS of things have changed between Windows XP and Windows Vista.  It’s worth a look.

You can read more about it here:  http://www.microsoft.com/mspress/books/9536.aspx 

http://www.microsoft.com/winme/0702/20430/index.html 

This webcast focuses on the Network Diagnostics Framework (NDF) and the Network Connectivity Status Indicator (NCSI).  These features will help you determine if you are connected to a local network and the Internet, and get you re-connected when there are common problems.

This webcast is slightly more technical than the Support webcast that I recorded in December.

The paper covers the Network Diagnostics Framework (NDF) and the Network Connectivity Status Indicator (NCSI) in depth including related registry keys/values and event log IDs.

http://www.microsoft.com/downloads/details.aspx?FamilyID=1698e42b-03fd-4cd9-b568-d948de55b0f8&displaylang=en

This is a great resource if you really want to get the most out of these features.

http://support.microsoft.com/kb/927551

During this 45 minute webcast I introduce two new features in Windows Vista: the Network Diagnostics Framework (NDF) and the Network Connectivity Status Indicator (NCSI).

The webcast is worth a look if you are interested in advances in network troubleshooting or if you simply want to get a head start learning about some of the new features in Windows Vista.

For the better part of the last two years I have been working as a Program Manager on the Network Experience team in the Core Operating System Division at Microsoft.  I have been working on the network diagnostics built into Windows Vista with a team of talented and dedicated Developers, Testers and Program Managers. 

These are v1 features that I hope will help every Consumer user running Windows Vista overcome the most common networking issues that they typically experience.  I also hope that experienced support folks can also leverage these features to reduce the amount of work they have to do to isolate and fix common networking issues.  I plan to make a few blog posts to evangelize these features in the near future.

Why did we build network diagnostics into Windows Vista?  In the past, in order to troubleshoot a network issue a knowledgeable individual would have to use several support tools to gather information, test hypotheses, and identify how to fix an issue.  As you can see from some of my other blog posts, I developed many support tools in the past to help experienced troubleshooters do just that. 

There are several issues that limit the usefulness of support tools:

• Accessibility: the number of users that can really take advantage of support tools is limited for a couple of reasons:
• Typically the user of a network support tool needs to have knowledge of networking and experience troubleshooting network issues to effectively make use of a network support tool.  Although there are many IT Pros that have the required mix of knowledge and experience to use such tools, there are many, many more people that do not.  Support tools are not useful to the vast majority of users that experience network issues.
• Many support tools are not localized.  i.e. they only support the language of the developer that wrote them.  If the user doesn’t understand the same language they probably won’t be comfortable using the tool.   

• Consistency (Variable Input/Output): every tool takes different input (or the same input but with a different format) and generates different output. i.e. there is no universal syntax for support tools.  If the user must use three or four support tools to troubleshoot an issue, chances are each tool requires different switches than the others.  The user has to be able to interpret each tool’s output and determine which pieces of output need to be used as input for the next tool.

• Serviceability: maintaining support tools can be challenging for their developers.  As new requirements emerge it can be difficult (and expensive) to retro-fit old tools to meet the new requirements.  Many times it is easier to develop new tools to meet the new requirements.  This exacerbates the previous two issues I mentioned above.

One of the goals we had for network diagnostics in Windows Vista was to mitigate the need for users to use network support tools when they encountered common network related issues.  This simplifies the troubleshooting process for both Consumers and IT Pros and makes network diagnostics more accessible for everyone.  We wanted to simplify the input and output that users had to deal with (this is much harder to do than it sounds).  Since these network diagnostics are built into Windows Vista, the output is localized in all the languages that Windows Vista supports and being built-in will also improve our ability to service network diagnostics over time.

I will introduce you to some of these new features included in Windows Vista in my upcoming blog posts.

I have developed and released numerous networking and security support tools over the years.  I get e-mail weekly from customers who use my tools.  Frequently I get e-mail from people who have difficulty finding some of my tools.  Many of these tools have been released as part of the Support Tools directory on the Windows XP CD and on the Windows Server 2003 CD.  These tools are also available as free downloads from the Download Center on www.microsoft.com . 

I have been asked many times to publish a list of the resources/URLs for each tool to make them easier to find.  I hope this helps.

PortQry

TCP/IP connectivity test tool, port scanner, and local port monitor.   Networking and security usages.

Download link

http://www.microsoft.com/downloads/details.aspx?familyid=89811747-C74B-4638-A2D5-AC828BDC6983&displaylang=en

KB articles

PortQry Overview

http://technet2.microsoft.com/WindowsServer/en/Library/52704f7f-dfda-4656-90fc-c747a565b4ca1033.mspx

New features and functionality in PortQry version 2.0

http://support.microsoft.com/kb/832919/

Webcasts

Port Scanning Using PortQry

http://support.microsoft.com/kb/325494/

New features and functionality in PortQry 2.0

http://support.microsoft.com/default.aspx?kbid=834626

Port Reporter

TCP/IP port usage logging service.  Networking and security usages.

Download link

http://www.microsoft.com/downloads/details.aspx?FamilyID=69ba779b-bae9-4243-b9d6-63e62b4bcd2e&DisplayLang=en

KB article

Availability and description of the Port Reporter tool

http://support.microsoft.com/kb/837243

Webcast

Port Reporter

http://support.microsoft.com/kb/840832/

Port Reporter Parser (PR-Parser)

Log parser for Port Reporter log files.  Networking and security usages.

Download link

http://download.microsoft.com/download/2/8/8/28810043-0e21-4004-89a3-2f477a74186f/PRParser.exe

KB article

Description of the Port Reporter Parser (PR-Parser) tool

http://support.microsoft.com/kb/884289

DNSLint

Domain Name System (DNS) troubleshooting/health monitoring tool.

Download link

http://download.microsoft.com/download/2/7/2/27252452-e530-4455-846a-dd68fc020e16/dnslint.v204.exe

KB articles:

Description of the DNSLint utility

http://support.microsoft.com/kb/321045/

How to use DNSLint to troubleshoot Active Directory replication issues

http://support.microsoft.com/?kbid=321046

Webcast

Microsoft Windows: Using the DNSLint Utility

http://support.microsoft.com/kb/329982

Promqry

Detects Windows systems possibly running network sniffers.  Networking and security usages.

Download links

Command line version

http://www.microsoft.com/downloads/details.aspx?FamilyID=4df8eb90-83be-45aa-bb7d-1327d06fe6f5&displaylang=en

GUI version

http://www.microsoft.com/downloads/details.aspx?FamilyID=1a10d27a-4aa5-4e96-9645-aa121053e083&DisplayLang=en

KB article

Description of Promqry 1.0 and PromqryUI 1.0

http://support.microsoft.com/kb/892853

NetBIOS Browsing Console (browcon)

Helps troubleshoot NetBIOS browsing issues in Windows domain environments.

Download link

http://download.microsoft.com/download/b/2/a/b2ae4b0e-dc51-40d8-98bf-7a4ade88dcdf/browcon.exe

KB article

Description of NetBIOS Browsing Console (Browcon.exe)

http://support.microsoft.com/?kbid=818092

Webcast

Using the NetBIOS Browsing Console to Troubleshoot NetBIOS Browsing

http://support.microsoft.com/kb/820914

NBLookup

WINS/name resolution troubleshooting/monitoring tool.

Download link

http://download.microsoft.com/download/f/3/a/f3adc5b4-2716-4ef3-bbb8-f4cd4446d415/nblookupv1.exe

KB article

NBLookup.exe command-line tool

http://support.microsoft.com/kb/830578

SPCheck

Helps identify the service pack level of networking components on a file by file basis. 

KB article 

How to Use the SPCheck Tool to Determine the Service Pack Level of Components

http://support.microsoft.com/kb/279631

Download links

Windows Server 2003:

http://download.microsoft.com/download/c/5/6/c56eb418-9b8a-4ced-b077-998b662c807c/w2k3.exe

Windows XP:

http://download.microsoft.com/download/6/e/0/6e0b8c10-a71b-44f1-99d5-27f6fc535f5c/xpspchk.exe

Windows 2000:

http://download.microsoft.com/download/5/7/6/57622a9c-d6b4-47bb-9f37-008a8b1405c8/w2kspchk.exe

Windows NT 4.0:

http://download.microsoft.com/download/5/c/4/5c426317-7403-4e05-8183-7f370c383017/nt4spchk.exe

Exchange 5.5:

http://download.microsoft.com/download/1/8/8/1882bcc6-c940-4904-8330-8aa1faabfe5e/exchange55.exe

Internet Security and Acceleration Server (ISA) 2000:

http://download.microsoft.com/download/2/8/a/28a889cf-6880-4b97-b7e8-12ccf5fa8d74/isaspchk.exe

This type of passive attack can be very difficult to detect.  There are numerous third party tools that try to detect network sniffers running on the network by looking for signs of systems with network interfaces running in “promiscuous mode.” Since many of these tools use network-based detection techniques that rely on bugs in operating systems and/or specific sniffer behavior, they can generate false positive and false negative results.

I have developed a tool that can detect managed Windows systems that have network interfaces running in promiscuous mode – a key indicator that a network sniffer is running on the system.  I use a host based detection technique instead of a network based detection technique in order to make this tool as accurate as possible.

I built two versions of this tool:

• Promqry – a command line tool
• PromqryUI – a tool with a GUI

Both of these tools essentially have the same functionality:

• Query the local system’s network interfaces
• Query a single remote system’s interfaces
• Query a range of remote system’s interfaces

Both tools require the .Net Framework to run.  This means you need the .Net Framework installed on the system you run Promqry or PromqryUI from, but not on the remote systems you want to query.  If you don’t have the .Net Framework already installed, you can get it from here:  http://msdn.microsoft.com/netframework/downloads/framework1_1/   The “general users” install package will be sufficient for most users. 

You can get both versions of Promqry (for free) from the download center on www.microsoft.com using these links:

A command line version:

http://www.microsoft.com/downloads/details.aspx?FamilyID=4df8eb90-83be-45aa-bb7d-1327d06fe6f5&DisplayLang=en

A version with a GUI:

http://www.microsoft.com/downloads/details.aspx?FamilyID=1a10d27a-4aa5-4e96-9645-aa121053e083&DisplayLang=en

I hope you find these tools useful.

I frequently get asked where the idea for this tool came from, so I thought I would post the story here.  I developed this tool when I worked on the Enterprise Platform Support Networking team in Product Support Services (here at Microsoft).  One of the services that this team supports is DNS.  After Windows 2000 shipped it seemed like almost every customer I talked to needed help designing a DNS namespace or had implemented a design that they needed help with.  The primary reason for this is that Windows 2000 requires DNS for Active Directory and many customers were upgrading from Windows NT 4.0 which did not require DNS for domain building purposes.  Many people needed help with DNS during this transition period.

After spending hours with nslookup troubleshooting lame delegation issues, I decided to build a tool to automate the process and save everyone some time.  DNSLint was born.  Travis Adams from the Enterprise Platform Support Directory Services team asked me to add a feature to help troubleshoot Active Directory replication issues caused by missing or inconsistent DNS records.  Then I added a feature that allows you to query all the DNS records specified in an input file.  With this feature you can check all the DNS records for all of your critical servers (domain controllers, web servers, SQL servers, etc) on every DNS server that should know about them in a very short time frame.

I receive e-mail about DNSLint weekly.  A frequently asked question I get about this tool is not a technical question at all:  Is the Lint in DNSLint an acronym and if so…what does it mean?  Just to clear this up…lint is something you find in your blue jeans after they come out of the dryer.  When you find lint, it is useless and sort of embarrassing…so you quickly throw it away.  Not unlike outdated or inaccurate DNS records for important systems. ;>)

You can read all the technical details about DNSLint in this Knowledge Base article: 

http://support.microsoft.com/?kbid=321045

I also recorded a webcast for your listening and viewing pleasure:

http://support.microsoft.com/default.aspx?scid=kb;en-us;329982

Also, there are lots of good DNS resources at the DNS center:

http://www.microsoft.com/Windows2000/technologies/communications/dns/default.asp

Some examples…One person’s Windows Media Center Edition system was rebooted while they were watching their favorite show on TV.  Another person, who uses their laptop as an alarm clock when they travel, slept in because they system was rebooted and the alarm clock application didn’t restart.  Another person said they were working on a Word doc and went to the restroom only to return to find their system rebooted and the Word doc gone (lucky it is so easy to recover Word docs).

Most of the stories have two things in common:

1. The system was a Windows XP SP2 system with the AU client configured to “Automatically download recommended updates for my computer and install them on a schedule.”
2. A user was logged on to the system and the console wasn’t visible (it was locked or they were away from the console) when the reboot occurred.

The answer is NOT to disable the AU client.  You definitely want to keep your system up to date with the least amount of effort…so please don’t disable the AU client…read on….

As it turns out, the reboot is actually expected behavior.  You have Automatic Updates on your system configured to “Automatically download recommended updates for my computer and install them” on a schedule.  When one or more of those updates requires a reboot, the system gets rebooted. 

But let me explain why it does this and how to prevent it from happening again.  First, check what AU client settings are currently set on the system.  To do this, open the Control Panel and double click on the Automatic Updates icon. 

With the recommended setting (“Automatically download recommended updates for my computer and install them” on a schedule), I should expect my system to reboot at approximately 3:00 AM if any installed updates require a reboot.  If you have this set to install during your work hours or when you are watching TV, etc…you should expect an automatic reboot during that period if updates are installed and one or more of them requires a reboot.

If the AU client has rebooted your system, you should see a few related events in your system’s event log.  One event is logged when updates are ready to install.  The event below is logged when the updates are installed and this results in an automatic reboot (notice the time is shortly after the default 3:00 AM install time).

Event Type:      Information

Event Source:   Windows Update Agent

Event Category:            Installation

Event ID:          22

Date:                10/15/2004

Time:                3:02:02 AM

User:                N/A

Computer:         MY-COMPUTER

Description:

Restart Required: To complete the installation of the following updates, the computer will be restarted within 5 minutes:

- Critical Update for Office XP on Windows XP Service Pack 2 (KB885884)

- Cumulative Security Update for Internet Explorer for Windows XP Service Pack 2 (KB834707)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Data:

0000: 57 69 6e 33 32 48 52 65   Win32HRe

0008: 73 75 6c 74 3d 30 78 30   sult=0x0

The key is this line:  “To complete the installation of the following updates, the computer will be restarted within 5 minutes…”   When you are logged on to the system, whether the console is locked or not, a dialog box pops up with a timer counting down to reboot.  If you are logged on as an administrator, you can abort the count down.  If the console is locked or you are not in front of the system when the timer appears…it counts down and reboots the system.

This behavior is controlled by a registry entry.  A great source of information on the AU client (and Software Update Services) is the “Software Update Services Deployment White Paper.  You can download a copy of this paper from here: 

http://www.microsoft.com/windowsserversystem/sus/susdeployment.mspx

Page 57 - 59

To prevent Automatic Updates from restarting a computer while users are logged on, the administrator can create the NoAutoRebootWithLoggedOnUsers registry value in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU. The value is a DWORD and must be either 0 (false) or 1 (true). If this value is changed while the computer is in a restart pending state, it will not take effect until the next time an update requires a restart.

Summary of behavior for NoAutoRebootWithLoggedOnUsers settings

The following table shows the difference in behavior with NoAutoRebootWithLoggedOnUsers enabled (set to 1) or disabled or not configured (not set to 1).

Hopefully you are not logged on very often as an administrator, but either way, pick the scenario that matches how you use your system from the grid above and set NoAutoRebootWithLoggedOnUsers to give you the behavior that you are looking for.

IMPORTANT:  If you choose to configure your system not to reboot when a security update which requires a reboot is installed, you are taking a huge risk.  The fixed code is not actually loaded (in memory) by the system until after the reboot.  i.e. the old, vulnerable code is still running until a reboot is completed.  If you do not reboot the system for whatever reason (you didn’t realize a security update was automatically installed, you want to wait for a regular maintenance window, you forget, you were on vacation, etc.) your system will still be vulnerable.  You also risk system stability by delaying a required reboot.  When some files that are in use are replaced but not loaded, and other files that are not in use are replaced, you can get into a mixed binary situation. Depending on the binary, there may be conflicts that cause system instability.

Given this reality, it may be prudent to deal with “unexpected” reboots in order to always be up to date and safe.  You need to weigh the risk…

I hope this tip saves you some confusion. 

http://www.winnetmag.com/Article/ArticleID/39436/39436.html

Why does Mark, and many other people, think that NetBIOS name resolution is still so important?  You still run WINS on your network…right?  The vast majority of customers that I talk to, still run a WINS service somewhere on their network.

Many people anticipated the demise of WINS when Windows 2000 was released.  They had a vision of a simplified network where the only types of name resolution problems to troubleshoot were related to DNS.  No more name registration problems, replication issues, record tomb stoning riddles or secure channel troubleshooting to do.  This was going to be a world where every application was directory aware and discoverable via protocols like DNS and LDAP.

There are several reasons why WINS is still necessary on most networks.  The biggest reason I can think of is that many applications still use NetBIOS to provide some functionality to users.  In the past I tried to compile a list of such applications, but this was a daunting task because an application’s use of NetBIOS can be very subtle.

As it turns out, for most administrators, the question of whether to use WINS or not is an easy one to answer and doesn’t require an exhaustive list of applications that use NetBIOS.  Two of the most popular applications that have shipped with different Windows operating systems over the years are Network Neighborhood and My Network Places.  These applications are used heavily by administrators and the end-users that they support.  End-users love these applications. 

If you or your users use these applications, you are probably going to want to use WINS to help populate the lists of network resources that these applications present to the user.  These lists are generated and maintained by the NetBIOS Browsing mechanism built into the Windows operating system.  In fact, if you run applications that allow the user to open and/or save data across the local network or pick a computer to connect to, i.e. select a server or workstation from a list of network resources, then it’s a good chance those applications use the NetBIOS Browsing mechanism to populate those lists.  Where NetBIOS Browsing is used, WINS is typically involved too.  WINS helps facilitate the distribution of the browse lists of network resources, to all the Windows systems on a network.

Some applications are now using mechanisms other than NetBIOS to populate these types of lists.  But, upon close inspection, it may surprise you how many applications that you use still rely on the NetBIOS Browsing mechanism and WINS.

If you have been considering retiring a WINS server on your network it would be prudent to determine how much it is being used before stopping the service.  One method that many customers have found effective is to use Performance Monitor on the WINS server.  When WINS is installed on a server, some performance monitor counters for WINS are also installed.  These counters can tell you how many queries and responses the WINS server is handling.

If it turns out that you still need to run the WINS service, there are a few Resource Kit tools to help you manage it and troubleshoot problems.  As I mentioned above, I developed a tool that may help you with troubleshooting and name registration/record availability confirmation tasks.

Nblookup.exe is a tool that is modeled very closely to the nslookup.exe utility that is used to troubleshoot DNS issues.  It is relatively small (around 102 Kb) and does not have an installation program (just copy it into any directory and run it).  It allows you to query WINS servers for name registration records just like nslookup allows you to query DNS servers for DNS records.  Unlike most other WINS tools that you may have used, nblookup does not require an authenticated connection to the WINS server, i.e. you don’t have to run this tool in administrator context.  I also added some features like ability to query/verify large numbers of records very quickly using an input file.  This makes it very easy to quickly determine whether all of the important systems/applications on your network are registered and discoverable using all of the WINS servers on your network.

This tool is not part of any resource kit, but it can be downloaded (for free) from microsoft.com.  You can download nblookup and read all the details in this Knowledge Base article:

http://support.microsoft.com/Default.aspx?kbid=830578

Mark Minasi was kind enough to include nblookup as one of his “The Magnificent Six” list of tools.  Did I mention that Mark is a great author. ;>)

http://www.winnetmag.com/Article/ArticleID/42914/42914.html

If you still run WINS, and you probably do, it may be worth your while to add nblookup to your toolkit.