FIX: Setup could not configured one or more system components.

Whilst integrating the Dell E7240 and E6440 to our Windows 7 Sp1 64 bit image I got an error at deploy time right after the end of the WinPE Phase and in the first boot into Windows.

The error appeared after devices installation and in the phase where "Setup is applying system settings".

Here is a screen-shot of this error:

I opened a cmd prompt by pressing Shift + F10 and checked the "C:\Minint\SMSOSD\OSDLOGS\BDD.log" to see.

The "Property PHASE is now = STATERESTORE"  entry gave us an indicator as to where in the  TaskSequence the error occurred. Yet no specific steps where throwing the error as there was no entry in the BDD.log from ZTIGather.wsf (which is the script called by Gather local only).

Digging a bit further I took a look at the "C:\Windows\Panther\setuperr.log" and found this error.:
"[0x030153] CMI    Callback_CMI_ConfigInstall: CBS startup processing re-run failed."

From the cmd prompt I was also able to run mmc.exe to check the device manager and my Intel Management Engine Interface controller was showing a yellow ! with an error 37.

A quick google search for "setuperr [0x030153]  Intel Management Engine Interface"  took me to this page from the Dell Community Wiki where the reason for this problem is explained as quoted below:

" Reasons for failure:

-          Windows 7 Operating system comes with KMDF 1.9 (Kernel Mode driver framework) as part of image. Any driver release which is built with newer version of KMDF requires reboot of system during the installation, this reboot is unexpected during OS Setup.

-          If the Win7 image used contains any security update or patch affecting the KMDF components is used along with driver (which is built on newer version of KMDF) then deployment would fail. Example:KB2808735"

I tested the solution given in the article by mounting my image Wim with DISM, adding the package kmdf-1.11-Win-6.1-x64.msu to the mounted image and committing the change.

On the next deployment both the E7240 and E6440 deployed correctly.

I hope you find this entry useful. Until next time !!

How-To Run commands in SYSTEM context

Just a quick post on how to run commands, installation, programs in system context in windows vista and above.

For XP we use a tool called CmdAsSys.exe which we simply ran with admin rights.

But for windows 7 this tool would not run interactively in the currently logged in user session and instead the operating system would throw a prompt to change session which just isn't a convenient way to work.

Therefore, for Windows 7 we are now using psexec from sysinternals. This utility can be downloaded here.

From an elevated command prompt run:
PsExec -s -i cmd.exe

Here is a screenshot showing the command, task manager with the cmd.exe process running as SYSTEM as well as notepad started as SYSTEM.

That's it for now, hope you will find this entry useful and if you have other ways of doing this, please use the comment section to share them !!

How-To Manage the new Java security prompts without using keytool

As explained by Oracle on their web (follow this link for the full details):


"Java 7 Update 21 introduced changes to the Java browser plug-in behavior that enable you to make more informed decisions before running the Java applet in the browser. "

In the case of  "Java application with a certificate from a trusted authority" if the user checks the option "Do not show this again ... " well ... they would not get prompted again. 

Yet some administrator could still want to manage some of those prompts for their environment. For instance to prevent such prompt for their intranet applications.

To do so, you would need to: 

1. Get the URLs of the web pages throwing those warnings. 

2. On a test machine, install a version of Java that is higher than 7u21 and ensure that there is no trusted.certs file under C:\Users\<UserID>\AppData\LocalLow\Sun\Java\Deployment\security (unless you want to update an existing keystore)

3. Then browse each of the URLs you would like to pre-authorize on behalf of the users and ensure that you check the box "Do not show this again ... " and click on Run.

This will create and add the signing certificate information to the C:\Users\<UserID>\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs file.

To deploy this file you have several options, you could be using a GPO to push this file to your clients, or include it into your java package, or if java is installed in your corporate image simply copy it to the image prior to capturing it.

The file should be copied to the SYSTEM Java security folder - this way it will apply to all users. - under: 

C:\Program Files (x86)\Java\jre7\lib\security

and eventually 

C:\Program Files\Java\jre7\lib\security ( If you use 64-bit browser and 64 bit Java add-on) .

Here is a screenshot of the settings of a GPO that was tested to push the file to the clients: 

Should you want to carry on updating the keysotre file to add new applications as time passes then simply copy you existing trusted.certs file to your test machine - as per step 2 above - prior to adding more exceptions.

I have noticed when testing that the method that consists of first adding the certificate as described above and then going to the Java control panel to export the certificate as a .cer file to finally use keytool to add the signing certificate details to a keystore file did not work for me.

I have compared a working and a non-working trusted.certs file and the only difference I noticed was the Alias.  When letting java do the job of updating the trusted.certs the alias created looked like:
deploymentusercert$tsflag$loc=https//secure.entrust.com:443java.util.random@973f09
or
deploymentusercert$tsflag$loc=https//java.com:443java.util.random@a549a8

and this was the only way it would work. 

I hope you enjoy this article, until next time ... 

Understanding what triggers UAC prompt Vista, W7, W8 and 8.1

Recently, I got escalated an issue where standard users were getting a UAC prompt when trying to open the registry editor (C:\Windows\Regedit.exe). Although many people on the net seems to think this is a normal behaviour, actually it is not, unless standard uses are assigned additional priviledges.

Lets look into more details at how UAC really works.

I started by reading the info documented here:  http://www.pretentiousname.com/misc/win7_uac_whitelist2.html
and more specifically at the section "Win 7 UAC Code-Injection: How it works" although this does not explain why regedit.exe was asking for UAC to std users it is still interresting to know that there are groups of applications and not all of them interact with UAC in the same way. Regedit.exe is not on the MS white list so I kept digging.

My searches got me to stumble upon this forum entry, were the application manifest files were pointed out.
 http://stackoverflow.com/questions/16370317/accessing-regedit-without-admin-rights 

"You can run regedit without administrative privileges by launching it as a non-administrator. If you launch it as an administrator user, you get the UAC prompt, but if you launch it as a regular user, you get no prompt and most things outside of HKEY_CURRENT_USER are read-only.
regedit.exe is marked with <requestedExecutionLevel level="highestAvailable" uiAccess="false" />, which does not always ask for admin permissions, only if the current user is an administrator.
If you really need to run regedit as an admin user without admin rights, according to this thread, you can use the Compatibility Administrator tool to configure your system to ignore therequestedExecutionLevel"

To see the manifest for an application you can either edit the exe with notepad and you will find it near the end of the file or you can use a Sysinternal utility called sigcheck and use the -m switch followed by the exe's path.

A bit more digging on the net to get to the Microsoft documentation on how to create an application manifest and this was the key to understand the UAC behaviour. As per this msdn article http://msdn.microsoft.com/en-us/library/bb756929.aspx application uses manifest to communicate to the operating system their needs.
For UAC, the manifest attribute in which we are interested is "requestedExecutionLevel" <requestedExecutionLevel

level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/>

Here is a description of each level:

And here is a description of the UAC behaviour for each level for Administrators, Standard Users and Standard Users with additional priviledges.

The Consent policy settings (2nd column for the table above) can be identified either by looking at the GPO settings by running RSOP from an elevated command prompt or through the registry under  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
The following Microsoft article explains every settings: http://technet.microsoft.com/en-us/library/dd835564(v=ws.10).aspx

Here is a screenshot of the Consent settings in the registry:

At the end it turned out that an application was adding Authenticated Users to a custom Database Admin group converting standard users in standard users with additional priviledges. So the lesson learned here is that when UAC is not behaving "as expected", the user rights have probably been modifyed. So a good thing to do is to check the membership of the local group to see if the Users, Authenticated Users or Everyone group are member of other groups giving them additional priviledges and modifying the UAC behaviour.

This is it for now. I do hope that you will find the info provided usefull.
Thanks for reading.

FIX - GPP Item-level targeting based on Active Directory group membership not working

I came across a GPO change that required Item-level Targeting based on Active Directory group membership and learned a valuable lesson.

Although the Group Policy Editor allows you to type in your group name manually i.e.: MyDomain\My_Security_GroupName, this will not work when applying the GPP to a machine or user.

Instead, you must ensure that you actually click on the "..." button to browse the domain and select the group this way. This ensures that the group SID is included in the GPO and that was how I fixed this  Item-level Targeting issue.

HOWTO - Automatically restart Stopped Hyper-V VMs

I am currently studying SCCM 2012 and have created a small lab on 2008R2 with Hyper-v and two 2012  servers.

One is running my Domain Controler, DNS and DHCP and the other is my SCCM 2012 Primary Site server.

There is a small issue with this lab though is that my Hyper-V VMs keep shuting down every so often.
Checking the Event Viewer seems to indicate an issue with the licensing.

It seems that because I am using server 2012 in evaluation mode, once the grace periode has expired this is the standard behaviour. Of course I can use slmgr.vbs to rearm the grace period up to 5 times but then ...

So I added this little PowerShell code to my $profile to add an event that run a Start-Lab function to restart my VMs should they have stopped.

If you have not done so already, download the HyperV Module from Codeplex HERE, and ensure that you are have enabled your script execution policy as RempoteSigned or Unrestricted using this command:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Also ensure that you run PowerShell with elevated rights.

Enough preparation, lets dig into this short script:

#Manually create a Modules folder under your PS profile and add the HyperV module.
#C:\Users\Administrator\Documents\WindowsPowerShell\Modules\HyperV
#Add the HyperV cmdlet to this session
Import-Module HyperV

## Create an Timer instance 
$timer = New-Object Timers.Timer

## Now setup the Timer instance to fire events
$timer.Interval = 300000     # fire every 5mins
$timer.AutoReset = $True  # enable the event again after its been fired
$timer.Enabled = $true

## register your event
Register-ObjectEvent -InputObject $timer -EventName Elapsed -SourceIdentifier HyperV  -Action {Start-Lab}

# Start your timer
$timer.start

Function Start-Lab
{
#Use the get-vm STopped switch to return VMs that need restarting,
# filter them by name and restart if its a match.
get-vm -Stopped | %{if(($_.ElementName -eq "PS1") -or ($_.ElementName -eq "DC1"))
{Start-VM $_.ElementName} -Wait }
}

HOW-TO GPP Apply Once and Do Not Reapply

With Group Policy Preferences the settings "Apply Once and Do Not Reapply" can be enforced.

This is a great feature but when testing a GPP that you need to re-work and then re-test, it can be a bit annoying.

Instead of using another machine, you can clean your test machine as follow:

To know if a GPP has already been applied to a machine, the machine stores the Unique ID associated with each  "Apply Once" settings in the registry.

For USER settings the UIDs are stored under:
HKEY_CURRENT_USER\Software\Microsoft\Group Policy\Client\RunOnce

and for MACHINE settings under:
HKEY_LOCAL_MACHINE\Software\Microsoft\Group Policy\Client\RunOnce

To know which UID(s) to clear, take a backup of your GPO and search for the "FilterRunOnce" ID in the gpreport.xml file.