Techibee.com

Using PowerShell, we can query who has permissions to a given GPO or a list of GPOs. We can do this either using Quest Active Roles cmdlets or by using native cmdlets that comes along with Windows 7 installation. In this post, I am going to demonstrate and show you the native method. To use the native method, you must be running one of the following:

• Windows Server 2008 R2 on a domain controller
• Windows Server 2008 R2 on a member server that has the GPMC installed
• Windows® 7 with Remote Server Administration Tools (RSAT) installed. (RSAT includes the GPMC and the Group Policy cmdlets)

GPMC(or RSAT) installation also installs a powershell module called grouppolicy using which we can query the GPOs. Before start dealing with GPOs, we should import this module by using import-module GroupPolicy command.

Below is the sample code that helps you get permissions of a give a GPO.

function Get-GPOPermissions {            

param($GpoName)
import-module GroupPolicy            

$permsobj = Get-GPPermissions -Name $GPOName -All
foreach ($perm in $permsobj) {            

    $obj = New-Object -TypeName PSObject -Property @{
   GPOName  = $GPOName
   AccountName = $($perm.trustee.name)
        AccountType = $($perm.trustee.sidtype.tostring())
        Permissions = $($perm.permission)
 }
$obj | Select GPOName, AccountName, AccountType, Permissions            

}
}

Below is the sample output:

Hope this helps. I will continue writing some GPO related scripts in coming days.

Have you started using Group Policy Preferences lately to manage your Windows 7 and Windows 2008 computers? It is possible that Group Policy Preferences can cause increase in login times in your environment if security groups are used for targeting preferences. For example, you may be mapping drives based on user security group membership(ex: sales, finance, etc). Per AskDS, when a security group is used for targeting a group policy preference setting, the computer has to make several round trips to domain controllers to verify the user group membership. This trip time depends on the kind of connectivity you have to domain controllers and the load of DC. If you are on a Wan link, the trip time may be even more. The windows 7/2008 computer won’t allow you to complete the login until this preference setting is evaluated and applied. In such graces the logon time will increase drastically which is a very bad experience for end users.

The AskDS team suggested using Organization Units instead of security groups for targeting. Usage of OUs will reduce the trips to domain controllers as the GPPs have to just parse the DN text of computer/user account to verify if a setting is applicable or not.

After reading the AskDS article, I wondered why they(MS) didn’t use security tokens for evaluating computer/user group membership at the time of processing the target. It is very easy and less traffic to domain controllers. It makes sense. Isn’t it?

I question was answered in very short time in the form of another AskDS article.  They exactly implemented what I felt. MS release hotfix(http://support.microsoft.com/kb/2561285) which injects this nice feature into Group Policy Preferences which can reduce the user logon times and computer startup times(if you are using security group targeting in computer GPPs).

So, if you are using Group Policy Preferences in your organization, then make sure that all your Windows 7/2008 computers have this hotfix. Otherwise one or other day you will end up looking for it when you users keep complaining about slow login issues.

Are you new to Group policies? Looking for a document to get basics? Well Microsoft has recently released a document which helps beginners to understand basics of GPOs. This document explains various components of GPOs and their usage.

You can download this document from here

Windows 7 and Windows 2008 R2 are having real good amount of new GPO settings that IT administrators can manage on their Client and server computers. These includes, controlling the USB devices, configuring firewall rules, and many more. One can go through gpedit to get a understanding of all the settings but that is time consuming.

I came across these nice downloads from Microsoft which describes significance of each settings, their options, and the corresponding registry keys if any. Using this sheet you can quickly search for a policy and understand its functionality.

Download these reference guides from MS download center

Happy Learning….

Windows needs to download and install a software driver from the \<servername> computer print to <printer-name>. Proceed only if you trust the \<servername> compuer and the network.

You might see above message with “UAC” prompt to install drivers while adding network printers from a windows 7 computer. This behavior is expected as normal users are not allowed to add network printers(drivers installation requires admin rights) in a Windows 7 environment.

To fix this, you need to enable below group policies with described settings.

Computer Configuration -> Administrative Templates -> Printers -> Point and Print Restrictions and it’s settings should look like below.

Before reaching this policy setting, I have gone through the options to allow device and class ID/GUIDs through GPOs(click here for details) but in vain as they are not fully developed for printers.

Happy learning..,
Sitaram Pamarthi

German AD team has announced a sweet online tool(http://gps.cloudapp.net/default.aspx) which helps windows administrators in easily locating their GPO settings. It’s pretty useful tool in case if you want to refer a setting, regkey, path, description of a particular GPO to a friend or forum member.

I like it for two major reasons…

1) The easy access of registry key name/path of a particular GPO setting

2) It’s online and accessable for everywhere.

But I have seen that copy option in this tool is not consistently working. I am thinking that it is problem my browser(tried with IE and FF). Let me know if you also see this issue.

Thanks,
Sitaram

I recently read a article in Microsoft DS blog about the change in the way GPOs processes startup/logon scripts in Windows 7 and Windows 2008. The thing here is that, till XP/2003 days, computer startup/user logon scrips used to get executed in synchronous manner. That means, if you have more than a script configured in computer startup/user logon via GPOs, those scripts will get executed one after another. This behavior is changed in Windows 7/2008. In these latest operating systems, computer startup/logon scrips are asynchronous…means, execution of scripts starts at the same time. The big advantage I am seeing with this approach is, faster start/logon times in Windows 7/2008. Considering the hardware that we use to run Windows 7/2008, running scripts simultaniously will not tamper any of the computer resources and it’s a good move by Microsoft to increase the logon/startup speeds.

However, for some customers, running scripts synchronously might be a requirement. Output of one script might become inout to next script. In such a cases, you can always make Windows 7/2008 to process startup/logon scripts synchrounouly by altering registry key values.

Logoff/shutdown scripts are always Asynchronous and there is no tweak available for it to make synchronous.

Registry keys to create are…

Computer Preference
Key: HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogon
ValueName: RunStartupScriptSync

Computer Policy Key: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystem
ValueName: RunStartupScriptSync

User Preference
Key: HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWinlogon
ValueName: RunLogonScriptSync

User Policy Key: HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem
ValueName: RunLogonScriptSync

[ Source:ASKDS Blog]

I came across nice PPT which is explaining about today and tomorrows of Group policy infrastructure. It gives a general over view of what you can do with GPOs/GPPs in Windows 7/2008 and I felt it is useful to my blog readers; hence writing this post. You can get this presentation from this download link.

Happy Learning..,
Sitaram Pamarthi

 I had spent real huge amount of time in dealing with drive mapping in Group Policy preferences in last week. It’s easy as you see, but very difficult when you want to troubleshooting. So, I decided to write this post to help my blog visitors by providing as much as information I have gathered/learnt in Drive mapping related things. 

As said before, things are really smooth when you configure drive mapping preference for the first time.  If you start playing with it to satisfy different kind of situations, then you are caught.  What I did to make my life tough is, I deleted the mapped drives after login and did a “gpupdate /force” no drives were mapped L. Again, what I did is, I re-logged into the machine and found that they are not in place still. I surprised and made relogin again, this time they mapped. Finally after applying multiple tests like this, I came to a conclusion that, I have below two problems… 

1. Drive mapping is not happening at every attempt
2. Background processing of drive mapping is not working

 The very big mistake I did to resolve above is, trying to resolve both the problems at same attempt and really mixed up the things and made myself confused.  After taking a break, I followed the divide and conquer method. 

Problem#1: Drive mapping not happening at every login

Initially I am not sure why the drive mapping is not happening at every login. I ran rsop and there drive mapping processing time is not updated. This made me to realize that drive mapping CSE didn’t triggered at all. Well, now I enabled GPO debug logging on my Windows 7 machine and started looking at the logs. They are clearly saying that drive mapping CSE processing skipped as there is no change in version number. Hmm, whatever it is doing is right and I have enabled “Process even if the Group Policy objects have not changed” option in “Drive maps preference extension policy processing” policy which is located at [Computer Configuration | Policies | Administrative Templates | System | Group Policy] and restarted my PC. Things started working and drive mapping is happening every time I re-login.

First problem is solved. Let’s move on to the second problem.

Problem#2: Background processing of drive mapping is not working.

After login, if I delete mapped drives and initiate a “gpupdate /force” command, my drives are not coming back. I again relied on GPO logs and realized that drive mapping CSE refresh is happening as part of background processing. I STRONGLY recommend to not to follow the description of Drive mapping CSE; it is really contradicting with its behavior. As per the policy description, drive mapping refresh should work during the background processing by default — but it is not the case. Now I went to the registry key, HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonGPExtensions{5794DAFD-BE60-433f-88A2-1A31939AC01F} and changed the value of “NoBackgroundPolicy” to “0”. This did the trick and background refresh of drive mapping started working fine.

Hurry…I resolved both my problems and trying to figure out a new problem I observed just now.  I will blog it as soon as I resolve it. 

To Summarize:

How to make GPO to process Drive mapping at every login:

1. Edit the GPO which is applicable to your computers and navigate to [Computer Configuration | Policies | Administrative Templates | System | Group Policy]
2. Now go the properties of “Drive maps preference extension policy processing” policy and enable the option “Process even if the Group Policy objects have not changed”
3. Save you GPO and reboot your machine

 How to enable background processing for drive mapping CSE:

1. Go to regedit and navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonGPExtensions{5794DAFD-BE60-433f-88A2-1A31939AC01F}
2. Locate “NoBackgroundPolicy” value and change it to “0” from “1”
3. Now try doing a background refresh by issuing the command “gpupdate /force” and it should work

Thanks for reading the log story and happy learning,
Sitaram Pamarthi

People familiar with UseEnv logging for GPO debugging on Windows XP can forget that procedure if you started looking into Windows 7 operating Systems. Things have really changed and you should follow the below procedure enable debug logging on Windows 7 Computer. I guess this procedure works straight away with Windows 2008 hosts as well(I didn’t tested it).

1. Logon to the Windows 7 Computer as local administrator
2. Save the below few lines as .reg file and execute it on the Windows 7 computer.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionDiagnostics]
“GPSvcDebugLevel”=dword:00030002

 Now time to restart your Windows 7 PC to make changes come into effect.

The debug log file will be available under “%systemroot%debugUserMode” folder and the file name is “gpsvc.log”.  If you want a nice view of this log file for easy reading, I prefer you download the policy reporter tool from SysPro Software. This tool allows you to analyse the time taken for each policy detection and processing.

Let me know you are in doubt anywhere…

Happy Learning..,
Sitaram Pamarthi