Kernel Confusion

Hello everyone!

Our company tries very hard to use the newest software available, so customers see it in action when our consultants work with them. But in the “real world”, the clocks don’t tick as fast. Most of the time we face companies that are now migrating to Windows XP and Office 2003… oh my. In order to stay “compatible” with their workflows, it can be very complicated to maintain both worlds in one notebook.

To ease this pain, I looked into the Microsoft Desktop Optimisation Pack, short MDOP. The MDOP is available for companies that have Microsoft Software Assurance. One part of it is App-V. It virtualizes a software package in order to let it run on systems where compatibility issues due to other installed software would occur. It is not a full operating system virtualization, it’s just the application itself, running in a sandbox. So the software has still the prerequisite to be compatible to your target machines.

This step-by-step guide shows you the basic workflow to create a virtual software package and distribute it to a client with the ConfigMgr, in this case Microsoft Office 2003.

The following environment was used:
“Test Client”
Windows 7 Enterprise x64
Virtual Guest (Hyper-V)
App-V Sequencer installed

“Productive Client”
Windows 7 Enterprise x64
LenovoT61 Notebook
App-V Client and ConfigMgr Client installed (as well as a bunch of other stuff)

“ConfigMgr Server”
Windows Server 2008 R2 Enterprise x64
Virtual Guest (Hyper-V)
System Center Configuration Manager 2007 R2 installed

Be warned, this is a very long, screenshot-heavy post. To view the pictures correctly, click on the little button on the top right corner of the header to increase the column width.

More »

2008 I installed a System Center Configuration Manager 2007 environment at a customer’s site. In the end, we had quite large task sequences with dozens of “install software” entries to automate OS deployments as good as possible. A “feature” of ConfigMgr was to wait 90 seconds in between each task. Imagine 50 software packages… and do the math. It took much too long. A hotfix (KB955955) was released by Microsoft and I deployed it on the SCCM Server. It extended the CCM Client Agent with a MSP file that is applied while the agent is installed. The 90-sec limitation was gone.

So far, so good. This works well, until you upgrade to service pack 2! This will update the Client Agent and render it incompatible with the MSP file. Unfortunately, if you didn’t touch that software package for several months, you may forget about the MSP file. As a result, all your deployments will fail at the “Setup windows and ConfigMgr” task. Pretty simple: removing the MSP will solve the issue. The way to this solution took me a little longer than just a quick bing’ing, anyone who debugs System Center products knows what I’m talking about.

Here are screenshots from the smsts.log, which was logged on the failing client:

Today’s task was to upgrade an existing SCCM R2 SP1 installation to service pack 2. I checked the site status before I started: everything was “green”. The prerequisite check was “ok”, despite two minor warnings. So I went on and all SP2 tasks finished successfully. Well then, I thought, let’s check the existing OS deployment tasks to see if it’s still working.

MP Error Log

We set up a VM and tried booting into PXE… with no response of the server. Restarting the WDS service didn’t do the trick. So I dug a little deeper and took a look at the logs in %programfiles%\Microsoft Configuration Manager\Logs. Interesting files to look at: mpcontrol.log and pxecontrol.log (use SMS TRACE to

PXE Error Log

view these logs, if you don’t have any other preference). The PXE log didn’t tell me anything interesting, it even logged successful self-tests! Funny, because the log in the ConfigMgr-Console told me otherwise: the PXE service was not responding. It also told me the Management Port was giving a HTTP 500 error.

After a lot of rebooting and error-hunting I came up with a “solution” to this problem. It seemed the service pack installation didn’t properly update the PXE and management point and caused the unresponsiveness of both service roles.

WARNING: You may already know it, but just to be clear on this: the Configuration Manager takes some time to do it’s work. So be calm and watch the application log for MSI events, stating a successful (de)installation before rebooting. This is true for both the ConfigMgr Roles and Client Agent.

I did the following to solve it:

• Removed the Management Point Role (in ConfigMgr)
• Reboot
• Reinstalled the Management Point Role
• Removed the ConfigMgr Client Agent (ccmsetup /uninstall)
• Removed the PXE Role (in ConfigMgr)
• Reboot
• Removed the WDS Role (Windows Server)
• Reboot
• Reinstalled the WDS Server Role (no configuration after that of course)
• Reinstalled the PXE Role
• Reinstalled the CCM Client Agent
• Reboot

Yes I know: lots of lots of reboots. You may skip them if you dare, please drop me a line if it work anyway.

After that, all components went to green in the system state view and the PXE service started to respond as expected.