Update #2: The new supersedence is set for the November Update release so you should no longer be seeing previous roll-ups offering as they were in the past.  I've struck through that text below.

Update #3: We recently made a publishing change that resolves Scenario #1 below.

If you're a customer who has built, or is building, new images based on the latest volume license media, published in November, there are a couple of issues you should be aware of when it comes to updating the media properly.  Firstly, the following updates are not a part of the media (or were released in conjunction with the media) and will offer to these systems when they scan Windows Update. 

Secondly, you may notice that prior rollups from May through October are offered to you.  This is due to the fact that Nov. Update is currently marked as Optional for Windows Update.  Because we would never want to offer an Optional update over an Important one, these will continue to offer.  The Nov. Update will change to Important at some point in the near future and this will no longer be an issue.

Lastly, there are scenarios where April rollup (aka S14 to some) will reoffer.  These scenarios are pretty specific and I have a KB article that will be out soon outlining these but I wanted to note them here.  They are:

Scenario 1

Images were built using the November 2014 Volume License Media

Resolution: Integrate KB2959977 using the DISM method below (note: this cannot be installed via MSU)

Scenario 2

Images were built using the April 2014 Volume License Media where only KB3000850 has been installed

Resolution: Integrate KB2934018 using the DISM method below (note: these cannot be installed via MSU)

Scenario 3

Images built using either of the above methods where one of the following language packs is later installed: cs-cz,da-dk,de-de,el-gr,es-es,fi-fi,fr-fr,hu-hu,it-it,ja-jp,ko-kr,nb-no,nl-nl,pl-pl,pt-br,pt-pt,ru-ru,sv-se,tr-tr,zh-cn,zh-hk,zh-tw

Resolution:

·         Install Language Packs required for the environment prior to installing KB2913955 -or-

·         Install KB2934018 using the standalone installer

Scenario 4

Images built using the DISM /resetbase command

Resolution: Integrate KB2959977 using the DISM method below

Using DISM to integrate packages into an image

1.       Download the standalone package for the update(s) to integrate

2.       Create a new directory to expand the update packages

3.       Extract the update package using the following command:

a.      expand -f:* <path to .msu> <destination>

4.       For example, the following command expands KB2959977 to the c:\cabs directory

b.      expand -f:* Windows8.1-KB2959977-x64.msu c:\cabs

5.       Integrate the expanded cabinet file into the image from the expanded package

c.       DISM /Online /Add-Package /PackagePath:<path to extracted .cab file from Step 3>

6.       For example, the command to integrate the KB2959977 cab file would be

d.      DISM /Online /Add-Package /PackagePath:c:\cabs\Windows8.1-KB2959977-x64.cab

--Joseph

1. Export and then delete the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{e7ef96be-969f-414f-97d7-3ddb7b558ccc}
2. Reboot the impacted system
3. Reattempt KB3000061 installation

You do not need to reimport the exported key once this is completed and it can be safely deleted.  Do not delete any of the other provider keys aside from the one above.  We're still investigating why the provider keys arent being properly updated on upgrade but until that investigation is completed, the above solution is our supported workaround.  If you have issues installing other updates, please open a support case with Microsoft support and they will be able to assist you.  If you're curious what the failure looks like in the CBS.log, a snippet is posted below.  I've highlighted the bad GUID entry in red, this is the one we see as installed.  What we're looking for is the entry marked in green (which will be the proper provider entry once you delete the key and reboot.)

2014-11-06 22:33:32, Error                 CSI    00000002 (F) Logged @2014/11/6:11:33:32.429 : [ml:240{120},l:238{119}]"EventAITrace:Provider Microsoft-Windows-Win32k is already installed with GUID {e7ef96be-969f-414f-97d7-3ddb7b558ccc}.

"
 [gle=0x80004005]
 2014-11-06 22:33:32, Error                 CSI    00000003 (F) Logged @2014/11/6:11:33:32.429 : [ml:168{84},l:166{83}]"WmiCmiPlugin manproc.cpp(683): InstrumentationManifestAssert failed. HR=0x80073aa2."
 [gle=0x80004005]
 2014-11-06 22:33:32, Error                 CSI    00000004 (F) Logged @2014/11/6:11:33:32.429 : [ml:166{83},l:164{82}]"WmiCmiPlugin eventloghandler.cpp(192): ProcessEventsInstall failed. HR=0x80073aa2."
 [gle=0x80004005]
 2014-11-06 22:33:32, Error                 CSI    00000005 (F) Logged @2014/11/6:11:33:32.429 : [ml:170{85},l:168{84}]"WmiCmiPlugin eventloghandler.cpp(212): EventLogHandlerInstall failed. HR=0x80073aa2."
 [gle=0x80004005]
 2014-11-06 22:33:32, Error                 CSI    00000006@2014/11/6:11:33:32.429 (F) CMIADAPTER: Inner Error Message from AI HRESULT = HRESULT_FROM_WIN32(15010)
  [
 [22]"Configuration error.

"
 ]
 [gle=0x80004005]
 2014-11-06 22:33:32, Error                 CSI    00000007@2014/11/6:11:33:32.429 (F) CMIADAPTER: AI failed. HRESULT = HRESULT_FROM_WIN32(15010)
  Element:
  [92250]"<events xmlns="https://schemas.microsoft.com/win/2004/08/events">

  <provider guid="{8c416c79-d49b-4f01-a467-e56d3aa8234c}" messageFileName="%SystemRoot%\system32\win32k.sys" name="Microsoft-Windows-Win32k" resourceFileName="%SystemRoot%\system32\win32k.sys" symbol="W32kControlGuid">

--Joseph

--Joseph

A couple of snippets that I'm sure will interest some of you include:

• Determine the size of the component store using the new /AnalyzeComponentStore command: https://technet.microsoft.com/en-us/library/dn251566.aspx
• Clean up the component store and reclaim space using the /StartComponentCleanup command: https://technet.microsoft.com/en-us/library/dn251565.aspx

For fun, here’s one of my machines at work running the preview.  First, I analyzed the store on my machine and got the following results

Next, I ran the /StartComponentCleanup switch, which completed successfully and my new analysis reported:

So, my hard linked files didn't change and my backups directory went down about 15MB.  There was no appreciable change in the cache.  Lastly, I ran the /StartComponentCleanup with the /ResetBase command as well.  Here are those results:

Again, size of the backups folder shrank by about 13MB.  All in all, the reported explorer size of my component store went from 5.3GB when I started to 5.26GB when I was done.  Obviously, these parameters will vary greatly as more and more updates, features, roles, etc are installed as there is the possibility of more files available to remove. 

More on interpreting the  /AnalyzeComponentStore output

Let’s talk a little more about what is actually happening with the /AnalyzeComponentStore command when its run.  As many of you are aware (or have commented here in the past), a very common complaint is regarding the size on disk of the component store.  We’ve talked about it other posts regarding how hard links work, what explorer’s doing, etc.  Well if you wondered about this stuff in the past, this command was built for you.

I know many of you have used tools in the past that are hard link aware to tell me about how the true size of your component store was only fractionally smaller than what Explorer was reporting and asked why we bother mentioning hard links.  The problem with those tools is they are only discounting “duplication” caused by hard links internal to the component store. That represents only a small portion of the misreporting due to hard links because it also needs to account for the files that are hard linked external to the component store.  Those files make up Windows and are required with or without the component store.

Given that, when we look at the example below, here’s how to read what /AnazlyeComponentStore is reporting back to you:

The green boxes above show that 100MB of files exist between the Windows Explorer reported size on disk and the actual component store size.  This is what was being reported by the hard link aware tools that some of you ran on your systems (this accounts for the hard links internal to the component store).  The orange box shows a “Shared with Windows” size of 4.69GB.  This represents the files that would be part of Windows whether or not the component store existed (this accounts for the hard links external to the component store).  The actual overhead of the component store is the sum of the Backups and Disabled Features and Cache and Temporary Data, or in this case ~480MB.

NOTE: The Backups and Disabled Features also includes component store metadata and true side by side components but that was a little too long to include in an output :)

Hope this is interesting, let me know if there are any questions.

--Joseph

The Surface Pro Driver package was released recently to enable enterprises and power users the ability to re-image their Surface Pro devices with their own gold image.  The package contains a couple of important drivers that I know have caused issues for some power users who reimaged with their own media (namely the wireless driver and firmware).  So, if you're considering a Surface Pro device in your environment, I encourage you to check it out.  There is also a quick start guide for deploying the drivers.  That package is located here:https://www.microsoft.com/en-us/download/details.aspx?id=38826

The other update is a new Wacom driver that add Surface Pro pen sensitivity for applications which previously lacked this functionality such as Adobe Photoshop.  This driver package is located here: https://www.wacom.com/en/support/drivers .  Simply choose Windows 8 as the operating system and the driver package will be available for download.

Combining these drivers with your deployment solution should give you an easy way to deploy your own image and have all of the functionality you require to fully utilize the device.  Let me know if there are any questions.

--Joseph

Adding previously removed Features back to a computer using Features on Demand

As I mentioned in part 1 there are three available sources for adding roles and features back to a computer after their payloads have been removed using the Features on Demand option.

· Installation Media

· Network location of install.wim from media

· Windows Update (if configured)

To add features back into an image, administrators will need to use DISM.exe from an elevated command prompt, the Windows PowerShell cmdlets for DISM or Server Manager and path to the Windows Image file (.WIM) that holds the necessary payload for the feature to be restored. Source paths are not required if GPO’s have been defined for the environment. I’ll talk about that later.

To restore features using DISM.exe

1. Locate the .WIM file that contains the payload for the restore operation. This can be located on locally attached storage or a network share.

2. Run the command: DISM /online /enable-feature /featurename:WindowsServerBackup /source:wim:c:\install.wim:2 /limitaccess (where the WIM index is the image in the WIM file that contains the source of the feature payload)

a. The limitaccess switch will prevent the installation from attempting to contact Windows Update/WSUS Servers.

You can get the WIM index using the following command:

If you didn’t specify the source path you would get the following:

When restoring Roles/Features using the Server Manger GUI interface you will get the following notifications if the GPO is not configured.

Group Policy for Features on Demand

As I mentioned earlier there is a new Group Policy option in Windows Server 2012 allows for the configuration of an installation source for domain joined clients. The Group Policy is located in the Group Policy Editor in the Administrative Templates\System node and named "Specify settings for optional component installation and component repair".

Available policy settings include the following:

· Alternate source file path: Specifies the network location for use in installation operations. This must be a fully qualified path and can be either a folder location or WIM file. You can specify multiple paths by using ";" between the paths. Valid syntax is wim:<path to wim>:<index>

· Never attempt to download payload from Windows Update: Disables the use of Windows Update as an installation source

Values for this policy are in the registry under the following key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing

"LocalSourcePath"

"RepairContentServerSource"

"UseWindowsUpdate"

Possible registry values include:

• LocalSourcePath – Specifies location to use for installation source. Can specify more than one source when separated with a “;”. Valid sources include a network folder path or a WIM file (using the syntax wim:<path to wim>:<index>)

• UseWindowsUpdate – Enables use of Windows Update as an installation source

1. Make sure the source you’re using isn't corrupted.  If you have a download ISO from MSDN/TechNet/VL/etc, make sure that the ISO is good or try another source just to make sure.
2. Make sure the component store isn't corrupted.  I’ve spoken in the past about the Inbox Corruption Repair feature (aka in-box CheckSUR) and it usually resolves a lot of these problems.  You can check your system for problems by running the command: DISM /Online /Cleanup-Image /RestoreHealth from an Internet connected machine.  Any corruption and repair operations will be logged to the CBS.log
3. If you have a WSUS server on your network, use the /LimitAccess switch from DISM and install the component that way.  For example, for the .Net Framework, this command is: DISM /Online /Enable-Feature /Featurename:NetFX3 /Source:G:\sources\sxs /LimitAccess (where G: is the appropriate letter for the location of the DVD/ISO)
4. Update your source media.  I reference how to do this in this prior post
5. If all else fails, open a support ticket with us so we can take a look at your logs and determine what’s going on.

Most of the time, I’ve seen steps 1-4 (or a combination of them) resolve these types of issues.

Hope that helps, let me know if you have questions.

--Joseph

Features on Demand is a new feature in Windows 8 and Windows Server 2012 that will allow you to remove files associated with specific roles and features, typically referred to as payload files. The major benefit of this feature is to conserve disk space. Once removed, these binaries will need to be added back from a valid installation source before the feature can be used again. Unlike the stage and un-stage process used by the component store, Features on Demand removal results in a permanent removal of those binaries. Available sources include Windows 8/Windows Server 2012 WIM files, an expanded Windows 8/Windows Server 2012 DVD (flat), an available network location with Windows 8/Windows Server 2012 installation files and Windows Update.

Removing Roles/Features from a computer using Features on Demand

First let’s talk about removing Roles and Features from an installed Operating System. Features on Demand is exposed via the DISM command line interface as well as the new DISM and Server Manager Windows PowerShell cmdlets. Below are examples of the new DISM and Server Manager Windows PowerShell cmdlets.

DISM PowerShell Cmdlet

Server Manager PowerShell Cmdlet

It’s important to note that in Windows 8 features on demand is only exposed via DISM and DISM PowerShell cmdlets. This is important because DISM does not understand the parental dependencies. So DISM will only remove the packages you specify and will not remove any dependent packages, if they exist. For this reason it is highly recommended to only use the Server Manager PowerShell cmdlets to remove features in Windows Server 2012.

Below I will give an example of how you would remove the payload for the Windows Server Backup feature using all three methods:

DISM:

DISM.exe /Online /Disable-Feature /Featurename:WindowsServerBackup /Remove

To verify the payload has actually been removed you would run the following:

You can see from the above screenshot, that the State is Disabled with Payload Removed

DISM PowerShell Cmdlet:

Disable-WindowsOptionalFeature –Online –FeatureName WindowsServerBackup –Remove

To verify the payload has actually been removed you would run the following:

You can see from the above screenshot that the State is DisabledWithPayloadRemoved

Server Manager PowerShell Cmdlet:

Remove-WindowsFeature Windows-Server-Backup –Remove

To verify the payload has actually been removed you would run the following:

You can see from the above screenshot, that the Install State is Removed

To get a list of all Roles/Features that have been Removed you can run the following command

Get-windowsfeature | Where-Object {$_.InstallState -eq "Removed"}

Removing Roles/Features from an installation source

An administrator can also remove Roles and Features from an installation source so that they can reduce the size of their image as well as limit the Roles and Feature a specific group will have available to them. In this scenario, administrators must consider some factors to ensure the removal does not inversely effect the environment. First you will need to know what type of installation source will be used when adding roles or features back to the image. You will also need to take into account how much disk space will be needed for the addition of Roles and Features. Administrators will want to keep at least 10 GB of space free for potential component store growth.

Below are the steps to remove the Windows Server Backup feature from an installation source

1. Copy the installation WIM to a local directory (in this example C:\)

2. Create a mount directory to mount the WIM to (in this example C:\image)

3. Find the index of the image you will be editing:

DISM /get-imageinfo /imagefile:c:\install.wim

4. Mount the image to the folder created in step #2:

DISM /mount-image /imagefile:c:\install.wim /index:3 /mountdir:c:\image

5. Remove the Feature from the image:

DISM /image:c:\image /disable-feature /featurename:WindowServerBackup /remove

6. Verify the state of the feature is removed:

DISM /image:c:\image /get-featureinfo /featurename:WindowsServerBackup

7. Commit the changes to the WIM:

DISM /unmounts-image /mountdir:c:\image /commit

8. Prepare the image for deployment by adding it to a WDS or MDT deployment point.

--Joseph

My colleague Ben Herila from the Server Core team has some information about this on their team blog: https://blogs.technet.com/b/server_core/archive/2012/11/05/using-features-on-demand-with-updated-systems-and-patched-images.aspx

This post is to show you how you can update a recovery source to match that of your environment so it can successfully be used later to install roles and features.  For the purposes of this discussion, I’ll use KB2756872 (https://support.microsoft.com/kb/2756872) as most people received this package during the initial Windows 8 release.

First, you want to download the contents of the needed updated from the Microsoft Update Catalog (https://catalog.update.microsoft.com/v7/site/Home.aspx).  In this case, you’d just type in the KB number and get the following results:

Choose the appropriate downloads needed for your environment to a local computer, in this case we’ll use the 2012 update.  When the updates are downloaded, they will look like this in explorer.  These are the files we’ll need to use to update the source

Once you have the files downloaded, mount an install.wim for the operating system you need to update as a source.  On a Windows 8 or Windows Server 2012 machine, this can all be done from an elevated command prompt using the IMAGEX commands.  In the commands below, we’ll walk through the steps to mounting the install.wim to a temporary location and updating it to be a new source directory.

Copy install.wim from DVD to a temp directory

copy d:\sources\install.wim z:\install.wim

Make a mount directory for the install.wim

mkdir c:\mountdir

Remove the Read-Only attribute from the copied file so we can modify its contents

attrib.exe -r z:\install.wim

Get index information from the WIM file so we can verify the proper source index we wish to modify

dism.exe /get-wiminfo /wimfile:z:\install.wim

Mount the ‘2’ index of install.wim to our mount location

dism.exe /mount-wim /WimFile:z:\install.wim /index:2 /mountDir:c:\mountdir

I highlighted the image index above because you’ll want to ensure you’re updating the proper index when performing these operations.  The Server WIM contains 4 indexes (typically) and indexes 2 and 4 contain the full operating system binaries where indexes 1 and 3 contain only the Server Core binaries.  We’ll also need to make sure we know which index we updated so we can later use it for adding the roles and features back to the OS.

With the WIM mounted, you’ll need to use DISM to add the package to the index you’d previously mounted.  The command for this if you’d downloaded the files above to your C:\ folder would be:

dism.exe "/Image:c:\mountdir" /Add-Package "/PackagePath:C:\2756872\Update for Windows Server 2012 (KB2756872)"

NOTE: We use the source folder for this command and not an individual MSU inside the folder

Once this step is completed, commit the changes you’ve made to the WIM and unmount it:

dism.exe /Unmount-Wim /MountDir:c:\mountdir /commit

Now you have a new source directory that can be used to add roles and features back to your patched images.  So, if you were on Server Core and wanted to add back the shell components using your updated index 2 source, the command would be:

Install-WindowsFeature Server-Gui-Mgmt-Infra,Server-Gui-Shell –Source:wim:z:\install.wim:2

Organizations will need to determine how often they need to update their source recovery media.  Any time an update is released, the source is potentially invalid for reinstallation or repair operations. 

Hope that helps.

--Joseph

I've noticed people on the forums and other places have clicked through the setup process on Windows Server 2012 and ended up in Server Core (as expected btw).  I've seen several people mention they'd need to rebuild their machines to get back to a user interface, which was the case in Server 2008/2008 R2 but isn't true in Server 2012.  My colleague Mike Stephens recently authored an excellent post on how to manipulate the shell in Server 2012 using Features on Demand.  It's located here and I think its a worthwhile read for those of you interested in the servicing of Windows: https://blogs.technet.com/b/askds/archive/2012/09/20/windows-server-2012-shell-game.aspx

--Joseph