PXE deployment stopped work and you get the "No MP Certificates" in the SMSTS.log

During a routine task of moving the ConfMgr database at a customer one of my colleagues used the normal guidelines (How to Move the Site Database - http://technet.microsoft.com/en-us/library/bb680707.aspx).
Everything looked like it successed without any errors. The Site status was all green and the sms provider had no problems accessing the ConfMgr database, but sometime after the customer began to experience problems with the site not allow for PXE and Software advertisements.
As part of the task of moving the databse the SMS installation will automatically kickstart the "Perform site maintenance or reset this site" which changes the installation by running a Microsoft Installer "Change Installation" task that uses the Configuration Manager install role MSI packages to reconfigure the installation. One of these is the MP.msi which installs the ConfMgr Management Point. Sometime this fails on Windows 2008 servers due BITS not being configuration correctly.
The reconfiguration actually brakes the Management Point which results in the errors below.
You get the following failure in the mpsetup.log:
mp.msi exited with return code: 1603
Backing up drive:\program files\Microsoft Confgiuration Manager\logs\mpMSI.log to Drive:\Program Files\Microsoft Configuration Manager\logs\mpMSI.log LastError
Fatal MSI Error - mp.msi could not be installed.
You get the following failure in the smsts.log (Windows PE log):
"No MP Certificate"
Follow the guidelines in this KB article to fix the issue: http://support.microsoft.com/kb/2419559

Tags: , ,

Why is SMS_SystemConsoleUser returning a blank value

This fredag I found myself in a really weird SC Configuration Manager issue at a customer. They had created some custom reports that used the "Console User Information" collected by the Asset Intelligence in Configuration Manager to find the owner/user of their machines. For some reason the information wasn't available from even half of their machines.

The error can be seen here below:

The standard asset intelligence report (Hardware 6A - Computers for Which Console Users Could not be Determined) also returned a large amount of the Windows machine that the console user could not be determind. I verified all the prerequisites from the Microsoft Technet article (http://technet.microsoft.com/en-us/library/cc161947.aspx), but everything seemed to be in order.  It was pretty weird?


After verifying all aspect of the communication between the SCCM client and server. I saw that the clients all ran the WMI query to collect the information so the SCCM client must be collecting the information. 

All clients had the string "Successfully Completed Inventory for SMS_SystemConsoleUser" but only half of them worked.

I finally decided to perform the WMI query on a couple of the clients and truenought there was not value returned. Knowing that the WMI query read the security eventlog for the last 90 days of information to determind the console user I took a look at the log. I couldn't find a single logon/log off entry within the log. The log was full of log entries from the Windows Filtering Platform and due to the amount of logging that was done by the filtering platform only about an hour of data existed in the 16 megabyte large security eventlog. It's a scary thought that the filtering platform undermines the purpose of the security log.

The specific policies “Audit Filtering Platform Connection” and “Audit Filtering Platform Connection” logs may extensive amount of information to the Windows security Eventlog for both successful and failed connections allow or blocked by the Windows Filtering Platform. Microsoft Windows 7 / Windows 2008 R2 introduces 53 new policies that isn't always preferred to have enabled. The default settings within Windows 7 is to have most of these policies enabled.

The “Audit Filtering Platform Connection” and “Audit Filtering Platform Packet Drop” policies are enabled if you have defined the "Object Access" auditing function within group policies for either/both failure and success. With that said you are now able to manage these policies more specific under Windows 2008 R2. See this TechNet article for more information: http://technet.microsoft.com/en-us/library/dd772712(WS.10).aspx


Here is how you get rid of the mass flooding of Event ID 5156 - The Windows Filtering Platform has allowed a connection within the Event Log

I would recommend that the WFP be disabled using either scripting or group polices.



To manually configure the changes to the Windows auditing function. You verify the problem you can use the Microsoft Auditpol tool that allows for changing the Windows auditing policies.

"auditpol /set /subcategory:”Filtering Platform Connection” /success:disable /failure:disable"

"auditpol /set /subcategory:”Audit Filtering Platform Packet Drop” /success:disable /failure:disable"


Executing these commands changes the setting to disabled auditing for the Filtering Platform Connection and Audit Filtering Platform Packet Drop.

Verify the setting with "auditpol /get /subcategory:”Audit Filtering Platform Packet Drop”


For more information check these articles:



Group Policies

1. Open the Group Policy Management Console and create a new Group Policy called "Advanced Client Auditing" (Or use existing).

2. Modify the group policy and configure the settings for auditing.

3. Verify that the console user appears in the SCCM report after a hour (Group Policy refresh is usaually 15min + replication) 


For more information check these articles:





(Asset Intelligence Client Access License (CAL) reports do not contain data):




Tags: , ,