Windows 7 unsupported CPU’s starting to hit the market

As has been well documented

The newest Intel and AMD processors are not supported when using Windows 7, 8.1, Server 2008R2 and Server 2012 R2… While this has been known for a while, however its always variable how much time the new hardware takes to hit the market.

A client recently had ordered a number of Dell 3040’s….. but Dell apparently decided to send 3050’s instead due to stock issues…. leading to this clients build’s not working.

While I, like many others, hate being “forced” to move versions (of anything), Win 10 is actually a pretty good OS and with Windows 7 extended support ending in 2020, its simply time to start planning to migration.

SCCM – BADMIF error 4

It is very common to get the following errors in your SCCM component status window for the component “SMS_Inventory_Data_loader” – the most of common of which goes something along the lines of

Inventory Data Loader failed to process the file D:\Program Files\Microsoft Configuration Manager\inboxes\auth\\Process\H38H6C71.MIF because it is larger than the defined maximum allowable size of 5000000.

The size of the MIFs can be checked by navigating to D:\Program Files\Microsoft Configuration Manager\inboxes\auth\\BADMIFS\ExceedSizeLimit and taking note of the largest MIF, then adding a bit of headroom, modifying the registry as per

For one client recently, once that was done, the larger MIFs started processing, however they then got many entry’s in D:\Program Files\Microsoft Configuration Manager\inboxes\auth\\BADMIFS\ErrorCode_4

This article – nicely documents some of the errors you may get, but not specifically what error code 4 relates to. This TechNet forum post seems to nail the issue, but not necessarily how to solve it.

In my case, I navigated to the SCCM logs directory, open dataldr.log and searched for errors to find the specific line of SQL which was not being imported nicely – it was pretty easy to find thanks to CMTrace’s desire to highlight lines with “error” in them to red.

With this, its fairly easy to see that the troublesome statement is

*** [23000][547][Microsoft][SQL Server Native Client 11.0][SQL Server]The INSERT statement conflicted with the FOREIGN KEY constraint “WINDOWS8_APPLICATION_USER_INFO_DATA_FK”. The conflict occurred in database “CM_xxx”, table “dbo.System_DATA”, column ‘MachineID’. : pWINDOWS8_APPLICATION_USER_INFO_DATA


Armed with this information, you can then choose if you care about this hardware inventory information – and if not, you can exclude it from inventory.

Importing AD powershell module into Windows PE and then using encrypted creds

Powershell makes life much easier than vbscript…. however it does have its downsides…  signing policy can sometimes be a bit of pain and the modules you need have to be available…. which is an issue in particular for Windows PE.

Mick (good aussie name there) was nice enough to write a blog on how to import powershell into PE – without having to add it statically to the boot wim –

As a little shortcut from the blog, you can copy both the x86 and x64 required directories via robocopy rather than determining the version via powershell.

The next step however is the more important one…. a task sequence doesn’t allow us to run a powershell command in PE with credentials, we need a secure way of running the command. In this case, we want to delete a computer object….

Step 1 – Generate a key file (perform on any full OS)

$KeyFile = “\\sccm\PSource$\OSD.DeleteComputer\DeleteComputer.key“

$Key = New-Object Byte[] 16


$Key | out-file $KeyFile


Step 2 – Encrypt a password using the key

$PasswordFile = “\\sccm\PSource$\OSD.DeleteComputer\DeleteComputer.txt“

$KeyFile = “\\sccm\PSource$\OSD.DeleteComputer\\DeleteComputer.key“

$Key = Get-Content $KeyFile

$Password = “Your password here” | ConvertTo-SecureString -AsPlainText -Force

$Password | ConvertFrom-SecureString -key $Key | Out-File $PasswordFile


Step 3 – Create your script utilising the creds – (Below is the one I use to delete a computer object)

Import-module ActiveDirectory

#SCCM TS Object
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

#SCCM Variables
$CompName = $tsenv.Value(“_SMSTSMachineName”)

# Get current path in order to get encrypted password
$MyDir = [System.IO.Path]::GetDirectoryName($myInvocation.MyCommand.Definition)
$User = “Domain\Account”
$PasswordFile = “$MyDir\DeleteComputer.txt”
$KeyFile = “$MyDir\DeleteComputer.key”
$key = Get-Content $KeyFile
$MyCredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, (Get-Content $PasswordFile | ConvertTo-SecureString -Key $key)

# Remove the computer from AD
Remove-ADComputer -Identity $CompName -server <DC name required> -Credential $MyCredential -confirm:$false


One obvious risk is, this is not very secure. It will stop a random snooper type person from seeing a plain text password…. but it will not stop someone who is capable of pressing F8 to get into the running TS (if you have it enabled) and then grabbing the key and txt and being able to use them…. So, take this into consideration when choosing to use (or not use) for your environment.

UEV now included in Windows 10 1607 (and above)

User Experience Virtualization (UEV) use to be part of the MDOP packs…. however MDOP’s last update was in 2015…. leaving some of us wondering what was happening to awesome tools contained within.

Given Microsoft’s strong movement towards cloud platforms, it seemed likely that these tools were dead.

Fortunately for UEV, its now included in Windows 10 Enterprise as a default service, for versions 1607 and 1703 (and we may be able to assume future releases as well). Some details on the release are here –

Unfortunately, the documentation is somewhat unhelpful.

The UEV documentation is located here –

However, there are a couple of quite important things that anyone deploying this should be aware of

  • Even though it isn’t stated anywhere in the doco, and seems quite counter-intuitive based on what’s presented in the GPO settings, the default Microsoft included templates do not automatically register on clients. These can be copied to your custom templates path, or you can register them with powershell on each machine as per
  • The UEV template generator is part of the ADK (1607 or 1703) – however, it does not show up if you try and run the ADK installer on Windows 8.1 or server 2012 R2. I haven’t tried on Windows 10 versions below 1607 or 1703 – but it will show/be installable on those versions.