Posts Tagged ‘Configuration’

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

 

 

Advertisements

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

 

 

Recently we noticed some performance issues in laptops with shared graphics when the Windows 7 Basic Theme was being used (particularly with external monitors using display port cables) These issues were resolved when selecting the Windows 7 Aero Theme. We were even able to reproduce the problems on the manufacturers image.

I have asked on a few international Configuration Manager forums and apparently the Windows 7 Basic theme being used as a default is a well known issue / problem for people when you capture an image using a virtual platform such as Hyper V or VMWare. Some are deploying custom branded themes (which utilizes the aero technology) and others are setting the default Windows 7 Aero theme with Group Policy as we have done with this solution. Others are aware of the setting but have elected to do nothing and leave it as is with Windows 7 using the Basic Theme as the default.

We have applied two distinct actions.

1. Apply an additional step at the end of our build Task Sequences to run winsat.exe dwm which assesses the ability of a system to display the Aero desktop effects.

pic1

2. Created a new Group Policy which targets the Windows 7 OS version via a WMI query to set the Windows 7 Aero theme (Settings located at User Configuration \ Administrative Templates\ Control Panel \Personalization: Force a specific visual style or force Windows Classic & Load a specific theme file)

pic2

2014-08-13_091526

Our builds are now using Windows 7 Aero theme as the default upon login.

Cheers

Damon

We recently implemented the Configuration Manager 2012 Management Pack with Operations Manager 2012 to improve our ability to analyse load, performance and health of our environment.

Following the installation we initially had some issues with only the Primary Site being partially monitored and no site system roles being reported as healthy. This also included components such as our Distribution Points and Management Point.

Eventually we were successful and the Management Pack is now monitoring our environment in full. We did the following in order to resolve the problem.

  1. Installed the SCOM agent on all of our servers running either Site System or Site Server Config Manager components
  2. Enabled Agent Proxy under the Security Tab on each managed server with Config Manager infrastructure running on it including the Primary. This is contrary to the Management Pack documentation.
  3. Created SCOM exclusions for our Anti-Virus (Initially we had to completely uninstall it on our SCOM server for the monitoring to fully work)
  4. Disabled the client discovery object as we are not running Config Manager clients on our infrastructure
  5. Decreased the Hierarchy Discovery time from 86400 seconds to 600 seconds
  6. Decreased the Central Site Discovery time from 14400 seconds to 600 seconds
  7. Increased the Site Services Discovery, Hierarchy Discovery and Distribution Point Drive Discovery timeout from 300 seconds to 500 seconds
  8. Performed a manual Site System Discovery and Hierarchy Discovery from the SCOM console
  9. Waited approx 6 hours for monitoring data to initially full populate

2014-07-01_102127

Out of the box the management pack provides monitors for all the Config Manager infrastructure which you don’t need to create overrides for. However if you want to start collecting performance data then you do need to create overrides for each specific area. You can refer to the MP documentation here for the full list.

http://www.microsoft.com/en-us/download/details.aspx?id=29267

2014-07-01_102907

I’ve created some custom dashboards in addition to inbuilt ones (Note these wont work until you have tuned the MP to your requirements by enabling additional rules). Hopefully these give you an idea of what is possible with the MP. We have a couple of these cycling through on a large LCD panel in our office which give the Service Desk staff a good overview of the status of the Config Manager environment.

OVERALL HEALTH DASHBOARD

2014-07-01_103430

DISTRIBUTION POINTS PROCESSOR UTILIZATION

2014-07-01_104138

DISTRIBUTION POINTS FREE DISK SPACE %

2014-07-01_114029

MANAGEMENT POINT UTILIZATION – TOTAL ONLINE CLIENTS

2014-07-01_104313

MANAGEMENT POINT UTILIZATION – Authentication Requests / Sec, Hardware & Software Inventory Requested / Sec

2014-07-01_104956

HIERARCHY DIAGRAM SHOWING HEALTH ROLLUP

2014-07-01_105913

I’ve only really scratched the surface with what you can monitor and report on. Hopefully this gives everyone a good idea of what’s possible and how to do some basic installation troubleshooting based on what we experienced.

Cheers

Damon

I have applied the recently released Cumulative Update 1 to my System Center 2012 R2 Configuration Manager production environment today. I thought it might be useful to blog about the process I went through. Now to be clear, the ADK 8.1 Update is not a pre-requirement for 2012 R2 CU1. I have just taken the opportunity to apply it whilst applying CU1 as a restart is required for both processes. If your interested in the new ADK version and unsure if you should apply it here is a good blog on the subject.

Step 1: Update the ADK from 8.1 to 8.1 Update The new ADK provides a number of hot fixes including some for USMT 6. Here are the release notes and here is the download link. As I was already running the ADK 8.1 , I just ran the new versions setup and installed the updated components over the top of the existing ones. Note that the installer detects which components you have installed.

2014-04-07_135853

2014-04-07_140157

I checked out the USMT folder after the setup completed and I had rebooted. It leaves your existing custom files in place and just updates the changed components – new loadstate.exe and scanstate.exe versions for a start amongst others with a date modified of 20/2/2014.

2014-04-07_141203

Step 2: Download and apply Cumulative Update 1 (KB2938441) It can be downloaded from here. Running through the installation process is fairly straight forward although make sure you are installing the update with an account that has appropriate access to your SQL instance.

2014-04-07_141026

2014-04-07_141312

2014-04-07_141345

Opening the log file shows the standard msi file install process. The log file is created in the c:\Windows\TEMP directory

2014-04-07_141607

2014-04-07_141656

2014-04-07_141731

I only created an update package for the new Client as I only have a small environment with one Primary and no other site servers. I also only have 5 instances of the Configuration Manager Console and have chosen to manually apply the update on those computers.

2014-04-07_141832

2014-04-07_141916

2014-04-07_142031

The installation and update process only takes around 5 minutes.

2014-04-07_142256

2014-04-07_142518

2014-04-07_142713

Rebooting the server after installation is required.

2014-04-07_142800

Step 3: Tweak some settings and update your USMT package I have changed the option in each Client Update package that gets created so that the installation notification is suppressed. This will prevent any notifications from appearing on computers. You can of course leave it unchecked but why bother users.

2014-04-07_144609

If you have your USMT Tool Package setup correctly then it should point to the USMT folder within the ADK installation folder (Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\User State Migration Tool). So all you should have to do here is simply update your distribution points. If you have a separate package, the you will need to update your source files with the new versions and then replicate that packages content.

2014-04-08_100741

Step 4: Create / Update your client collections and deploy the new client:

You should end up with an x86 and x64 R2 CU1 client update package in the console. I have setup some client hot fix collections to target my x64 and x86 clients with appropriate limiting base collections to ensure that I’m targeting healthy clients. Against each collection I have a query to control collection membership.

The query syntax for x64 based clients that I’m using is:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceID = SMS_R_System.ResourceId  inner join SMS_G_System_SMS_ADVANCED_CLIENT_STATE on SMS_G_System_SMS_ADVANCED_CLIENT_STATE.ResourceId = SMS_R_System.ResourceId  where SMS_R_System.Client = “1” and SMS_G_System_SYSTEM.SystemType = “X64-based PC”  and SMS_R_System.Active = “1” and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.DisplayName = “CCM Framework”  and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Version != “5.00.7958.1203”

The query syntax for x86 based clients that I’m using is:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_SMS_ADVANCED_CLIENT_STATE on SMS_G_System_SMS_ADVANCED_CLIENT_STATE.ResourceID = SMS_R_System.ResourceId where SMS_R_System.Client = “1” and SMS_G_System_SYSTEM.SystemType = “X86-based PC” and SMS_R_System.Active = “1” and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.DisplayName = “CCM Framework” and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Version != “5.00.7958.1203”

Be careful when copying and pasting as the inverted commas are often copied incorrectly into the query statement window.

2014-04-08_101920

Then deploy your client update packages to your collections. The upgrade is quite quick, taking only a few minutes.

2014-04-07_150755

You will end up with a client version of 5.00.7958.1203

2014-04-08_105025

Step 5: Modify your Task Sequences to include the client update

This is the final step that I have done. To ensure that client patches are applied during OSD I have previously created a separate Configuration Manager Client Package with Hotfixes as per this blog.

I’ve updated this package with the new client files and copied the new hotfix msp’s (configmgr2012ac-r2-kb2938441) to the respective updates folder.

Finally I’ve modified each of Task Sequences with the updated hot fix name.

2014-04-08_103835

Happy updating,

Cheers

Damon

I’ve implemented this solution based on information provided in the following blogs – credit to these people for posting this information.

http://www.deploymentresearch.com/Research/tabid/62/EntryId/97/PowerShell-wrapper-for-MDT-2012-Update-1-and-MDT-2013-Preview.aspx

http://blogs.technet.com/b/deploymentguys/archive/2013/10/21/removing-windows-8-1-built-in-applications.aspx

So I’ve moved on from my old process of corporate WIM image creation. I used to build up an image from a source ISO for a respective operating system using Hyper V, make my customisations, apply patches, then use MDT to do a sysprep and capture. I know, I know, there are probably numerous reasons why you shouldn’t do this. Well no more after watching Johan’s session from System Center Universe this year here 

The new process involves the more contemporary approach of doing a completely automated build and capture in one process with MDT performing any additional changes using scripts and additional steps. The session that Johan presented is in my view the best by far that I have seen.

One thing that wasn’t covered was how to remove the built in Windows 8.1 Modern Applications. In my case (like many others) we are deploying Windows 8.1 and do not wish to have all of these applications available.

Here is a solution you can implement which will remove these apps as part of your MDT or Configuration Manager Task Sequence. My example will be in MDT 2013.

Firstly create a new powershell script from the this blog, you can amend the script as required so that it only removes the applications that you want. Alternatively I have copied the script syntax into a word document here removemodernappsnew – please make sure that you edit this script in Powershell ISE to confirm that there are no syntax errors.

Copy the script to your MDT server sources folder.

Create a new MDT application and give it an appropriate name such as Remove Windows 8.1 Modern Applications

RemoveApps1

Use the following powershell wrapper command – credit to Johan who posted the install wrapper argument here

powershell.exe -Command “set-ExecutionPolicy Unrestricted -Force; cpi ‘%DEPLOYROOT%\Applications\Remove Windows 8.1 Modern Applications\RemoveWindows8Apps.ps1’ -destination c:\; c:\RemoveWindows8Apps.ps1; ri c:\*.ps1 -Force; set-ExecutionPolicy Restricted -Force”

Note you will need to adjust the path to your powershell script depending on how you setup the application in MDT.

RemoveApps3

Now just add an install application step in your existing MDT / Configuration Manager Task Sequence, its that easy.

RemoveApps2

If you implement a Suspend action in your MDT Task Sequence you can check that the apps have been removed.

RemoveApps4

RemoveApps5

Cheers

Damon