Another change!

As you can see, the site has once again changed!

I’ve made some fairly big changes, but i’ve kept as much of the old content as I can. There’s a few broken links and formatting oddities, but welcome to migrating blog systems!

I’m using Jekyll at the moment, but since I’m a Windows bod, the buildchain is odd. I’m considering Hugo as an alternative, but I’ll make sure i’ve fixed the oddities and the links before I do that.

I’m working on the band side of things again, as well as some exciting projects coming up at work. This means there will hopefully be a few bits of shiny content and perhaps some music!

South Coast PowerShell Usergroup

I gave a presentation at the UK South Coast PowerShell usergroup back in June about psake and I thought I would post about it (finally!).

It was the first time i’d ever presented to a room of (mostly) strangers, but it was a really rewarding experience and something I am planning to repeat :).

You can find the presentation and the code on GitHub

If you are in the area, I strongly recommend you check it out! The meetup group for the South Coast group is here and the other user groups in the UK and details about them are here.

Discovering Open RDS User Profile Disks

Another week, another quick script!

Very occasionally, we have a problem with Remote Desktop User Profile Disks (UPDs) getting stuck mounted when there’s a problem with a RDS session host and it either reboots or crashes. Here’s a little script I’ve written to show the open VHDX files on a file server or SOFS cluster to find out which RDS host the VHDX is mounted on. Because user profile disks are quite fragile, there is a lot of odd behaviour around when a host crashes. When users log in again, the profile disk may mount on the new host, but the user always seems to receive a temporary profile and the disk gets stuck even after the user is logged out.

After this, you can then take action to unmount it and then deal with the disk. Anyways, here’s the script!

Script to be posted, sorry!

PowerShell Argument Completers

Something I do a lot of the time to make people’s experience with PowerShell easier, especially when they are new, or reluctant to learn is to write argument completers. A lot of the time, I write them for advanced functions and cmdlets I build, but I also find the odd occasion where I build them for existing commands.

I can’t believe I haven’t talked about this before, but I started doing this after watching this awesome video from the PowerShell Global summit by the awesome Rohn Edwards.

I always make sure to ship these even if 99% of the time the script is running completely automated because they are easy to write and, when you find you need them, the convenience is just awesome. Since these are PS v5 commands, you can always make sure you skip these when running on lower versions if you don’t want to require v5 as the minimum shell version, since they are entirely optional.

Probably the biggest time saver argument completers I’ve ever written are for the MSOnline Office 365 PowerShell module, as being able to tab through UPNs (and sometimes tenant IDs, once you start to recognise them :S) is absurdly useful.

These particular argument completers take a dependency on a little function to test whether you’re connected to Office 365, but there are other ways to do this as well. This function is also included below.

Anyways, because they’ve saved me a lot of time, here they are. Hopefully they will save you some time too!:

Completer 1

Completer 2

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

or

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TWinUI4%Operational.evt

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
Keywords:
User: DOMAIN\user
Computer: RDSH.domain.local
Description:
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
Description:
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
Keywords:
User: DOMAIN\user
Computer: RDSH.domain.local
Description:
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
Keywords:
User: DOMAIN\user
Computer: RDSH.domain.local
Description:
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.