By now, most folks know that there are some major changes between IIS 6 (included with Windows Server 2003) and IIS 7 (included in Windows Server 2008) and now IIS 7.5 (included in Windows Server 2008 R2). This of course directly relates to and affects BITS enabled distribution points in Configuration Manager 2007 and the underlying IIS configuration because BITS on the server side is essentially a function of IIS. Actual configuration of IIS 7 and 7.5 in preparation for BITS enabled DPs is covered in TechNet: http://technet.microsoft.com/en-us/library/cc431377.aspx.

Near the bottom of the above linked page is a section that generally tells you to loosen some of the security restrictions in IIS to accommodate BITS distribution of software. This is the result of the inclusion of most of the features of the IISLockdown security tool directly into IIS. These security features prevent IIS from responding to requests using malformed URL strings, which could lead to elevated access or running commands that should not be allowed, or serving restricted content like configuration files or database files. The requestFiltering section described in the article specifically deals with the later and is the usual suspect when BITS is having issues providing content to clients. The ConfigMgr team recently posted a great article on troubleshooting the BITS process:

http://blogs.technet.com/configmgrteam/archive/2010/01/14/troubleshooting-client-content-download-in-configuration-manager-2007.aspx.

I ran into both the bin folder being blocked and the double escape sequence being blocked as described in step 6 of the above linked article. At the time though, I had no idea what was actually causing the problem. My first step was to open the IIS log on the DP and look for any errors. In reviewing the log, I noticed that many of the files were being transferred successfully as indicated by a success code of 200. However, there were numerous files failing with a code of 404 – content not found in HTTP error code terms. The only commonality for the failures I found was that the URLs contained Program+Files – checking the source files reveled that there indeed was a Programs Files folder there – BITS adds the plus to encode the space. Not being an IIS expert I didn’t know exactly how to correct this issue even though I knew what the symptoms were.

I copied the URLs into IE on a client system and received similar results, a generic 404 for the files with Program Files in their path and a download attempt on the others. Just because (call it intuition), I did the same on the DP itself and the error page returned gave me the cause of the symptoms: double escaping is disabled. Although I had forgotten and got a little lucky, the thing to point out here is that IIS (by default) will return extended error information to the web client (IE in this case) if the request was local to the IIS system. Thus, if you are having issues downloading content using BITS, locate the URL in the IIS log and enter it into IE on the DP itself and IIS should tell you exactly what’s going on.

In my previous post (Client = No) I mentioned that the ConfigMgr Team had recently posted a good article on client registration but I couldn’t find it. MVP extraordinaire Torsten Meringer sent me the link yesterday.

http://blogs.technet.com/configurationmgr/archive/2010/01/20/how-it-works-automatic-client-approval-in-configuration-manager-2007.aspx

Good on ya Torsten!

At my current customer we are performing a clean, side-by-side upgrade from their current SMS 2003 infrastructure. We are using client push to install the ConfigMgr 2007 SP2 agent on all client systems. Pretty smooth for the most part with two exceptions.

The first issue has to do with automatic uninstallation of the SMS client during the installation of the ConfigMgr agent. On a handful of clients (about 5% of our initial 200 in the pilot group), we were getting the following message in ccmsetup.log and then the log would stop, services.exe would jump to 50%+ CPU time, and the client install would just hang there:

RemoveW2KDrivers. Removing Remote Control drivers ccmsetup

After some web searching and only a couple of hits and some manual inspection we determined that the permissions on the registry key holding the information for SMS Remote Tools mouse driver were somehow corrupt. The exact key is HKLM\System\CurrentControlSet\Enum\Root\*SMS_MOUSE and all of its subkeys (not values). We wrote a quick for loop in a batch script to use regini to connect to every client in SMS and reset the permissions. Given the very low number of hits I got while searching for this issue, I can only conclude that it was something very unique to this environment and perhaps one of the legacy images used to deploy systems.

The second pain point has been that another handful of clients (some of the same ones) would get fully installed, find the MP properly, get assigned to the site, registered, and even start downloading policies but would never actually flip from No to Yes in the console for having the client installed. Multiple collection updates and client Data Discovery cycles changed nothing. This was a real head-scratcher for a while until I ran across an entry in the ClientIDManagerStartup.log on the client:

Smsid is missing but (re)generation is disabled.

A quick web search revealed a couple of posts relating this message to the local SMS certificates on the client system. Given that these were being upgraded from SMS, it made (some) sense that the self-signed certificates created by the SMS Agent were expired, corrupt, or in some other way unusable. Using the Certificates snap-in I deleted the two SMS certificates (located in the SMS store of the local computer account) on one of the systems and then restarted the ConfigMgr agent. During agent startup I monitored the ClientIDManagerStartup.log to verify successful registration. Once that happened, I waited a minute (or two) for prosperity and updated a collection containing the resource and low and behold, the client was now properly showing in the console. I truly have no idea what the exact cause of this issue is/was either. Unfortunately, the actual client registration process is somewhat of a blackbox and very little documentation exists for it. I thought that the ConfigMgr team had recently posted an article with some more detail, but I can’t find it right now.

The next step is automating the certificate removal for systems experiencing the same which I haven’t quite figured out yet because certutil is not native to Windows XP (yes this customer is still stuck on XP, 3,000 systems worth) and as far as I can see certutil has no remote capabilities.

How to extend hardware inventory in Configuration Manager to add World Wide Names (WWN) from your HBAs: http://ross-family.org/blog/2010/01/06/extend-system-center-configuration-manager-2007-to-collect-fibre-channel-hba-information/

The nasty OSD App Tree bug has been squashed and version 2.5.1 is ready: http://myitforum.com/cs2/blogs/jsandys/pages/osdapptree.aspx.

It has been brought to my attention that a nasty bug slipped by my rigorous QA process that pretty mush kills OSD App Tree 2.5. I will be sorting this out post-haste and posting an update ASAP.

Announcing the latest version of OSD App Tree: version 2.5. This is a rebranding of OSD App Chooser with a greatly updated look and feel, tooltips, added customization and branding abilities, along with a relatively major new feature: application dependencies.

Get it here: http://myitforum.com/cs2/blogs/jsandys/pages/osdapptree.aspx.

Any and all feedback is welcome; the application dependencies and enhanced title area are the direct result of feature requests. Please use the contact form at the above link to let me know what you think and for any comments, feature suggestions, or support requests.

ConfigMgr SP2 is now available (and has been since Oct 22). Time to address the two commonly recurring questions I have seen in the forums and mailing lists?

When will the full integrated installation media be available?

This refers to a full install of ConfigMgr integrated with SP2 so that you do not have to first install ConfigMgr SP1 and then immediately upgrade to SP2.

The answer from reliable sources is that it is expected by the end of December. There is no promise or guarantee, so don’t stake your business plan on it, but there is no reason not to believe this timeframe for release.

Without the integrated media, how do I install a primary site server on Windows Server 2008 R2?

First, yes this is a supported configuration per http://technet.microsoft.com/en-us/library/ee344146.aspx.

There are two options for this currently:

• Install ConfigMgr SP1 and then install SP2 immediately following the install. I tested this in the lab and had no issues and have seen and heard of others also doing this successfully.
• Install ConfigMgr SP2 evaluation and then when you get the final licensed media, do an in place upgrade.

Both of the these have their cons, although slight. My first full production install of ConfigMgr post SP2 just started and we are going to opt for the first option above. I don’t like option two because if for some reason they don’t release the media as planned, the customer is out of luck and I recommended something based on verbal information – not a good situation for a consultant to be in.

Holy cow batman! The title says it all and is the conclusion of one Mark Russinovich – Windows Guru Guru Extraordinaire.

Check out his blog post: The Machine SID Duplication Myth.

There are numerous tools provided by Microsoft to deploy Windows; however, I see a lot of confusion and questions about which of these tools to use, when to use it, and what the roles of each of them are.

WAIK

Windows Automated Installation Toolkit

This is the baseline set of tools provided by Microsoft to perform the atomic operations involved with deploying Windows: things like creating and modifying a Windows image, creating and updating a Windows PE boot image, and creating answer files. There are three main incarnations of the WAIK:

• 1.0 Initial release for supporting Vista deployment
• 1.1 Updated to support Vista SP1 and Server 2008 (SP1) – note that the RTM release of Server 2008 was already at the SP1 level
• 2.0 Updated to support Windows 7 and 2008 R2

The WAIK is suitable for deployments where a high level of automation is not desired without significant effort on the part of the implementer.

MDT

Microsoft Deployment Toolkit

MDT is stand-alone, end-to-end solution for deploying Windows in a fully automated, repeatable fashion. MDT builds on and uses the WAIK by adding best practices, scripts, tools, and a deployment methodology that significantly simplifies Windows deployment and brings it to a new level.

MDT is a free solution from Microsoft. MDT 2010 is the latest version of the toolkit which has been around for a number of years and was formerly called the Business Desktop Deployment (BDD) toolkit:

• BDD 2.0
• BDD 2.5
• BDD 2007 Added support for Vista and Server 2003 deployments
• MDT 2008 Initial release of re-branded toolkit, added support for Vista SP1 and Server 2008
• MDT 2008 Update 1
• MDT 2010 Support for Windows 7 and Server 2008 R2, USMT 4.0, and PowerShell automation added.

(There were a lot of versions of the BDD and I don’t remember what each added or what they all were; for purposes of this post, the above is sufficient though.)

The MDT is suitable for any Windows deployments where any level of automation is desired without a significant investment in custom scripting. It also comes at a great price: free.

OSD

Operating System Deployment

OSD is a component of System Center Configuration Manager (ConfigMgr) -- not SCCM. OSD is also an end-to-end solution for deploying Windows in a fully automated, repeatable fashion. OSD also builds on the WAIK the same way that MDT does. The advantage that OSD has over MDT is that OSD can leverage the other capabilities of ConfigMgr including Software Distribution and Software Updates to create a single utility to manage systems from cradle to grave. There are also multiple versions of OSD, these are synonymous with the ConfigMgr versions though and cannot be separated:

• ConfigMgr 2007 RTM Initial Release
• ConfigMgr 2007 SP1 Added support for Vista SP1 and 2008 SP1
• ConfigMgr 2007 SP2 Added support for Windows 7 and 2008 R2 – note that this service pack has not yet been release

OSD is suitable for any Windows deployments where any level of automation is desired without a significant investment in custom scripting in combination with the great features of ConfigMgr.

Note that the MDT also operates in a second mode traditionally called Zero-touch Installation (ZTI) where it integrates into ConfigMgr providing a few additional features/enablers that can solve some additional common challenges.

Alphabet Soup No More

So which one is right for you? In all but the simplest, image only deployments, no one should consider using just the WAIK. That leaves the choice between MDT and OSD. The choice between OSD and MDT has to do with the deployment, maintenance, and cost of ConfigMgr. ConfigMgr is a great product (yes I’m biased, bias based on experience and not whim though), that solves a lot of challenges but not everyone is prepared to pay for and maintain it. Thus, organizations without ConfigMgr can still take advantage of MDT and organizations that already have or are willing to step up to the greatness that is ConfigMgr can use OSD!

Announcing my latest venture into coding and improving the experience of Operating System Deployment: OSD++.

OSD++ is a better way to get input from the user and populate task sequences variables. It retrieves values from the registry, queries WMI, and/or prompts the user for input via an input box or a drop-down box. All values retrieved are stored in internal OSD++ variables that can be used as replacement variables in further data retrieval. They can also be written out to the registry or used to set task sequence variables.

OSD++ variables can also be persisted in a file that can be loaded by OSD++. This is useful during refresh scenarios to display the interface to the user before the task sequence begins, save their responses to the variable file, and then using another run of OSD++, output the saved responses to task sequence variables.

Get it here (updated 9/13/09): http://myitforum.com/cs2/blogs/jsandys/pages/osdplusplus.aspx

My second blogcast on Operating System Deployment (OSD) in Configuration Manager (ConfigMgr) is now available: http://myitforum.com/cs2/blogs/jsandys/pages/osd-blogcast-series.aspx.

I run across a lot of questions in the forums and from customers about why their batch files are failing when run using a ConfigMgr program. There is an easy answer to this (usually): the command shell, which executes batch files, cannot change its current directory to a UNC path. Although that’s a straight forward statement, I thought I’d create some demo programs to show the ramifications of this in action and to compare against an executable and a VBScript.

For each type, there are two possibilities, running from the DP – which is when a UNC is used – or running from the cache which is typically referred to as a download and execute. The choice between these two possibilities is set on the advertisement and not the program.

exe

For the exe, I wrote a small application that called the Win32 APIs GetCurrentUser and GetCurrentDirectory.

Run from DP

Run from Cache

VBScript

For the VBScript, I used the UserName and UserDomain of the WScript.Network object and the CurrentDirectory property of the WScript.Shell object.

Set WshNetwork = WScript.CreateObject("WScript.Network")
Set WshShell = WScript.CreateObject("WScript.Shell")

info = WshNetwork.UserDomain & "\" & WshNetwork.UserName & vbCrLf & WshShell.CurrentDirectory

WScript.Echo info

Run from DP

Run from Cache

batch

For the batch file, I output to a local file the USERNAME and USERDOMAIN environment variables as well as the “cd” command which if used by itself echoes the current directory.

echo %USERDOMAIN% > "c:\context.txt"
echo %USERNAME% >> "c:\context.txt"
cd >> "c:\context.txt"

As you can see below, the current directory for the batch file when run from the DP is C:\Windows. Thus, if your batch file tries to call anything from the package using a relative path, it will fail.

Note that is XP/2003, the USERNAME and USERDOMAIN environment variables are blank for the SYSTEM account, thus the first two lines of the just say “ECHO is on.”

Run from DP

Run from Cache

batch2

This batch file calls the exe using the %~dp0 batch parameter: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/percent.mspx?mfr=true. This parameter returns the directory that the batch file was run from (including a trailing backslash).

%~dp0context.exe

The use of this parameter is pretty well documented within SMS\ConfigMgr circles – although it is not specific to SMS/ConfigMgr in any way – it is one possible solution to the batch file problem. Another is to set the program to use a drive letter instead of a UNC in the ConfigMgr program properties. This works; however, if you try to use a download and execute advertisement for the program, you will get an error because these two settings – run with drive letter and download and execute – are not compatible. %~dp0 works either way though, so is usually the best solution.

Another thing to point out is that the child process inherits the current directory from the parent process, in this case, the child is the exe and the parent is the command shell. This isn’t a big deal in the run from cache scenario, but note the current directory in the run from DP scenario for the exe.

Also notice the warning at the top of the command prompt in the Run from DP scenario. It more or less sums up what I said in the opening paragraph of this post.

Run from DP

Run from Cache

The main thing to keep in mind when using ConfigMgr programs, is that ConfigMgr is not doing anything “magic”. It is simply running the command-line you tell it to run. Things don’t work the way you think they should sometimes because you’ve made some false assumptions, not because ConfigMgr is broken.

My inaugural blogcast on Operating System Deployment (OSD) in Configuration Manager (ConfigMgr) is now available: http://myitforum.com/cs2/blogs/jsandys/pages/osd-blogcast-series.aspx. More to follow soon.

I visit a lot of clients and work work with a lot of different admins and one the recurring themes for many of these admins is having multiple – three plus usually – RDP sessions open at one time. There’s nothing wrong with this in and of itself, the problem comes when trying to find the correct window on the task bar. I often sit back patiently waiting for the person to click through all of their open sessions until they find the right one – OK, I’m not always that patient :-) More time usually gets wasted cycling through all of the open sessions than actually working in them.

Another issue that working with multiple RDP sessions brings up is screen real-estate. If you maximize the RDP session to get the biggest session to work on, you lose access to the start menu and task bar. Now if you need to switch to Outlook or IE or launch another app then you have to resize the full-screen RDP session. Also, it’s easy to forget that you’re in an RDP session and accidentally shutdown or restart the production server that you’re working on – admit it, we’ve all done it at least once.

The answer to the above is to get a second monitor (which doesn’t address the first problem above) or to not maximize your RDP sessions. The problem with not maximizing your RDP sessions is that the special key combos – like Windows+E – which I use constantly, are not passed on to the remote system.

There are other issues too, but I’ll cut the discussion short on those because you should be on board with me by now :-)

Enter a handful of multi-session RDP clients. Microsoft included an MMC based one in Windows 2000, but it was less than elegant and really didn’t improve on much. The third-party batch include an open-source one, Terminals, which works pretty well. It has it’s annoyances but does address all of the above problems (and more). It is tabbed based, stores credentials securely, organizes and tags connection settings, and is free.

My current choice however is VisionApp Remote Desktop 2009 or vRD for short. vRD is a commercial app but a free version is available – the only significant limitation is the ability to only open three remote sessions at a time. vRD does everything Terminals does but is cleaner and just seems to work better. It has a few “upscale” features also like storing credentials (securely of course) separate from the connections so that they can be shared and the navigation pane collapses when you start a new session among other things. A new version is on the horizon also.

There are at least one or two others is the game also, although the ones that I know are not free in any way – one used to be but has been converted to a shareware package.

As an enabler for any admin, using either Terminals or (stepping up to) vRD is a great move that I encourage everyone to take advantage of.

What’s the difference? Why two types? When should I use each?

These are frequent queries I get from customers and are also often echoed in the forums.

OS Install Packages are packages built using the actual source files from the OS media. For Windows XP/2003, this includes all of the individual files (in a compressed form) installed to a system during setup and the actual setup program. For Vista/7/2008, this includes an install.wim file that contains a generic “image” of the OS and the setup files used to deploy and configure this “image”. Note that WIM files are essentially just compressed archive files using the Microsoft CAB format; they contain the files that make up the OS and thus the Vista/7/2008 setup mainly just un-compresses the WIM onto the destination hard drive.

OS Images are WIM files without any other associated setup files. These are captured from a reference system that has been generalized using sysprep. The reference system is one where the OS has already been installed and possibly configured with software, updates, tweaks, and other configurations. This is all captured into the WIM file which can then be deployed to other systems making the two systems identical (minus any hardware difference of course).

Both of the above are stored in ConfigMgr packages. Package is a very ambiguous term though. For ConfigMgr, a package is a collection of source files contained in a specified folder and its subfolders; a package has no inherent functionality. Thus an “OS Install Package” has lots of files and an “OS Image” package has just one, a WIM.

OS Install Packages are used to deploy an OS from scratch using the OS setup program. In XP/2003 this means going through the “Blue Screen” setup. In Vista/7/2008 it means going through the PE based install.

OS Images are used to deploy a pre-configured OS built on a reference system (including any updates, software, tweaks, etc.). The advantage of using an OS Image is speed and the fact that it ensures that each system deployed is identical in configuration. Installing the OS and updates takes a long time typically as do some software packages. Capturing these in a single compressed file, like a WIM, eliminates the need to actually install any of these. An old Unix saying is that everything is a file. For Windows, not everything is represented as a file (as in Unix), but Windows is merely a collection of files – even the registry is just a set of files. Thus, deploying an OS contained in a WIM simply means extracting all of the files that the WIM contains onto the target system: full setup not needed.

OS Install Packages are directly used by Build & Capture Task Sequences to automatically create an image of a reference system captured in a WIM file. It is possible to use an OS Install Package to deploy systems; however, this is not commonly done -- the trade-off is time as discussed above.

OS Images are used by Deployment Task Sequences to deploy an OS to target systems.

A common follow-on question is why not use the install.wim from the Vista/7/2008 media directly without creating a reference image first? The answer is because its not recommended: the install.wim for these OSes was built using the D drive as the OS root drive. The setup program goes through great pains to fix this after the install.wim is deployed. If you simply import the install.wim and use it in a deployment task sequence, you will have undefined results.

Thus, you should always build a WIM from reference system no matter what OS you are deploying. The preferred method is to use a build and capture task sequence, but manually building and capturing a reference system is “acceptable” although highly discouraged in my opinion.

A practice previously used by many when updating their images is to deploy an existing image, make changes, and then recapture the image. This is generally considered bad form for many reasons, but was technically acceptable. This is no longer the case in Vista/7/2008. A single installation of Windows is only allowed to be syspreped three times with these newer versions of Windows because of activation: http://support.microsoft.com/kb/929828. The best practice is always to create your images from a cleanly installed reference system; this is exactly what a Build & Capture Task Sequence does for you.

I often make use of what I call “Roll-up Collections” in ConfigMgr. These are parent collections that contain sub-collections that specialize the intended membership of the parent collection. An example parent collection might be Texas with sub-collections for San Antonio, Austin, Dallas, Houston, Corpus Christi, etc. The parent collection’s membership, Texas in this case, is determined by the membership of the sub-collections; i.e., everything in the sub-collections should also be in the parent collection.

This is different than a trickle down collection where each sub-collection is limited to the membership of its parent collection and uses a query to “filter” the membership of that parent collection. The end result is similar however.

So when would you use a roll-up collection: typically if you populate the sub-collections using direct membership rules or there are more than a few sub-collections where combining the rules for use in the parent collection is non-trivial.

The following query, when added as a Query Rule to the parent collection, will accomplish the feat of a roll-up collection (where XYZ00123 is the Collection ID of the parent collection):

I was at a customer this week doing a one-day, whirlwind tour of Operating System Deployment (OSD) in ConfigMgr. They were specifically interested in server deployment so we set up a build and capture task sequence for Server 2003 SP2. Everything went well until the Prepare OS task which runs sysprep. It just wouldn’t finish; the scrollbars moved forward, then back, then forward, etc. I left at the end of the day and it was still running after 90 minutes. I couldn’t find any references on the web for a sysprep hang though.

It turns out that when I created the sysprep package, I removed the documentation files (The two chms, one doc, and readme.txt) – at least thats what I though I did. Repopulating the sysprep files with the entire contents of the deploy.cab file and re-running the B&C TS worked like a charm. Really weird.

Incidentally, did you know that each version and service pack level of Windows has its own specific version of sysprep? Vista/7 and 2008/R2 make this easier because they include sysprep as part of their base install; however, slipstreaming a service pack into either XP or Server 2003 does not update the deploy.cab and thus sysprep does not get updated.

You can download the deploy.cab for each version and service pack level from Microsoft by using your favorite decision engine and searching for “Windows XP SPx Deployment Tools” or “Windows Server 2003 SPx Deployment Tools”. An odd thing about the Server 2003 SP2 deployment tools download is that it is distributed as a patch and not a self-extracting executable. The easy way to get to the deploy.cab is to run the patch with the /extract switch which will prompt you for a location where it will dump the files from which you can pluck the deploy.cab file.

Hmmm. I received the following feedback anonymously about OSDAppChooser:

I just wanted to drop in a few suggestions for future enhancements to the OSD AppChooser in case you ever get the chance to tweak it. It'd be nice if there was some way to adjust the size of the application window. Also, it'd be nice if the line of text that reads "Please Choose an Application Set" could contain a lot more characters. And maybe if you could make the Help icon live and we could have a separate file that we could customize for support issues (for the not-so-bright techs). And lastly, is there any way to have it display for X minutes, and if there is no interaction, to close and continue on? For those times when techs start an install and then walk off, forgetting to wait around to select the desired applications. Just some suggestions!

First, I’d like to say I welcome feedback and am happy to add features to OSDAppChooser. I just wish this person would have given me a way to respond to directly to them so that I can either point out things they may not know or figure out exactly what they want.

Anyway, if that anonymous person is out there and reading this, here’s my response, please follow up with me so I can modify OSDAppChooser appropriately.

Feedback: It'd be nice if there was some way to adjust the size of the application window.

Response: The window is fully resizable; just grab a corner and drag.

Feedback: Also, it'd be nice if the line of text that reads "Please Choose an Application Set" could contain a lot more characters.

Response: Valid, but there’s only so much real estate to work with. Would a tool tip work better?

Feedback: And maybe if you could make the Help icon live and we could have a separate file that we could customize for support issues

Response: Would a tooltip here also help? Maybe combine the last two items into a single tooltip?

Feedback: is there any way to have it display for X minutes

Response: I initially planned for this (and actually included it in version 1 which was based on AutoIT), but determined it was redundant because if you are using a run command line task in a task sequence, it already has the ability to set a time limit.

I have a couple of other small ideas for improving OSDAppChooser and will hopefully release a new rev soon. If anyone has anything else they’d like to see, please let me know.

Press release.

I am by no means abandoning myITForum because we all know that myITForum rocks!

System Center Central is another destination with unique resources, information, and personalities. One of the main things I espouse to all of my current and potential customers is the strength of the community that supports Microsoft products in general and the System Center products specifically. System Center Central is just adding to this ecosystem and model that is only a dream for Microsoft’s competitors. The more the merrier IMO.

ConfigMgr FTW!

Working with a customer recently, they had an issue using SAN attached disks during Operating System Deployment. They could successfully create and format the SAN attached disk as the D drive during the WinPE portion of the task sequence, but the disk would go offline during the Windows 2008 mini-setup. This was causing a major issue because they were directing the install of the ConfigMgr client to the D drive. This step was obviously failing because the disk was offline. Also, because there are no steps between the mini-setup and installation of the agent, there is no way to inject a diskpart script or any other command.

After working with CSS a little, the customer discovered a setting in the unattend.xml that could be adjusted to force Windows to bring all SAN attached storage online: SANPolicyType.One additional issue they ran into is that the WAIK documentation states that the default value for this policy is to “mount all available storage devices” – they weren’t seeing this behavior in practice though. If you reference the MSDN documentation on the underlying Windows configuration setting that is controlled by this setting in the unattend.xml though, the default setting for Windows 2008 Datacenter and Enterprise is actually to “mount all storage devices except those on a shared bus”. Once they figured this out and added the setting to their unattend.xml, everything clicked into place.

(All credit for the above info goes to Chris P at the anonymous customer.)

It is pretty well known how to add custom extensions to the Configuration  Manager hardware inventory using sms_def.mof and configuration.mof. What isn’t well-known or documented (at least not that I could find), was how to check-up on or remove a custom extension from ConfigMgr manually. There are two tools that can help you with deleting the extension: delgrp.exe (available from the SMS 2003 resource kit) and SiteSweeper from SCCMExperts. But what do you do if these tools aren’t working for you or you simply want to check up on your extension?

First, it is important to note that a best practice for custom inventory extensions is to always test them on a test ConfigMgr site; however, most folks don’t have test installations of ConfigMgr and even if they do, the data isn’t necessarily representative of the data in their production site.

The following is of course completely unsupported – by Microsoft or me – so tinker with the DB at your own risk (or peril). Make sure that you have a good DB backup as a simple restore should get you back to where you were if you foobar something.

The following database objects are involved with HW extensions (where Extension_GroupID is the name of the group as specified in sms_def.mof by the SMS_GROUP_NAME qualifier).

Tables:

• InventoryClass – Lists extension classes
• InventoryClassProperty – Lists properties of extension classes, references rows in the InventoryClass by InventoryClass.ClassID
• DataItem – References rows in the InventoryClass by InventoryClass.ClassID
• DataItemProperty – References rows in the InventoryClass by InventoryClass.ClassID and rows in InventoryClassProperty by InventoryClassProperty.PropertyID
• GroupMap – Maps the class ID to the tables in the database
• Extension_GroupID_DATA – Contains data for the extension
• Extension_GroupID_HIST – Contains history data for the extension

Views:

• v_GS_Extension_GroupID0 – View used for actual data retrieval/reporting
• v_HS_Extension_GroupID0 – View used for historical data retrieval/reporting
• vex_GS_Extension_GroupID0 – ?

Stored Procedures:

• pExtension_GroupID_DATA
• dExtension_GroupID_DATA

The WMI repository on the site server also contains information about HW extensions in the root\SMS\Site_XYZ namespace (where XYZ is the site code). The following classes will exist:

• SMS_G_SYSTEM_Extension_GroupID
• SMS_GH_SYTEM_Extension_GroupID
• SMS GEH_SYSTEM_Extension_GroupID

Removing the rows referencing the extension from the first five tables listed above, deleting the other DB objects, and deleting the WMI classes listed, should remove a hw extension from ConfigMgr. Note that deleting WMI classes also deletes all instances of the class. You can also simply monitor the tables if you just want to verify the data or creation of the proper objects. It is of course possible and likely that the above list is not all inclusive, but in my (limited) testing, this is what turned up.

Today, I was honored with the Microsoft Most Valuable Professional award for System Center Configuration Manager. I am humbled, excited, encouraged, enthusiastic, and truly honored. A big thank you to anyone and everyone who has supported me over the past years and enabled me to achieve this level of recognition from the company whose products my career revolves around.

Anyone who’s dealt with ConfigMgr knows that the log files are invaluable for troubleshooting issues and day-to-day monitoring. One of ConfigMgr’s strengths (IMO) is that nearly everything, in detail, is in a log file – somewhere.

The “problem” that often crops up is knowing which log file to look in; although the main purpose of each log file is documented on TechNet, it’s often difficult to narrow down exactly which log file to dig through. Log files also roll (by default) every 2MB: for some log files this is a lot, for others, like ccm.log, this might only last a couple of hours especially during a large client push.

Wouldn’t it be nice to have a single, searchable repository for all of your log files?

Enter Splunk. Splunk is a free tool (up to 500MB a day of logs) that will suck in and index all of the specified log files on a system. It does more than just text log files, but for ConfigMgr, that’s all we’re really concerned with. Splunk then provides a web based search page for all of the indexed data so we can search for all occurrences of a string. Splunk also creates fields based on name=value pairs, has an event definition mechanism, and provides data tagging.

Splunk allows you to forward the data from one system to another. The obvious application here is to forward all of the collected logs from all of the  site servers to a central Splunk server, perhaps your primary site server. You could forward everything from secondary site servers and child site servers also giving you a single, central, searchable repository for all of your logs from all of your sites.

There is an Enterprise version of Splunk that costs money, so it may be worth looking into if you have a large installation or require some extra security, but I think the standard free version would suffice for most installations.

I’m not a Splunk expert, but I see a lot value in using Splunk for ConfigMgr logs.

The following is a list of significant post SP1 updates for ConfigMgr. Most of these updates are by request only; all you have to click the link at the top of the KB and complete the quick request.

Operating system deployment fails in a System Center Configuration Manager 2007 SP1 environment if you deploy a different operating system to a client within one hour of a previous deployment
http://support.microsoft.com/kb/969113

Recurring advertisements or maintenance windows start to run an hour later or earlier than expected when the time is changed because of DST in System Center Configuration Manager 2007
http://support.microsoft.com/kb/956259

You receive an error message when you click and then update the Drivers node in the Configuration Manager console of a Configuration Manager 2007 Service Pack 1 site that uses SQL Server 2008 for the site database
http://support.microsoft.com/kb/955262

Error message when you try to import OSD drivers in System Center Configuration Manager 2007 Service Pack 1 systems: "The selected driver is not applicable to any supported platforms"
http://support.microsoft.com/kb/961105

A task sequence that contains many packages may take longer to run after you install System Center Configuration Manager 2007 Service Pack 1 or hotfix 949225
http://support.microsoft.com/kb/955955

When you use System Center Configuration Manager 2007 Service Pack 1 to capture an image of Windows Vista SP2 or of Windows Server 2008 SP2, the image capture process fails during the "Prepare Windows for Capture" stage:
http://support.microsoft.com/kb/970093

Hardware Inventory isn’t a huge topic, but there are a lot of details – far more than I could cover in a single post. The intent of this post is to cover a significant change from SMS 2003 to ConfigMgr 2007: the separation of reporting classes and data classes into two files.

The first thing I usually tell folks is that hardware inventory isn’t really hardware inventory, it’s inventory from the WMI repository. WMI is most often associated with hardware and most of the default information stored in WMI is hardware related, but not all of it. This is of course significant when you look at the Resource Explorer and see Add/Remove Programs under it or when you want to extend inventory in Config to collect registry values and are told that it is handled by the hardware inventory process. Definitely a potential cause for confusion also.

Also, ConfigMgr does not pull everything available from WMI, it pulls a selected subset as defined in the sms_def.mof file (located in <Installation Dir>\inboxes\clifiles.src\hinv). SMS_DEF.mof is a plain text file that you can edit with notepad or any text editor. It is in a special format called Managed Object Format (MOF); MOF files are part of the WBEM/CIM standard and not Microsoft proprietary. The MOF file format is fully documented on MSDN: http://msdn.microsoft.com/en-us/library/aa823192%28VS.85%29.aspx.

Unless you are extending a MOF file, you don’t need to be intimately familiar with the format details. The main thing to know is that MOF files define classes of information, similar to classes in object-oriented programming. Each class can have properties and methods, although for data collection we don’t really care about methods.

This bring us to our two files: SMS_DEF.mof and Configuration.mof.

SMS_DEF.mof defines “reporting” classes. These classes exist (or are created by ConfigMgr) in the WMI namespace root\CIMV2\SMS and specify where the actual data we are interested in is stored. It does this by creating classes in this namespace that are (nearly) identical in definition to the class that holds or provides the real data; a.k.a., the data classes. Here’s an example snippet of a reporting class from SMS_DEF.mof:

[ SMS_Report     (TRUE),
  SMS_Group_Name ("Computer System"),
  SMS_Class_ID   ("MICROSOFT|COMPUTER_SYSTEM|1.0") ]

class Win32_ComputerSystem : SMS_Class_Template
{
    [SMS_Report (FALSE)     ]
        uint16     AdminPasswordStatus;
    [SMS_Report (FALSE)     ]
        boolean    AutomaticResetBootOption;
    [SMS_Report (FALSE)     ]
        boolean    AutomaticResetCapability;
    [SMS_Report (FALSE)     ]
        uint16     BootOptionOnLimit;
    [SMS_Report (FALSE)     ]
        uint16     BootOptionOnWatchDog;
    [SMS_Report (FALSE)     ]
        boolean    BootROMSupported;
    [SMS_Report (FALSE)     ]
        string     BootupState;
    [SMS_Report (FALSE)     ]
        string     Caption;
    [SMS_Report (FALSE)     ]
        uint16     ChassisBootupState;
    [SMS_Report (TRUE)      ]
        sint16     CurrentTimeZone;

ConfigMgr matches up the names of the reporting classes to the names of data classes and then sucks out the data from the data classes. The above snippet instructs ConfigMgr to pull data from the Win32_ComputerSystem data class. The boolean value of a special qualifier, SMS_REPORT, on a reporting class and its properties tells ConfigMgr which classes and properties to actually inventory. SMS_DEF.mof by default, defines a large number of reporting classes and their properties that ConfigMgr takes no action on. If you decide that you want that information, just flip the SMS_REPORT qualifier from FALSE to TRUE. That change will go out during the next policy interval and the clients will report the info during their next hardware inventory cycle.

The SMS_DEF.mof file is converted into policies by the site and distributed to clients as part of the policy distribution process. The SMS_DEF.mof file is not distributed to clients in its raw form. Also note that no data is normally stored using the reporting classes. These classes are simply “road-signs” telling ConfigMgr which data classes to pull data from.

Configuration.mof is new to ConfigMgr and splits out the definition of data classes from the reporting classes.  Data classes are usually located in root\CIMV2. Most data classes used by ConfigMgr by default already exist in the repository because they are just default Windows WMI classes. Thus, there is no definition for the majority of data classes in Configuration.mof – they already exist. It is also worth noting that “data class” is a ConfigMgr only term that refers to the WMI classes that ConfigMgr pulls data from. There’s nothing inherently special or particular to ConfigMgr about these classes; they are normal WMI classes available to anyone or thing that queries WMI.

In contrast to SMS_DEF.mof, the Configuration.mof is delivered in its entirety, embedded in the policy, to each client . The Configuration.mof file is then automatically compiled and added to the WMI repository using mofcomp.exe. Although Configuration.mof file is specific to ConfigMgr, as I said above, the classes it creates are not special in any way nor is the process used to create them – this is all just standard WMI configuration.

Data can be statically populated in the data classes or populated using a dynamic process – similar to object-oriented programming or database design, the classes themselves do not actually store data, rather instances of the classes store the data. The classes just define how to store the data and what it looks like. There are many dynamic methods to populate data including WMI providers, like the registry provider, or VBScripts. All of the default WMI classes (and presumably those provided by other applications) populate their own classes automatically through their own processes.

One of the takeaways from this is that if you want to extend the hardware inventory in ConfigMgr you must add a reporting class and a data class. The reporting class is always defined in SMS_DEF.mof and, to reiterate, tells ConfigMgr where the data lives that it should retrieve. The data class on the other hand, can either be defined in Configuration.mof or through any WMI extension process. Why the difference? Because remember that data classes are not in any specific to ConfigMgr, they are just WMI classes so you can create these any way that you like – ConfigMgr just sucks the data out of them as defined by the SMS_DEF.mof file.

In addition to defining the data class (either via Configuration.mof or some other process) you must also populate these classes with data – this can be done on the fly with a dynamic provider like the registry provide, a VBScript, a custom WMI provider, or any other way you want to write data into WMI.

To sum up quickly, SMS_DEF.mof defines where to collect data from in WMI via the use of reporting classes and Configuration.mof defines how the actual data is stored in WMI using data classes.

  Well, I’m not sure what to make of Twitter, but I’ve finally jumped on the bandwagon anyway. You can follow me by clicking on the link in the news section or here. 

What I intend to do is tweet one or two links every weekday about technology that I think others would also either enjoy or find interesting or informative. I promise not to bore anyone with personal activities like taking my daughters to ballet or going to church.

With that said, let the tweeting commence.

If you try the technique below on an install of Windows Server 2003 with Service Pack 2 (sp2), it fails. I don’t remember the exact error, but it translates to the wrong required sp level. It’s simple fix though as detailed here: http://blog.stealthpuppy.com/windows/windows-2003-r2-and-integrated-service-pack-2.

I just stumbled on this today; i.e., I can’t take credit for all of it (http://develnet.blogspot.com/2008_09_01_archive.html).

It is a great way to restart a task sequence from within Windows PE preventing the lengthy hardware reboots particularly on servers. Simply kill TsmBootstrap.exe and start a new instance of TsBootShell.exe. You can kill TsmBootstrap.exe by starting the command prompt and then starting task manager by typing “taskmgr” (unfortunately, taskkill is not available by default in PE). You can then launch a new instance of TsBootShell.exe from the command prompt or the run line of task manager – do not kill the existing instance of TsBootShell as this is the main shell used by PE during OSD and killing it will cause all other processes to be closed and the system to reboot.

This mainly works if you forgot to advertise the TS properly or the TS never really kicks off properly but you are still in PE. If the TS bombed part way through, it leaves files behind that prevent a new TS from properly starting. The one time I had a chance to test this on a failure half-way through the process, it gave an error about not being able to properly read the TS environment (or something like that). In hindsight, we should have formatted the C drive from the command-prompt and tried again, but it was late on Friday we we weren’t thinking straight anymore.

The entire scenario is difficult to test as a whole, so your mileage may vary but what do you have to lose if the TS bombed anyway.

Just thought I’d document the steps taken at a recent customer engagement for deploying Windows Server 2003 with the R2 bits in the image.

1. Copy the entire R2 CD to your package source repository.

2. Create a standard software distribution package for the R2 source directory.

3. Create a program with the following command-line:

CMPNENTS\R2\setup2.exe /q /a /sr

The command line options are documented at http://technet.microsoft.com/en-us/library/cc756937(WS.10).aspx.

4. In your build and capture task sequence, create an Install Software task for this new program at the beginning of your other software install tasks. Make sure you add a reboot somewhere after this task and before the capture.

5. To suppress the “Windows Server Post-Setup Security Updates” window, add a command line task near the end of the deployment TS with the following command:

reg add “HKLM\SOFTWARE\Microsoft\Windows\Current Version\ServerOOBE\SecurityOOBE” /v DontLaunchSecurityOOBE /t REG_DWORD /d 1 /f

This registry key is documented at http://technet.microsoft.com/en-us/library/cc757061(WS.10).aspx.

That’s it.