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.
