System Center 2012 Configuration Manager, 802.1x and Migration

It was interesting going to a Microsoft System Center 2012 launch party and hearing the opinion that wired 802.1x is an old outgoing technology and we should all move to IPSEC. At the same time across town Cisco have 802.1x at the heart of their up and coming ISE product. Anyway, well done to Microsoft for bring the System Center product up to date (to a point!)

My guess is that we will still be hacking away at Microsoft Products in order to enable the smooth running of wired 802.1x. Fortunately, with the ground laid down in my previous posts, there is very little to do different from the latest version of Configuration Manager. if you have not already read those posts, you will need to cover those. This just adds on to the previous offering.

Your prepared boot images will still work with one exception. Microsoft have done something amazingly sensible: They have moved the start up hook from the TSConfig.ini file and into the GUI. To be precise, you no longer have to amend the TSConfig.ini file I referred to in my previous into the boot image before showing it to Configuration Manager. In fact, if you do it will ignore it now. Instead go to the boot image in Configuration Manager and select property. On the Customisation tab tick 'Enable prestart command' and enter your script command here: x:\windows\system32\cscript.exe pretsmboot.vbs.

I have still included the pretsmboot.vbs files in the image because they are needed when you run a task sequence that does not boot from PXE, such as when you run it from the new Software Center. However, you do have the choice of including the files and you also specify this in the same location.



There is a gotcha, of course. If you want to do the same for a CD or USB bootable image, you will need to put those same files into a package. When you create the bootable CD image you will be asked for a package is you want to include file, not just a source directory. But that's not a problem.

Otherwise everything else is the same as before. Of course, we are still talking about Windows 7 here, not Windows 8. That's another hurdle that will be long into the next half of the year before we venture there.

Other Gotchas in System Center 2012 Configuration Manager

• It is entirely possible to import the Operating System Images and driver packages from SCCM 2007. My advice? Don't. Especially the OS images. Don't even think about just copying the same previously captured WIM file. I don't know what the MDT does to images when you capture them, but it creates interesting and varied problems with OSD afterwards. One such problem is the disappearance of the OSD Task Sequence Progress Bar on 64bit builds. Who knows why, it just solves it when you create and capture a new image. Instead create new images captured with the 2012 MDT that is the only version compatible with System Center 2012. This will save you a whole heap of pain.
• I don't know about you, but we are now running totally on 64bit, with any 'I really need 32bit' applications running happily on Application Virtualisation. However, that does not mean you can ditch the 32bit boot image. Oh, no! If you want PXE to work, even if you only server 64bit OS to PCs, you need a 32bit boot image set up to be served by PXE as well as your 64bit version that will be the only image ever used. PXE will not run without a 32bit image. I think it's something like a comforter. PXE has reached that age when no-one really wants it in the room, but seeing it still hasn't written a will, everyone is being nice to it, so really it can do what it likes and no one will scold it. I will be glad when the IPv6 equivalent finally makes an appearance and puts the old man to bed.
• Capture those reboots. The 2012 OSD seems to be a little less robust in handling unexpected reboots. So wherever possible, try to catch those application reboots with a -noreboot flag or similar. The OSD will bomb out if it is hit with an unexpected reboot and it will not recover.

Finally, if you haven't already, introduce some custom task sequence variables. The standard MDT Task Sequence includes such things as "Request State Store" regardless of whether it has actually done a Capture User State or not. You will end up with errors every time you run a task sequence on a new PC. It is a trivial task to clean up this mess by settings a task sequence variable after the Capture User State and referring to that Variable as a condition for the State Store Restore tasks. I don't know about you, but I hate spurious red marks in my logs that I know should not be there. It just makes it look like it's not a clean build when it really is.

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.