March, 2012

  • FIXED: Cluster Shared Volumes (CSV) in redirected access mode after installing McAfee VSE 8.7 Patch 5 or 8.8 Patch 1

    A fix for the above titled problem has been released.  If you are running into this problem, please downlaod and install the following fix on all Clusters running McAfee and wanting the updates they provide.

    Redirected mode is enabled unexpectedly in a Cluster Shared Volume when you are running a third-party application in a Windows Server 2008 R2-based cluster;EN-US;2674551


    Below is the information from the original post:

    There is an issue with Cluster Shared Volumes and McAfee VirusScan Enterprise that I wanted to pass along. When installing McAfee VSE 8.7 Patch 5 or 8.8 Patch 1, the CSV drives will go into redirected mode and will not go out of it.

    The reason for this is that the McAfee filter driver (mfehidk.sys) is using decimal points in the altitude to help in identifying upgrade scenarios for their product. The Cluster CSV filter only accepts whole numbers and puts the drives in redirected access mode when it sees this decimal value.

    When seeing this, if you run FLTMC from an administrative command prompt, you may see something similar too:

    C:\> fltmc

    Filter Name   Num Instances   Altitude   Frame
    CSVFilter          2          404900       0
    mfehidk                       329998.99  <Legacy>
    mfehidk            2          321300.00    0

    If you were to generate a Cluster Log, you would see the below identifying that it cannot read the altitude value properly.

    INFO [DCM] FsFilterCanUseDirectIO is called for \\?\Volume{188c44f1-9cd0-11df-926b-a4ca2baf36ff}\
    ERR mscs::FilterSnooper::CanUseDirectIO: BadFormat(5917)' because of 'non-digit found'
    INFO [DCM] PostOnline. CanUseDirectIO for C2V1 => false

    McAfee has released the following document giving a temporary workaround.

    Cluster Shared Volumes (CSV) status becomes Online (Redirected access)

    Microsoft is aware of the problem and currently working on a fix. When this fix is available, this will be updated and a new KB Article will be created with the fix.

    John Marlin
    Senior Support Escalation Engineer
    Microsoft Enterprise Platforms Support

  • Performance issues due to Inactive Terminal Server Ports

    Good morning AskPerf!  There are several issues that have been associated with a high number of inactive Terminal Server ports.  Delayed logon times to RDP sessions, failure of printers to redirect, and slow server performance due to registry bloat from all the ports. These inactive TS ports accumulate because the Remote Desktop Services Device Redirector service creates a new port every time an RDP session is established, but the ports are not always recycled.  Every RDP session can possibly create a new port, and every ended session means a new inactive port. Performance degradation is known to occur when 250 or more TS ports exist in the registry. Increasingly large numbers of redirected devices will exacerbate performance delays.

    To eliminate any issues these TS ports may cause, we have a new Windows Server 2008 R2 hotfix.  The Hotfix can be downloaded here - KB 2655998 Long logon time when you establish an RD session to a Windows Server 2008 R2-based RD Session Host server if Printer Redirection is enabled.  This hotfix will prevent inactive TS ports from accumulating in the future, but you also have to clean up any currently inactive TS ports using the Fixit tool included in KB2655998.  The FixIT tool itself can also be downloaded directly from  The FixIt tool will remove the entries already accumulated under the TS ports registry key below:


    Because the Hotfix and the FixIt perform two different functions, you must install the Hotfix and run the FixIt one time on your 2008 R2 Remote Desktop Server. 

    For down-level operating systems such as Server 2003, Server 2008 Terminal Servers and Windows 7 in a VDI scenario, we highly recommend a scheduled task be created to execute the Inactive TS Port FixIt on a bi-weekly basis, since the hotfix only supports Windows Server 2008 R2 at this time.

    The FixIt is an MSI package so you can run it silently with no user interaction required.  Follow these simple steps:

    1. Locate the MSI file in Windows Explorer and note the exact path to it

    2. Click Start and type in the following:

    msiexec /package “path” /quiet

    For example, if the MSI file MicrosoftFixit50833.msi is located in the “temp” folder of your C drive, then the path would be C:\temp\MicrosoftFixit50833.msi and the command would look like this:

    msiexec /package “C:\temp\MicrosoftFixit50833.msi” /quiet

    3. To add logging and check the results, use this command:

    msiexec /package "c:\temp\MicrosoftFixit50833.msi" /quiet /log c:\temp\MSI50833.log

    Additional Resources

    -Jess Cunningham

  • Print update rollup available for Windows 7 & Windows Server 2008 R2

    A new printing hotfix rollup was released that updates the core print spooler components localspl.dll, splwow64.exe, spoolsv.exe, win32spl.dll, and Winprint.dll.  This rollup is designed to reduce known issues such as printing performance, print spooler crashes, connectivity to print queues, and print driver installation. 

    To download the update and get more information on the fixes included in this rollup, please see KB article 2647753:  Description of an update rollup for the printing core components in Windows 7 and in Windows Server 2008 R2

    Many of the printing related support cases at Microsoft are resolved by one of the included hotfixes.   We highly recommend installing this hotfix rollup when troubleshooting any printing related issues. 

  • Why is the CNO in a Failed State?

    Hello, my name is Steven Graves and I am a Support Escalation Engineer (SEE) in the Platforms Support group here at Microsoft. One of the technologies I support is Windows Server Failover Clustering. I’d like to take a couple of minutes to share some information on an issue I previously worked on. The customer wanted to create an Exchange 2010 DAG, which would be the first Windows Server 2008 R2 cluster in their environment and they were having issues bringing the CNO online after the cluster was created. The customer domain was originally 2003 and they had to add a 2008 R2 DC and update the schema in order to install Exchange 2010 DAG.

    For starters, since I knew the CNO was not coming online after creating the cluster I had the customer destroy the cluster, pre-staged a new computer object for the CNO then created a new cluster based on the name of the new CNO. After the cluster was created I noticed that the computer object was still disabled in AD and the following error message in the cluster log.


    00000e80.00000d5c::2012/03/14-16:07:33.149 INFO [RES] Network Name <Cluster Name>: Trying to find computer account W2K8R2Cluster object GUID(cae8b3dcc60aa040bbcef250634427bb) on any available domain controller.
    00000e80.00000d5c::2012/03/14-16:07:33.306 WARN [RES] Network Name <Cluster Name>: Search for existing computer account failed. status 8007052E
    00000e80.00000d5c::2012/03/14-16:07:33.352 WARN [RES] Network Name <Cluster Name>: Couldn't get information from DC \\ status 5
    00000e80.00000d5c::2012/03/14-16:07:33.352 INFO [RES] Network Name <Cluster Name>: Trying to find object cae8b3dcc60aa040bbcef250634427bb on a PDC.
    00000e80.00000d5c::2012/03/14-16:07:33.462 WARN [RES] Network Name <Cluster Name>: Couldn't get information about PDC. status 5
    00000e80.00000d5c::2012/03/14-16:07:33.462 INFO [RES] Network Name <Cluster Name>: Unable to find object cae8b3dcc60aa040bbcef250634427bb on a PDC.
    00000e80.00000d5c::2012/03/14-16:07:33.462 INFO [RES] Network Name <Cluster Name>: GetComputerObjectViaGUIDEx() failed, Status 8007052E.

    clip_image002Access is denied’

    In the System Event log you will see an ID 1207 that should be in synch with the time in the cluster log. The main thing to focus on is the “Unable to get the Computer Object using GUID”.

    Log Name: System
    Source: Microsoft-Windows-FailoverClustering
    Date: 3/14/2012 9:07:10 AM
    Event ID: 1207
    Task Category: Network Name Resource
    Level: Error
    User: SYSTEM
    Cluster network name resource 'Cluster Name' cannot be brought online. The computer object associated with the resource could not be updated in domain '' for the following reason:
    Unable to get Computer Object using GUID.
    The text for the associated error code is: Logon failure: unknown user name or bad password.

    At this point, I’m pretty convinced there are some issues with the GPOs on the domain controllers but I still need to do my due diligence in troubleshooting the issue with the Cluster Network Name in a failed state.

    Since I pre-staged the CNO and it was still disabled after creating a new cluster, this gave me more evidence indicating an issue with the DC. I created a new OU and blocked inheritance in order to prevent any GPOs from being applied to the Node(s). I refreshed the GPO’s on the Node(s), confirmed there are no GPOs applied by running Gpresult /V from an Administrative CMD Prompt, but the Cluster Network Name still fails to come online. I’m convinced there is some issue with GPO’s on the DC but I’m not sure where to start looking.

    Next, I verified the permissions in AD on the CNO and, to be on the safe, I granted the CNO Full Control to the object and also confirmed that the CNO has the correct permissions to the OU(READ permissions on the OU should be sufficient rights to access the OU and get to the computer object). Despite this, the Cluster Network Name failed to come online.

    I moved on to check the DNS Host A record for the CNO not really thinking this is the issue but more or less making sure everything is in order. I came to find out a Host A record was not created for the Cluster Network Name because they do not have Dynamic Updates enable for DNS. I created the Host A record and checked off “Allow any authenticated user to update the DNS records with the same owner name.” I already knew the node was able to resolve the DC from the warnings in the cluster log but couldn’t get information from DC \\ So it was not a name resolution issue trying to access the DC.

    At this point, I have gone through all the normal troubleshooting steps that generally resolve the ID 1207 and the CNO in a failed state from the cluster perspective. Now it’s time to engage Directory Services to take a deeper look at the DC configuration. After some time reviewing the Domain Controller configuration and GPOs the DS engineer narrowed it down to permission issues in the “Access this computer from the network” policy. The default permissions are pictured below.

    Access this computer from the network - This user right determines which users and groups are allowed to connect to the computer over the network. Since "Everyone" and "Authenticated Users" were missing from the settings, this meant that no computer would be able to access the domain controller.


    Picture above shows the default permissions for the Access this computer from the network policy

    The DS engineer modified the “Access this computer from the network” policy in the Default Domain Controllers policy by adding Authenticated Users, refreshed GPOs by running GPUpdate /force, ran RSOP.msc to confirm the GPO is applied, and the CNO came online.

    Steven Graves
    Support Escalation Engineer
    Microsoft Enterprise Platforms Support

  • How the Clipboard Works, Part 2

    Last time , we discussed how applications place data on the clipboard, and how to access that data using the debugger.   Today, we'll take a look at how an application can monitor the clipboard for changes.   Understanding this is important more
  • How the Clipboard Works, Part 1

    Recently I had the opportunity to debug the clipboard in Windows, and I thought I’d share some of the things I learned.   The clipboard is one of those parts of Windows that many of us use dozens (hundreds?) of times a day and don’t really think more
  • Our Team in Bangalore is Hiring - Windows Server Escalation Engineer

    Would you like to join the world’s best and most elite debuggers to enable the success of Microsoft solutions?   As a trusted advisor to our top customers you will be working with to the most experienced IT professionals and developers in the industry more
  • Unable to connect to WMI locally – “Win32: The system cannot find the path specified”

    Good morning AskPerf! Sanket Jagtap here from Platforms Team here to discuss an interesting issue I recently worked.  My customer had a Windows 2008 R2 Server, and could not connect locally to WMI.  When they ran “wmimgmt.msc” and tried to connect, the following error appeared:

    Failed to connect to <local computer> because "Win32: The system cannot find the path specified."


    When this failed, the following events were recorded to the Application log:

    Log Name: Application
    Source: Microsoft-Windows-WMI
    Date: <Date/Time>
    Event ID: 28
    Task Category: None
    Level: Error
    Keywords: Classic
    User: N/A
    Computer: <Computer Name>
    Description: Failed to Initialize WMI Core or Provider SubSystem or Event SubSystem with error number 0x80070003. This could be due to a badly installed version of WMI, WMI repository upgrade failure, insufficient disk space or insufficient memory.

    Log Name: Application
    Source: Microsoft-Windows-WMI
    Date: <Date/Time>
    Event ID: 43
    Task Category: None
    Level: Warning
    Keywords: Classic
    User: N/A
    Computer: <Computer Name>
    Description: Windows Management Instrumentation ADAP failed to connect to namespace \\.\root\cimv2 with the following error 0x80070003

    We checked the WMI Security tab, and the Root namespace was missing, as well as under the Advanced tab:



    During the course of troubleshooting, we tried running “winmgmt /verifyrepository”, however it failed with a similar error:

    C:\>winmgmt /verifyrepository
    WMI repository verification failed
    Error code: 0x80070003
    Facility: Win32
    Description: The system cannot find the path specified.

    At this point, we decided to run the WMIDiag Tool (WMIDiag 2.1) to help troubleshoot this issue. The WMIDiag log reported the same error multiple times for most of the Root namespace:

    1843 12:43:16 (0) ** - Root, 0x80070003 - The system cannot find the path specified.
    Error Result: 0x80070003 ( -2147024893 )
    Message Text: The system cannot find the path specified.

    We then popped open the Registry and browsed to the following key:


    We compared a working to a non-working registry and made the following discover:

    Working Machine


    Non-Working Machine


    The registry “Type” was set to REG_SZ instead of REG_EXPAND_SZ. We took a backup of the CIMON folder, then deleted the old “Repository Directory” value and created a new one using the REG_EXPAND_SZ type. After a restart, WMI now successfully connected to the Repository/Default Namespace.

    Unfortunately, we were unable to determine what changed this value, however it could have been a user change, some type of script, or caused by an application.

    Additional Resources

    - Sanket Jagtap

  • Windows Performance Monitor Disk Counters Explained

    Hello AskPerf and Happy Friday!  This is just a quick post to let you know that Flavio, one of our Disk Experts on the Core team, has posted another informative blog post; this time on Performance Monitor Disk Counters.  Check it out and have a great weekend!

    Windows Performance Monitor Disk Counters Explained

    -Blake Morrison