Welcome to TechNet Blogs Sign in | Join | Help

News

  • Welcome to the blog for the Microsoft CSS Enterprise Platforms Networking team.

    Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.

    Blog Tools

    Add to Technorati Favorites
    Blog Flux Directory
    Computers Blogs - Blog Top Sites

    Add to Google

    Locations of visitors to this page

The Quick and Easy on Using NMCap to Create Circular Network Traces Based on File Size

Hello all Networking Blog readers.  My name is Brett Crane and I am an engineer with the Networking Teams here at Microsoft.  I wanted to take a minute to show you a quick way to utilize Network Monitor to perform Sequential, or also called Circular, captures for troubleshooting issues.  This is particularly useful when you can’t dictate when the networking communications you are looking for are going to happen. This method of troubleshooting has been available via GUI configurations using other network traffic capture utilities but has been, and currently is, only available through the command line options provided with Network Monitor. 

(NMCap is a tool that is installed when you install Network Monitor 3.x.  This is a command line based tool that provides great a bit of functionality.  As time goes by you will find more postings on other uses this tool can provide.)

As said before, the goal of this discussion is to describe how to collect a sequential trace.  What I mean by that is that you set Netmon to create a trace that only grows so large… 200MB for example.  Once the capture has grown to 200MB it will close the current file and create a new one.  That file will grow up to 200MB and then create another file.  This will provide you the ability to go back and review your files and look to see if the date/time stamp matches the date/time of when your possible problem may have occurred.  Having this information helps because you can delete the trace files that you know do not meet your criteria.  If you were to just start a trace file and walk away it could easily fill your hard drive or become so large that it will become too much of a burden to be open or parsed in a timely fashion. 

(Actual file size is adjustable and is dictated by the user entering the command.  Based on your needs it could be 1500B or larger.  The upper limit on the file size is 500MB.  If you do not dictate a size it will default to 20MB.  Please make sure you check available disk space as this process could easily fill your entire drive if not monitored properly.) 

To utilize NMCap to collect the sequential captures you will need to install Network Monitor 3.x. (For download and installation information please look back at our other postings: http://blogs.technet.com/networking/archive/tags/Network+Monitor/default.aspx)  

Once Network Monitor is installed, open a command prompt and use the following command line statement:

image

Statement Definitions:

NMCap: The application used to provide command line statements.  It is a lighter weight application, takes fewer resources, and is more flexible.

/Network: Selects one or more space delimited network adapters to capture from. Adapters may be specified using their index, partial name with wild *, or quoted friendly name.  (If you are uncertain of the Network adapters name you want to trace from you can find it using the NMCap /displayNetwork command)

/Capture: Saves frames that pass the frame filter to the specified capture files.  Think of this as the start command for Network Monitor.

/File: The command after this switch will be what you are wanting to name the trace file.  By following up this command with a “:” and a size, you will set the size in which each file will grow to be prior to stopping and starting the next file.  Each new file will be noted by an incrementing number notation.

* Notes:

- In the example given above we used the file name test.chn.  The extension chn stands for Chain.  By using this extension in the filename we are telling NMCap to start the next file in the chain when we reach the stated size (200MB in the example).  If you utilize the .cap extension in the filename of the format used above it will not create a new file.  It will just cap off the file at the stated size then overwrite older data.  By using the .cap file extension you will NOT accomplish the goal of multiple file creation!

- Keep in mind, as with all command line statements, the file will save in the current directory (e.g. from above: the file will be stored on the C:\ drive).

- There are many useful advanced filters that can also be used during the process of capturing Sequential/Circular Trace files (E.g.: /RecordFilters; /RecordConfig).  For more information on commands of these sorts please refer to the Help for NMCap.  (Help for NMCap can be accessed by running the following command in your CMD window: nmcap /?)

To stop your Capture process:

Once you feel the tracing has run long enough to capture what you are looking for, you will need to stop NMCap from continuing to create your trace files.  To do this correctly all you will need to do is make sure that your Command Prompt window that you have opened and running the sequential traces on is the focus on your machine and hit Ctrl+C.  Or, you could just close the Command Prompt Window.  Keep in mind that if you close the window you started tracing in, or log off, you will stop the tracing process.

*Note:  There are advanced methods that can stop the tracing based on different variables such as Date/Time, for example.  More information on these methods can be found in the Help for NMCap.  (Help for NMCap can be accessed by running the following command in your CMD window: nmcap /?)

So, that’s all there is to it!  Now you can let your traces run, checking back often and deleting the files that you know do not contain any relevant information!

(For more detailed information on using nmcap you can also refer to this link: http://blogs.technet.com/netmon/archive/2006/10/24/nmcap-the-easy-way-to-automate-capturing.aspx)

- Brett Crane

Springboard Series Virtual Roundtable with Mark Russinovich

Springboard Series Virtual Roundtable
Under the Hood: Windows Vista Performance...Need Answers?

clip_image002Join Mark Russinovich and a panel of industry experts for a LIVE virtual roundtable to explore your top of mind performance issues, common misconfigurations, and tips on how to fix them. From boot times and applets to disk performance and battery life, find out how to optimize Windows Vista and what you can do to improve overall system performance. 

Submit your performance questions live during the event or send them in advance to vrtable@microsoft.com.

Save the date!
Wednesday, September 24, 2008
9:00am Pacific Standard Time

springboard

Find answers to your Windows Vista adoption questions with resources, tools, monthly straight-talk articles, and upfront guidance based on early adopter and community feedback. To learn more, visit www.microsoft.com/springboard.

Springboard Series: The resource for Windows desktop IT professionals

- Michael Platts

New Networking-related KB articles for the week of August 10 - August 17

941091  The SnmpMgrOpen function fails and returns a null session, and the GetLastError function returns a 0 in Windows Server 2003

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

936330  Information about Windows Vista Service Pack 1

935791  How to obtain the latest Windows Vista service pack

953733  MS08-047: Vulnerabilities in IPsec policy processing could allow information disclosure

Engineering Windows 7 Blog goes live

Hi everyone,

Just in the last couple of days, I've heard that there's a new blog in town.  It is just getting going at this point, but this could be a great one to check out as more details are released:

http://blogs.msdn.com/e7/

- Michael Platts

How to test the BITS client on your machine?

Now let’s look at a series of Bitsadmin commands used to create a BITS job and download a file. These commands are used to test the BITS client side and verify it works.

1. Create a download job called bitstest by typing the following in the directory where Bitsadmin resides:

Bitsadmin /create /download bitstest 

2. Add the file you want to get and where to copy it to by typing the following:

Bitsadmin /addfile bitstest  http://go.microsoft.com/fwlink/?LinkID=18922 c:\MSSecure.cab 

3. Set your proxy settings to be the same as your IE settings:

Bitsadmin /setproxysettings bitstest preconfig 

4. Check the job to make sure it's in a suspended state:

Bitsadmin /info bitstest /verbose 

5. Set the job to go by typing:

Bitsadmin /resume bitstest

6. View the job again to make sure it’s in a state of Transferred:

Bitsadmin /info bitstest /verbose 

7. To complete the job which will take the bits temp file and write it to the location you specified in step 2, type:

Bitsadmin /complete bitstest 

Once you have completed these steps, you should see a file named MSSecure.cab in the root of the C: drive.

Listed below is an example of the commands described above being run on Windows Server 2008 using Bitsadmin 3 and the output from each command:

C:\Users\testuser>Bitsadmin /create /download bitstest

BITSADMIN version 3.0 [ 7.0.6001 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

Created job {026C1A35-4608-4A54-AC31-2B632522BC7B}.

C:\Users\testuser>Bitsadmin /addfile bitstest http://go.microsoft.com/fwlink/?
LinkID=18922 c:\MSSecure.cab

BITSADMIN version 3.0 [ 7.0.6001 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

Added http://go.microsoft.com/fwlink/?LinkID=18922 -> c:\MSSecure.cab to job.

C:\Users\testuser>Bitsadmin /setproxysettings bitstest preconfig

BITSADMIN version 3.0 [ 7.0.6001 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

Proxy usage set to PRECONFIG.
C:\Users\testuser>Bitsadmin /info bitstest /verbose

BITSADMIN version 3.0 [ 7.0.6001 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

GUID: {026C1A35-4608-4A54-AC31-2B632522BC7B} DISPLAY: 'bitstest'
TYPE: DOWNLOAD STATE: SUSPENDED OWNER: DOMAIN\testuser
PRIORITY: NORMAL FILES: 0 / 1 BYTES: 0 / UNKNOWN
CREATION TIME: 8/6/2008 6:16:19 PM MODIFICATION TIME: 8/6/2008 6:16:33 PM
COMPLETION TIME: UNKNOWN ACL FLAGS:
NOTIFY INTERFACE: UNREGISTERED NOTIFICATION FLAGS: 3
RETRY DELAY: 600 NO PROGRESS TIMEOUT: 1209600 ERROR COUNT: 0
PROXY USAGE: PRECONFIG PROXY LIST: NULL PROXY BYPASS LIST: NULL
DESCRIPTION:
JOB FILES:
        0 / UNKNOWN WORKING http://go.microsoft.com/fwlink/?LinkID=18922 -> c:\MSSecure.cab
NOTIFICATION COMMAND LINE: none
Peercaching flags
         Enable download from peers      :false
         Enable serving to peers         :false
CUSTOM HEADERS: NULL

C:\Users\testuser>Bitsadmin /resume bitstest

BITSADMIN version 3.0 [ 7.0.6001 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

Job resumed.

C:\Users\testuser>Bitsadmin /info bitstest /verbose

BITSADMIN version 3.0 [ 7.0.6001 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

GUID: {026C1A35-4608-4A54-AC31-2B632522BC7B} DISPLAY: 'bitstest'
TYPE: DOWNLOAD STATE: TRANSFERRING OWNER: DOMAIN\testuser
PRIORITY: NORMAL FILES: 0 / 1 BYTES: 68468 / 366823
CREATION TIME: 8/6/2008 6:16:19 PM MODIFICATION TIME: 8/6/2008 6:16:37 PM
COMPLETION TIME: UNKNOWN ACL FLAGS:
NOTIFY INTERFACE: UNREGISTERED NOTIFICATION FLAGS: 3
RETRY DELAY: 600 NO PROGRESS TIMEOUT: 1209600 ERROR COUNT: 0
PROXY USAGE: PRECONFIG PROXY LIST: NULL PROXY BYPASS LIST: NULL
DESCRIPTION:
JOB FILES:
        68468 / 366823 WORKING http://go.microsoft.com/fwlink/?LinkID=18922 -> c:\MSSecure.cab
NOTIFICATION COMMAND LINE: none
Peercaching flags
         Enable download from peers      :false
         Enable serving to peers         :false
CUSTOM HEADERS: NULL

C:\Users\testuser>Bitsadmin /complete bitstest

BITSADMIN version 3.0 [ 7.0.6001 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

Job completed.

C:\Users\testuser>

- Wayne Melvin

Don't be THAT guy... The case of the missing DNS zone

Introduction to the “Don’t be THAT guy” blog series:

I come in to work every day and get calls with these exact scenarios.  Of course, the names have been changed to protect the innocent and to keep the guilty from having to find new jobs.  The reason I wanted to start detailing some of these cases was to provide some cautionary tales for any one in the position of network or server administrator.  Therefore, read this, what I hope to be the first of many blog entries, so that you might avoid being “THAT guy”.

Don’t be THAT guy…  The case of the missing DNS zone.

The call came in from Scotland and apart from enjoying the gentlemen’s accents and their appreciation for a good pint I knew they had a pretty big problem.  They described to me that the DNS zone for their company’s domain (corp1.local) was found to be empty after name resolution issues were reported.  With their DNS servers being Active Directory integrated this meant that it was likely blank throughout their domain due to replication, and indeed it was.  This is definitely in the “not good” category.

With all of their zone information gone an Authoritative Restore of the AD partition containing the DNS zone was going to be necessary.  Once we started looking at this it was determined that the root cause of the problem was an Active Directory Object collision.  This was collision brought about by someone at the company in a remote location (neither of my new Scottish friends) creating a 2003 server domain controller (DC) and installing DNS on it.

As you might have guessed all of the DNS servers are Active Directory integrated and store the zone information in AD.  This means that all of the DNS records and zones are stored as objects within (AD).  You can further specify where in AD you want these objects stored.  You can choose to have them stored in the System partition (where Windows 2000 servers stored the info by default).  Or, with Windows Server 2003 you can choose to store it in a domain-wide container (DomainDNSZones) or a forest-wide container (ForestDNSzones) depending on how you want the zone information deployed.

Now prior to the creation of this new DC and installation of DNS, all of their DNS servers (and by the way, to be AD integrated a DNS server must be a DC) were set to replicate to “All domain controllers in the Active Directory domain” as seen below:

Figure 1.

clip_image002

This configuration places all of the DNS zone information in the System partition of AD under the MicrosoftDNS container as shown below.

Figure 2.

clip_image002[6]

Now when the customer’s technician (aka THAT guy) installed DNS they apparently did two things that are a BIG no-no.  First after installing DNS he actually created the zone for the domain that he knew he would need.  Now the first time people hear that they say “so…”, but after you think about how Active Directory Integration works with DNS you know this was a bad thing.  Once this zone was created and left blank this “Change” was replicated out to all of the other DNS servers.  Therefore, a blank zone for their domain was propagated through their environment effectively wiping out all current DNS zone information in its wake.

Now, admittedly the first mistake was probably the biggest since it can bring an entire network to its knees in one replication cycle, but the second mistake made it harder for us to correct the first one.  When THAT guy was creating the new blank zone he accepted all of the 2003 Server DNS defaults which has the SECOND radio button (from figure 1 above) selected: “To all DNS servers in the Active Directory domain”.  This forced the NEW zone that was created to be stored in the DomainDNSzones partition (See fig 3 below) and not the System partition like all of the other DC’s in the domain.

Figure 3.

clip_image002[8]

Now I know what you’re thinking: If all of your other DC’s are using the System partition to replicate the DNS zones and that is also where there zone information is loaded from, then WHY would these DC’s load the “blank” zone from the DomainDNSzones partition?  I’m glad you asked because I did the same thing.  When we looked at the System partitions on the DC’s we found that all of the correct zone information was there and had not been overwritten by the “blank” zone.  Why did it not load into DNS?

When the new zone replicated to the DomainDNSZones partition this created a duplicate object for the corp1.local zone within AD that in turn caused a collision.  This collision or conflict within AD kept the good zone data from being loaded.  Once we determined that the empty zone existed in DomainDNSzones we simply deleted it and restarted the DNS service on the DCs to restore the proper zone info and name resolution was restored throughout their network.

So what could have prevented this poor soul from becoming THAT guy? Here are some possibilities:

1 – Having a test domain with either physical or virtual machines set up to mimic your corporate environment so upcoming changes can be demonstrated as safe.  Even condensing a world wide environment to a handful of VM’s is better that shooting from the hip.

2 – Having a change control process where the changes to be made are reviewed before granting permission for they implemented.

3 – Having your buddy look over your shoulder and give you a reality check before you press “OK”.

If you would like to know more about the DNS scenario that took place above please follow the link below:

867464 Event ID 4515 is logged in the DNS Server log in Windows Server 2003

And remember: Don’t be THAT guy.

- Steven Martin

NetBIOS browsing across subnets may fail after upgrading to Windows Server 2008

When installing a new Windows 2008 server or upgrading an existing server to Windows 2008, the Computer Browser service is set to disabled by default.

If you upgrade the Domain Controller that is assigned the PDC FSMO role or you move that role to a Windows 2008 DC, you may see the domain wide NetBIOS-based network browse list get smaller and remote subnet machines will disappear from the list.  Eventually you may only see computers from the local subnet in the network browse list.  If you have subnets with only one server and it is Windows 2008, then you may also see inconsistent local subnet browse lists due to clients taking a master browser role and they may be rebooted, turned off, etc.

You may see a combination of all local computers on a subnet and some remote computers on a subnet if you have IPv6 deployed and LLTD is being used with Network Discovery to build a network browse list, using Vista clients and Windows 2008 servers.  To see if that is the case, you can use the "net view" command or the browstat.exe tool to see just the NetBIOS-based browse list.

To resolve this problem, you can either set the Computer Browser service to Automatic on the DC holding the PDC role, or move the PDC role to another DC that has the Computer Browser service started.  You will need File and Printer sharing On in the Network and Sharing Center, otherwise the Computer Browser service will fail to start since the required ports will not be open.  In a multiple subnet environment, make sure WINS is configured properly so that you have the proper NetBIOS name resolution.  After making the corrections, the computers holding the master browser roles will begin to populate the browse list for the entire network.

If you need a tool to test and determine the browsing roles from a Windows Server 2008 machine, you can use the Windows XP Support Tool Browstat.exe on a Windows Server 2008 to determine the computer that has the browse master roles. The Windows XP Service Pack 2 Support Tools can be downloaded from Microsoft at the link listed below and installed on a XP machine.  After that, move the browstat.exe utility to the Windows Server 2008 machine to do the test.

Windows XP Service Pack 2 Support Tools

- Tod Edwards

IPSEC Domain Isolation: A Test Study - Developing a Plan

This post is second in a series by David Pracht and Steve Martin.  To read the first post, click here.

Developing a plan...

We started by brainstorming about what we might need to consider in the environment.

For example – Does the Forest or Domain level matter?  What exceptions will we need? Do we need to consider what OS we configure polices from? What machines will we need?

Our first consideration was how to implement the environment. We decided to implement the simplest possible configuration that a novice user might envision - Domain Isolation using the Microsoft Default policies that look, from their descriptions, like they should work without much modification.  So for example, the servers and clients in the Secure network would need to have an IPsec policy of Secure Server - Require Security.  The Servers and clients in the Boundary network would need to have an IPsec policy of Server - Request Security, and the DC’s and the untrusted servers and clients would need to have an IPsec policy of Client – Respond Only.

Last, all these settings would most likely be set via Group Policy from the DC.

Figure: Basic IPsec Domain Isolation scenario

clip_image002

Along the way the following questions arose.

Q: Does the Forest Level affect IPSec?

A: No the Forest Level does not affect IPSec even when using AuthIP with Windows Server 2008 and Vista as there are no schema extensions.

Q: Does the Domain level affect IPsec?

A: IPSec is not affected by the Domain Level but a 2008 domain level will require all 2008 Domain Controllers. This is not a likely scenario as most people will need to do a migration for Windows Server 2003 and not be able to use a 2008 Domain Level yet.

Q: What do we need to consider concerning Group Policy Management?

A: Group Policy management does have one caveat. Group Policy only requires that the policy be configured from a Windows Vista or Windows Server 2008 machine if you need support for the new features provided with AuthIP.

Our plan is a Windows Server 2003 Domain with 2003 Forest and Domain levels using XP/Windows Server 2003 IPsec policed managed from the DC.

The following machines are used with this plan:

2003 Domain Controller as untrusted
2008 Domain Controller as untrusted
2003 Member Server in the Secure domain
2003 Member Server in the Boundary domain
XP client in the Secure domain

After implementing the above “All Default” plan we experienced the following.
Servers and clients in the Secure zone could not communicate with any other machines.
                This means that they could not:
Resolve names via DNS
Obtain an IP address from DHCP
Request Kerberos  tickets for authentication
or much of anything else except ICMP

Have we forgotten something? Maybe we need this hotfix:

914841 How to simplify the creation and maintenance of Internet Protocol (IPsec) security filters in Windows Server 2003 and Windows XP

The Windows Server 2003 update and the Windows XP hotfix add functionality to Windows that enables you to use an IPsec "Simple Policy." For most environments, the installation of this update and hotfix lets you reduce the number of IPsec filters that are required for a Server Isolation deployment or for a Domain Isolation deployment. You can reduce the number of IPsec filters from many hundreds of filters to only two filters.

We added the hotfix to make sure that the timing was correct for connections but still couldn't make any of the connections work even though it was supposed to allow a configuration with fewer (if any) filters/exceptions.

What was left out of the plan on purpose was something we felt like many customers might not plan for: Exceptions.

So why did our initial set up not work? There is a hint in the points above and we will let you in on the solution with our next post.

- David Pracht

- Steve Martin

New Networking-related KB articles for the week of June 27 - July 3

954412  The IPsec remote management registry value is not preserved when you upgrade your computer to Windows Server 2008 or to a Server Core installation of Windows Server 2008

954408  Dynamic updates do not work on the standard primary DNS zone in Windows Server 2008

954396  The BITS client upload job fails when you use two virtual directories that share the same physical folder on a Windows Server 2008-based computer

954395  An additional cleanup task remains after you upgrade a server that is running BITS from Windows Server 2003 to Windows Server 2008

954423  A Windows Server 2008-based DNS server stops responding, and event ID 7023 is logged in the DNS server event log

- Mike Platts

Intermittent file sharing connectivity from various clients to a Windows Server 2008 server

Issue

In recent weeks we have seen a number of cases with intermittent file sharing connectivity to Windows Server 2008 servers. I wanted to get this information out so that people who may be experiencing the issue won't have to spend a lot of time tracking down the problem.

The issue generally manifests in one of two ways:

  • After a period of time Windows XP and Windows Server 2003 clients can connect to file shares on a Windows Server 2008 server but Windows Vista clients time-out.
  • After a period of time Windows Vista clients can connect to file shares on a Windows Server 2008 server but Windows XP and Windows Server 2003 clients time-out.

Network traces look similar in both cases. After the TCP 3-way handshake the client sends an SMB Negotiate Dialect but the server doesn't respond.

Eventually the TCP session times out and is reset as seen in this example:

image

Resolution

Two things are currently known to address the issue:

  • Upgrading the NIC drivers is known to help but not completely resolve the issue.
  • In the cases we have seen so far, uninstalling anti-virus software has resolved the issue.

Most of these cases involved older anti-virus software versions but we have also seen the issue with current versions that are supported on Windows Server 2008.

While there is not currently a complete resolution, I hope providing this information will help some people identify this issue quickly so they can resolve it and minimize the disruption to their environment.

- David Pracht

DNS name resolution issues after installation of Windows Update discussed in bulletin MS08-037

We have been hearing of an issue since the recent release of an update to address a DNS spoofing vulnerability, MS08-037, discussed in KB951748.  After application of the update, affected systems can experience problems with applications that rely on DNS name resolution.  For example, a user on an affected system would not be able to browse the Internet.

The cases we have seen so far have involve ZoneAlarm software and Check Point Endpoint Security (previously named Check Point Integrity). 

There are updates available for the ZoneAlarm products affected as well as interim workarounds posted at the following link at the ZoneAlarm site:

Workaround to Sudden Loss of Internet Access Problem

Check Point has updates available for its Endpoint Security and Integrity products as well.  These updates and additional information may be found at this link:

Installing Microsoft security update for Windows (KB951748) might prevent Secure Access, Endpoint Security (Integrity) and ZoneAlarm users from accessing the Internet

We recommend updating the Check Point or ZoneAlarm software to correct the problem.  We do not recommend not installing or uninstalling the update described in security bulletin MS08-037.  Please read the bulletin to learn more about this vulnerability:

Microsoft Security Bulletin MS08-037 - Important

More information about the vulnerabilities corrected in this update may be found here:

CVE-2008-1447

CVE-2008-1454

Security Vulnerability Research & Defense - MS-08-037: More entropy for the DNS resolver

- Mike Platts

New Networking-related KB articles for the week of June 21 - June 26

953730  The netsh command cannot start the PNRP Machine Name Publication Service on a Windows Server 2008-based computer

952899  Event IDs 1018 and 1020 appear in the Application log after you remove the SNMP service on a Windows Server 2008-based computer

953828  The NLB host does not converge as expected on Windows Server 2008 Hyper-V virtual machines

954425  Error message when you use the Bitsadmin.exe tool to try to upload files to a Windows Server 2008-based server that is running Internet Information Services 7.0: "The requested URL does not exist on the server"

952131  Piggybacked data on a TCP Acknowledgement (ACK) package may bypass the WFP inspection process in Windows Vista

952709  A reliability and performance update is available for Windows Vista SP1-based computers

954370  Error message when you try to connect to a domain controller for remote administration from a Windows Vista SP1-based computer that has Remote Server Administration Tools (RSAT) installed: "The RPC server is unavailable"

953609  Error message when you try to add a wireless network to a Windows XP-based computer that has hotfix 917021 applied: "At least one of your changes was not applied successfully to the wireless configuration"

- Mike Platts

New Networking-related KB articles for the week of June 14 - June 20

952790  An application is unable to obtain an exclusive lock to a volume after the system runs for several hours in Windows Server 2008 or in Windows Vista Service Pack 1

953270  After a Windows Vista-based computer resumes from hibernation, the computer waits 30 seconds before it starts connecting to a new wireless network

952876  The TCP/IP Registry Compatibility service may stop responding when a computer that is running Windows Vista or Windows Server 2008 is under high stress

953650  You cannot connect to an 802.1X wired network after you upgrade to Windows XP Service Pack 3

953761  Some DHCP Options are not recognized on a Windows XP SP3-based client computer when the DHCP server offer includes option 43

- Mike Platts

Steps to move a DHCP database from a Windows Server 2003 or 2008 to another Windows Server 2008 machine

The DHCP database can be moved or migrated from a Windows Server 2003 server to a Windows Server 2008 server, or from one Windows Server 2008 server to another.  The information below details the necessary steps.

Export the DHCP database from a server that is running Microsoft Windows Server 2003 or Windows Server 2008

To move a DHCP database and configuration from a server that is running Windows Server 2003 or Windows Server 2008 to another server that is running Windows Server 2008:

1.   Log on to the source DHCP server by using an account that is a member of the local Administrators group.

2.   Click Start, click Run, type cmd in the Open box, and then click OK.

3.   Type netsh dhcp server export C:\dhcp.txt all , and then press ENTER.

Note: You must have local administrator permissions to export the data.

Configure the DHCP server service on the server that is running Windows Server 2008

1.   Click Start, click Administrative Tools, click Server Manager. If needed acknowledge User Account Control.

2.   In Roles Summary click Add Roles, click Next, check DHCP server, and then click Next.

Import the DHCP database

1.   Log on as a user who is an explicit member of the local Administrators group. A user account in a group that is a member of the local Administrators group will not work. If a local Administrators account does not exist for the domain controller, restart the computer in Directory Services Restore Mode, and use the administrator account to import the database as described later in this section.

2.   Copy the exported DHCP database file to the local hard disk of the Windows Server 2008-based computer.

3.   Verify that the DHCP service is started on the Windows Server 2008-based computer.

4.   Click Start, click Run, type cmd in the Open box, and then click OK.

5.   At the command prompt, type netsh dhcp server import c:\dhcpdatabase.txt all , and then press ENTER, where c:\dhcpdatabase.txt is the full path and file name of the database file that you copied to the server.

Note When you try to export a DHCP database from a Windows 2000/2003 domain controller to a Windows Server 2008 member server of the domain, you may receive the following error message:

         Error initializing and reading the service configuration - Access Denied

Note You must have local administrator permissions to import the data.

6.   To resolve this issue, add the Windows Server 2008 DHCP server computer to the DHCP Admins group at the Enterprise level and redo steps 4 & 5.

7.   If the "access is denied" error message occurs after you add the Windows Server 2008 DCHP server computer to the DHCP Admins group at the Enterprise level that is mentioned in step 6, verify that the user account that is currently used to import belongs to the local Administrators group. If the account does not belong to this group, add the account to that group, or log on as a local administrator to complete the import and redo steps 4 & 5.

Authorize the DHCP server

1.   Click Start, point to All Programs, point to Administrative Tools, and then click DHCP.

Note You must be logged on to the server by using an account that is a member of the Administrators group. In an Active Directory domain, you must be logged on to the server by using an account that is a member of the Enterprise Administrators group.

2.   In the console tree of the DHCP snap-in, expand the new DHCP server. If there is a red arrow in the lower-right corner of the server object, the server has not yet been authorized.

3.   Right-click the server object, and then click Authorize.

4.   After several moments, right-click the server again, and then click Refresh. A green arrow indicates that the DHCP server is authorized.

- Wayne Melvin

Differences in network performance between Windows Vista/Windows Server 2008 and Windows XP/Windows Server 2003
Overview of Windows Vista and Windows Server 2008 performance improvements

This is just an overview; I am including several links with more detail on Windows Vista and Windows Server 2008 networking. You can take this as far as you like; it is a very deep rabbit hole.

For simplicity I am going to compare Windows XP and Windows Vista. Please remember that Windows Server 2008 contains the updated networking stack that was introduced in Windows Vista so the comparison is still valid.

We have had a few support calls in Networking Support lately where people are comparing network performance between operating systems and they want to know two things:

  1. Why is Windows Vista so much faster on the network when connecting to another Windows Vista or Windows Server 2008 system, especially for SMB?
  2. How do I make Windows XP perform like Windows Vista?

Actually, the second question is usually asked more along the line of "why is my Windows XP computer broken and what can I do to "fix" it?" but I think you get the point.

Let me start by saying that there is nothing "wrong" with Windows XP.  It is not "broken" and does not need to be "fixed".

To answer question 2 first, you will never get Windows XP to perform exactly like Windows Vista from a networking perspective; the network stack is very different between the two. There are some changes that can be made to Windows XP that may affect performance. Notice that I said "changes". This is because in some of these changes there are potential tradeoffs to resources on the local system that could negatively impact overall system performance and could change the behavior of TCP in a way that may actually decrease performance on the network. In some instances making these changes on a large scale to several clients could even negatively impact the overall performance of your entire network. 

So why the difference?

I recently had a call from a customer who was seeing up to a 7 times performance improvement when transferring files between two systems running Windows Vista, compared to transferring the same files between two Windows XP systems. I found this fairly impressive since in the testing and studies I have read about the expected improvement was generally about 3.5 times. So I agreed to investigate to ensure that there was in fact not a problem with Windows XP. After reviewing much data and testing some changes on the Windows XP system we concluded that he was in fact seeing that much better performance across the wire for his Windows Vista systems.

To answer question one, what changed that could explain such a difference in performance? Well, a lot. Starting with Windows Vista we have a new network stack. The Cable Guy, aka Joe Davies (you may have noticed his name on the cover of some of the MS Press books), has written some good overviews of the new network stack, you can find them at the following links.

Next Generation TCP/IP Stack in Windows Vista and Windows Server 2008
http://technet.microsoft.com/en-us/library/bb878108.aspx
Performance Enhancements in the Next Generation TCP/IP Stack
http://technet.microsoft.com/en-us/library/bb878127.aspx

Some of the really cool stuff that has been added to the new network stack is:

  • Receive Windows auto-tuning - Allows for tuning the maximum receive window size based on current network conditions.
  • Compound TCP - This allows for more aggressive increase of the send window especially in high bandwidth and high delay networks.
  • ECN Support - Allows routers that are experience congestion to mark packets so peers who receive these packets can lower their transmission rates.

I hope everyone reading this can appreciate how huge this is. More aggressive send and receive and more intelligent congestion avoidance! If you’re a network admin and you didn't already know about this and your still in your chair, check your pulse, you should be dancing about and people should be looking at you like you have lost your mind. This is part of the "magic" that will allow for more throughput while also avoiding congestion so fewer retransmitted packets. Yay!

But then you have to sit down and realize that these are changes to the very core of the networking stack and these changes which involve large amounts of code changes can never be made to Windows XP, the new stack is just too different.

But that's not all, act now and receive...

So besides the network stack there is another improvement. This is more at an application layer but very important for things like file copies.

Let me point out again that the better performance we saw was doing a file copy between Windows Vista or Windows Server 2008 connecting to another Windows Vista or Windows 2008 system. One reason this is significant is something called SMB2. SMB2 is only available starting with Windows Vista so even if you are on a Windows Vista client, if you connect to a Windows XP or Windows Server 2003 system you will not be able to take advantage of the improvements made in SMB2.

A good quick overview of SMB2 is actually on the Performance Team blog.
http://blogs.technet.com/askperf/archive/2008/05/30/two-minute-drill-overview-of-smb-2-0.aspx

Some of the changes made in SMB2 include;

  • Sending multiple SMB commands in the same packet which reduces the number of packets sent between a client and server
  • Larger buffer sizes
  • Increased scalability in terms of the number of shares, users, and simultaneously open files
  • Support for Durable Handles - These are handles that can survive a network disconnect.

So this also translates to a much improved user experience for anything using SMB 2, such as file copies.

In summary

As I mentioned this was just an overview but I wanted to make sure everyone understands why they may be seeing some difference in the performance of legacy systems and Windows Vista and Windows server 2008 and also help explain why these changes won't be back ported to the legacy systems.

References:

For a comparison of Windows XP and Windows Vista networking performance, see the results of the the analysis done by The Tolly Group.  This can be downloaded from the following link.
http://www.microsoft.com/downloads/details.aspx?FamilyID=04cad8b9-9f9f-453a-893a-458d22dbb3c5&DisplayLang=en
Mark Russinovich's blog "Inside Vista SP1 File Copy Improvements."
http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx
Next Generation TCP/IP Stack in Windows Vista and Windows Server 2008
http://technet.microsoft.com/en-us/library/bb878108.aspx
Performance Enhancements in the Next Generation TCP/IP Stack
http://technet.microsoft.com/en-us/library/bb878127.aspx
SMB2 Two Minute Drill on the Performance Team blog.
http://blogs.technet.com/askperf/archive/2008/05/30/two-minute-drill-overview-of-smb-2-0.aspx

- Clark Satter

More Posts Next page »
Page view tracker