Tag Archives: group policy

Server 2016 – Remote Desktop Session Host Start Menu

Last week we ran into a small issue with one of our first Server 2016 deployments when using it as a Remote Desktop Session Host (RDSH) that took us a little while to figure out.

The Problem

When we added the machine to the RDSH collection, the machine would then fail to load any Appx apps (including the start menu (ShellExperienceHost!). We initially had a bit of trouble targeting the cause, as other than adding the machine to the session collection, nothing had changed.

Some Troubleshooting

We did find some events saying the application couldn’t be installed in the application log (for the first login only), but also every time in the TWinUI log. This gave me a good idea of where the problem lay, but we followed through looking at the logs to see if it would give us some more information.

This log is found in the following places:

Applications and Services Logs\Microsoft\Windows\Apps\Microsoft-Windows-TWinUI/Operational



The events looked like the following:

Log Name: Microsoft-Windows-TWinUI/Operational
Source: Microsoft-Windows-Immersive-Shell
Date: 20/03/2017 14:08:32
Event ID: 5985
Task Category: (5961)
Level: Error
User: DOMAIN\user
Computer: RDSH.domain.local
ActivateApplicationForContractByAppIdAsUserWithHost of the app Microsoft.Windows.ShellExperienceHost_cw5n1h2txyewy!App for the Windows.Launch contract failed with Install failed. Please contact your software vendor..

We also tried trusty ProcMon (nothing obviously access denied or wrong), all that would happen WerFault.exe would appear when trying to run ShellExperienceHost.exe manually.

Log Name: Application
Source: Application Error
Date: 20/03/2017 13:55:19
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: RDSH.domain.local
Faulting application name: ShellExperienceHost.exe, version: 10.0.14393.447, time stamp: 0x5819bf85
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.14393.953, time stamp: 0x58ba5c3d
Exception code: 0xc0000409
Fault offset: 0x00000000000521d0
Faulting process id: 0xbe0
Faulting application start time: 0x01d2a1819c994d20
Faulting application path: C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: 4c97f524-b5e8-44c0-b03a-2b939c6924d2
Faulting package full name: 
Faulting package-relative application ID:

A Clue!

We then looked in the next place we usually look when this kind of thing goes on, even though there were no changes to the machine, other than adding the machine to the session collection.

You guessed it, the AppLocker logs! We saw a few events like this:

Log Name: Microsoft-Windows-AppLocker/Packaged app-Deployment
Source: Microsoft-Windows-AppLocker
Date: 20/03/2017 14:08:22
Event ID: 8026
Task Category: None
Level: Error
User: DOMAIN\user
Computer: RDSH.domain.local
No packaged apps can be executed while Exe rules are being enforced and no Packaged app rules have been configured.
Log Name: Microsoft-Windows-AppLocker/Packaged app-Execution
Source: Microsoft-Windows-AppLocker
Date: 17/03/2017 17:13:35
Event ID: 8027
Task Category: None
Level: Error
User: DOMAIN\user
Computer: RDSH.domain.local
No packaged apps can be executed while Exe rules are being enforced and no Packaged app rules have been configured.

Turns out the issue was Applocker blocking the install and the run of the app, which is odd since it wasn’t affecting us before. This problem doesn’t seem to affect administrative users that log on before the machine is added to the session collection (which I believe is the expected behaviour). The unexpected behaviour is that AppLocker policies appear to be enforced for all users when the server is in a session host collection, which in our case prevented the start menu from working.

The Solution

A simple fix in the end.

We added the default Appx signed apps allowed rule to our Applocker Policy, however you could make sure just the required applications (like ShellExperienceHost) are allowed.

I’m glad we got to the bottom of it reasonably quickly and I hope that this post might help some others with the same issues.

SCEP 2012 R2 – Updated ADMX Template for the February Update – KB3041687

The revised February update for Microsoft Endpoint Protection products is out (KB3041687) and brings with it a couple of changes to registry keys introduced in the first February update.

This update deprecates the DisableGenericReports subkey and adds a new DWORD called SubmitSamplesConsent to the following place:

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Antimalware\SpyNet

This new key will allow configuration of sample submissions to Microsoft for analysis.

I have added these updates to my ADMX template for SCEP 2012 R2, which can be downloaded from GitHub.

Notes from KB3036437

Endpoint Protection may request file samples to be sent to Microsoft for further analysis. By default, Endpoint Protection will always prompt before it sends such samples. There is an option available to send samples automatically. To opt in to automatic sample submission, open the Endpoint Protection UI, click the Settings tab, select the Advanced section, and then click Send file samples automatically when further analysis is required.

Administrators can manage automatic sample submission with additional configuration options through WMI, PowerShell, and Group Policy by using the following registry subkeys:

MAPS Configuration

Registry location:

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Antimalware\SpyNet

DWORD name: SpyNetReporting
DWORD values:

  • 0 – Off
  • 1 – Basic Membership
  • 2 – Advanced Membership

Sample Submission

Registry location:

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Antimalware\SpyNet

DWORD name: SubmitSamplesConsent
DWORD values:

  • 0 (default) – Automatic sample submission disabled. End-users will always be prompted for samples.
  • 1 – Most samples will be sent automatically. Files that are likely to contain personal information will still prompt and require additional confirmation.
  • 2 – All sample submission disabled. Samples will never be sent and end-users will never be prompted.
  • 3 – All samples will be sent automatically. All files determined to require further analysis will be sent automatically without prompting.

SCCM 2012 R2 – Problems with SCEP 2012 R2 and Group Policy Results

We ran into an issue yesterday with Group Policy Results when using SCEP 2012 R2, the problem exactly follows this particular issue on the TechNet Forums, but appears to affect a couple of extra registry keys.

It’s really unfortunate that this still isn’t fixed in SCCM 2012 R2, having also been an issue in 2012, as the post describes.

To resolve the problem, I used my existing SCEP Group Policy ADMX template in creating a GPO to replicate the default settings pushed out to clients with SCCM, which solves the problem, as the exceptions and settings we push out to standard clients aren’t any different from the Microsoft recommended settings.

In the GPO I had to specify the exclusion settings and also the default threat actions, which are specified in the registry here:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\Threats\ThreatSeverityDefaultAction

Previously these settings were defined as REG_DWORD, but need to be REG_SZ, as shown below: