Posts Tagged ‘Update’

VERY IMPORTANT UPDATE

Adding the English en-GB language pack to Windows 10 1607 as part of an MDT build and capture can cause the indexing service not to work depending on how its being added. See here for the specific scenario. You will note that I have commented on this forum post as I have been working over the past 2 weeks to resolve the issue.

To avoid this indexing issue the language pack needs to be added to the original 1607 media that Microsoft released last July 2016. Do not use the CBB media that was released in November 2016. The install.wim has been serviced and any language packs that are added will either fail or cause problems with the reference image when its deployed.

To summarise, the solution involves:

  1. Injecting the language pack and feature on demand components offline
  2. Adding the latest Windows 10 1607 CU to the reference image as an extra MDT TS step
  3. Using a slightly modified unattend.xml when you deploy the reference image

The Language Pack

The language pack must be added before a Cumulative Update is installed for the first time. And here is essentially where the problem lies – applying a CU during a build and capture and then applying a language pack at a later date is the root cause of the indexing issue.

During my testing I’ve found that injecting the language pack and feature on demand components offline using DISM is the easiest way to accomplish this task.

See this MSDN documentation for the relevant commands on how to mount the install.wim file, inject the cabinet files and then commit and unmount the wim.

I have added the following files in this specific order:

  • Windows-Client-Language-Pack_x64_en-gb.cab
  • Microsoft-Windows-LanguageFeatures-Basic-en-gb-Package.cab
  • Microsoft-Windows-LanguageFeatures-OCR-en-gb-Package.cab
  • Microsoft-Windows-LanguageFeatures-Handwriting-en-gb-Package.cab
  • Microsoft-Windows-LanguageFeatures-Speech-en-gb-Package.cab
  • Microsoft-Windows-LanguageFeatures-TextToSpeech-en-gb-Package.cab
  • Microsoft-Windows-LanguageFeatures-Speech-en-au-Package.cab
  • Microsoft-Windows-LanguageFeatures-TextToSpeech-en-au-Package.cab

The order in which you add these is important.

Once you have your modified install.wim file you can import this into MDT as an Operating System for your build and capture task sequence.

The Cumulative Update

So its pretty important to apply the most current CU available to Windows 10 1607, there are a ton of fixes, we know this. However there was a bug in the WU agent with the original 1607 media which prevented it from contacting a WSUS instance. As a workaround to this I’ve added a step in my MDT task sequence which uses WUSA to install the latest CU and then restart the OS. This occurs prior to the Windows Update patching step that I have in my task sequence.

I now have a Windows 10 Enterprise 1607 install.wim with the language pack and feature on demand components added. I’ve completed an MDT build and capture and I have my patched reference image which I’ve added into Configuration Manager CBB.

The Unattend.xml

The last step we need to look at is making a small adjustment to the unattend.xml file that it being used when the reference image is deployed. Because we now have English US and English GB in the wim file, we need to tell Windows 10 which language to use during the out of box experience phase (OOBE) so we don’t see a prompt asking us which language we would prefer.

Pretty simple – make the following changes to the Language value so it is changed to en-GB.

<InputLocale>0c09:00000409</InputLocale>
<SystemLocale>en-AU</SystemLocale>
<UILanguage>en-GB</UILanguage>
<UserLocale>en-AU</UserLocale>
<UILanguageFallback>en-US</UILanguageFallback>

That’s it! Deploy the new reference image and after a domain user logs in verify that you have the English (Australia) language pack installed and most importantly that the indexing service has correctly indexed the control panel and other items that normally would have failed.

I’ve kept my original blog below for reference only – please note that it is now inaccurate and shouldn’t be followed.

Cheers

Damon

 

 

Original Post

Something that used to be quite simple, is now not so simple. With the advent of Cortana, the English (Australia) Language pack is now no longer included in the base Windows 10 ISO. This does make some sense given the large number of languages that Windows 10 now supports with Cortana in mind.

By default if you deploy Windows 10 Enterprise using Configuration Manager with an Unattend.xml file specifying en-AU as per this example:

<InputLocale>0c09:00000409</InputLocale>
<SystemLocale>en-AU</SystemLocale>
<UILanguage>en-AU</UILanguage>
<UserLocale>en-AU</UserLocale>
<UILanguageFallback>en-US</UILanguageFallback>

You end up with Australia as your region but with English (US) as your default display language.

You also do not have English (Australia) as your Speech Language with no Australian Text-to-speech voice options.

In order to fix this we need to add a Language Pack as well as some additional cabinet files from the relevant Windows 10 Features on Demand ISO available though VLSC.

To be clear – if your deploying Windows 10 1607 x64 Enterprise – you will need to download the Windows 10 1607  x64 Enterprise Language Pack ISO and the Windows 10 Features on Demand ISO as there are individual ISO’s per Windows 10 release.

You will notice that there is no en-AU language pack cab file. This is because the English (Australia) display language is a part of the en-GB cab file. There are specific en-AU Text-to-speech and Speech cab files though which should be added for Cortana functionality.

The Solution

  1. Copy the following cab file from the extracted Windows 10 Language Pack ISO to a source folder on your ConfigMgr source packages share.
    • Windows-Client-Language-Pack_x64_en-gb.cab
  2. Copy the following cab files from the extracted Windows 10 Features on Demand ISO to the same source folder
    • Microsoft-Windows-LanguageFeatures-Handwriting-en-gb-Package.cab
    • Microsoft-Windows-LanguageFeatures-OCR-en-gb-Package.cab
    • Microsoft-Windows-LanguageFeatures-Speech-en-gb-Package.cab
    • Microsoft-Windows-LanguageFeatures-TextToSpeech-en-gb-Package.cab
    • Microsoft-Windows-LanguageFeatures-Basic-en-gb-Package.cab
    • Microsoft-Windows-LanguageFeatures-TextToSpeech-en-au-Package.cab
    • Microsoft-Windows-LanguageFeatures-Speech-en-au-Package.cab
  3. Rename the files to the following, this will ensure they install in the correct order:
    • _1Microsoft-Windows-Client-Language-Pack_x64_en-gb.cab
    • _2Microsoft-Windows-LanguageFeatures-Handwriting-en-gb-Package.cab
    • _3Microsoft-Windows-LanguageFeatures-OCR-en-gb-Package.cab
    • _4Microsoft-Windows-LanguageFeatures-Speech-en-gb-Package.cab
    • _5Microsoft-Windows-LanguageFeatures-TextToSpeech-en-gb-Package.cab
    • _6Microsoft-Windows-LanguageFeatures-Basic-en-gb-Package.cab
    • _7Microsoft-Windows-LanguageFeatures-TextToSpeech-en-au-Package.cab
    • _8Microsoft-Windows-LanguageFeatures-Speech-en-au-Package.cab
  4. Create a ConfigMgr Package i.e. Windows 10 1607 en-AU Language Pack and Distribute to your DP’s
  5. In your Task Sequence add a Run Command Line step after the Setup Windows and ConfigMgr Step, this will call DISM and add the cabinet files2016-08-04_121556
  6. Once the deployment is finished, logon and open the Settings App. Open Time & Language and you should see under Region & language that English (Australia) is present with “Language Pack Installed”. If you open the Speech option, you should see English (Australia) as the spoken language.

2016-08-04_122457

2016-08-04_122514

Cheers

Damon

 

Advertisements

The number one reason for update installation failures from Microsoft is because your computers are running an out of date WUA (Windows Update Agent) or its not configured correctly. So how can this occur when we have Config Manager managing our updates and deploying them? Well its because WSUS handles the updating of the WUA agent and its components, not Config Manager. Incorrect Group Policy settings can also cause problems.

2013-08-19_121950

A client running the internal SelfUpdate process

There are a number of blogs out there discussing how to correctly implement WSUS, Config Manager and Group Policy, in fact Jason Sandys presented on this at MMS this year (2013). This gives a great overview of how to implement Software Updates ensuring that your WUA updates itself also.

http://channel9.msdn.com/Events/MMS/2013/UD-B405

When I upgraded to Config Manager 2012 I experienced quite a few clients that had out of date WUA’s. I was completely oblivious to this, however I identified the issue when decommissioning my old Config Manager 2007 instance. I could see in the IIS logs that I had computers still trying to contact my old WSUS server to do a WUA version check even though these computers had the new 2012 Config Manager agent running on them. This indicated that a number of computers had issues with their settings relating to how they were contacting the new WSUS server. I knew that my Group Policy settings, WSUS and Config Manager Software Updates implementation were correct as the vast majority of my clients were updating and communicating correctly.

So how do we put some checks in place so we can identify those computers with out of date WUA versions and re-mediate them? Well, I have done the following, maybe you will find the following information useful.

According to Microsoft you can use this SQL query:

http://technet.microsoft.com/en-us/library/bb680319.aspx

however you can’t run this from within the Config Manager Console, you get an error about the view being unavailable.

2013-08-19_095949

A work around for this is to use the following query which I obtained from a Technet discussion (credit to Jason Sandy’s and those who responded on this page). Go to Monitoring tab within your Configuration Manager Console and create a new query with the following syntax:

select rsys.Name, wua.Version from  SMS_R_System as rsys full join SMS_G_System_WINDOWSUPDATEAGENTVERSION as wua on wua.ResourceId = rsys.ResourceId

This will give you a view with results similar to the following:

2013-08-19_101344

When I initially ran this in my environment I then noticed a number of computers with out of date agents or no agent version at all even though they had the new 2012 client installed. This can mean that the Config Manager client has yet to run an inventory and upload the information, however in my case I could see that the inventory actions were running and had uploaded data. Subsequently I checked the WUAHandler.log on the problem computers and ran across two distinct issues.

Issue 1.

On some of the computers I could see that the WUAHAndler.log indicated that it was still pointed to the old WSUS server that no longer existed. I was seeing the following error in the WUAHandler.log

*******************************************************************************
Its a WSUS Update Source type ({63897A13-E330-463A-B09E-101151D25935}), adding it.
Enabling WUA Managed server policy to use server: :8530″>:8530″>http:// :8530
Waiting for 2 mins for Group Policy to notify of WUA policy change…
Group policy settings were overwritten by a higher authority (Domain Controller) to: Server “>”>http:// and Policy ENABLED
Failed to Add Update Source for WUAgent of type (2) and id ({63897A13-E330-463A-B09E-101151D25935}). Error = 0x80040692.
*******************************************************************************

For these instances I browsed to the c:\Windows\System32\GroupPolicy\Machine folder on the computer and manually removed the Registry.pol file. This file was then re-created by doing a gpupdate /force on the computer. Following this action, the WSUS server reference in the WUAHandler.log was corrected and the computer then started to communicate with the new WSUS server. So it would seem that this file was corrupted and was not being replaced by my updated Group Policy.

Note: This can also be caused by incorrect Group Policy settings which override any local WSUS server policy that the Configuration Manager client attempts to set so bare this in mind when troubleshooting this error.

2013-08-19_111944

Issue 2.

On the remaining computers I was seeing a search related error in the WUAHandler.log, subsequently inspecting the WindowsUpdate.log indicated an issue with the client being able to contact the new WSUS server:

2013-08-19_105452

2013-08-19_105508

For these computers the problem lied with the machine proxy setting. This was shown when running netsh winhttp show proxy. This setting had been configured but then not removed as part of another internal process within our domain. To correct the communication problem I ran the following from an elevated command prompt then restarted the computer:

2013-08-19_113028

Allowing for inventory to be run on the re-mediated clients, the WUA version information then appeared in the SQL Query that I had configured in my environment. Checking the WindowsUpdate.log on those computers also indicated that the self update process was working.

I hope these two issues and their associated resolutions help you with your WUA version compliance when running Software Updates with Configuration Manager 2012!

Cheers Damon

So recently I discovered that certain file extensions with my Windows 8 Enterprise deployments were associated by default with the new modern/metro applications. These included .jpg .bmp etc. Now for tablet users this may not pose a problem but for a Desktop Enterprise scenario it certainly raised some eyebrows with my end users who were consistently switching between the traditional desktop applications and the new modern applications when working.

To combat this change Microsoft have introduced a new way to set and manage these file type associations. You can no longer use a VB or Batch file to script these changes in the registry due to a security hash checking process built into Windows 8. We can now use the Dism utility to generate an XML answer file which we can then deploy and manage using Group Policy.

I recommend following these steps to configure and deploy your desired associations.

1. Deploy a copy of your current Windows 8 Enterprise WIM with your chosen deployment solution. Run up Default Programs under Control Panel and look at your current file type associations. Take note of which ones you want to alter and make your changes

.Image

2. Now we need to generate our XML file. Run an elevated command prompt and type Dism /Online /Export-DefaultAppAssociations:\\youshare\AppAssoc.xml This will output a file with all of your file types and their current associations.

Image

3. Edit this file to include only the file associations that you wish to change. You can elect to keep the file intact in its entirety if you wish. Optionally you may wish to make copies of the file if you have different file association requirements for different business groups in your organisation which you can target using separate Group Policies.

Image

4. Once you have this XML configured to your preference we can specify it in our Windows 8 Group Policy setting. Open up the Group Policy MMC on your Windows 8 environment (with RSAT installed) or Server 2012 instance and locate the policy Computer Configuration\Administrative Templates\Windows Components\File Explorer\Set a default associations configuration file Now specify the location of where you have stored the XML file. A possible option is to use a network share, or you may want to copy/inject the file locally to the Windows 8 Enterprise build as part of a Configuration Manager Task Sequence.

Image

Image

Hey presto! You now have a method of controlling and setting file associations in your organisation which is flexible enough to cater for the different scenarios you may find yourself having to manage – thanks to the Modern Desktop 🙂

Technet Reference http://technet.microsoft.com/en-us/library/hh825038.aspx