Posted in Best Practice Tutorials

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

Continue Reading...
Posted in News Tip

Get TechNet Subscription 28% discount with promo code

Microsoft has just released a new TechNet Subscription discount code for any IT Pro that wants to evaluate and test Microsoft software. This is a great way to get your hands on and test Microsoft software for a business to make sure its the right solution for your needs. If you are a Group Policy Administrator this is a great…

Continue Reading...
Posted in Security Setting of the Week

Group Policy Setting of the Week 11 – Prompt for password on resume from hibernate /suspend

The setting of the week this time highlights the one and ONLY power management policy that has been around since Windows 2000. The “Prompt for password on resume from hibernate / suspend” can be found under User Configuration > Administrative Templates > System > Power Management. Until Windows Vista came along this was the only power management setting that could…

Continue Reading...
Posted in Best Practice Tutorials

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…

Continue Reading...
Posted in News Security

KB978207 (MS10-002) Internet Explorer “Google China” patch is out now

As I have previously mentioned there has been a lot of press lately where some hackers took advantage of some holes in IE and Adobe Reader to hack Google’s systems in China. As a result Microsoft have burnt the midnight oil and rushed out an Out of Cycle patch for Internet Explorer to resolve this issues even thought this issues…

Continue Reading...
Posted in Best Practice Security Tutorials

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

Continue Reading...
Posted in Other Site Links

Automate Group Policy Preferences printer-management using Windows PowerShell

Jan Egil’s has just written a good blog post explaining how to use Power Shell with Group Policy Preferences to easily setup multiple printer connections. If you have ever had to make printer connections with Group Policy Preferences you will know that it is a real easy to copy a printer connection. However it is a real pain to then…

Continue Reading...
Posted in Setting of the Week

Group Policy Setting of the Week 10 – Remove Default Programs link from the Start menu

This weeks group policy setting of the week is about the “Remove Default Programs link from the Start menu” option that can be found under User Configuration > Policies > Administrative Templates > Start Menu and Taskbar. The start menu entry “Default Programs” was was introduced as part of the United States v. Microsoft Antitrust settlement case back in the…

Continue Reading...