Tag Archives: group policy

Getting all GPP Drive maps in a Domain with PowerShell

Group Policy Preferences are mostly great and frequently used to solve different kind of policy related problems in an it Environment.
There are a few PowerShell cmdlet for GPO’s (28 last time I checked) but only three of them are related to Group Policy Preferences.
2013-12-31 13-31-59.

Case and Solution
A customer of mine wanted to inventory their GPP Drive maps, and get information about what GPO, drive letter, drivepath, security Filtering and so on.

I know there are quite a few solutions that can do this for you, but why not use PowerShell when possible? 🙂

The script is using the GroupPolicy POSH-module which has been around since 2008R2, so this works even there.
It simply gets all Group policies in your domain, checks each policy for drive maps (by checking if Drives.xml exists) and gives you a bit of nice output. (ehh.. could be nicer, but anyway… )

See my examples below:
1. Gives you all Drive Map GPO’s plain and formats the output as a table.

2013-12-31 13-48-24
Note: The DriveAction object is not translated to a more friendly name at this time so U, stands for Update, D, for delete and so on. That is also applies on the DrivePersistent output (“Reconnect”).
Update: This is now updated so it gives you a bit of nicer output!

2. Searches for drive maps in a specific GPO.
2013-12-31 13-42-38

3. Exports the output to a csv.

.\Get-GPPDriveMaps.ps1 | Export-Csv DriveMaps.csv -NoTypeInformation


           The script finds the GPP Drive Maps in your domain. 
           File Name: Get-GPPDriveMaps.ps1     
           Author   : Johan Dahlbom, johan[at]dahlbom.eu     
           The script are provided “AS IS” with no guarantees, no warranties, and it confer no rights. 
#Import the required module GroupPolicy
Import-Module GroupPolicy -ErrorAction Stop
throw "Module GroupPolicy not Installed"
        $GPO = Get-GPO -All

        foreach ($Policy in $GPO){

                $GPOID = $Policy.Id
                $GPODom = $Policy.DomainName
                $GPODisp = $Policy.DisplayName

                 if (Test-Path "\\$($GPODom)\SYSVOL\$($GPODom)\Policies\{$($GPOID)}\User\Preferences\Drives\Drives.xml")
                     [xml]$DriveXML = Get-Content "\\$($GPODom)\SYSVOL\$($GPODom)\Policies\{$($GPOID)}\User\Preferences\Drives\Drives.xml"

                            foreach ( $drivemap in $DriveXML.Drives.Drive )

                                {New-Object PSObject -Property @{
                                    GPOName = $GPODisp
                                    DriveLetter = $drivemap.Properties.Letter + ":"
                                    DrivePath = $drivemap.Properties.Path
                                    DriveAction = $drivemap.Properties.action.Replace("U","Update").Replace("C","Create").Replace("D","Delete").Replace("R","Replace")
                                    DriveLabel = $drivemap.Properties.label
                                    DrivePersistent = $drivemap.Properties.persistent.Replace("0","False").Replace("1","True")
                                    DriveFilterGroup = $drivemap.Filters.FilterGroup.Name

The script can of course be extended with a lot more information, and make the output easier to read, but that’s a later project.



Quick Tip: Windows 8.1 – PowerShell as default Win+X shell with Group Policy

A massive amount of post out there describes how easy it is to change from the default (cmd.exe) to Powershell when using the “Power User Menu” (Win+X) in Windows 8.1 and Server 2012 R2. One example you find here from my friend Daniel.
I honestly don’t know why they didn’t set PowerShell as the default Shell, which actually was default in the Preview.

Rolling out Windows 8.1 (or Server 2012 R2) in an Enterprise, you would of course want this as the default setting for all users.
Doing the change in the UI, the registry key
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\DontUsePowerShellOnWinX is set to 0.

Here is how to do it with group policy preferences
* The GP Preferences (except the PowerShell-line) can be created from any machine with gpmc newer than Server 2008. The other policy requires you to have the latest .admx-files or do the change from a Server 2012 R2 Machine

In Group Policy Management, in a new or in an already existing user policy, navigate to User Congfiguration\Preferences\Windows Settings\Registry and create a new registry item configured as below.
(the entire key path used is “Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced“)
2013-12-26 20-07-43
If you want to do the same thing as above against an existing policy, you can do it with the following PowerShell line:

Set-GPPrefRegistryValue -Name "YourPolicy" -Context User -Key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced -ValueName DontUsePowerShellOnWinX  -Value 0 -Type DWORD -Action Update

If you instead want to prevent your users from changing the shell, there is a policy setting for that under
User Configuration\Administrative Templates\Windows Components\Edge UI 
2013-12-26 20-40-05
Why you would want prevent your users from changing from cmd to PowerShell I don’t know, but someone obviously wanted cmd.exe as the default one…
Note that the registry value for the PowerShell menu does not work if you enable this policy!

Directaccess in Windows 8 and Server 2012 – Hotfix frenzy

Windows Server 2012 DirectAccess includes a number of enhanced features and improvements as below:
⦁ Direct Access and RRAS coexistence
⦁ Simplified Direct Access management/setup for small and medium organization administrators
⦁ Built-in NAT64 and DNS64 support for accessing IPv4-only resources
⦁ Support for Direct Access server behind a NAT device
⦁ Load balancing support
⦁ Support for multiple domains
⦁ Support for OTP (token based authentication)
⦁ Automated support for force tunneling
⦁ Multisite support
⦁ Windows PowerShell support
⦁ User and server health monitoring

I’ve now done a couple of DirectAccess implementations (both small scale and large scale) and I must say that most things works very well and straightforward.

There are however a couple of hotfixes that you may have to apply, if you for example are enabling external load balancing in your implementation.
Below is a summary of the hotfixes that have been useful in my different implementations of DirectAccess

Windows Server 2012 and Windows 8 – DirectAccess Related Hotfixes:
KB2782560: DNS64 does not resolve computer names when you use DirectAccess and external load balancing in Windows Server 2012.

KB2788525: You cannot enable external load balancing on a Windows Server 2012-based DirectAccess server.

KB2769240: You cannot connect a DirectAccess client to a corporate network in Windows 8 or Windows Server 2012.

KB2748603: The process may fail when you try to enable Network Load Balancing in DirectAccess in Window Server 2012.