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.