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.

I’ve recently finished our companies Windows 10 reference image using MDT 2013 Update 1 to perform the build and capture. Then using Configuration Manager 2012 R2 SP1 CU1 + some hotfixes to deploy the reference image.

There have been a number of issues that I’ve had to find solutions for over the past 8 weeks not withstanding the numerous bugs in the RTM version of MDT 2013 Update 1.

These have included:

  • Setting default file type associations
  • Implementing custom branding such as lockscreen wallpaper and disabling the default hero wallpaper at login
  • Removing selected Windows 10 modern applications
  • Blocking Windows 10 modern applications that can’t be removed with App Locker
  • Creating a default custom start menu layout
  • Pinning default items to the taskbar
  • Group Policy settings, in particular for Edge and Internet Explorer 11 Co-Existence
  • USMT 10 implementation and data migration

Over the next week or two, I will be blogging on these topics and how I’ve implemented a solution to each.

Cheers

Damon

Lets assume that your using MDT 2013, WSUS and HyperV to build and capture your Windows 7 SP1 reference image.

Due to the large number of updates now required for Windows 7 SP1 (Over 200!) you may run into an issue where your VM runs out of memory. Specifically, the problem is caused by the process TrustedInstaller.exe. To avoid this, make sure you allocate at least 4GB of memory. In addition to this its worth adding an additional processor to improve performance.

2015-04-09_153840

2015-04-09_154043

2015-04-09_153644

Even with these settings it takes a very long time for the process to complete. Hopefully Microsoft will release a new ISO this year with updates included.

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

This is an interesting one with a useful fix to know about.

A few months ago I did a new MDT Build and Capture, the process was largely automated with the use of LTISuspend.wsf to check a few things before resuming.

Recently I noticed that the Windows 7 Firewall Service wasn’t running on some computers. Not all, but still quite a few. I traced the problem back to this particular build.

Digging a bit more into the error – I could see Event 7024 ID’s being logged – The Windows Firewall Service terminated with service-specific error Access is denied..

 

2014-05-06_132121

The following Microsoft KB article was useful in diagnosing the fault and confirmed that the problem was related to the “NT Authority\MpsSvc” account not having the correct permissions to some registry keys.

http://support.microsoft.com/kb/943996

It would seem that somewhere during the build and capture process, the service account permissions were stripped out or not applied correctly, possibly during the WSUS patching phase of the build.

The following Blog discusses the specific, correct permissions required for the Windows Firewall Service to start under Windows 7.

http://blogs.technet.com/b/networking/archive/2011/06/14/the-windows-firewall-service-fails-to-start-registry-permissions.aspx

There seems to be quite a few articles that describe the cause and how to fix the problem, however I was unable to find a script or automated solution to address the issue. To automatically set the correct registry permissions I wrote a simply batch file using SubinACL, then created a program with Configuration Manager 2012 and deployed it to all my affected Windows 7 instances. Here is the syntax of the script:

Please be aware that when copying and pasting from this blog, the inverted commas may need to be re-typed.

SUBINACL /verbose=1 /keyreg “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy” /grant=”NT Service\MpsSvc”=QSCEYDA
SUBINACL /verbose=1 /keyreg “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Epoch” /grant=”NT Service\MpsSvc”=QS
SUBINACL /verbose=1 /keyreg “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Epoch2” /grant=”NT Service\MpsSvc”=QS
SUBINACL /verbose=1 /keyreg “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy” /grant=”NT Service\MpsSvc”=QSCEYDA
net start mpssvc
exit

2014-05-06_134329

SUBINACL can be downloaded from here.

The script sets the correct permissions for the respective registry keys discussed in KB article 943996 and the Microsoft Technet Blog. Then starts the Windows Firewall Service and exits. Of course you can also simply just run the bat file from an elevated command prompt manually. The below screen shot show the keys that are changed.

2014-05-06_133621

Applying this change has resolved the problem and performing a new MDT Build and Capture and then deploying that WIM file with Configuration Manager 2012 R2 CU1 has not resulted in the problem re-occurring.

Use this script at your own risk, whilst it only restores permissions that should already be present, it should still be tested in a Lab environment before use.

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