CheckAndLogOSInformation 0x87d00215

CheckAndLogOSInformation failed with 0x87d00215

CcmSetup failed with error code 0x87d00215

Running on ‘Microsoft Windows 7 Enterprise ‘ (6.1.7601). Service Pack (1.0). SuiteMask = 272. Product Type = 18

 

CcmSetup failed with error code 0x87d00215

 

 

0x87d00215 Is a WMI error and generally indicates WMI database corruption.  Very odd since this was during the imaging process and there really should have been no way for WMI to be corrupted, especially since Microsoft confirmed that they are simply making a call to “select * from Win32_OperatingSystem”

This in the end was one potential random symptom of a bad processor in the system.  See Core Gone Wild for full details.

 

To Reboot, or Not to Reboot, that is the question…

I have to thank a friend of mine for doing all the testing on this, but many times I’ve starred at the “Should Configuration Manager enforce specific behavior regardless of the application’s intended behavior?” options along with the Return Codes tab.

Reboot options on the “User Experience” for a Deployment Type

Return Codes and application intended behavior

Below is what happens when selecting the four different options in the drop down, assuming a 3010 return code from the application.

No specific action.
Software Center “Restart required” text: No
3010 causes reboot?  No
3010 System Center “Status” text: Installed

Whether or not the software is Required or Available, the computer is not forcibly restarted and no reboot prompts are displayed.

Determine behavior based on return codes:
Software Center “Restart required” text: Might be required
Application return code: 3010

If the installation is Required then following dialog is displayed.

If the software is Available then the computer is not forcibly rebooted and no countdown timer is displayed, only an optional reminder which the user can cancel.

Below is the text displayed in the Software Center when the application gives a return code of 0. 

 

The software install program might for a device restart:
Software Center “Restart required” text: Might be required
3010 causes reboot?  No
3010 System Center “Status” text: Installed

If the application installation does cause a reboot it is not logged as an error condition within the Software Center.

Whether or not the software is Required or Available, the computer is not forcibly restarted and no reboot prompts are displayed.  This setting is used to ensure that if the application installer itself (e.g. setup.exe) performs a reboot of the system, the SCCM agent is able to handle this scenario and doesn’t consider it to be failure.

Configuration Manager client will force a mandatory device restart:
Same behavior as Determine behavior based on return codes however it is not based on the return code of the application package.

Launch mode is not defined

If you’re smsts.log file ends with “Launch mode is not defined”, and you’re using a Prestart command / custom interface on your SCCM Task Sequence Boot image, the solution is simple:

DON’T REMOVE the DVD or USB boot disk PRIOR to seeing the “Installation Progress” Window/Progress bar!

Expression evaluation encountered a fatal error (0x80070002)

Main symptom was that App was not showing up in Software Center even though it was deployed.

This one showed up in a couple logs with different messages, so here they are so Google can index them:

AppDiscovery.log

Expression evaluation encountered a fatal error (0x80070002).
CLocalAppHandler::DiscoverApp failed (0x80070002).
Deployment type detection failed with error 0x80070002.
Failed to perform detection of app deployment type Install(Install, revision 2) for system. Error 0x80070002

AppIntentEval.log

Rejecting ScopeId_9d0608fa-33a2-4479-bb1b-078d045f7274/RequiredApplication_c9bc4f8b-958b-4243-a9f2-36fe91daee65/2 due to evaluation error

ScopeId_9d0608fa-33a2-4479-bb1b-078d045f7274/Application_c9bc4f8b-958b-4243-a9f2-36fe91daee65/2 :- Current State = Error, Applicability = Unknown, ResolvedState = None, ConfigureState = NotNeeded, Title = My Broken App

ScopeId_9d0608fa-33a2-4479-bb1b-078d045f7274/DeploymentType_5d322e96-cd06-40e4-9743-bc090cba35be/2 :- Current State = Error, Applicability = Unknown, ResolvedState = None, ConfigureState = NotNeeded, Title = Install

Solution

Not sure how it happened, maybe the SP1 upgrade or a scripting issue.  The app did not have detection rules, and therefore could not detect whether it needed to be installed.  Seems as though 0x80070002 in Windows land is typically some sort of file not found error, but looks like SCCM might be returning it as a generic “I couldn’t find something” error.

Core gone wild

What would you do if someone called you and said every time a computer finished imaging, it was missing a bunch of software?  Well, look at the logs of course, but after that is where things get interesting….

I had one computer in particular that was brought to me that was consistently throwing file errors, and the first thought was there had to be some download corruption.

But time and time again, everytime the image was loaded, errors would show up, not always on the same software, but at least a few various ones.  The hard drive was replaced first, but no improvement, then the RAM, and finally the motherboard.  No dice, issue still persisted.  The only thing left was to focus on the CPU.

After swapping the CPU from a known working computer, walla! No more errors!  And more importantly, the “bad” CPU reproduced the same random issues in the known computer.  Now, to get that CPU replaced…

Problem was, the PC OEM’s built in hardware diagnostics said everything was fine.  Even the Intel CPU diagnostics, came up clean.  In the process of installing all sorts of test utilities, I noticed a new pattern… There was no pattern.

Sometimes while simply double clicking a download to run an install, I’d get an extraction error, and then a minute later, it would run fine.  Intel’s own diagnostics tool is one example, here’s the error:

So how is this randomness possible?  When you run program, the Windows kernel will schedule the thread on an available logical processor, and considering this was a quad core computer, that means at random, it would be executing on one of the 4 cores.  To test the theory, I started setting the affinity to control which core it was running on.  Since processor affinity is inherited by child processes, I first open a command prompt and set  the affinity there, and started running my tests.

In classic suspenseful style, each core that I ran it on worked correctly, until the very last one was tested, and boom, error popped up.  I now had a %100 repeatable test, every time I had the affinity set to CPU 3, it would error out %100 of the time, any of the other CPU’s selected, and there was no error %100 of the time.

So why is a CPU issue manifesting as a file extract error?  Let’s look a little deeper at the files themselves.  Running Sysinternals Process Monitor, we see that the Setup.exe is extracting files to our Appdata temp folder, no surprises here:

But let’s grab a these files out of the temp folder before closing the error, and then do the same with the extracted files when there is no error.  Then using your favorite hex editor/comparison tool, look at the differences.

If you look closely, every where there is a difference between the good file and the bad file, the data is off by a value of 4.  From this point I can only speculate what is going on in the CPU.  It is decompressing a file, so maybe there’s a math error, or maybe a transistor somewhere that thought it gets set to 1 is still a 0, not sure.  That’s another job and another career for someone else to figure out….

What exactly is Win32_Keyboard.Layout ?

Anyone who’s ever done international OS deploys knows the fun of dealing with regional settings.  Recently, I wanted to improve some automation and inventory the keyboard layout to automatically re-deploy the same settings on hardware replacements.

The trouble with keyboards is who do you trust?  In reality, all keyboards are identical, they just have some different ink on the top.  There are a couple exceptions for Japanese and Korean keyboards though as they might have 106 or 109 keys.  Since all keyboards are generally the same, we have to tell the OS what the layout is since the keyboard itself does not provide any meaningful information describing itself to Windows.  It’s posible to tell Windows you have a standard US English keyboard, even though the print on the keys is French Canadian, and if you close you eyes and just type from muscle memory the letters will come out right.

So where is this info stored in Windows to let it know what keys map to which letters?  The answer as usual is multiple places!  There is the default keyboard for the currently logged in user (HKEY_CURRENT_USER\Keyboard Layout\Preload), the keyboard that will come up by default when you’re at the Ctrl+Alt+Del login screen (HKEY_USERS\.DEFAULT\Keyboard Layout\Preload), and lastly, the default keyboard(s) that a new user account will get when logging into the computer for the first time which is stored in C:\Users\Default\Ntuser.dat (Keyboard Layout\Preload).

All three of these can be easily viewed in the “Copy Settings” dialog box.

Now, most out of the box systems management solutions use WMI to collect inventory information.  There is a class name Win32_Keyboard which has a property named “Layout”, so many of you may already have this inventory information already available to you, but the question is, WHAT IS IT?  Microsoft’s fine documentation tells us it is a “Free-form string indicating the layout of the keyboard.”

https://msdn.microsoft.com/en-us/library/aa394166(v=vs.85).aspx

Well thank you Microsoft for the detail explanation, have your self some fun and change your own keyboard layout, and see what happens to this property, you might find that it doesn’t change.  Also, if you have multiple keyboards connected to the system, the value with be the same on all the keyboards no matter the physical layout or print on the keys. Through some testing and many many reboots, here is exactly what the Win32_Keyboard.Layout value represents:

In short, it is simply the default keyboard layout that will be used when logging in at the Welcome (Ctrl+Alt+Del) screen.  It is possible to have multiple keyboard layouts available at the Welcome screen, but the WMI value will be the default one which is stored under HKEY_USERS\.DEFAULT\Keyboard Layout\Preload\1

Whatever the data value is here, is what you will see in the WMI class.  UNLESS, it is a keyboard that has a substitute layout, for example, adding French Canadian has a Preload\1 value of 0C0C for French Canadian, but there is a Substitute of 1009 for English Canadian.  In this case, you will see 1009 as the value in WMI. (Sorry if I’ve offended any of my friends to the north with my lack of French Canadian history, I know there’s French legacy, US, French French, etc, but you get the point 🙂

These values are the InputLocale IDs, there’s a few different Microsoft sites like the one below that document the values, the MDT has a very nice xml file with values and names, and there’s many blogs about how to pull the display name from your very own registry if you like.

https://msdn.microsoft.com/en-us/goglobal/bb895996.aspx

If you manually change these registry values, they take effect immediately when you go to the login screen, but you need to reboot the computer before they will show up in WMI.

So is Win32_Keyboard.Layout good enough to use as an authoritative source on what type of physical keyboard a user has?  Maybe, for now it’ll be good enough for me, most end users in their right mind probably wouldn’t want to use Alt+Shift or switch the keyboard everytime they log into a computer, but it could happen.  Ideally it would be nice to have an array of all users that have profiles on the system with last logged on date, and the default + alternate layouts they have setup.  Then I would look at the data of the primary user of the machine and assume their default layout is what is actually attached to the computer.  At this point though, it’s just not worth the extra time to write a script for custom inventory.

The important thing is to understand your inventory data and what it means.  Be aware that the Layout value in WMI is what you get at the logon screen, and not necessarily what an end user uses day in and day out.

Create Task Sequence Media Error

Failed to connect to named pipe opened by AdminConsole of Configuration Manager, gle=5

Recently got this error message when trying to create Standalone Media.  My first reaction for media wizard errors is to close the Configuration Manager console, reopen and try again.  That didn’t work, and Google had nothing for me, so here I am posting what fixed it.

Simply a log off and log back on to my workstation.  I had changed my AD password a few days earlier, so perhaps that had something to do with it (gle=5) and 5 usually means Access Denied, but can’t be sure.

Definitely an easy fix, and it may not work for you, but hopefully this can save someone some time if you happen to be searching for this error message.

 

SCCM 2012 R2 Upgrade 0x87D00267

Hi everyone, Had some issues after upgrading from SCCM 2012 SP1 to SCCM 2012 R2.  In short, the symptom was our applications were not installing during the task sequence after the upgrade to R2.  We use an “Install Application” action in the task sequence with a dynamic variable list to install apps.

Reviewing the smsts.log file on a machine, we see a Policy Evaluation failed, hr=0x87D00267 message for every application in the list. Moving from the SMSTS.log to the DCMAgent.log, there’s nothing very interesting, so we look next to the CIAgent.log

 So we continue following the logs and look next to the CIAgent.log, then , CIDownloader.log, and finally DataTransferService.log where the event is logged for downloading the policy data from the server.

Here we see ErrorCodes 0x80190194 and 0x80070002 which if you do some internet searches there starts to me a lot more information and suggestions.

The general meaning of these is File or Document not found, so just to double check, I try the path in a web browser.

Normally doing the above in a browser will get you a bunch of encrypted xml data.  Having seen something similar in the past, I double check the “Allow this application to be installed from the Install Application task sequence action without being deployed”

In my case, it was already checked as expected, but to force a recompile of the application policy for task sequences, I made a  small change to any of the fields, such as the comments or description.  This essentially creates a new version of the application in SCCM which also causes the management points to create new policies for all computers that the application is targeted to, and the standalone policy file for task sequences.  After testing the task sequence again, boom, application installed.

The Big Fix

Since all the applications in the environment, roughly 3000, had this issue after the upgrade to SCCM R2, and automated fix had to be found.  I also didn’t want to change the description or comments on all the apps, so through some trial and error, I also found that simply assigning a category to an application also triggers a policy update.  The advantage here is that multiple applications can be selected in the SCCM console, and all assigned a category at one time.  This is probably good enough for most people, and the category can just as easily be removed the same way if desired at a later time.  However, this is still quite slow in the SCCM console if you have a large number of apps selected, and there’s a limit somewhere around 300 that can be done at once before console errors out.

Let’s automate it! 

Below is some VB.NET code to loop through every application instance on the server and add a category if it doesn’t already exist.  This leverages WMI through the Configuration Manager SDK libraries.  Could easily be done in VBscript, Powershell, or anything else that talks to WMI, but this is my current interface of choice.