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.