Installing .NET Framework 3.5 during Task Sequence

Have you ever tried enabling .NET Framework during OS deployment in a Task Sequence? Instaling Windows 8.1 this should be enabled easily by running the following command line:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All

However, it's not as easy as it looks. This task often fails with error 0x800f081f during TS deployment. Also if you try to install .NET Framework offline by mounting the image it fails with the same error, see below.

Searching around I found out that 2 packages are prohibiting the .NET Framework action from succeeding. Package KB2966826 and KB2966826 are both integrated in the default Windows 8.1 installation.

Solution:
To enable .NET Framework in the first place both packages should be removed. These actions can be run as Command Line action in the Task Sequence.

Uninstall KB2966826

• DISM /Online /Remove-Package /PackageName:Package_for_KB2966826~31bf3856ad364e35~amd64~~6.3.1.7 /quiet /norestart

Uninstall KB2966828

• DISM /Online /Remove-Package /PackageName:Package_for_KB2966828~31bf3856ad364e35~amd64~~6.3.1.4 /quiet /norestart

After removing the packages, the .NET Framework feature can be installed succesfully using the comand line below.

• DISM /Online /Enable-Feature /FeatureName:NetFx3 /All

The KB updates can be installed afterwards using the Software Updates step. These actions can be run in the Build and Capture phase, so .NET is available in every deployment.

 

ConfigMgr Cumulative Updates

Every now and then Microsoft releases Cumulative Updates. Twitter explodes on the new release, like everyone is going to deploy the update without a doubt.

However: when I read the Microsoft support article I come across the following lines:

A supported update is available from Microsoft Support. However, this update is intended to correct only the problems that are described in this article. Apply this update only to systems that are experiencing the problems described in this article. This update might receive additional testing. Therefore, if you are not severely affected by these problems, we recommend that you wait for the next service pack that contains this update.

So, I found that non of these apply to my customer(s). Should I apply the update anyway, or wait for the Service Pack to come?

The only things I see here are the additional testing and administrative burden that are involved applying the CU.

So what is your advice or way to go? Please leave your comments, just a line will do, I'm curious.

Thx!

Symbolic Links to the rescue

Lately I needed a solution to redirect System Center Endpoint Protection 2012 R2 definition updates to a alternative location. The situation was it was installed on a VDI machine which means the C-drive is non-persistent.
So I created a brand new vDisk with the latest definition updates and brought it online. The first day the definition updates are all current, but after a restart of the VDI, it gets back to the initial state. It's not recommended nor desirable to create a new vDisk every day, but I wanted to stay current with the updates. So every day the VDI needs to download more definitions and is not current at startup.

I came up with a solution to use a Symbolic Link to redirect the definition updates to a persistent writecache or overflow disk.
So before the Endpoint Protection solution in installed I created a folder on the D-drive to store the updates.
Then I created the SymLink on C:\ProgramData\Microsoft

Mklink /d /j "Microsoft Antimalware" D:\SCEP

So what this does is create a Symbolic Link named "Microsoft Antimalware" and connect it to the actual location D:\SCEP. For the OS the Symbolic Link looks like any ordinary folder and is threated that way. Also when you browse through the folders it looks like your in the folder, while your actually browing D:\SCEP. So easy to setup and yet so powerfull!

So when the Endpoint Protection client is installed and downloads the definition updates, the updates are placed in the "Microsoft Antimalware" location which is.... right the D:\SCEP location. So now you have an up-to-date AV solution in your VDI deployment.

System Center Endpoint Protection 2012 R2 policy issue

Recently I came across this issue about SCEP update definitions not being applied on (in my case) Citrix VDI computers.

Errors in the C:\Windows\CCM\Logs\EndpointProtectionAgent.log
Failed to apply the policy C:\WINDOWS\CCM\EPAMPolicy.xml with error (0x80004005).
Failed to apply policy with error 0x80004005, retry number : 1 after 60 second.

But mainly visible in the Management Console.

Luckily there are some community colleagues who dealt with this issue before, I did not solve my issue, maybe because we use streamed vDisk, or because this issue already existed for a long time. Any way many people benefit from the solution.

See Henk's blog for a solution.

Edit: Another solution could be to remove the gpt.ini (C:\Windows\System32\grouppolicy) because it became corrupt.