Posts Tagged ‘Windows 10’

Credit goes to J v D on the myITforum Configuration Manager email list for his response to my question about how to resolve this. I have adapted elements of his solution to suit my own situation.

Lately I’ve been doing a lot of Windows 10 1607 deployments some of which have been in-place upgrades from Windows 7 and Windows 10 1511.

I noticed that my multi-language settings were not being migrated as part of this process.

BEFORE AN IN-PLACE UPGRADE

2017-03-17_154018

AFTER AN IN-PLACE UPGRADE

2017-03-17_155042.jpg

So how do you resolve this issue? Well I’ve finally found a suitable and reliable way of setting these values as part of a Configuration Manager in-place upgrade Task Sequence.

Some background on why this problem has occurred.

For Windows 10, I like others have used the English (US) ISO.  I’ve then added the en-GB language pack for English (Australian) language support as part of a Configuration Manager Task Sequence. For Windows 7 we have always used the media with English (US) as the base system language.

This is important to note as you can’t in-place upgrade an existing OS using Windows 10 media from another base system language i.e. you wouldn’t be able to in-place upgrade a Windows 7 OS using a base system language of en-US with say the Windows 10 en-GB media.

The combination of this multi-language environment has resulted in the subsequent Windows 10 1607 language settings not being correctly configured for the welcome screen or for new user accounts following in-place upgrades.

THE SOLUTION

1. Add a  Run Command Line step in your in-place upgrade Task Sequence that references your language package. This adds the relevant Language Pack and Feature on Demand cab files. This is the same process that you would undertake if you were preparing a reference image. As an example you could use a cmd file that contains the following (adjust for your language):

2017-03-17_191509

2017-03-17_161559

2. Create the following SetLanguage.xml file and adjust as per your requirements. This xml file is imported as part of a scheduled task that gets created later in the sequence. I would recommend using Notepad++ to error check the file and then test it by manually running the import command in step 3. This way you can be confident that it is working before moving to testing with in-place upgrades.

2017-03-17_161944

3. Create the following PostUpgrade.cmd file. This cmd file is run as part of a step in the task sequence.

2017-03-17_162245.jpg

4. Create a new package in Configuration Manger containing these 2 script files and call it something appropriate.

2017-03-17_164657

5. Modify your existing in-place upgrade Task Sequence to include the following 3 steps.

2017-03-17_162936

SMTSPostAction with a value of cmd /c shutdown /r /t 0 /f

2017-03-17_163111.jpg

Command line of xcopy * “c:\Windows\Temp” /D /E /C /I /Q /H /R /Y /S

2017-03-17_163213

Command line of: schtasks /create /tn “PostUpgradeTask” /tr “c:\Windows\Temp\PostUpgrade.cmd” /RU SYSTEM /SC onstart

These sequence steps copy the script files to c:\Windows\Temp, then create a scheduled task. Finally the SMTSPostAction restarts the PC after the sequence has finished running so that the scheduled task executes and runs PostUpgrade.cmd. This cmd is responsible for importing the adjusted language settings.

There you have it, once implemented you should have a working solution and your language settings should match what was set in the previous version of Windows 10.

Cheers

Damon

 

 

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

 

So a while back I implemented a working Windows XP to Windows 7 refresh using Configuration Manger 2012 R2, some of you may be aware that this was an issue initially as there was a bug with the client being unable to stage the boot image just prior to the initial restart into WinPE. To address this a hotfix was released however the whole process had a lot of caveats to it working and was generally painful to implement.

Good news, nothing has changed with that! So last week I was thinking maybe my existing process can be used to achieve a Windows XP to Windows 10 refresh, surely that’s possible assuming that the original change Microsoft made in the client to support staging a Windows PE 3.1 boot image had been retained in the latest Configuration Manager 2012 R2 SP1 client? Well I’m happy to report that with a few changes this is indeed possible, although totally unsupported my Microsoft!

A note before proceeding. This is not supported by Microsoft and I take no responsibility for any adverse outcomes if you choose to implement this in a production environment 🙂

So with that out of the way how do we go about this?

Well the main problem with trying to do this is the issue of staging the boot image to Windows XP – so make sure that you have a Windows PE 3.1 boot image and that you have a Configuration Manager client on your Windows XP OS that is 5.00.8239.1203 or higher. If you get this wrong, you will see an error in the logs relating to an inability to stage the image as per the below screen grab. The other main issue your likely to run into is a lack of drivers in your Windows PE 3.1 boot image, so spend some time making sure you have all of your hardware models NIC and storage drivers added to the boot image that are required.

2015-10-05_111554

A few assumptions are going to be made by me here.

  • You have a working Configuration Manager 2012 R2 SP1 site with Cumulative Update 1 installed + hotfix KB3084586
  • You have installed the Windows ADK 10 and have a working USMT 10 package
  • You have installed MDT 2013 Update 1 and have integrated it with your Configuration Manager instance
  • You have a working USMT 4 package (You can download the Windows AIK to grab the USMT files, usually in c:\Program Files\Windows AIK\Tools\USMT)
  • Your Windows XP machine has a working, active Configuration Manager agent installed at version 5.00.8239.1203 or higher
  • You have a working custom Windows PE 3.1 x86 boot image with your hardware model network and storage drivers injected into it – follow this guide for building your own boot image. You can use DISM to inject drivers in a mounted wim file with this documentation. Remember that you will need to inject the correct driver versions relevant to the PE 3.1 boot image, in most cases this will be the Windows XP equivalent for each of your hardware model types.
  • You have added this Windows PE 3.1 x86 boot image to your Configuration Manager environment and have replicated it to your Distribution Points

2015-10-05_114630

  • You have a Windows 10 reference image

The process

  • Create your USMT 4 package and distribute the package to your Distribution Points. As mentioned previously the source files can be obtained from the Windows AIK.

2015-10-05_102155

  • Create a new MDT Client Replace Task Sequence specifying your Win PE 3.1 boot image, MDT Files package, Windows 10 OS reference image, Client package, USMT 10 package and your Settings Package. Make sure that you add any driver packages, applications and other settings for your Windows 10 OS such as Start Menu Layout file import steps, etc. Also don’t forget to set a local administrator password, time zone and any other Task Sequence specific settings that need to be addressed.

2015-10-05_104246

2015-10-05_104855

  • Edit the newly created Task Sequence so that the Capture User State step runs your USMT 4 package. Even though Microsoft have documented that USMT 10 supports capturing files and settings from Windows XP, it fails with an execution error about scanstate.exe not being a valid Win32 Application. Note that you could use USMT 5.0 however I already had a working USMT 4.0 Files package so for this blog I have chosen to leave the version at this level. You can leave the Restore User State step as USMT 10 as it will restore the data from the Capture User State step.

2015-10-05_102026

  • Create a new collection for deployment and review your Task Sequence.
  • Check that your Windows XP client is running the correct Configuration Manager client version of 5.00.8239.1203 or higher and add your Windows XP client to the collection.

2015-09-28_134201

2015-10-02_145049

2015-10-02_152141

2015-10-02_154909

2015-10-05_081808

2015-10-05_110650

  • Review your results. Its worth mentioning that the User State Migration Process doesn’t restore the wallpaper settings between Windows XP and Windows 10 and I don’t believe this is possible. However I’m happy to be corrected on this one if anyone does manage to achieve this. It does however migrate the source jpg and I’ve just reset this as the background image.

Cheers

Damon

 

 

There are a number of aspects to our Windows 10 corporate branding / look and feel that I have implemented recently with three main changes involved. Its worth mentioning up front that I’m not using a corporate logo or style however you could easily substitute what I have done with your own images to achieve the same outcome.

With that out of the way!

These changes are:

  1. Setting a default lock screen wallpaper that is consistent with the Windows 10 operating system and the Microsoft color scheme.
  2. Removing the default Hero wallpaper that is displayed immediately after a Windows 10 workstation is started prior to logon.
  3. Setting a default desktop wallpaper (where required).

To achieve these changes I’ve used a combination of Group Policy and Operating System Deployment choices with our Configuration Manager 2012 Windows 10 Task Sequence.

Setting the Lock Screen Wallpaper

To implement this you will need to add the following to the Group Policy that is targeting your Windows 10 workstations under Computer Configuration/Policies/Administrative Templates/Control Panel/Personalization.

  1. Set Do not display the lock screen to Enabled (This is not required although in our environment we have chosen to enable this for other reasons)
  2. Set Force a specific default lock screen image to Enabled with a value of c:\windows\web\screen\yourcustomlockscreenimage.jpg

Don’t worry about the file not actually being present at the this location, as we are going to use our Configuration Manager Task Sequence to copy the lockscreen image to the workstation as part of the build process. Alternatively you could copy the image file using a group policy preference or even reference the image to a highly available DFS file share (Although I personally don’t like the idea of this for various reasons).2015-09-28_125040

Now that we have configured our Group Policy we need to create a simple package in our Configuration Manager 2012 environment and add a step to our Task Sequence.

  1. Create a new folder for your package under your source share. I’ve called ours DoJ Windows 10 Branding but its entirely up to you.
  2. Copy your JPEG image to the folder. This image should be formatted correctly for your environment with regards to size. If your using anything other than a solid color, then you may need to have multiple images of various sizes. This blog offers a good way to manage this, but for my blog this is out of scope as I am using a solid color background with a resolution of 3840 x 2160. The color I have chosen is the default blue that is included in Windows 10.
  3. Replicate your new package.
  4. Create a new Run Command Line Task Sequence step called Copy Corporate Branding Lockscreen Image (or similar) and specify the package details as per below.2015-09-28_130411
  5. When you build a workstation now you should now see your custom lockscreen image! Note that there is a small Group Policy bug in Windows 10 which requires you to restart after your Configuration Manager Task Sequence completes. This seems to be related to Windows 10 not applying Group Policy objects even though the SMSTSPostAction variable is set with a restart command.2015-09-28_130743

Removing the Default Hero Wallpaper

I’ve seen quite a few ways of implementing this, but basically it comes down to a registry change which set the value of HKLM\SOFTWARE\Policies\Windows\System\DisableLogonBackground from 0 to 1.

My preference is to do this during the Operating System Deployment process, but again this change could be implemented by Group Policy or as an additional step in your Task Sequence i.e. executing a reg add command or merging a reg file.

I’ve found that using unattend.xml for this process is quite effective and simple. It also has the added benefit of reducing administrative overhead that the other solutions offer.

  1. Open your unattend.xml using Windows System Image Manager and add the following to your specialize pass from the amd64_Micorosoft-Windows-Deployment_neutral component. Please ensure that the order value is 1. In the screen captures my order value is 2 because I am applying an additional registry key change which is not relevant to this blog.2015-09-28_1324262015-09-28_132656
  2. Save your unattend.xml and replicate the package so your Task Sequence uses the updated version.
  3. Now when you deploy your reference image this registry change will be added. Please note that again, you may need to restart your workstation after the Task Sequence has completed for the change to be effective.2015-09-28_134201

Setting a Default Desktop Wallpaper

Again with this change I’ve chosen to leverage Group Policy. We have a small group of workstations that require an enforced background.

To implement this you will need to add the following to the Group Policy that is targeting your Windows 10 users under User Configuration/Policies/Administrative Templates/Desktop/Desktop

  1. Set Desktop Wallpaper to Enabled and specify the location of your image file.

You could add an additional step to your Configuration Manager Task Sequence to copy the image file to c:\windows\web\wallpaper\yourcustomwallpaper.jpg however in my case as its only a small subset of workstations, I’ve pointed the group policy to my Distributed File System.2015-09-28_134423

I hope this blog helps those of you looking to implement some changes to the default appearance of Windows 10.

Cheers

Damon

UPDATE 2:

If you’re having difficulty setting default file associations using the dism import method then you can try the following alternative.

  1. Perform a basic Windows 10 deployment and set your file associations manually as per your preference
  2. Create an xml file of these file associations by running Dism /Online /Export-DefaultAppAssociations:<path to xml file>\AppAssociations.xml
  3. Rename this file to OEMDefaultAssociations.xml
  4. Create a Configuration Manager Package with this file and distribute to your DP’s
  5. Add a Run Command Line step in your Windows 10 Task Sequence which copies the file to c:\Windows\System322017-01-30_145524
  6. Windows 10 will use this xml file when setting default file type associations

UPDATE:

I’ve updated the script I use to Powershell. Process is the same though.

Be aware that a lot of people have reported difficulty in setting file association defaults with them reverting back to their defaults at first login. This seems to be related to an update that was included in the April/May Windows 10 Cumulative Update. There is no fix presently that I’m aware of however some have had the issue and some do not which makes me think its related to the application itself and how its modifying the Windows 10 default file type settings. Hopefully this will either be addressed by developers releasing updated versions of their applications that conform with Microsoft’s expectations or Microsoft releasing an update to address the issue.

  1. Create a ps1 script with the following contents: dism.exe /online /Import-DefaultAppAssociations:$PSScriptRoot\AppAssociations.xml
  2. Copy that script to a package folder with your application associations xml file
  3. Add a Task Sequence step to execute the script

3QNpv-Lo

With Windows 10 now approaching its 2 month anniversary since RTM, I have finally finished the reference image our agency is going to use. Its taken quite a few attempts to get things right so hopefully some of my approaches to implementing solutions to some common issues will save you some time and effort.

Firstly lets establish how I’m creating my reference image. I’m using two Hyper V Virtual Machines running on a solid state drive.

1 x Server 2012 R2 with MDT 2013 Update 1 Build 8298

1 x Server 2012 R2 running a WSUS instance

Then running a pretty standard Build and Capture task sequence with LTISuspend.wsf to allow for some minor changes. With that out of the way – lets talk about how I’m setting my default file associations.

By default Windows 10 has a number of default associations which you may not wish to keep. For example, by default the PDF extension is associated with Microsoft Edge so if your deploying a 3rd party PDF reader, you’re most likely going to want to deal with this. Some other file types you may want to change may include what application is associated with photos and videos as by default these are associated with the built in modern applications. You may also want to change the default browser from Edge to Internet Explorer 11.

You can control file type associations with group policy and there are quite a few blogs already about this. I’ve chosen not to use this approach as it enforces a baseline set of associations and I want my environment to be flexible to allow for variation if needed.

  1. On a reference computer running Windows 10, install all of your standard operating environment applications then set your default programs as per your preference.
  2. Once finished run an elevated powershell instance and  type Dism /Online /Export-DefaultAppAssociations:<path to xml file>\AppAssociations.xml2015-09-24_133139
  3. Next create a new Configuration Manager package that includes this xml file and distribute it to your DP’s. You can edit the file if you need to make further changes. Note that you don’t need to create a program.2015-09-24_133611
  4. Now we need to create two new Run Command Line steps in our Windows 10 Configuration Manager Task Sequence. One to copy the xml file locally to the target workstation and a second to execute the DISM import command. I’ve added these steps to my OSD Results and Branding group section of my Task Sequence. Make sure you disable 64-bit file system redirection otherwise your DISM import command will error out.2015-09-24_135038 2015-09-24_135343
  5. That’s it! You will now have a reference image that has a default set of file type application associations.