Policy Evaluation Failed. Error Code 0x87d00267.

I have recently been engaged on a customer site who have been having all manner of random and frustrating problems with Operating System Deployments.  Sometimes the OS image would fail to download, sometimes the ConfigMgr Client would fail to download or install, sometimes any given application would fail to install.  Failure Status Messages include the below;

Install Software failed, hr=0x80070001. The operating system reported error 2147942401: Incorrect function.

 

Failed to configure OSD setup hook (0x80091007)
Configure hook failed with error code (80091007).
Failed to install setup hook (80091007). The operating system reported error 2148077575: The hash value is not correct.

 

Installation of image 1 in package P0100198 failed to complete.. 
he hash value is not correct. (Error: 80091007; Source: Windows). The operating system reported error 2148077575: The hash value is not correct.

 

They had been through all the usual Refresh DP/Validate/Remove/Re-add nonsense that sometimes fixes corrupt applications to no avail.  This all added up to something that is usually very unlikely to be the fault of Configuration Manager, the way it is configured or the applications within.  This had plagued them for weeks, months perhaps.

In the scenario where one or more of these errors were occuring when deploying physicsal clients from a physical distribution point, they found that something unusual was happening with their Riverbed setup – which was that whenever the task sequence rebooted and proceeded to try and install the next application, the HTTP session was somehow being interfered with by the Riverbed device – resulting in the client being unable to request policy after the reboot.  They took the Riverbed out of the equation and that resolved some physical > physical build issues.

Where we were experiencing one or more of the errors above in the VMware environment, it was discovered that most (if not all) of the VMware test client systems and VMware Distribution Point servers were configured with either the E1000 or E1000E ‘legacy’ Network Adapter.  Changing the client systems to use the E1000E didn’t help and we are not at a convenient point to include the VMXNET 3 adapters in the boot images (nor does the VMXNET 3 adapter support PXE Boot.)  It was therefore decided (by me, lol) to take a punt on re-configuring the Distribution Point Server to use the VMXNET 3 adapter.

Success!  VM DP to VM Client and VM DP to Physical Client deployments all taking place without any such random nonsense occuring.  A quick Google session revealed the use of the E1000/E adapters in VMware is generally bad Ju-Ju and so I implore you all to consider making sure that where possible you use the VMXNET3 adapter (Requires VMware tools installing) on your VM Distribution Points.


		
Advertisements

Task Sequence Install Applications 80074005, HTTP 401 Unauthorized

Always use the FQDN when specifying your Network Access (and possibly other) accounts within Configuration Manager, ie: “DOMAIN.COM\NetAccess”.  I found that this can resolve issues where you are building WORKGROUP or UNTRUSTED DOMAIN systems and they are failing to obtain content from the Distribution Point.  In short, it appears that IIS/Kerberos does not appreciate systems from other domains coming in and specifying the NETBIOS domain name as part of the Network Access Account, ie: “DOMAIN\NetAccess”.  This may be because systems in those domains have a different DNS suffix and/or are unable to resolve the NETBIOS domain name.

Failed to Sync Update. Error: The Microsoft Software License Terms have not been completely downloaded and cannot be accepted.

I was seeing the above error in the Configuration Manager 2012 SP1 wsyncmgr.log in a customer environment and I suspected this was as a result of SQL services being interrupted during the WSUS syncronisation process – which is never a good thing.  Despite trying to remove classifications and removing/reinstalling the SUP role the problem persisted.  When I loaded up the WSUS console and filtered for all updates I noticed that around 12 updates were showing that their content download (the EULA) had not been successfully downloaded.  I simply highlighted the affected updates, right clicked and chose to “Retry Download” and these changed to Pending Download and eventually all was OK.  A re-sync in Configuration Manager then resulted in a happy wsyncmgr.log and a successful sync event.

There is apparently a hotfix available for this issue which might be worth a try if you encounter this issue when proxy credentials are required;

http://support.microsoft.com/kb/2838998

.NET Framework failed to register Configuration Manager dll’s

I had a recent interesting experience where Configuration Manager 2012 SP1 setup completed successfully however there were problems lurking under the hood.  It was only until I proceeded to configure the environment and add additional roles that these came to light.  Several of the component installations failed, in particular those of the newer roles which require .NET 4.0 and their respective logs showed some very unusual errors I had never, ever, seen before.  The CloudMgr.log was absolutely full of instance creation errors.

At first I put this down to the Windows Server 2008 R2 virtual machine – it was based on an image and provided to me in a bit of a rush and with some history of a power failure/unexpected shutdowns – however a fresh DVD installation of the Operating System resulted in the same errors.  My attention then turned to the ISO media provided on the server that I extracted and performed the installation from – perhaps it was corrupt?  Not quite, but it was the cause of the problem.

The ISO file had been copied up to the server by somebody else over the network and for some reason the server took to marking the file in it’s properties with “This file came from another computer and might be blocked to help protect this computer” and gave me an unblock button.  I hadn’t noticed this and the result was that all of the subsequent extracted files were all marked the same.

windows-server-2012-unblock-file

The problem here is that the regasm.exe utility of .NET Framework 4.0, in it’s default configuration, will not permit the registration of dll’s that it perceives as coming from remote sources such as unc paths.

The answer here is not to proceed with the .config file editing solution offered by the only blog post I found regarding this error, it is simply to ensure that this attribute/property is not applied to any of the files from the Configuration Manager 2012 media before you start installation.  Attempting to patch the installation back together I am sure would be a futile and unsupportable task – there are simply too many possible errors introduced into the installation.  I even found that when you provision site roles on other site systems, the file attribute traveled with the dll’s copied to the remote site system and introduced role issues there.

It’s incredible, how something so random and inert could cause so many issues.

MBAM Beta 2.0 & ConfigMgr 2012 SP1: Empty MBAM Supported Computers Collection

I deployed MBAM Beta 2.0 into my lab environment tonight but was struggling to see any compliance information for my MBAM encrypted systems.  The collection which is targeted by the Compliance Baseline was empty – despite the changes made to the configuration.mof and the import of the sms_def.mof classes – and the subsequent fully populated hardware inventory classes with data showing in the resource explorer.  So what gives?

Well, it looks to me like the default collection logic and parentheses might be a little mixed up – resulting in no clients meeting the criteria.  Here’s the default membership rule:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_OPERATING_SYSTEM_EXT on SMS_G_System_OPERATING_SYSTEM_EXT.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_TPM on SMS_G_System_TPM.ResourceID = SMS_R_System.ResourceId where ((SMS_G_System_OPERATING_SYSTEM.Version like "6.1.%" and SMS_G_System_OPERATING_SYSTEM_EXT.SKU in (1,4,27,28,70,71) and SMS_G_System_TPM.SpecVersion >= "1.2") or SMS_G_System_OPERATING_SYSTEM.Version like "6.2.%") and SMS_G_System_COMPUTER_SYSTEM.DomainRole = 1 and SMS_G_System_COMPUTER_SYSTEM.Model not in ("Virtual Machine")

Here’s my modified membership rule that now includes my MBAM clients and non-MBAM clients that have returned HW inventory:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_OPERATING_SYSTEM_EXT on SMS_G_System_OPERATING_SYSTEM_EXT.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_TPM on SMS_G_System_TPM.ResourceID = SMS_R_System.ResourceId where (SMS_G_System_OPERATING_SYSTEM.Version like "6.1.%" or SMS_G_System_OPERATING_SYSTEM.Version like "6.2.%") and SMS_G_System_OPERATING_SYSTEM_EXT.SKU in (1,4,27,28,70,71) and SMS_G_System_COMPUTER_SYSTEM.DomainRole = 1 and SMS_G_System_COMPUTER_SYSTEM.Model not in ("Virtual Machine") and  SMS_G_System_TPM.SpecVersion >= "1.2"

It’s late, maybe I don’t fully understand the default membership rule, but all I know is that my collection now contains the systems it should, and only the systems it should.

Andy

ConfigMgr 2012 SP1 with MDT 2012 Update 1, UDI Task Sequence and Bitlocker Error 6767

Redmond, we have a problem.  The “Client Task Sequence” template when used with Configuration Manager 2012 SP1 does not work too well when UDI is enabled and we want to Bitlocker our devices.

When we are performing a User Driven Installation, the MDT 2012 Update 1 template makes use of the ConfigMgr “Pre-provision Bitlocker” step, which adequately pre-provisions Bitlocker on the Operating System drive on a ‘used space only’ basis.  This is a good thing.   Later on in the Task Sequence we have an MDT specific step that uses the ZTIBde.wsf script which SHOULD configure and enable the protectors – but you may find that this will fail, resulting in an exitcode of 6767.  Tracing this error in the ZTIBde.wsf script takes us into a failure of the function that enables the Bitlocker protectors.  So what is going wrong?

Let us first understand that the ZTIBde.wsf was designed for MDT deployments primarily – with added ConfigMgr integration as an afterthought.  The ZTIBde.wsf script ON ITS OWN is capable of pre-provisioning Bitlocker in Windows PE AND ALSO, later (in the OS phase) configuring and enabling the protectors.  It’s a great little script.  In the MDT Client Task Sequence template however, the ZTIBde.wsf script is not used within the Windows PE phase to Pre-provision Bitlocker and instead the in-built ConfigMgr function is used.  The ConfigMgr function will pre-provision Bitlocker, however it does not then configure the appropriate variable that the ZTIBde.wsf Pre-provisioning function would and this is needed and consumed later by the ZTIBde.wsf script when it comes to Enabling the Bitlocker Protectors in the OS Phase.

The ZTIBde.wsf script has a section which checks if Bitlocker is enabled on the drive (IsBDE = TRUE) and also if the drive has NOT been pre-provisioned earlier (IsBDEPreProvisioned <> TRUE).  This test is used to accommodate the refresh scenario when the existing suspended protectors of a Bitlocker drive can simply be turned back on without having to configure any.  In the absence of the IsBDEPreProvisioned variable (or if it doesn’t equal TRUE) then this section of code will cause the script to skip over the configuration of any required protectors (specified in the UDI wizard) and simply try to enable any existing protectors, of which there are none – resulting in the error 6767 spat out by the EnableProtectors function.

So what do we need to do about this?  Well you could amend the script – but that wouldn’t be supported by Microsoft and your modifications could well be wiped out by any future revision (which may or may not address its shortcomings.  There are a few (non-exhaustive) alternatives that I could propose;

  1. If you are using the UDI Wizard AND you want the Bitlocker options to come through from it, then you should replace the “Pre-provision Bitlocker” step in the task sequence that uses the ConfigMgr function with the ZTIBde.wsf script – the very same script used later on to “Enable Bitlocker”.  This keeps the Pre-provisioning process and the Enable Bitlocker process solely in the MDT camp.  However, if you want the Recovery Key to be backed up to Active Directory then you will need to use a script afterwards to do that, or implement MBAM.
  2. If you are using the UDI Wizard AND are removing the Bitlocker configuration page but still want Bitlocker enabling then replace the “Enable Bitlocker” step in the task sequence with the ConfigMgr function – as you can specify the protectors used and also escrow the Recovery Key to Active Directory automatically.
  3. If you are NOT using the UDI Wizard but want to implement Bitlocker in your Task Sequence, then stick with the ConfigMgr step for pre-provisioning Bitlocker and replace the ZTIBde.wsf method for Enabling Bitlocker with the ConfigMgr function – for the same reasons as above.  In this scenario, you would need to ensure that your partitioning layout is suitable for Bitlocker.

Have fun with that!

Andy

ConfigMgr 2012 SP1: KB2801987 to fix MicrosoftPolicyPlatformSetup.msi Authenticode Signature

You should apply this hotfix as soon as possible to your Configuration Manager 2012 SP1 environments;

http://support.microsoft.com/kb/2801987

This is a server-side install only and you do not need to push anything out to the clients. The patch will update the existing MicrosoftPolicyPlatformSetup.msi in the client installation files folder.

Related to an earlier post of mine about having patience, you should VERY MUCH be patient after installing this hotfix as it will trigger the re-installation of most, if not all, of the server site components in the background after the hotfix install has completed.  Use CMTrace to monitor your sitecomp.log and give it plenty of time to settle down before firing up the ConfigMgr console to do ‘stuff’.  My server took about 30 minutes to complete the whole background tasks and also you should check that your MP has been re-installed correctly by monitoring the MPSetup.log and the mpMSI.log.  My MPSetup.log indicated a 3010 exit code after re-installation which means a reboot is required and you would be wise to do this immediately after the sitecomp.log has settled.

Andy