Kernel Confusion

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:

Computers tend to get slower over time, the more you use it, the faster this will happen. But is this true for hardware as well? In this case: smartcards? I didn’t believe it until I got my hands on a few cards from employees that complained about very slow read times. Our company enrolled smartcards for Direct Access usage (and I love this Windows Server 2008 R2 feature!).

vSEC:CMS Key Tool

In the logon screen, it took Windows nearly 45 seconds to read the slowest card and ask for the PIN. Wow! There was no evidence against the card reader, nor the other hardware, as a slow card was slow on all test systems.

But what can you do? Format C! And C stands for “card”. The simplest answers are the best! A short “bing” later, I found a tool named vSEC:CMS Key Tool, provided freely by Versatile Security. With it you can set the smartcard’s PIN and AdminPIN, unblock the user’s passcode and manage certificates. In this particular case, I deleted the original cert and reissued it. And guess what: as good (fast) as new!

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.

A Microsoft Sharepoint Server can be very complicated, to say the least. Last week I had the task to establish Kerberos authentication throughout a very small Sharepoint environment, consisting just of a MS SQL 2008 Server and the Office Sharepoint Server itself. The installation was based on Microsoft’s best-practice recommendations, so every application pool and Windows service  had it’s own domain user.

Looking up all interesting data can take some time, especially if you did not setup these servers yourself. I stumbled upon a small tool that gathers useful data about Office Sharepoint and Sharepoint Services environments. It is called SPSFarmReport and is an open-source project at Codeplex.

The following “questions” will be answered by the tool: 

• How many servers exist in the farm?
• What services are run by each server in your farm? Which server is the Query/Indexer?
• Which server(s) host(s) the Central Administration web site in the farm?
• How many SSPs exist in the farm?
• Which is the default SSP in the farm?
• What is the URL of the administration site of an SSP?
• What is the URL of the My Site provider of an SSP?
• What Web applications are associated with each SSP?
• Which application pool is associated with each web application in the farm?
• Which account is used to run a specific application pool?
• How many content databases are associated with each web application and how many site collections does each have?
• What AAMs are configured for each web application?

You run it on one of the Sharepoint servers and it will gather all the data from there and create an HTML result file.

It really helped me to get an overview and locate all the accounts I had configure for Kerberos.

Get it here: http://www.codeplex.com/SPSFarmReport

Welcome to my little IT related blog.

As an consultant, I often face new technologies and problems, as the environment I work at changes with each customer I work for. Without all the blogs out there, work would be a lot harder. As a generalist, you cannot know everything about each product you get in touch with, thatis no secret. I really appreciate all the people that share their knowledge with others, so I want to return the favor. I will blog about everything I think is worth sharing. If you want to know more about me, read my “about” page or drop me a line.

Well then, have fun and maybe you find something useful.

Christoph