Category: Best Practice
How to use Group Policy Preferences to dynamically map printers with Roaming Profiles
One of the great new feature with Group Policy Preferences is the ability to map printers based on a various number of criteria such as group membership, AD Site or even IP Address range. This allows for some powerful options such as being able to map all the printers physically near a user based on the computer IP address. This of course assumes that the networking team allocates the same subnets to certain computers near each other (e.g. a building or floor) but I have found this is often the case.
One of the problems that occur when you map printers with Group Policy Preferences is that if the user has a roaming profile configured and they then logon to a computer that is located in another area they will automatically get all the printers from the previous area they were in and the new area. These printer mapping can build up over time as users logon to computers in different areas they can soon amass a large number of printer mappings that can make their computer run slow especially during logon.
Normal Group Policies are applied via IP address (AD Site) are not a problem as the new computer they are logging on to has no idea of what the previous setting were or the policy falls out of scope so the setting revert back to their original values. But as the printer mapping (and all preference settings) for a user are stored in their profile then this printer mapping will follow them if they are setup with a roaming profile.
Question? So how do you map all the printers in one location but not have them follow you to another location if you are using a roaming profile?
Answer? Is a two step solution which I will go through below. There is also an optional third step that address the problem maintaining default printer mappings once a user gets back to their normal location.
Step 1. The first part is just to create a simple printer mapping that maps the printer targeted by the IP address of the users current computer.
Figure1. Create New Shared Printer
Figure 2. Target setting to only be mapped for computers between 10.1.1.0 to 10.1.1.255
Figure 3. Resulting printer mapping
The images above shows the printer “\\server\printer1†being mapped for the users that logon to a computer that is in the 10.1.1.0/24 subnet. It is important to note that we are talking about the IP address range of the computer that you want to map the printer on not the IP address range of the printer server or the printer itself.
Step 2. The second step is to delete the printer mapping if the IP address of the printer does not fall within the IP address range that you want the printer to be mapped. To do this we start by copying the existing printer mapping that we made in step 1. This avoids making any typo’s in either the printer queue name of the IP addresses.
Figure 4. Copying the existing printer mapping made in step 1.
Figure 5. Paste the setting into an unused part of the pane
Figure 6. Both printer mapping entries
Now we make the changes to the second printer mapping to change the action type and the targeting so that it will remove the printer mapping if the user logs onto a computer that is not in the subnet that we want the printer to be mapped.
Figure 7. Open the properties of the second printer
Figure 8. Change the Action to “Deleteâ€
Figure 9. Go back to the targeting and change it to an “Is Not†between “10.1.1.0†and “10.1.1.255â€
Figure 10. New target rule
Figure 11. Two printer entries to map and then clean up the printer queues for a user based on their location.
Step 3. Maintaining Default Printer Mappings
You have now configured dynamic printer mapping for your user based on location of the user. However this solution does have one problem, user normally like to set a default printer and if a user was to logon to a workstation in another location then return to their normal desk their default printer will have been reset. To get around this problem we have to change the targeting on the Delete printer option so it does NOT delete if the printer is configured as the default printer. To do this we need to look at the registry location that the default printer is saved and test to see if the printer we are deleting is the default printer and if so then do nothing.
So let take a look go back to the targeting setting for the Delete printer action and add another test that will check to see if the printer is the default printer.
Figure 12. Add a new Item of type “Registry Matchâ€
Figure 13. Configured Registry Match Setting
Change the Match Type to “Match value data†and the Value data match type to “Substring match†as the value we are looking for will contain other information as well that we don’t care about. Make sure the Hive is set to “HKEY_CURRENT_USER†and the Key Path is set to “Software\Microsoft\Windows NT\CurrentVersion\Windowsâ€. The Value name “Device†is where in the registry the default printer information is saved”. We then set the Substring to “\\server\printer1†which is the UNC path to the printer queue. The substring value should be set to the same value as in the Path for the printer mapping and delete under the main properties for the setting.
There, now you know how to use Group Policy Preferences to map and remove printer queues for users based on their physical location to the printer even if you have user configured with a roaming profile. The default printer mapping will still follow the user no matter where they logon to however as we are limiting this to only one printer this will not have a large affect on the users logon speed nor will it result in the collection of printer mappings from multiple areas.
Technorati Tags: Group Policy Preferences,Printer,Roaming Profiles,Tutorial,How to
How to schedule a delayed start logon script with Group Policy
Logon Scripts!!! I hear you yelling at me about why I am doing a tutorial about logon scripts when Group Policy Preferences is supposed to allow me to stop using my logon scripts. Well in a utopian world there would be no logon scripts to maintain however there are still some situations that you might have to execute a program…
How to use Group Policy Preferences to Secure Local Administrator Groups
One problem I keep seeing again and again is that IT administrator seem to never control who is a local administrator of a computer. The problem is that when someone is a local administrator on a computer they have full control and stopping them from doing the wrong thing is very hard and it is even harder to discover who is in the local admin group because you have to query every computer to find this out. So how do you give a user full admin access to a computer but stop them from adding more people to the local admin group on a computer? Use Group Policy Preference of course.
But first a bit of History… Since Group Polices were first introduced with Windows 2000 there was an option called “Restricted Groups†which allows you to control the membership of a group. This option had two modes the “Members†option which I also call the “Iron Fist†option and “Members Of†option which is much more gentler option. The “Members†option removes any groups or users that are not explicitly specified and the “Members Of†option just adds a specific group which out removing any existing groups. The “Members†option was really good at cleaning up those rogue members of the local admin group but its was also really hard to setup as you had to have a new group policy every time you wanted a different list of members in local group on a computer. The “Members Of†option was a lot easier to maintain as you could layer multiple group policies on top of each other but this normally resulted in just adding another layer of group to the pile of groups that were already in the local administrators group. The other problem was the “Members†option would override the “Members Of†option so there was really no way of mixing the two modes.
Well the good news is that Group Policy Preferences has Variables therefore this allows you to be very extremely granular in controlling you local admin group while still having “Iron Fist†control. Muuhhaaaahahahahah!!!
How do I setup a restricted local administrator group?
The following steps will need to be applied pretty much to any computer that you want to use Group Policy Preference to control the local administrator groups. Remember however that you must make sure you don’t have any Group Policy “Restricted Groups†settings applied to your computers as they will always override any group policy preferences settings.
Step 1. Open the Group Policy Management Consol and edit the group policy that is applied to the scope of computers that you want to control.
Step 2. Go to the Computer Configuration > Preferences > Control Panel Settings > Local User and Groups option (see Image 1.).
Image 1. Local User and Group
Step 3. Now click on Actions > New > Local Group
Step 4. Now you will be need to select “Administrators (built-in)†from the group name as this allows you to secure the built-in administrators group even if you have renamed the group to obfuscate the name to enhance security on your computers.
Step 5. Tick both “Delete all member users†and “Delete all member groupsâ€. These two options will automatically remove any users or groups that are not explicitly being added to the group. You only need to do this on item number 1 in the list of settings as that setting will be processed last.
Step 6. Now you will need to make sure you have added back in the Domain Admin’s and Local Administrator groups so that you don’t totally local yourself out of the computer. To do this click the “Add…†button to bring up the “Local Group Member†dialogue box (see Image 2)
Image 2. Local Group Member
Step 7. Now type “BuiltIn\Administrators†in the Name field and click OK (see Image 3.)
Image 3. Local Administrators group added to the local administrators group
Step 8. Now as you computer is a domain added machine you should also added the Domain Admin’s group into the local Administrators group as best practice. But this time we are going to use some special Variables to ensure that you always add the correct group. So Click “Add…†again and now click in the “Name:†text field and then press F3. This will now bring up the “Select Variable†dialogue box (See Image 4.). Click on the “DomainName†field and press “Select†and then “OKâ€. (alternatively you could type %DomainName% in the name field and just press OK.)
Image 4. Selecting the DomainName Variable
You should now see the the following which will now restrict the local administrator group on any computer this policy is applied to only have the Domain Admins and the local Administrator in the local Administrators group on that computer.
Image 5. Basic local administration group setting
SO WHAT? Your right… You can do this already with the “Restricted Groups†Group Policy setting and only having the local Administrator and Domain Admin’s in the local admin group is not not much use unless you are willing to give everyone the local admin password or give them all Domain Admin’s privileges (Like that ever happens) which is a major no no. Well this is where Group Policy Preferences comes to the rescue as you can now create another preference that will merge with the above list of allowed groups which I will go into below.
How to add individuals to a single computer?
Now we are going to go thorough how to add a uniquely named domain group to the local administrators group easily and without the need for setting up multiple group policies. This scenario is very helpful if you want to grant a single user or group to the local administrators group on a single computer but still ensure that no other users or groups are added without explicitly being approved. Say for example the computer name is DESKTOP01 and the domain name is CONTOSO we will then want to add the group “CONTOSO\DESKTOP01 Administrators†to the local administrator group but we also want the same to happen on DESKTOP02, DESKTOP03 and so on, each with their own uniquely named group based on the computer name.
Step 9. First go back and repeat steps 1 to 6 until you get to the Local Group Member dialogue box (see Image 6.)
Image 6. Add Local Group Member
Step 10. Type “%DomainName%\%ComputerName% Administrators†in the Name text field and click “OKâ€. Now you should see something similar to (Image 7.)
Image 7. Configuration to automatically unique group to local administrators group
Now this will now automatically add a domain group called “DOMAINNAME\COMPUTERNAME Administrators†to the local administrators group on the computer to which the policy is applied.
This group policy setting combined with the other setting made earlier (see Image 5.) will mean that the local administrator group on the computer DESKTOP01 in the CONTOSO domain will have the following members automatically added to the group:
CONTOSO\Domain Admins
DESKTOP01\Administrators
CONTOSO\DESKTOP01 Administrators
But ANY other users or groups will be automatically removed after the next group policy refresh. This does mean there is a slight window of opportunity for someone to slip in an un-authorised account into the local administrators group but normally this gets cleaned up before they realise what is going on. The great thing about doing this is that the users almost never complain as they realise what they are doing and BIG BROTHER must have been watching them and removed their access.
However the “CONTOSO\DESKTOP01 Administrators” group will only be added to the local administrators group on the computer DESKTOP01 if that group is already exists. Therefore you do not need to create the group until the need arises to add an individual user or group to just a single computer.
AWSOME!!!! I hear you say… but wait there is more…
How do I add additional broader groups to the local administrators group?
Now that you are able to granuarlly add a single user or group to the local administrators group on a computer you might run into problems id you have more than a 1000 computers due to AD Token Bloat Issues . So to get around this we can setup some more broadly applied administrator groups to the computer that will give admin access to only a subset of computers such as workstations or perhaps only the SQL Servers in your organisation.
Workstations Admin Groups
To apply a Workstation administrators group to the local administrators group on all workstations make sure you have a group policy only targeted to your workstations. This is normally pretty easy as most companies isolate their workstations computer accounts to one (or a select) number of Organisational Unit.
Step 11. Go back and repeat steps 6 and 7 but this time add the group “%DomainName%â€\Workstations Administrators†in the name field. This will added the additional group “CONTOSO\Workstation Administrators†to the local admin group on all the workstations in your domain which will allow you to easily add all the Desktop Administrators in your organisation access to all the workstations without having to give them the local admin password or domain admin’s privileges.
Server Role Admin Groups
In these steps we are going to automatically added a domain group called “CONTOSO\SQL Server Administrators†to all the servers you have that have SQL Server installed on them. This will be very handy to making sure SQL service accounts or database administrators have admin access to all the servers that have Microsoft SQL Server installed
Step 12. First make sure you are editing a group policy that is applied to all your servers in your organisation.
Step 13. Now repeat Step 9 and 10 and then we open the properties of the new policy setting and specify the group but this time we type “%DomainName%\SQL Server Administrators†in the name field.
Step 14. Now click on the “Common†tab and then tick “Item Level Targeting†and click the “Targeting…†button.
Step 15. Click on the “New Item†in the menu bar and select the option you want to use to target all the SQL servers in your organisation. This could be an Organisation Unit that has all the computer accounts of all the SQL servers in the organisation OR a security group that has all the SQL Servers computer accounts as members.
But for this example we are going to select the “File Match†option to look in the Program Files folder and see if a sub-folder exists called “Microsoft SQL Servers†(See Image 8). This is normally true for any server that has Microsoft SQL Server installed and so it will then automatically apply the SQL Server Admin group to that server if it was installed.
Image 8. Testing to see if Microsoft SQL Server is installed.
Now any computer that SQL Server, MSDE or SQL Express installed will get the group “CONTOSO\SQL Server Administrators†automatically added to the local admin group.
This really nice thing about this is that if SQL is installed on the server at some point in the future the SQL Admin group will be added automatically at the next group policy refresh without you having to do a thing.
Finally now you have tight control of the local administrator groups on all the computers in your domain it is now important to monitor and secure the domain groups that are being added to the local administrator groups as they are now control who has admin access to all your computers. But I will save how to do that for another blog post…
Alan Burchill
How to use Group Policy Preferences to change account Passwords
If you are using the Group Policy Preferences to apply local user account be aware there is a security risk in doing this. In short the passwords are stored in the AD SYSVOL encrypted using AES however the encryption key is well known so this could only be considered obfuscated at best…. More info about this can be read at http://blogs.technet.com/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx
However using Group Policy Preferences to set passwords on local user accounts is still extremely useful and one could argue that not changing the local administrator account password is potentially more of a security issue over time. So if you still want to use this option but want to mitigate the risk in using this feature then here are a few steps that can be taken that will help.
Before you start tell as few as people as possible when you are changing the passwords. This is important as if you tell people when the password is changing they will know when to look for the password stored in the SYSVOL.
Step 1. Change default group policy refresh period to be as short as you dare (see Image 1). The default is 90 minutes but if you can safely crank it down 5 or 10 minutes that would be better. This will speed up the propagation delay of the new password once is configured in the group policy.
Image 1. Changing the default group policy refresh
Step 2. Some time during the middle of the day create a new group policy object and configured the the new local user password option (See image 2). then wait for the setting to propagate.
Image 2. Configuring the Local Account Password
Step 3. Then you need to wait… How long? The formula i would use for the time to wait is as follows:
Max Active Directory Propagation Delay + Max Group Policy Refresh Interval
Therefore if it take 16 minutes for Group Policy changes to propagate to all DC’s in the domain and you have set group policy refresh to 10 minutes the formula will look like this.
16 minutes + (10 minutes + 2 minutes) = 28 minutes
Note the 2 minutes is to take into account the 20% offset that group policy refresh interval has from the set value.
Step 4. Then one you have waited for the new password setting to rollout DELETE the group policy password setting you configured. This will purge the obfuscated version of the password from the SYSVOL. The reason also I recommend you create and delete a new group policy each time you do this is so the password file is store in a different path in the SYSVOL which is just another way to make it harder for someone to file the password file.
Step 5. You may want to repeat steps 4, 5 and 6 a couple of days apart to ensure that you have applied the setting to all the computers that were not turned on or connected to the network the first time (sounds like a great reason to deploy Direct Access).
Step 6. Finally don’t forget to wind back the default group policy refresh interval to its original value.
Now as we are all good IT Professional it would be best to tell people that the local admin password has changed and will be disseminated securely (NOT via email or IM) when needed. The key is to do it quick and then remove the policy as soon as you are done to have the smallest window of opportunity as possible for someone to grab the password file.
Of course this sound very devious and some could say you are covering your trails by deleting the policy once you are done which is not something you generally want to do as a good IT Professional… But if you are going to do this in a organisation then your are probably going to need to follow change control anyway so you should still have an official record of what you have done.
Alan Burchill
How to configure Group Policy to use Data Recovery Agents with “Bitlocker to Go†drives – Part 2
As I previously mentioned in Part 1 “use Group Policy to save “How to use BitLocker to Go†recovery keys in Active Directory – Part 1†one of the cool new features in Windows 7 is the ability to encrypt removable storage devices to help prevent the loss of data within an organisation while storing a copy of the decryption key in Active Directory. Another way to encrypt the removable storage devices and still have the ability to recover a encrypted devices if the unlock key is lost is to use a Data Recovery Agent digital certificate.
Now before you begin you first need to have deployed you a PKI infrastructure in your organisation so that you can issue the data recovery certificate to your nominated recovery agents.
So lets get started…
How to configured Group Policy to use a Data Recovery Agent with “BitLocker to Go†drives
Issuing the EFS Data Recovery Agent
First you need to create/issue at least one account with the Data Recovery Agent certificate that will be used for when encrypting all the Bitlocker to Go drives.
Step 1. Click Start, and then type certmgr.msc to open the Certificates snap-in
Step 2. In the console tree, expand Personal, and then click Certificates.
Step 2. Right click on Certificates and click on All Tasks and then Request New Certificate…
Step 3. Click Next to the first page of the Certificate Enrollment wizard and then then click on Active Directory Enrollment Policy and click Next
Step 4. Tick the EFS Recovery Agent policy and then click Enroll
Step 5. Click Finish once your account has enrolled as the EFS Recovery Agent certificate.
You should now see the File Recovery Certificate in you Personal Certificate store.
Exporting the DRA Certificate
You now need to export the DRA certification information to be used in the BitLocker Drive Encryption group policy in a future step.
Step 1. Double-click the BitLockerDRA certificate to display the certificate properties sheet.
Step 2. Click the Details tab
Step 3. Click Copy to File
Step 4. Click Next on the Welcome to the Certificate Export Wizard page
Step 5. Leave the No, do not export the private key selected and then click Next.
Step 6. On the Export File Format page, verify that DER encoded binary x.509 (.CER) is selected, and then click Next.
Step 7. On the File to Export page, click Browse to display the Save as dialog box. In File name, type BitLocker. In Save as type, verify that DER Encoded Binary X.509 (.cer) is selected, and then click Save to return to the File to Export page.
Step 8. The File name box on the wizard page should now display the path to the BitLocker.cer file in your document library. Click Next.
Step 9. On the Completing the Certificate Export Wizard page, verify that the information displayed is correct, and then click Finish.
Step 10. When the certificate has been exported, the Certificate Export Wizard dialog box will be displayed with the message The export was successful. Click Close to close the dialog and the wizard.
Configuring the Bitlocker Data Recovery Agent in Group Policy
In this section we are going to take the Data Recover Agent certificate we exported above and import it into the group policy to apply to computers that will have DRA certification for encrypting Bitlocker drives. The screenshots below are from a Windows Server 2008 R2 server with the group policy management console installed but if you are on a Windows 7 computer you will need to have install the Remote Server Admin Tools installed.
Step 1. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.
Step 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
Step 3. In the console tree under Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Public Key Policies, right-click BitLocker Drive Encryption, and then click Add Data Recovery Agent to start the Add Recovery Agent Wizard.
Step 4. Click Next on the Add Recovery Agent Wizard welcome screen
Step 5. On the Select Recovery Agents page, click Browse Folder
Step 6. Browse to the location you have a copy of the BitLocker.cer file that you exported in the previous procedure select the certificate and click Open
Step 7. Click
Note: You can repeat this process as necessary to add multiple data recovery agents. After all data recovery agent certificates you want to use have been specified, click Next.
Note: The example above has USER_UNKNOWN because the DRA file was manually imported.
Step 8. On the Completing the Recovery Agent Wizard page, click Finish to add the data recovery agent
Below is the BitLocker Drive Encryption setup with a DRA installed.
Additional Group Policy Configuration
BitLocker Identification Field
You now need to configure the BitLocker Identification field on all the computers you are going to use Bitlocker on as this helps identify what removable devices belong to your organisation.
Step 1. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.
Step 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
Step 3. In the console tree under Computer Configuration\Administrative Templates\Windows Components\Bitlocker Drive Encryption and then double click on Provide the unique identifiers for your organization
Step 3. Enter you specific Bitlocker identification name that you use to identify your Bitlocker encrypted devices in the BitLocker identification field
Note: You can add additional Bitlocker identifiers from other trusted organisations in the Allowed BitLocker identification field
Enable Allow Data Recovery Agent
Continuing on from above you will need to configure you computers to Allow the Data Recovery Agent option.
Step 4 (cont.). In the console tree under Computer Configuration\Administrative Templates\Windows Components\Bitlocker Drive Encryption\Removable Data Drive and then double click on Choose how Bitlocker-protected removable drives can be recovered , then you will need to click Enabled and tick Allow data recovery agent then click OK
Note: You still have the option of configuring the standard AD recovery keys in this window. The Allow Data Recovery Agent option as far as I can tell has no bearing of the other options.
You have now configured Group Policy to use a Data Recovery Agent certificate to be used to encrypt all the “Bitlocker to Go†drives in your organisation.
How to unlock a “BitLocker to Go†drive with a Data Recovery Agent
Below are the instructions explaining how to use the Data Recovery Agent to unlock a BitLocker to Go encrypted drive
Step 1. Put the drive into the computer you want to unlock.
Step 2. Right Click on a Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
Step 3 (optional). If you want to get information on the volume before you unlock it you can run manage-bde -status E:
Step 4. Now you need to get the “CertificateThumbprint†of the drive you want to unlock type the command manage-bde –protectors –get E: where E: is the volume you are trying to unlock
Note: Take a note of the Data Recovery Agent (Certificate Based) Certificate Thumbprint (see circled in red).
Tip: You could also mark the thumbprint by using the Edit > Mark option of the command prompt.
Then select the thumbprint by clicking on the first character of the thumbprint and dragging to the last character.
Step 4. To unlock the drive, type the following command Manage-bde –unlock E: -cert –ct 88d07b2874031569e17eedf402e0a098fc0f7b81
You have now successfully unlocked the drive using a Data Recovery Agent.
Note: You will need to have the Data Recovery Agent Certificate (with the private key) installed in the Personal certificate store on the computer you are performing this task.
Step 5 (optional). Try getting running the following command again to view more information about the drives encryption manage-bde -status E:
Form more information about BitLocker drive encryption with Data Recovery Agents see the following pages:
Microsoft TechNet: Configuring the BitLocker Identification Field (Windows 7)
Microsoft TechNet: Using a Data Recovery Agent to Recover Bitlocker-Protected Drives
Microsoft TechNet: Using Data Recovery Agents with Bitlocker
How to use Group Policy to save “BitLocker to Go†recovery keys in Active Directory – Part 1
One of the cool new feature in Windows 7 Ultimate and Enterprise is the ability to encrypt USB devices with a password to protect the data from falling into the wrong hands. One of the problem with this is that if a user were to ever forget the unlock key then they will need to remember where they kept the recovery file or paper print out of the 48 digit recovery key. Now for a consumer this feature this might be fine as you keep can keep the key in a fire proof safe or even a locked filing cabinet but if you are managing this in a corporate environment you might have to keep track of thousands or even ten’s of thousands of these devices to keep track of the recovery key.
Well there is where group policy can be your saviour…. of course!
In Part 1 of this “how to†I am going to show you how to setup the recovery key archiving into Active Directory. In Part 2 I will show you how to use Group Policy with Active Directory Certificate Services to enable a Data Recovery Agent so that all your devices can be recovery using a single EFS recovery agent account.
Part 1
Using group policy you can mandate that all encrypted removable device must first have the recover key stored in Active Directory before they start to encrypt. This ensures that for any USB encrypted devices in your organisation that you will always have the ability to unlock the data on the drive even in case that someone forgets the unlock password.
Now before we begin there are a few pre-requisites that we need to cover to make sure this work.
1. You Active Directory must be running the Windows Server 2003 R2 scheme extensions. But I hear you say “you said that Group Policy Preferences doesn’t need schema changes to work†well yes… this is still true it is not a group policy requirement it is a BitLocker requirement.
2. You should install the “BitLocker Drive Encryption Administration Utilities†with Windows Server 2008 R2 or with the RSAT tools for Windows 7 (see image 1.) on at least one computer in your organisation. This computer can then be used to search for and view the recovery keys if you ever need them. This is a new tool with 2008 R2/Windows 7 and makes it MUCH easier to read the recovery keys than back in the 2003 R2/Vista days.
Image 1. Installing “BitLocker Drive Encryption Administration Utilitiesâ€
How to configured Group Policy to save the Recovery Key?
Now before I go on I will assume that you are already familiar with Group Policy so all I am going to cover is the key (pardon the pun) policies you need to ensure the recovery keys are backed up to AD DS for all your removable USB storage devices in your organisation.
Step 1. Edit the group policy that you have applied to all your workstations and navigate to Computer > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives. Here the two policies you need to enable are “Deny write access to removable drives not protected by BitLocker†and “Choose how BitLocker-protected Removable drives can be recovered†(see Image 2).
Image 2. Removable Data Drives BitLocker Drive Group Policy
Step 2. When you Enable the “Deny write access to removable drives not protected by BitLocker†also tick the “Do not allow write access to devices configured in another organization†option (see Image 3). This setting is important as it will make any non-BitLocker encrypted devices from being written to in your organisation thus bypassing the whole reason to use BitLocker.
Image 3. Deny write access to removable drives not protected by BitLocker
Step 3. Now Enable the “Choose how BitLocker-protected Removable drives can be recovered†and make sure that the “Save BitLocker recovery information to AD DS for removable data drives†and the “Do not enable BitLocker until recovery information is stored to AD DS for removable data drives†are both ticked (See image 4.). This setting ensures the computer has successfully saved recovery key into AD before encrypting a USB storage device.
Image 4. Choose how BitLocker-protected removable drives can be recovered
You may also want to consider ticking the “Omit recovery option form the BitLocker setup wizard†as this will prevent you users from saving the recovery key manually which might be desirable if you don’t trust them to store the key in a safe place.
Because of the “Do not enable BitLocker until recovery information is stored to AD DS for removable data drives†option has been ticked if the user tries to encrypt a new USB storage device when not connected to the corporate network then they will get the following error message (see image 5).
Image 5. Error saving recovery key
If the user is out of the office they will need to establishing a VPN connection or enable BitLocker on the device the next time they are in the Office. This would not be a problem if you have configured Direct Access but this is a post for another time.
Note: The loop hole to this is that if someone already had a BitLocker to Go encrypted device and plugs it into a computer they will be able to save information to the device. This does not mean the data will not be encrypted its just you wont have the recovery key if they forget the password to that particular device.
To help with this problem you can set the BitLocker identification field on all the computers in the organisation so they will reject all encrypted devices that don’t have the same identification field value. This setting is under Computer > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption called “Provide the unique identifiers for your organization†(see image 6.). This might sound like you can mandate outside memory sticks can’t be used in your organisation but if someone has set the identification field to the same value this would get around option.
Image 6. Provide the unique identifiers for your organization
How to recover the BitLocker recovery password in AD?
So you have deployed BitLocker to your organisation and you have told everyone to be careful to remember the passwords but of course your manger has come to you saying that they have forgotten the password for his USB memory stick and it has the only copy of some really important files on it that he has have for a meeting tomorrow.
What do you do?
Step 1. First we need to identify the USB devices Recovery key identifier by plugging it into a computer running Windows 7 Ultimate/Enterprise. You can then find this identifier by clicking on the “I forgot my password†option (see image 7.)
Image 7. I forgot my password
Step 2. Then write down the 8 characters of the recovery key identifier (See image 8.)
Image 8. Recovery key identifier
Step 3. Now go to the computer that you installed the “BitLocker Recovery Password Viewer†tool that I previously mentioned above launch “Active Directly Users and Computers†MMC snap-in with and account with Domain Admin privileges. Click on the domain name that will have the recovery key saved and then click “Action†and then “Find BitLocker Recovery Password…†(see image 9.).
Image 9. “Find BitLocker Recovery Password…â€
Step 4. Now type the first 8 characters you wrote down in step 2. and click “Search†(See Image 10.). This will show you the Recovery Password in the Details pane that you will need to unlock the drive.
Image 10. Find BitLocker Recovery Password…â€
Step 5. Now go back to the computer you have plugged the USB device into and click on “Type the recovery key†(see image 7.).
Step 6. Now type the 48 digit Recovery Password into the text box and click “Next†(see image 11.)
Image 11. Enter your recovery key
Step 7. Click OK and you will now be able to read the required file off this drive (See Image 12.).
Image 12. You cannot save file on this drive
Note: If you want to restore the drive back to normal you will need to go to the control panel and go into the “Manage BitLocker†option to “Turn off BitLocker†(see Image 13.) on the device and then go back and select the option to “Turn On BitLocker†again. This will completely reset the recovery key on the device making the one you just recovered totally invalid.
Image 13. Control Panel BitLocker Drive Encryption option
Part 2 can now be found here “How to configure Group Policy to use Data Recovery Agent to encrypt “Bitlocker to Go†drives – Part 2”
How to use Group Policy Preferences to manage Windows Power Plans
One of the new feature of Group Policy Preferences in Windows 7 and Windows Server 2008 R2 is support for configuring power plans using preferences for Windows Vista and later (see Image 1). You used to be able to control power management in Vista using native policies however the advanced targeting of preferences now enables lot of new scenarios with power savings. AWSOME!
Image 1. Creating a new Windows Vista and Later Power Plan
One of the really neat things that you can do with Group Policy Preferences (GPP’s) and Targeting is change the power scheme of a computer based on the time of the day and the day of the week. This allows you to apply more aggressive power plans to your workstations after hours but then then back off during the day when people are working. Even though that Windows Vista (and Windows 7) support adaptive display time out which backs off the screen saver timeout when a user is still sitting at a computer but not actively using it they still have to wake up the computer by before the timeout started to back off. Applying the less aggressive power plan during working hours means that the user is less likely to have to keep waking up their computer in the first place as you have configured longer time out values.
Now if this sounds familiar you’d be right as I did demo some of this during my TechEd Australia Group Policies session that I did with Lilia Gutnik and it is similar to the TechNet Edge video by Michael Kleef and Mark Gray. But in this article I am going to diving a lot deeper than my demo or in the TechNet Edge video.
So before we talk about how to do this first lets go over what we are trying to achieve. We are assuming you manage a fleet of workstations that are only used during standard business hours and afterhours you want the computers to go to use as little as power as possible. You want to apply different power plans to the computers not only based on the day of the week but also the time of the day to make sure you get maximum possible power savings (see Image 2).
Image 2. Example power plan timetable
So to do this we setup two separate power plans, with one that is applied by default all the time and the other one that will take precedence and apply during business hours.
How to setup the Default Power Plan Policy
Step 1. Create a Power Plan under the User Configuration option of a GPO that has has aggressive power savings configured without any targeting other than being applied to all the users you want to control the power plans. I will leave the exact details of the power plan up to you but I will recommend that if you are going to set the “Sleep†timeout for Windows Vista (or greater) then make sure you also enable the “Allow hybrid sleep†option (even on your desktops) (see Image 3.) as this will protect your computers from data loss if you lose power to your office environment afterhours.
Image 3. Enable hybrid sleep mode
Step 2. Rename the item to be called something like “Default Power Plan†(see Image 4) and also make sure that it is always set to order number one.
WARNING – If you do this make sure you either immediately disable the item (tool bar > red circle “disable this itemâ€) or setup the Business Hours Power Plan straight away so that you don’t start shutting down all your computer during the middle of the day.
Image 4. Default Power Plan at Order 1
How to setup the Business Hours Power Plan Policy
Step 3. Create another Power Plan setting item called “Business Hours Power Plan†(see Image 5.) making sure it is lower order than the default power plan. Again I will leave the exact settings up to you but this one should be less aggressive than your default power plan.
Image 5. Business Hours Power Plan
Step 4. Now go into the properties of the “Business Hours Power Planâ€
Step 5. Click on the Common Tab and tick “Item-Level Targetingâ€
Step 6. Click on the targeting button
First of all we are going to create a collection that will target the Business House Power Plan to only the weekdays of the week.
Step 7. In the targeting Editor click on “Add Collection†(see Image 6.)
Image 6. Creating a targeting collection
Step 8. Click on the “New Item†and then click on “Date Match†(see Image 7 & 8.)
Image 7. Creating a Date Match rule
Image 8. Date match rule before being dragged into a Collection
Step 9. Now you will need to drag the “AND the day of the week is Sunday†onto the “the collection is true†and change the day to “Monday†(see Image 9.)
Image 9. Date Match rule after being dragged in the collection.
Step 10. Now make sure that “the day of the week is Monday†is highlighted and click CTRL-C once and CTRL-V four times to copy and paste the date match rule once for each weekday (see Image 10).
Image 10. Five date match rules in one collection
Step 11. Now click on each of the “AND the day of the week is Monday†and press F6 to change each date match rule from and “AND†to a “OR†and then change the days to Tuesday , Wednesday, Thursday and Friday (see Image 11).
Image 11. Data Range Collection configured to apply only during weekdays
Now we will add a Time Range option that will refine when we target the Business House Power Plan to just working hours of the weekdays.
Step 12. Click on the “this collection is true†and then click on “New Item†and then click on “Time Range†(see Image 12).
Image 12. Adding Time Range to targeting
Step 13. Now configured the time range to when during the day you want to Business Hours Power Plan to apply (see Image 13).
Note – Make sure you allow for the policy refresh interval (default 90 minutes with a 20% random offset) when configuring the start and end time. This means you might want to start applying the policy 2 hours before the start of business (e.g. 6:30am) to make sure all the computers are configured with the Business Hours Power Plan before people login in the morning (e.g. 8:30am).
Image 13. Targeting configured with Date Range collection and a Time Range
Now you have configured a Group Policy Preference to apply less aggressive power plans to your computer during business hours while still having more aggressive power plans applied after hours.
Other Option – More user Control
In the example above we just modified the “Balanced†power plan setting when we wanted to make changes to the power settings. If you did not want to give your users some more control and not force specific power plans you could just select the “High performance“ plan and tick “Set as the active power plan†for the Business Hours Power Plan (see Image 14) and the “Power Saver†plan as active in the Default Power plan (see Image 15).
Image 14. Setting the High Performance plan as active
Image 15. Setting the Power Saver plan as active
This way your users can still configure each of the power plans to their own preference but you will still make sure that the “Power Saver†plan will be applied to your computers after hours. However as you are only setting which plan is active then your users could get around the power plan as by configure both plans to never time out thus negating the benefit of any of the plan’s.
Other Options – Less aggressive Default Power Plan
You may also want to set the default power policy to be less aggressive by default and then apply the aggressive power as the second item in the list using a little more complicated targeting (see Image 16). The advantage of this method is you can easily turn off the aggressive power savings plan when you want to do afterhours by just disabling the “Afterhours Power Planâ€.
Image 16. Targeting to apply plan only afterhours
How to make Adobe Reader 9 more secure using Group Policy
Update: I have since reposted this article with new registry keys that makes configured Adobe updater a lot easer. Check it out at  https://www.grouppolicy.biz/2010/06/updated-how-to-make-adobe-reader-more-secure-using-group-policy/ Recently there have been a number of critical security issues that have been associated with Adobe Reader (see below). http://securitygarden.blogspot.com/2010/04/critical-adobe-and-adobe-acrobat-update.html http://securitygarden.blogspot.com/2010/01/adobe-readeracrobat-critical-update.html http://securitygarden.blogspot.com/2009/10/adobe-reader-and-acrobat-critical.html http://securitygarden.blogspot.com/2009/05/critical-update-adobe-reader-and.html http://securitygarden.blogspot.com/2009/12/critical-adobe-pdf-vulnerability.html http://securitygarden.blogspot.com/2010/01/adobe-readeracrobat-critical-update.html http://www.adobe.com/support/security/advisories/apsa09-07.html To see a complete list of current updates for Adobe…
