Displaying C# Dialogs in the 64bit SCCM Task Sequence

Task Sequence Variables are a powerful tool when deploying new Operating Systems with Task Sequences in System Center 2012 R2. With a Task Sequence Variable, stored on a collection, you can reduce the number of Task Sequences you maintain. Each action or group of actions can be executed based on what the content of a Task Sequence Variable is.

The next logical step to using Task Sequence Variables for existing systems is to use them for unknown computers. For that you need a user dialog box to appear at the start of the Task Sequence to allow the person building the new PC to select what options to include in the build. You might want to be very specific about the drivers you install, for example.

For a Task Sequence with a 32bit boot image Psexec.exe is perfect for launching a dialog in Session 0. Without the option to do this the dialog does not appear. The application will run but it cannot display a GUI without having been launched in the same session at the Task Sequence.

However, 32bit is a bit old in the tooth. Most sensible people are now switching to 64bit operating systems. Psexec.exe however is a purely 32bit application that will not run on a 64bit WinPE image because WinPE does not support Windows on Windows (WOW64.) There are instructions on Technet Blogs about how to write your own application, which you then have to go search out each step of the way.

I did this and found the path a bit harrowing. It's not for the feint hearted but it's doable. I managed to write it first time. To make the application specific to Task Sequences (and not exploitable for other uses) it is written in such a way that it is tied to the task sequence process and will otherwise fail. If you like you can download it from here.

To use it, add it and the dialog executable to a package. In the task sequence use a "Run Command Line" option. Specify the package and for the command-line use tslaunch.exe

This was built for .Net 4.5.1 and works with the Window 8.1 64bit WinPE image (6.3.9600.16384)

If you would like the source code, please contact me on Google+ and I'd be happy to oblige.

Getting App-v to work with a Publishing Server

The way Microsoft is heading with App-v, we will all be dealing with it in a few years time. One day, it will be the way all applications are delivered to your PC. An application living as a distinct entity, yet interacting with the resources of the host PC. It is like discovering pot plants after years trying to weed a garden. If you knew you could isolate each plant, yet share the sunlight, rain and shade of the garden, you would never plant another in the ground ever again unless absolutely necessary. Later versions will allow you to plant two pots side by side so that you can share the same resources between them...

The latest offering, version 4.5 already expands Softgrid's approach by offering extra flavours. Not only can you stream an application from the Publishing Server or from a Terminal Server, you can now create an MSI file that loads the Application directly into the app-v cache and run the application without the need of a Publishing Server. Integration is also possible with System Centre Configuraion Manager.

But there are downsides to this expansion of the possible ways to use app-v: They become incompatible with each other. You cannot have either MSI approaches with a publishing server. There are registry keys that mess with the Publishing Server approach. One is:

HKLM/SOFTWARE/Microsoft/SoftGrid/4.5/Client/Configuration/RequireAuthorizationIfCached

This needs to be set to 1 if the Publishing Server is to work as expected. User targeting or the application may not run for some users, though it appears in the start menu or desktop.

Microsoft recomend that you deply the client application first and then apply the registry settings to make the application tick. I would suggest using SCCM for this. Use of the Setup.exe is almost essential as there is a prerequisite application buried in the Setup file. Don't even bother trying to extract it. You might see then name of the prerequisite during setup; don't bother going to look for it. Though you may install Visual C++ 2005 Redist, it still wants to run it's own version. Attempting to deploying the MSI alone through AD results in miserable failure.

Now to deploying the registry settings. If you are in an AD environment, you may not want to spend the effort writing a host (or PowerShell) script to deal with this. After all, Microsoft gives you the Group Policy Preferences. This is a great idea that saves time. However, Beware! The key registry setting that will cause the Publishing Server to silently fail to deploy its applicatons is:

HKLM/SOFTWARE/Microsoft/SoftGrid/4.5/Client/Configuration/UserDataDirectory

Why? When you place the %appdata% variable into Group Policy Preferences, the machine expands the key when applying the preference. The result is an entry that refers to the appdata for the system account. This is unreachable for normal user accounts. The app-v client appears to refresh, but no applications appear. If you check the list of applications, they will be listed, but will not show any icons.
Solutions: resort to a startup script that writes that particular key or, better still, do not add that key to the preferences at all. The default registry setting on installation is %appdata%...

Finally, it may be worth remembering that App-v is currently only 32-bit. The 64-bit version is apparantly due in 2010...

Finding that out after two days of pulling my hair out does not do wonders for your health. Hopefully, this tip will help you avoid the same pain.