Privacy.  Personally Identifiable Information.  Choice.  Disclosure.  These are all key concepts in the digital age.  We expose more of our personal data electronically than at any time in our history.  IE8 gives users more choice about controlling what information is shared – browsing history, cookies, preferences etc.  Andy Ziegler and Dean Hachamovitch, who are both Program Managers at Microsoft have posted a couple of detailed posts on IE8 and Privacy:

• Privacy Beyond Blocking Cookies: Bringing Awareness to Third-Party Content – Dean Hachamovitch
• IE8 and Privacy – Andy Ziegler

Enjoy!

- CC Hameed

Share this post :

Welcome back AskPerf readers!  For our readers in the United States, I hope you enjoyed your three day weekend for the Labor Day holiday, but it’s time to get back to work.  I know today’s title looks like it should be posted on one of our Networking blogs, but we see a few issues with name resolution over on the Performance team – especially when the problem relates to applications not functioning as expected.  So let’s dive right in …

When troubleshooting name resolution problems as they relate to application functionality, it is important to determine how the application connects – does it use NetBIOS name resolution or does it use sockets (host name resolution)?  NetBIOS application issues – especially with applications such as Windows Explorer, My Network Places and use of the various net commands (such as net use) are the ones that we see quite often on the Performance team.  When the Performance team supported Internet Explorer (which uses sockets / host name resolution), we obviously dealt with our fair share of customer incidents dealing with connectivity.

The most common symptom of a NetBIOS name resolution problem is the Error 53 message.  This message is returned when name resolution fails for a particular computer name or when there is a problem establishing a NetBIOS session – such as trying to connect to \\<servername>.  However, the error message itself does not tell you whether the problem is a name resolution one, or a session establishment problem.  To narrow down the problem you can try a couple of different tests:

• net view \\hostname: if this works, then you probably do not have a name resolution issue.  You can also ping the hostname to confirm this.  However, remember that if you encounter a problem connecting to a share name, for example, that the problem could also be due to an incorrect entry in DNS / WINS.  In that type of scenario, simple connectivity tests may work such as net view and ping, but net use will still return an Error 53, because the server does not have the resource name you are trying to use.
• net view \\ipaddress: This actually removes the name resolution piece from the equation.  By connecting directly to the IP address, we bypass both DNS and WINS.  If this test fails, then the problem is in establishing the NetBIOS session itself

When troubleshooting sockets (host name resolution) connections issues, we can still use the ping command – however, you should always specify the Fully Qualified Domain Name (FQDN) for the target machine to ensure that you are hitting the right system.  You can also use nslookup hostname to determine not only if you are hitting the correct machine, but also to determine if the DNS entry on whichever server you are using for your lookup server is correct.

Remember that we often assume that entries in the DNS and WINS server databases are correct – it never hurts to double check them!  That holds especially true if you are using static LMHosts or HOSTS files – it’s one of those things that we tend to overlook (and forget!) when dealing with name resolution.  This is especially true in legacy environments that have been upgraded.  The remnants of the old HOSTS / LMHOSTS file can create some issues.

With that, I’ll bring this post to a close.  Until next time …

- CC Hameed

From time to time, a customer support incident for a bugcheck will make its way over to us on the Performance team.  Those of you that have worked with support engineers on the Performance team already know that we generally don’t work with bugcheck issues.  Our Setup / Cluster team has that honor.  However, the STOP 0xC2 error message is BAD_POOL_CALLER, and that word POOL causes administrators and even some support engineers to think “Performance issue” rather than “Bugcheck issue”.  It’s funny how we can sometimes get so hung up on a word or phrase that we develop tunnel vision!  Today we’re going to clear up the confusion behind this Bugcheck …

The STOP 0xC2 message does not indicate resource depletion in the same vein as our old Event ID friends 2019 & 2020.  This bugcheck message means that some Kernel-mode process or driver attempted to perform an invalid memory operation – for example:

• Allocating a memory pool size of zero bytes
• Allocating a non-existent memory pool
• Trying to free a memory pool that has already been freed
• Allocating a free memory pool at an IRQL that is too high

Now that we know what our bugcheck actually means, how do we troubleshoot it?  The key parameter is the first one – that indicates the type of violation and determines the meaning of the other three parameters.  If you download and install the Debugging Tools for Windows, the Debugger.chm file provided as part of the installation has a Bugcheck Code reference section.  The table below is taken directly from the section on STOP 0xC2 errors and how to interpret the different parameters.

As you can see, there are a number of different combinations to consider when dealing with STOP 0xC2 errors, and obviously if you are comfortable with kernel debugging, then this information will mean quite a bit more to you.  For administrators who aren’t as familiar with debugging, there are a number of different troubleshooting options to consider – if the Bugcheck message lists a driver by name, you may need to update (if the driver is old), roll back (if the driver was recently updated) or disable that driver and work with the driver manufacturer for a resolution.  Obviously if there is a hardware component itself that is failing then removing or replacing that component would be the logical course of action.  You should also consider this problem from a software compatibility perspective.  Incompatible drivers, services, anti-virus scanners or backup software packages could all be potential causes for this type of issue – especially in Operating System upgrade scenarios.

There’s a lot of information to digest in this post, but the key takeaway is that the problem with a STOP 0xC2 is not (as is sometimes inferred) Pool Memory resource depletion – it is actually an invalid memory operation.  That’s it for today!  Until next time …

Share this post :

We deal with application and service issues on a daily basis.  Normally the problems relate to applications not performing as expected, hanging or crashing.  However, every so often someone will ask us what network port a service is using.  Unless we are talking about one of the well known services such as SMTP, FTP, HTTP, RDP, LDAP, basic RPC etc, the ports being used are potentially subject to change.  That does make life a little more challenging – but it’s nothing that we can’t figure out using some simple tools.

When considering network port numbers, the numbers are divided into three ranges: the Well Known ports, the Registered ports and the Dynamic (Private) ports.  The Internet Assigned Numbers Authority (IANA) is responsible for the global coordination of the port assignments.  The Well Known port range is from 0 – 1023, Registered ports run from 1024 – 49151, and the Dynamic ports run from 49152 – 65535.

So how do we determine the port that a service is using?  Without using Network Monitor, Wireshark or a similar utility, there are a couple of very handy utilities provided with the operating system that we can use – NETSTAT.EXE and TASKLIST.EXE.  Most administrators are familiar with NETSTAT.EXE already, but for those who are not, you can use NETSTAT.EXE to identify what ports are being used by a particular process.  The syntax that we will be using for NETSTAT.EXE is as follows: netstat.exe –a –n –o.  The switches we are using provide the following:

• -a: listing of all connections and listening ports
• -n: display address and port numbers in numerical form
• -o: display the owning PID associated with each connection

When the command is run, you will see output similar to what is below.  Something to keep in mind is that in the Proto column, the protocol may be TCP or UDP.

If there is a specific port in use that we want to examine, we need the PID of the owning process, and TASKLIST.EXE.  Turning our attention to TASKLIST.EXE, we covered some of the functionality in our post, Getting Started with SVCHOST.EXE Troubleshooting.  The command that we use to dump out all of the processes and their PID’s is simply tasklist.exe.  When I run this command, this is what the output looks like:

So, looking at the output from these two utilities, I can take the port number, and then map the PID to a specific process.  If the process that you are looking at is an instance of SVCHOST.EXE – let’s use PID 4784 as our example, then you will need to use slightly different switches for TASKLIST.EXE as shown below:

And thus I can tell exactly what services are running in that instance of SVCHOST.EXE.

And with that, we’ve reached the end of our post.  Until next time …

Additional Resources:

• IANA Port Assignments
• Microsoft KB Article 832017: Service Overview and Network Port Requirements for the Windows Server system
• Microsoft KB Article 319553: How to restrict FRS (File Replication Service) replication traffic to a specific static port
• Microsoft KB Article 224196: Restricting Active Directory replication traffic and client RPC traffic to a specific port

- CC Hameed

Share this post :

Hello AskPerf readers.  My name is Scott McArthur and  I am a Support Escalation Engineer with the Setup & Cluster team.  I know you’re probably thinking that one of us has somehow found our way to the wrong blog!  I recently ran into an interesting scenario while working on a customer issue, and since this has some impact on Application Compatibility, I figured AskPerf would be the best place to write about it.

The customer’s issue I was working on dealt with an application install failure on a 64-bit installation of  Windows Vista.  The application in question required Windows Vista Service Pack 1 as a prerequisite for installation, and the system administrator duly installed SP1 and then proceeded to launch the installation of the application.  And then, a funny thing happened – the application returned an error, indicating that Service Pack 1 for Windows Vista was not installed.  According to the Windows Update logs, the SP1 installation appeared to have completed without incident.  Trying the installation of the application on another machine, the administrator found that he encountered the same problem on every Windows Vista SP1 machine.  As Alice said, while in Wonderland, “curiouser and curiouser” …

It turned out that the problem wasn’t with the installation of Service Pack 1.  The problem lay in the method being used by the application to check the OS and Service Pack version.  The application was checking for the OS version in a registry value, specifically: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\CSDVersion.  On the x64 version of Windows Vista Service Pack 1, however this value does not exist.  The correct value does show up under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion however.  This highlights an inherent problem with relying on the registry method to capture this information.  As operating systems evolve, there is no guarantee that registry information will persist between operating systems, or in some cases there may be changes between service packs for the same operating system.

When determining OS versions for application installs, a better method than reading the registry would be to either use a WMI query or to use an API.  The GetVersionEx function is designed to retrieve this information and is not affected by change.  One caveat though – if you are testing for whether a particular feature is installed, the GetVersionEx function would not be the best approach.  With that in mind, below are some items returned by using this function that are specific to Service Packs:

• szCSDVersion: A null-terminated string, such as "Service Pack 3", that indicates the latest Service Pack installed on the system. If no Service Pack has been installed, the string is empty.
• wServicePackMajor:  The major version number of the latest Service Pack installed on the system. For example, for Service Pack 3, the major version number is 3. If no Service Pack has been installed, the value is zero.
• wServicePackMinor: The minor version number of the latest Service Pack installed on the system. For example, for Service Pack 3, the minor version number is 0.

And on that note, we’ve reached the end of this post.  Thanks for dropping by!

Additional Resources:

• MSDN: GetVersionEx function

- Scott McArthur

Share this post :

Hi, my name is Mark Ghazai and I am a Support Escalation Engineer on the Performance team.  Today, we’re going to discuss how to modify the Remote Desktop option on the Windows Server 2008 TS Web Access page.  This has been a fairly common question over the last few months.  In particular, many of our customers have asked how they can force connections through the TS Gateway.  Contrary to popular belief, making this configuration change is not as difficult as you might have thought …

Here’s the screen shot of Remote Desktop Option under TS Web Access page – if you’ve been using Windows Server 2008 TS Web Access, you are already familiar with this page:

In the TechNet article listed at the end of this post, there are instructions on how to specify the TSGateway for this Remote Desktop Connection (see the screen shot below):

Observing the TS Web Access behavior, you can see that IIS ASP application automatically detects if the user is on the local or external network.  If the user is on the local network, the web application will bypass the TSGateway by default.  But, what if you want to route all Remote Desktop connections using this option through your TSGateway server regardless of location?  With a fairly simple page modification, this can be done;

1. In the Internet Information Services (IIS) Manager Console, navigate to the TS folder under the Default Web Site.  This is the default path, you’ll need to navigate to the custom path if you’ve customized the TS Web Access site settings.
2. Right Click on the TS and select Explore option.
3. Windows Explorer should open that Web page folder associated with TS Web Access website.
4. Navigate to the \Web\TS\en-US
5. Edit the Desktops.aspx file using a text editor such as Notepad.

   

6. Modify the following section in the Desktops.aspx file and Save it.  NOTE: I would highly recommend making a backup of this file … just in case!

   

7. This change will take effect as soon as you restart the web site in the IIS Manager Console.  Making this change will force the Remote Desktop to be routed through TSGateway server (by default port 443) on all clients regardless of their location.

And that brings us to the end of our post.  Hopefully this helps answer some of your questions in this regard.  Until next time …

Additional Resources:

• Technet: Configure Remote Desktop Web Connection Behavior
• WS2008: Terminal Server Web Access Architecture

- Mark Ghazai

Share this post :

Today’s post is a friendly reminder about the August 2008 Cumulative DST Packages for Windows which have been released to the Microsoft Download Center for supported versions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. 

This update, which is published as Microsoft KB Article 951072 supersedes and replaces the December 2007 DST Update (Microsoft KB Article 942763).  This update also includes additional time zone changes that were signed into law after the update in Microsoft KB Article 933360 (August 2007 Cumulative DST update for Windows) was released.

If you have already deployed the December 2007 DST Update, please review the information in Microsoft KB Article 951072 to determine whether you need to deploy this update immediately.  For Exchange specific DST information, please refer to the Daylight Saving Time Help and Support Center and as well as the Exchange team blog.

NOTE:  The August 2008 DST Package for Windows will be pushed out via Windows Update on August 12, 2008 for Windows Server 2008, Windows Server 2003, Windows Vista and Windows XP.

Additional Resources:

Daylight Saving Time Help and Support Center
The Microsoft Exchange Team Blog

- CC Hameed

Every so often, a customer needs to enable logging on their print queues to capture as much information about print activities on their server.  Configuring the logging options is actually quite an easy administrative task, but there are a couple of different ways to configure the options – through the GUI or through the registry.  First, the GUI method.  To configure the logging options, open the Printers applet on the server from within Control Panel.  Right click on a blank area of the window, select Server Properties and navigate to the Advanced tab.  On this tab, there are three checkboxes that you want to check:

1. Log Spooler Error Events
2. Log Spooler Warning Events
3. Log Spooler Information Events

One caveat – if you are doing this on a Windows Server 2008 (or Windows Vista) machine, you do need to make sure that you use the “Run As Administrator” option to invoke Server Properties – otherwise you will not be able to modify the logging options as shown below:

Once you select the option using “Run As Administrator”, the check boxes are enabled.

Now let’s quickly cover how to modify the options via the registry.  The key you need to modify is HKLM\System\CurrentControlSet\Control\Print\Providers\Eventlog.  The same options above are available, but you modify the EventLog value to reflect the options.  Thus:

1. Log Spooler Error Events – set the value to 1
2. Log Spooler Warning Events – set the value to 2
3. Log Spooler Information Events – set the value to 4

You can enable these in different combinations by adding the appropriate values and using the sum as the value for Eventlog.  Thus, to enable all three options – set the value to 7.

Once you have your options configured, you will start to see Event Log messages that look like the sample one below:

Product: Windows Operating System 
ID: 10 
Source: Microsoft-Windows-PrintSpooler 
Version: 6.0 
Symbolic Name: MSG_DOCUMENT_PRINTED 
Message: Document %1, %2 owned by %3 was printed on %4 through port %5. Size in bytes: %6. Pages printed: %7

And with that, we are at the end of this post.  Until next time …

- CC Hameed

Share this post :

File system filter drivers are often the topic of some interesting discussions when working on server performance issues.  Understanding how a file system filter driver works is the topic of today’s post.  We’ll also quickly discuss one of the most common issues that we see  - especially when dealing with Anti-Virus filter drivers and updates.

Simply put, a file system filter driver is a driver that sits on top of the file system and examines requests made to the file system to determine how (and in some cases, IF) the request should be handled.  Different applications such are remote file replication services and file encryption use filter drivers, but the one with which we are all familiar is the Anti-Virus filter driver. 

Let’s look at an example of how this works when real-time scanning is enabled.  When an application tries to open a file, the filter driver intercepts the request and examines the file being opened to ensure that it does not have a virus.  If the file is clean, then the request is sent on to the file system.  However, if the file is infected, then the virus scanner notifies its associated Windows service process to quarantine or clean the file.  If the file cannot be cleaned, then the filter driver fails the request (usually with an Access Denied error) so that the virus cannot become active.

Now, you’re probably asking yourself, “That’s great, but what does this have to do with server performance?”  If a file system filter driver is not functioning properly, requests may get stuck, time out or fail – and not because the file being accessed is infected with a virus.  From the user’s perspective, access to their files (usually across the LAN / WAN) appears to be incredibly slow, or the files may appear to be inaccessible.  For those of you that have worked with our Support Engineers on issues like this, one of our common lines of questioning concerns how Anti-Virus, specifically On-Access or Real-Time scanning, is configured.  Which brings us to the second part of our post … the most common “gotcha” that we see with respect to the Anti-Virus filter driver and updates …

When updating Anti-Virus, the primary concern is ensuring that the Anti-Virus signature file is current to guard against emerging threats and existing viruses.  However, although keeping your signature file current is obviously important, it is equally important to ensure that your Anti-Virus file system filter driver is kept up to date as well.  We have had more than a few issues where a customer has reported Pool memory depletion or a server soft hang, and after investigating, the culprit turned out to be an outdated file system filter driver for the Anti-Virus software.  As part of your maintenance routine, when keeping an eye out for updated drivers and firmware for your servers, you should also keep an eye out to make sure that you are running the latest file system filter drivers for your Anti-Virus as well.

And with that, we’ve reached the end of our post.  Hopefully this sheds some light on what is going on behind the scenes when you are opening files, or using real-time scanning.  Until next time …

Additional Resources:

• WHDC – File System Filter Drivers
• MSDN: Load Order Groups for File System Filter Drivers
• GES Blog: The Case of the Low Hanging Filter Driver

- CC Hameed

Share this post :

We are doing some research into how our readers view our blogs and how we can improve them.  To that end, we are conducting a survey of our blog readers.  Below is the request from Ed Jolly, one of our directors:

UPDATES:

• 8/23/2008 - removed link to web survey.  Survey closed on 8/22

Although Internet Explorer support is no longer part of our portfolio on the Performance team, we do still keep an eye on what’s going on in the world of IE.  The IE team is looking for Beta Testers.  Below is the post from the IE Team Blog:

If you’re interested in helping test the newest version of Internet Explorer, contact the IE team and let them know!

- CC Hameed

Share this post :

Hello again AskPerf!  This is Austin.  In my last post, we discussed how to get a network trace using OneClick.  Today, I’m going to show you how you might use that data.  The example I am going to use is for a file server that is acting sluggish and show you how two registry values might alleviate some of your issues.  Don’t worry, we’re not going to start another chorus of “Get Rid of those .PST Files” – we’re going to assume that you’re in a .PST-free zone today!  Let’s take our network capture that we got from our OneClick session.  We are going to use Wireshark to do a two-minute analysis on our capture file.

Open up your .CAP file in Wireshark.  Once the capture file is loaded, click on Statistics, then Protocol Hierarchy.  This provides you with a breakdown of your network traffic.  When investigating sluggish file server issues, one of the things we look for is whether or not there is a disproportionate amount of Server Message Block (SMB) traffic – file / folder access type traffic.

In this capture we can see that well over 60% of the Network traffic is being generated by SMB.  The rest of the traffic percentage is the TCP overhead to encapsulate the packet.  Now let’s figure out if the SMB traffic is being caused by Change Notify requests.  Change notify requests are folder / file query requests when a change occurs to auto-refresh Windows Explorer.  Most folks notice this on Windows XP systems when their Windows Explorer screen seems to be flickering – because it’s auto-refreshing.  Let’s see if that’s what is really happening here.  To view the SMB details in Wireshark, click Statistics, then Service Response Time, SMB and then Create Stat.  Below is the SMB breakdown from our problem scenario:

Looking at this breakdown, we can see than over 50% of the traffic is Trans2 commands.  90% of the Transaction2 sub-commands are  are QUERY_FILE_INFO and QUERY_PATH_INFO.  Translation?  Something changed and Windows Explorer is refreshing its view … a lot!

As you can see, with a simple network trace and a couple of minutes work we’ve figured out where most of the traffic is coming from.  So how do we fix this?  Enter our two registry values:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\explorer
NoRemoteRecursiveEvents=1 (Dword)
NoRemoteChangeNotify=1 (Dword)

If the majority of the Trans2 Sub-Commands had been QUERY_PATH_INFO, we could have gone ahead and only enabled caching for all files and folders as opposed to both of the registry values above.  This would preserve the Auto-refresh feature in Windows Explorer, as opposed to the user having to use the F5 key to refresh the view (which is what you had to do in Windows 2000).  To enable the caching, set the registry value below:

HKLM\SYSTEM\CurrentControlSet\Services\MrxSmb\Parameters
InfoCacheLevel=10    (hex Dword / 10  – Enables caching for all files and folders  )

Alternatively, you could use the registry value above in conjunction with the NoRemoteRecursiveEvents entry so that some Windows Explorer refreshes happen automatically.  To dig into what files are being accessed by QUERY_PATH_INFO, you can set up a query in WireShark.  The query for this is: smb.trans2.cmd==0x5.  One thing to note here is that SMB refers to SMB 1.0 – not SMB 2.0.  When examining the traces in WireShark or Network Monitor, keep in mind what version of SMB you are seeing.  You could also see what type of files are being accessed by using the following WireShark query: smb.file contains "\\".

With that, it’s time to bring this post to a close.  Hopefully you are able to use this information to perform more in-depth investigations of what ails your file servers!

- Austin Mack

Share this post :

We often get questions on configuring Terminal Server Authentication.  The questions have less to do with configuring a simple logon scenario than they do with preventing attacks, in particular “Man in the Middle” attacks – especially when the Terminal Servers may be publicly accessible.  For those of you who are unfamiliar with the “Man in the Middle” scenario, this describes a situation in which an attacker intercepts the communication between two parties, and impersonates each one to the other.  There have been several improvements in Terminal Server security that can protect against attacks.

Our fellow bloggers on the Terminal Services team published post on Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks.  The post covers Network Level Authentication (NLA) and using SSL / TLS (among others).

Until next time …

- CC Hameed

Share this post :

Hello AskPerf readers!  My name is Austin and I am a Technical Lead on the Performance team.  In several of our posts, we’ve discussed troubleshooting server performance issues, especially on file servers.  Most of you have probably already read our post on Network .PST files, or Windows Explorer and SMB Traffic.  We have seen an increase in file server load issue that go beyond some of the obvious issues such as Network .PST files, misbehaving filter drivers, or pool memory depletion. As server environments continue to scale upwards with larger file server needs and thousands of clients connecting to file servers for user profiles and redirected documents, these issues become more common.

When troubleshooting these issues, there is often a need to capture a Network trace of the problem while it is occurring.  However, not every administrator is comfortable with capturing network traces.  On top of that, reading network traces is a bit of an art – and one that does take some time to master.  Today we are going to discuss a tool that can help you capture a network trace with very little effort.  In my next post, I’ll show you how to take that network trace and perform a quick analysis on it that doesn’t require you to be a network expert and apply some simple fixes that have resolved many of the issues that we have seen.  So, let’s get started …

The tool we are going to use is Network Monitor 3.1 OneClick.  This is a free tool available from the Microsoft Download Center.  There are two OneClick packages available – Autorun and ExtractOnly.  The Autorun package installs Network Monitor 3.1 on your machine if you did not previously have it installed and begin a network capture.  The capture is designed to stop automatically when it reaches 30MB in size, or after 120 minutes – whichever comes first.  After the capture completes, if you did not have Network Monitor 3.1 already installed on your machine, then Network Monitor 3.1 is automatically uninstalled.  The ExtractOnly packages is used if you want to save the OneClick utility on a USB key or other portable media and run the tool later on a different machine.  Let’s take a look at how the Autorun package runs on a Windows Server 2008 machine.

When you run the tool, the first thing you are prompted for is a path to save your network capture.  As you can see, the default location to save the capture is in your profile in the “Network Captures” folder.  For this demonstration, I am going to save the data in a different location – C:\TOOLS\NETCAPS.

If you are running this tool on Windows Vista or Windows Server 2008 with UAC enabled, you will see the following if you did not run the program with elevated privileges.  Alternatively, if your user account is in the NetMon Users group on the local machine, you should not encounter this error:

So, let’s try this again – and this time, we’ll launch the program with elevated privileges:

This time, Network Monitor 3.1 installed successfully, and the capture is launched.  If I look in the folder where I saved the capture, I can see that the capture reached the maximum size of 30MB and has stopped growing:

Once I am ready to end the capture (assuming that 120 minutes has not elapsed and auto-terminated the capture), I hit the ‘x’ key to terminate the capture and the capturing ends, and Network Monitor is removed:

And that’s how easy it is to get a Network Capture on a server!  The OneClick application automatically captures the traffic on all network interfaces so you don’t even need to worry about specifying which network card to monitor – which is very useful on multi-homed machines, such as cluster servers.

With that, it is time to bring this post to an end.  In my next post, we’ll take a look at an actual capture from a file server having issues and go over a quick fix you might be able to use in your environment,

- Austin Mack

Share this post :

The new cumulative DST Packages for Windows have been released to the Microsoft Download Center for supported versions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008.  This update, which is published as Microsoft KB Article 951072 supersedes and replaces the December 2007 DST Update (Microsoft KB Article 942763).  This update also includes additional time zone changes that were signed into law after the update in Microsoft KB Article 933360 (August 2007 Cumulative DST update for Windows) was released.

If you have already deployed the December 2007 DST Update, please review the information in Microsoft KB Article 951072 to determine whether you need to deploy this update immediately.  For Exchange specific DST information, please refer to the Daylight Saving Time Help and Support Center and as well as the Exchange team blog.

Additional Resources:

• Daylight Saving Time Help and Support Center
• The Microsoft Exchange Team Blog

- CC Hameed

Share this post :