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.

HOW-TO Work with Group Policy Preferences F Keys

Let's first clarify that here F stands for Function and not Fxxxing Keys.

I recently was asked why the Group Policy Preferences where applying extra Power Configuration settings to the clients than the one defined in GPP through GPEdit.

Although how to work with GPP is someting that is documented in many places on the net and also in the GPMC.CHM, the use for the Function keys it's not intuitive at all and either you know it or you don't.

Here is the gist of it, when working with GPP some of the settings appears in the GUI underlined in Green or Red. The color  is actually a code to indicate which setting's value will be applied by the GPP and which won't.

As far as I could check in my lab this is true for the following GPP items:
-  Folder Options
- Internet Settings
- Power Options
- Regional Options
- Start Menu

To swtich between enabled and disabled here are the keys:

FIX - RDP Session Disconnecting Randomly

We had an issue where domain users would lose their RDP connections randomly.

In our SOE, Remote Desktop is disabled by default and by design we only want to enable it for machine that are joined to the domain and receiving our Computer policies. Those policies also define specific Domain Security Groups that are member of the "BUILTIN\Remote Desktop Users" group allowing only specific users to use Remote Desktop Connections.

We asked some of the affected users to take note of the time when the issue occurred.
By looking at the event log at the given times no error nor warning where found, but we did notice that this was a large number of SceCli informational events taking place. As per this MS Knowledge Article the processing of the Security Setting Extension is how the Security policies are implemented on the machine.

This drove us to think that this issue was caused by the GPO refresh cycles.
When the refresh takes place the security policies registry key gets deleted to then be rewritten which leaves the machines - for a brief moment of time - without policy settings which in turn causes the user to loose their remote desktop connection. This can actually be seen in the GPSVC.log.

Since the registry key that control the Remote Desktop feature are written in two different locations when applied by the Policies than when applied by the Operating System, the refresh mecanism would cause the O.S. settings to be the only one present and enforced at the time when the users were getting disconnected.

Here are both locations for the fDenyTsConnections value:

O.S value location.: 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
\fDenyTSConnections

Group Policies value location: 
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\fDenyTSConnections

After manually setting the O.S.  registry key to 0 the problem disappeared.
To permanently automate this fix across the whole platform we added this registry entry to our policies.

As a result when the policy refresh occurs RDC rights are no longer lossed and our restricted group policy setting still ensure that  only users of the "BUILTIN\Remote Desktop Users" are authorized to RDC.

FIX - Windows 7 Password Expiry notification balloon not showing

We recently came across a situation where in Windows 7 the Password Expiry notification toast was not appearing near the task bar.

The only indication to the users that their password was about to expire was the double key icon in the task bar.

Of course that is if they had selected the option to always show all icons and notifications in the task bar.

Increasing the notification time to the maximum of 5 minutes did not help either.

The problem was that for some reason the GPO setting "Turn off all balloon notifications" needed to be changed from "Not Configured" to "Disabled". 

According to the setting description we should not have to do this but setting this option explicitely fixed our issue.