May, 2012

  • Hotfix to Enable Mini-Filter Performance Diagnostics With XPerf for Windows Server 2008R2

    Greetings ntdebugging community, Bob here again and today I would like to let everyone know about a new feature implemented in Windows Server 2008 R2’s kernel and filter manager binaries released in knowledge base article 2666390 .   Beginning with more
  • Debugging a Crash, Found a Trojan

    Hi, I'm Manish from Global Escalation Services. I would like to present a multiple random bug check issue, which was caused by malicious code (trojan) running on the machine. This is the walkthrough of how we found the virus on the server. In this particular more
  • Exchange DAGs and Cluster Networks

    One of my colleagues here at Microsoft wrote a couple blogs on managing Exchange networks on a cluster so I thought I’d post the links since they are tied into behavior you would see in a clustered environment.

    Exchange 2010: Mapping DAG network states to cluster network states…

    Exchange 2010: Collapsing DAG Networks

    Jeff Hughes
    Senior Support Escalation Engineer
    Microsoft Enterprise Platforms Support

  • Requirements to save Bitlocker Recovery Key to AD using MDT

    My name is Naziya Shaik and I am a Support Escalation Engineer with Windows Core team @ Microsoft. I would like to share information about enabling BitLocker while deploying operating system via MDT and the group policies that are required to be configured in AD DS.

    If you use Microsoft Deployment Toolkit to deploy Windows one of the prompts during Lite Touch is the prompt to enable Bitlocker Drive Encryption and you are given the option to save the bitlocker recovery key “in active directory”.  See Figure 1


    Figure 1.  Bitlocker prompt during Lite Touch

    You can also enable the step manually in the task sequence.  See Figure 2


    Figure 2.  Bitlocker step in TS

    The issue we have seen is that some customers believe that this is all that is required to save the recovery key to active directory.   

    In order for MDT to save the recovery key to active directory you must at a minimum enable the following group policy:

    Deploying Windows 7 with Windows Server 2003 or Windows Server 2008 DC

    Path to GP:  Computer Configuration\Administrative templates\Windows Components\Bitlocker Drive Encryption

    Policy:  Turn on Bitlocker backup to Active Directory Domain Services

    Deploying Windows 7 with Windows Server 2008 R2 DC

    Path to GP:  Computer Configuration\Administrative templates\Windows Components\Bitlocker Drive Encryption\Operating System Drives

    Policy:  Choose how Bitlocker-protected operating system drives can be recovered

    Additional configuration may be required also depending on your scenario.  For more information see “Backing Up BitLocker and TPM Recovery Information to AD DS


    The following blog refers to a script to back up the recovery information to AD DS.

    How to backup recovery information in AD after BitLocker is turned ON in Windows 7


    Naziya Shaik

    Support Escalation Engineer

    Microsoft Enterprise Platforms Support

  • Windows 8 and .Net Framework 3.5


    With each new release of Windows, it's a challenge to balance keeping the OS footprint small with maintaining forward compatibility for applications and devices. The .Net Framework is at the heart of this challenge. In Windows 8, Microsoft decided to take a new approach to the way that such features are installed. In this post, I will describe the new approach, how the changes might affect you, and how you can prepare for them to ensure a smooth transition to Windows 8.


    About the .Net Framework

    The .Net Framework provides a class library and a Common Language Runtime (CLR) that allow software developers to create rich, secure applications. Additionally, the Framework provides the functionality required for such applications to run. A program developed using a particular version of the Framework typically requires that version, or a compatible one, to be installed on computers where it will run.

    Windows 7 and Windows Server 2008 R2 included .Net Framework 3.5. Additionally many applications have been written using .Net 4.0, so that version is often installed using a redistributable package from Microsoft. Windows 8 and Windows Server 2012 include .Net 4.5, which supports building and running the next generation of applications and web services, including Metro-style apps. .Net 4.5 supports applications written for 4.0, so there is no need to install .Net 4.0 on Windows 8.

    Features on Demand (FoD)

    "Features on Demand (FoD)" is a new concept in Windows 8 that allows administrators and image builders to reduce the amount of space used by the component store by adding only the payload for optional components they need to a system image. "Payload" refers to the binaries and other files associated with a feature. Features on Demand also allows for the addition of roles and features to an image at any time they are needed .

    In Windows 8,.Net Framework 3.5 is now a Feature on Demand. And to simplify the installation of common legacy versions of the .Net Framework, .Net 3.0 and 2.0 have been included in the same feature package as 3.5. That means if any of those three versions need to be installed, all the administrator needs to do is enable the single .Net Framework 3.5 feature in Windows 8.

    While we encourage developers to create or upgrade their applications using .Net 4.5, we realize that many commonly-used apps exist that depend on older versions of .Net, and that it takes time for developers to upgrade their code and for customers to upgrade to the new apps. For these reasons we have provided a variety of methods by which customers can enable the legacy versions of .Net in Windows 8.

    Installation Sources

    The .Net Framework 3.5 payload can be obtained from any of the following sources:

    · Windows Update (WU)

    · A Windows Image file (.wim) to which the payload has been added

    · The \sources\sxs folder on the installation media

    There are unique advantages to using each. The source can be specified for the environment using a new Group Policy setting. It can also be specified when installing .Net 3.5 manually on an individual machine or image.

    The simplest scenario is one in which WU is accessible to both the machine and the user, and the machine is not configured to obtain updates from Windows Server Update Services (WSUS). In this case, when the feature is enabled, the user will be prompted for permission to download the update. If permitted, Windows will download the payload directly from Windows Update and install the feature. Done!

    In more controlled environments, administrators might want to redirect such download requests to an alternate source such as a Windows Image file (.wim) to which the payload was added, or the\sources\sxs folder from the installation media. There might also be network , proxy, or security configurations that prevent users from directly accessing Windows Update. Additionally, WSUS does not currently support the payloads for Features on Demand, although it does support the subsequent patching of the features. So in environments where machines are configured to obtain updates from WSUS, administrators will need to configure the source for initial FoD installations.

    To allow administrators to manage these scenarios, a new Group Policy setting was introduced in Windows 8 / Windows Server 2012: "Specify settings for optional component installation and component repair”, located under Computer Configuration\Administrative Templates\System:


    This policy allows the administrator to configure the installation of Features on Demand and feature store repair operations to use only authorized locations.

    When this policy is enabled, a network location (for example, a file server) can be specified for both repair of the feature store, and enabling features whose payloads were not originally added. The Alternate source file path can point to a \sources\sxs folder or a Windows image (WIM) file using the WIM: prefix. The repair WIM can be different than the initial WIM file used for installation. You can specify multiple paths by using ";" between the paths. Valid syntax is "wim:<path to wim>:<index>". Or "<path to sxs folder>".




    If you select Never attempt to download payload from Windows Update, WU is not contacted during an installation or repair operation.

    If you select Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS), attempts to add features (for example, .NET Framework 3.5) or repair the feature file store use Windows Update to download files. Target computers require Internet and WU access for this option. Normal servicing operations continue to use WSUS if it has been configured as a source.

    The advantage of a WIM file is that it can be kept current with updates. This may be important because files associated with features that have post-RTM updates will be repaired to their current versions if the specified source contains the current updates. It is important to note however, that the initial installation of FoDs from an updated WIM will still use RTM versions of files, with subsequent updates being applied using standard patching sources such as WU or WSUS. I'm not going to cover how to create and maintain a WIM file here. For more information on how to do that see Deployment Image Servicing and Management (DISM) Technical Reference .

    The\sources\sxs folder on the installation media can provide a quick and easy local source for initial installations. In addition to referencing the sxs folder in the policy setting above, you can specify it as the source for manually installation on individual machines. To make the source files available on the internal network, use the XCOPY command to copy the source files to a network share, and then reference the share as a mapped drive or a UNC where applicable:

    xcopy d:\sources\sxs\*.* x:\Win8Media\sources\sxs\ /s

    Installation Methods

    Now that we have covered the various sources, let's talk about how to enable the feature. There are three basic ways .Net 3.5 can be enabled, in order of preference: proactively, manually, or automatically.

    By far, the most hassle-free way to install any FoD to more than a very few machines is to add the payload and enable the feature on images you will be deploying in your environment. Couple that with configuring the Group Policy setting mentioned earlier to point to the right source for one-off scenarios, and about the only administrative work you will have beyond that will be maintaining an updated WIM file for feature repair. Again, I am not going into details here about how to create images for broad deployment. For more information on how to do that see Deployment Image Servicing and Management (DISM) Technical Reference.

    The simplest way to enable .Net 3.5 on a small number of Windows 8 client machine is through Turn Windows features on or off:

    1. On the Start Screen begin typing “turn windows features on or off”, select Settings in the search pane, and click on Turn Windows features on or off.

    2. Check the box next to .Net Framework 3.5 (includes .NET 2.0 and 3.0)

    3. The wizard will search for required files and then prompt you to download files from Windows Update.

    4. Select Download files from Windows Update.


    5. After the wizard completes, click Finish.

    The process on Windows Server 2012 is similar but is accomplished using the Add Roles and Features Wizard:

    1. In Server Manager, click Manage, then select Add Roles and Features.

    2. Click Next at the Before you begin screen.

    3. At the Select installation type screen, select Role-based or feature-based installation and click Next.

    4. On the Select destination server screen, select the target server and click Next.

    5. On the Select server roles screen, click Next.

    6. On the Select features screen, check the box next to .Net Framework 3.5 Features and click Next. If you expand the tree it looks like this:


    7. On the Confirm installation selections screen, a warning will be displayed asking "Do you need to specify an alternate source path?...". If the target machine does not have access to Windows Update, click the Specify an alternate source path link to specify the path to the \sources\sxs folder and click OK:



    8. After you have specified the alternate source, or if the target machine has access to Windows Update, click Install.

    Note that the Add Roles and Features Wizard gives the administrator the option to specify an alternate resource, whereas the Turn Windows features on or off dialog does not. In most environments, administrators will deploy standard images of client machines that include the necessary features, or they will configure Group Policy to specify the installation source for Features on Demand.

    Administrators can also use Deployment Image Servicing and Management (DISM) or Powershell cmdlets to enable the feature. DISM can be used to install the feature on individual computers, or to install it on an image that will be deployed to multiple computers.

    Here are some sample DISM commands to enable and get the status of the .Net Framework 3.5 feature:

    Dism /online /get-featureinfo /featurename:NetFx3

    Dism /online /enable-feature /featurename:NetFx3 /All

    Dism /online /enable-feature /featurename:NetFx3 /All /LimitAccess /Source:x:\sources\sxs

    Use /All to enable all parent features of the specified feature

    Use /LimitAccess to prevent DISM from contacting WU/WSUS

    Use /Source to specify the location of the files needed to restore the feature.

    (x: is the drive letter of the installation media or mapped network share that contains a copy of the installation files)

    To install using Powershell, use Server Manager cmdlets on servers to install features. (It should be noted that the Get-WindowsFeature cmdlet may not show a feature as installed unless all of its parent features are also installed):

    Get-WindowsFeature –name NET-Framework-Core

    Install-WindowsFeature –name NET-Framework-Core

    Install-WindowsFeature –name NET-Framework-Core –source x:\sources\sxs

    Similar DISM Powershell cmdlets can be used on either client or server, but note again that the Server manager cmdlets above are recommended on server..

    Get-WindowsOptionalFeature –Online –FeatureName NetFx3

    Enable-WindowsOptionalFeature –Online –FeatureName NetFx3 –All

    Enable-WindowsOptionalFeature –Online –FeatureName NetFx3 –All -LimitAccess -Source x:\sources\sxs

    Windows features that require .Net 3.5

    As of this writing, the only Windows feature I am aware of that requires .Net 3.5 (beyond those that are specific to .Net 3.5 and ASP.Net 3.5) is Powershell 2.0. If you need it for script compatibility, you will need to install .Net 3.5 to get Powershell 2.0 functionality. On Windows 8 client, Windows PowerShell 2.0 is already enabled and you simply need to enable .Net 3.5 to use it. On server, you will need to install the Windows PowerShell 2.0 Engine, which will prompt you to also install .Net 3.5.


    The automatic installation trigger I alluded to earlier requires a discussion about installing applications.

    As mentioned before, many applications rely on older versions of the .Net Framework. In fact, some current versions of Microsoft products including Microsoft SQL and some System Center products use older versions.

    Many applications perform checks during their installation to verify that the required version of the .Net Framework is installed. If not, they install the necessary version, often using a redistributable package available from Microsoft. However, the methods that application installers use to verify and install .Net can vary. The experience of installing apps in Windows 8 might have unexpected results because of how external attempts to install .Net are now intercepted and handled by Windows.

    Installation of the new.Net Framework 3.5 FoD package can be triggered automatically in Windows 8 in the following scenarios:

    · You attempt to install .Net 2.0, 3.0, or 3.5 using a redistributable package available for download from Microsoft.

    · An application attempts to install one of the redistributable packages for a required version during its own installation process.

    · An application that requires a legacy version, executes without preinstalling the required version.

    In each of these cases, an application shim in Windows 8 intercepts the attempt and invokes the installation of the new .Net 3.5 feature. Once triggered, the installation should proceed as if it was initiated from the UI, DISM, or Powershell.

    The classic "Your mileage may vary" disclaimer applies here because we really don't know how all applications will react to the shim intercepting the installation attempt. Also, some apps look for the existence of certain files to verify the installation of the desired .Net version. Such app installations may fail if .Net 3.5 was preinstalled because some files previously present on the older versions have been deprecated in Windows 8. We are however testing many frequently used apps, and in some cases introducing pre-app shims if they are detecting .NET inappropriately.

    To avoid problems with applications that need it, it is best to enable the new .Net 3.5 feature before installing your app.


    As with anything else, a little planning can go a long way. Here are the steps I recommend you consider in order of importance:

    A. Understand and evaluate the requirements of your applications. Don't just assume that every computer will require .Net 3.5 and enable it on all of your images. Doing this will defeat the potential benefits of having the payload removed. By the same token, if you deploy Windows 8 with the intention of dealing with the users and computers that need .Net 3.5 as they come up, you are setting yourself and your helpdesk up for a lot of unnecessary hassle. Install all of your common LOB and infrastructure apps one at a time in a test environment without .Net 3.5 and observer whether they attempt to install an older version of the Framework, and in general how they function. Then enable .Net 3.5 and make sure all apps function as expected.

    B. Include .Net 3.5 in images that will be deployed to users that will likely be running apps that require it.

    C. Copy the files from the installation media to a network share to so they can be referenced by manual installation attempts and optionally by the new Group Policy setting.

    D. Regardless of whether your environment includes WSUS servers, treat configuring the new Group Policy setting as a requirement. You should determine how you want to handle attempts to download not only .Net 3.5, but also other Features on demand. Additionally, as the name implies, the policy also tells Windows where to obtain files to repair the feature store.

    E. Create and maintain a Windows Image that can be referenced by the Group Policy setting for ongoing FoD and feature store repair downloads.

    F. Experiment with the DISM Powershell cmdlets to be prepared to deploy Features on Demand remotely to machines as needed.

    Misc. Considerations

    Upgrading from Windows 7 / Windows Server 2008 R2

    When a PC running Windows 7 (which includes .NET Framework 3.5.1 by default) is upgraded to Windows 8, or when a server running Windows Server 2008 R2 (which has .NET Framework 3.5.1 feature installed) is upgraded to Windows Server 2012, .NET Framework 3.5 is enabled automatically using the files on the installation media. The purpose of this is to increase the chances that all apps will work as they did before the upgrade.

    Multilingual images

    For images that will support more than one language, it is best to add the .NET Framework 3.5 binaries before adding any language packs. This order ensures that .NET Framework 3.5 language resources are installed correctly within the reference image and available to users and applications.

    Common Problems

    Here, I've included three issues that you might run into when installing .Net 3.5. The hex error code is the most recognizable part and uniquely identifies each error. I've also included variations on text that might accompany the error code to increase the discoverability of this post. The text will vary, depending on whether it occurs on Windows 8 or Windows Server 2012, whether you tried to install it using the UI, DISM, or PowerShell, and on the build (Developer Preview, Consumer Preview, Release Preview, etc.):


    Windows couldn't complete the requested changes.

    Windows couldn't connect to the Internet to download necessary files. Make sure you are connected to the Internet, and press 'Retry' to try again.

    Windows couldn't connect to the Internet to download necessary files. Make sure you're connected to the Internet, and press 'Retry' to try again.

    Error code: 0x800F0906

    The request to add or remove features on the specified server failed.

    Installation of one or more roles, roles services, or features failed.

    The source files could not be downloaded.

    The source files could not be found.

    Use the /source option to specify the location of the files that are required to restore the feature. The file location should be either the root directory of a mounted image or a component store that has the Windows Side-by-Side directory as an immediate subfolder.

    Use the "source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see

    Try installing the roles, role services, or features again in a new Add Roles and Features Wizard session, and on the Confirmation page of the wizard, click "Specify an alternate source path" to specify a valid location of the source files that are required for the installation. The location must be accessible by the computer account of the destination server.

    This is the most common issue that occurs when attempting to install .Net 3.5. It stems from the machine or user not having access to a configured payload source.

    To resolve this issue, make sure the machine and user have access to Windows Update, or that you have configured an alternate source to which the user and machine have access in the Group Policy setting. If machines in your environment are configured to use WSUS, make sure you have configured the Group Policy setting to direct download requests to WU or an alternate source. If it continues to fail, use the DISM command or Powershell cmdlet to install the feature, pointing to a local installation source.


    (The text for this message is often similar to that of the 0x800F0906 error above.)

    This can occur when trying to install from an installation source that is corrupt, incomplete, or invalid for the installed build (for example trying to use a Windows 8 Developer Preview source for a Consumer Preview or RTM installation). Also, make sure the full path is correct (x:\sources\sxs) and that the user has at least READ access to the location. Try to access the source directly as the installing user from the affected machine.


    DISM failed. No operation was performed. For more information, review the log file. The DISM log file can be found at %WINDIR%\logs\DISM\dism.log.

    Due to network policy settings, Windows couldn't connect to the Internet to download files required to complete the requested changes. Please contact your network administrator for more information.

    This might occur if Group Policy has been configured to prevent installing .NET Framework 3.5 from Windows Update. To resolve this, configure an alternate source in the new Group Policy setting.


    How to Enable or Disable Windows Features

    (How to) Configure a Windows Repair Source

    Microsoft .Net

    .Net Framework Developer Center

    .NET Framework 3.5.1 Features Overview

    Deployment Image Servicing and Management (DISM) Technical Reference

    How to Mount and Modify an Image

    How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site


    Jim Martin

    Senior Support Escalation Engineer

    Microsoft Platforms Core Support

  • Great blog post on RDS in Windows Server 2012

    Good morning Folks!  Today is a quick post to inform you of a new Blog from the Windows Server team that talks about the new RDS (Remote Desktop Services) features in Windows Server 2012.  Check it out!

    Windows Server 2012 Remote Desktop Services (RDS)

    Have a great weekend!

  • EVENT ID 55: When Good Bits Go Bad

    My name is William Effinger, and I am a Senior Support Escalation Engineer with the Windows Core team at Microsoft. Some of the most common questions we get here at the storage team center around CHKDSK. If you have ever come across any event ID 55s in your system event log, this blog is for you.

    What is an event ID 55? Let’s start by looking at the error:

    Event Type: Error
    Event Source: NTFS
    Event ID: 55
    The file system structure on disk is corrupt and unusable. Please run the chkdsk utility on the volume "Drive_letter:"

    While the error description is direct and self-explanatory, we often receive calls from customers who want to better understand how this occurred and their subsequent options.

    How did we get into this situation to begin with?

    The file system does not proactively check each write (doing so would hugely impact performance, as you can imagine). NTFS instead has a logic that checks some reads for congruence. As a preventative measure, we can only suggest best practices such as keeping up to date with drivers and firmware.      

    We do know, however, that the corruption that we see in the file system is due one of two things: either a hardware problem or an issue with the file system driver.

    The majority of the issues we see revolve around problems with hardware. As a rule of thumb, hardware tends to corrupt unpredictably.

    If you suspect hardware, the following techniques will likely help you identify the culprit:

    • Install the latest SCSIPORT/RAIDPORT update(s).
    • Remove or update filter drivers.
    • Update 3rd party storage drivers /firmware.
    • Try switching to different type of driver (raidport vs. monolithic).
    • P2V the machine and try using a different storage method (virtualized SCSI or ATAPI).
    • If all else fails, rearrange hardware into various combinations.

    While extremely rare, NTFS issues can certainly happen. Unlike hardware, NTFS will leave a trail of very specific clues in the corruption leading straight to the offending code. Due to the exceptionally large install base of NTFS, opportunities for corruption have already been identified and resolved. If a software concern still remains, updating the latest version of NTFS would be a prudent course of action.

    The only option left for Microsoft support is to look over your server and provide an analysis of the storage stack health. To do that, we look for filter and out of date storage drivers. Then we attempt to eliminate multi-pathing and/or contact the storage vendor suggesting updates as necessary.

    Sometimes identifying the root cause of the corruption is less important than resolving the corruption itself. Event ID 55 has alerted you to the fact that there is corruption on the volume, and the only tool capable of resolving the file system corruption is CHKDSK. Unfortunately, customers are unable to use the corrupted volume while CHKDSK is repairing problems with the file system and estimating downtime is impossible. My colleague summed this up in his blog “Questions you shouldn't call Microsoft for...

    If you have any event ID 55s in your system event log, it’s time to run CHKDSK. The longer you wait the worse it is likely to get.

    William Effinger
    Senior Support Escalation Engineer
    Microsoft Enterprise Platforms Support

  • MDT 2010 & 2012 – My deployment failed. What and where are logs I should review?

    One of the most common questions I get is “What logs should I look at if my deployment fails?” So here is a little summary of the logs you will be most concerned with when troubleshooting a failed Windows 7 or Windows Server 2008 R2 install that are being deployed via Microsoft Deployment Toolkit 2010 or 2012.

    First thing to note is that the location of the logs move around depending on what portion of setup we are talking about. Here is a breakdown of the log locations during a MDT install task sequence:

    Before the Image is applied to the machine:


    After the system drive has been formatted:


    After Deployment:


    The logs of most interest for troubleshooting a failed install will be:

    BDD.LOG – This is an aggregated log of all the MDT Logs.

    SMSTS.LOG – This log would be used to troubleshoot Task Sequence errors.

    Also note that each MDT script creates its own log files during execution (example: ZTIGather.log, ZTIDiskpart.log, ZTIDrivers.log, etc)

    Next Question is: How do I read the logs?

    Although you can view the logs with Notepad, it can be hard to make sense of the info in a regular text editor. The MDT logs are most easily read by Trace32 (which is part of the Microsoft SCCM 2007 Toolkit).

    Microsoft SCCM 2007 Toolkit

    Here is an excerpt of a BDD.log in Notepad:


    Here is that same portion of that bdd.log viewed in SMS Trace:

    Notice warnings are highlighted in yellow, and errors in red.


    Now that you know how to locate more detailed error information in the logs, here are some locations that you can use to search to help find solutions to your issues.

    The “Ask The Core Team” Blogs on TechNet:

    “The Deployment Guys” Blogs on TechNet:

    The MDT Social Forums on TechNet:

    The Microsoft Deployment Toolkit homepage on TechNet:

    The MDT Help Files also have a lot of information and serve as a good reference for finding proper syntax and examples.

    Hopefully, this information will help aid your MDT troubleshooting. Being armed with the proper tools and knowing where to look for the answers is the key to troubleshooting success.

    Bill Spears
    Microsoft Corporation
    Senior Support Escalation Engineer / Premier Field Engineer