How To Prevent Devices From Installing in Windows

One of the most underutilized feature in Windows for home users has got to be group policy. Anything that you can think of when it comes to administering and securing the operating system is laid out in group policy settings. With that being said though, one could argue that many home users really don’t need to configure their home computers at all hence why group policy is never used. This is true being how most casual users don’t need a reason to block access to the Control Panel or requiring users on the same computer to see the same wallpaper upon each and every log on. Enterprises and businesses however, love group policy. As an administrator, I could easily configure some group policy settings on a Windows server operating system and push those settings out to 1,000 client machines all without me having to manually configure them on each and every computer. It doesn’t matter if those machines are in different geographic locations. Group policy is a flexible and proven infrastructure for administrators to configure their Windows clients. One question I’m sure many users have asked themselves at one point or another is it possible to actually restrict/prevent the installation of certain hardware devices so that users can’t use them? The answer to this question is a definitive yes! With group policy, many things are actually possible in Windows and so we’ll take a look at just how we can prevent the installation of certain devices on a Windows machine in this article.

Just What is Group Policy?

Group policy is without a doubt my favorite feature in Windows. This feature dates back to as far as Windows 2000 and with each new iteration, Microsoft has provided more and more policies for administrators/users to play with. One of the main purposes of group policy is locking down a computer to just the way you want it to be. There are literally thousands and thousands of group policy settings that you can configure, although you obviously wouldn’t need to touch each and every one but just the settings that apply to your scenario or business needs. However, group policy can be as simple or as complex as you want it to be. I’ve actually written an introduction on this subject matter and I highly recommend you go over it to gain some beginner’s knowledge before proceeding with the rest of this article.

Introduction to Local Group Policy Objects: Part 1

Introduction to Local Group Policy Objects: Part 2

In Part 2, I went over the concept of Multiple Local Group Policy Objects. Here however, device installation restriction is a computer side configuration and not user side. Therefore MLGPO’s do not apply although I’d still recommend reading about it if the technology of group policy interests you.

Why Restrict Devices on Local Machines?

This is a very valid question. The answer though is it really depends on your situation. In organizations, companies have the headache of dealing with a myriad of user devices. Devices such as smart phones, tablets and USB drives have made it very convenient for a user to simply plug the device in and save data to it. I’m sure you’ve seen a movie where the bad/good guy sneaks his way into a company headquarter, plugs in a simple USB device and within seconds, they now have all of the top secret documents and plans to drive that company into the ground or to use for blackmailing. Many organizations that require a high level of secrecy are required to make sure that data and documents can only be accessed on internal computers and only on internal computers. Once those data makes their way onto a thumb drive, either maliciously or accidentally by a user, then that secrecy is breached and many headaches will ensue. To prevent this from happening, those organizations need to prevent users from installing devices onto their own machines in the first place.

As a casual user, you’ve probably now regretted reading up to this point in the article because you realize that this problem does not apply to you. If however, you are in charge of administering a small lab environment or for example a cafe where you provide computers for public use, restricting device installations can be a good idea just as long as you understand that doing so might cause users to be quite upset with you! By restricting some or all devices to be installed, you have reduced the attack surface of your computers. If a malware infested USB drive gets plugged in to the system, there is a very good chance that the malware will not spread because if the USB driver doesn’t get loaded, then the system basically won’t recognize the USB device and therefore, prevent the USB device from getting installed. As a regular computer user, have you ever had the need to share a computer with more than one person? Have someone installed a device onto that computer that caused the computer to behave strangely? Well, this is the perfect scenario to uninstall that device and prevent it from ever loading again.

How Device Installation Restriction Works

At a high level, the really only important thing that you must always remember is that in order for a hardware device to work properly on a system, there must be a corresponding driver to accompany it. Think of the driver as the software that allows your Windows machine to communicate with the actual physical device. If you have some type of hardware but can’t find the appropriate driver/software for it, then you’ve basically just have in your hands a piece of hardware device. By itself, it may look pretty and sophisticated but without the software to allow the computer to interact with it, then the device is practically worthless. When upgrading operating systems, many users are afraid for the fact that their current devices might not work on the new operating system. It could be that their device is very old and the manufacturer simply refuses to support it anymore. By not creating a new device driver for the new operating system, the user is basically left with no choice but to not upgrade to the newer operating system.

Restrictions ApplyWhen you plug in that new USB device you’ve just purchased, what basically happens is the computer will query the device to see what type of hardware it is. The device in return will provide information such as its hardware ID and other sorts of useful data to the computer that will help identify itself. The computer will use this information to see if it has a compatible driver installed to use for communication with that specific device. There are many ways to identify a device to a computer system. The most specific would be the hardware ID that specifically identifies that device for what it is. With this specific hardware ID, there can be no mistake as to what that device actually is or who made it. However, the computer sometimes won’t have a specific device driver for that specific device! If Windows actually included every single device driver for every single device ever made, you would need a very big hard drive to install Windows on because the size required would be tremendous! Instead, what Windows can do in these circumstances is use a generic device driver instead. For example, the computer could figure out what type of device class or group the hardware belongs too by looking at the compatible ID. I’m sure you are aware that there are many, many different types of USB thumb drives in existence today. However, they all work in the same fashion for the most part. Therefore, the computer system can load a very generic USB driver for those devices. The good news for doing so is that you as the user won’t have to worry about hunting down a specific device driver for each and every hardware device you plug in to the system. The disadvantage however is that when you have more advance devices like a $500 inkjet printer, while the generic driver does allow you to print to the device, it won’t allow you to perform more advanced functions. For that to work, you will need to use the manufacturer provided device driver for that specific printer model.

Device Installation Restriction Settings in Group Policy

I am performing this demo on a Windows 8 machine but all the steps and group policy settings are the same for Windows 7 as well.

There are 10 different group policy settings that pertains to device installation restrictions. The good news is that not every single one will apply. The group policy settings is located in:

Computer Configuration/Administrative Templates/System/Device Installation/Device Installation Restrictions

Policy Settings

Let’s go over each one briefly, although each policy setting already have a good description for it by default :

Allow Administrators to Override Device Installation Restrictions: This allows a user who is also an administrator on the computer to bypass device installation restrictions. Ideally, you should be the only administrator on the local machine and each and every other user accounts are standard users. If those other users also have administrative permissions, they can easily disable the group policy settings you’ve configured here.

Allow installation of devices using drivers that match these device setup classes: A device setup class you can think of as a bunch of similar devices grouped together. Device class GUID (globally unique identifiers) entries entered in this policy will be allowed to install.

Prevent installation of devices using drivers that match these setup classes: Device GUIDs entered here are disallowed from installing. Prevent policies have higher priority over allowed polices. If a device class GUID is configured for both allow and disallow policies, then the devices will not be allowed to install.

Display a custom message when installation is prevented by a policy setting: If a user tries to install a device driver in Device Manager, you can configure a custom message for the user to see. You can usually ignore this setting as Windows provides a default message.

Display a custom message title when device installation is prevented by a policy setting: Similar to the above policy but allows you to configure a custom message title instead. You can usually ignore this setting unless you wish to provide a custom title.

Allow installation of devices that match any of these device IDs: Specific hardware and compatible IDs (not setup classes) you enter in this policy will be allowed to install.

Prevent installation of devices that match any of these device IDs: Specific hardware and compatible IDs you enter in this policy are forbidden from being installed.

Time (in seconds) to force reboot when required for policy changes to take effect: When there is a change in device installation restriction policies, the computer will forced to reboot after the time configured in this policy. Home users can usually ignore this setting.

Prevent installation of removable devices: This ‘catch all’ policy setting forbids any device driver that lists itself as “removable” from being installed. This policy will forbid a device from being installed even if the specific device ID is configured as ‘allowed’ in other policies.

Prevent installation of devices not described by other policy settings:  This ultimate restriction policy restricts any new devices from being installed unless they are specifically configured in a ‘allowed’ policy. Think of this policy setting as the ultimate device smack down on device installation!

Where Do I Start?!

If you read the actual description for the restriction policies, some of them are only valid if another setting is enabled. Here are some scenarios I can think of:

Preventing all removable devices from installing – This one is pretty easy. Just enable the “Prevent installation of removable devices” policy and you’re good to go. As long as the driver is considered removable and have not yet been installed on the machine, this policy will block the driver from being installed. The bad news is that if you rely solely on this policy to prevent removable devices from installing, there are some devices that you may think is “removable” but the driver it uses it not. Therefore, the device will be able to install.

Prevent all devices from installing – This drastic scenario prevents all new devices from being loaded. If you really do not want your users to install any new devices into the system (not just removable drives, mind you), then you would enable the “Prevent installation of devices not described by other policy settings”.

Prevent all devices from installing with exceptions – Here, you want to prevent all unknown devices from getting installed except for those you deem appropriate. First enable the “Prevent installation of devices not described by other policy settings” policy. Next, configure the hardware IDs or device setup class GUID in the “Allow installation of devices that match any of these device IDs” or the “Allow installation of devices using drivers that match these device setup classes”, respectively. What happens here is that the devices you define in these two “allow” policies will be the exception. If a device itself or the device setup class it falls under is not defined, then the device will be blocked from installing.

Preventing only certain devices/classes from installing: To prevent specific devices or classes from installing, simply configure them in the appropriate “prevent” policies either for the hardware IDs or device setup class policy. For example, if you have a printer that is known to cause havoc on the system when installed, you can specifically block that printer from being installed. All other devices that does not match that printer ID or if it does not fall under its setup class will be allowed to install.

Notes to Consider Before We Start

Before we begin playing around with device installation restrictions, there are a couple of things you need to take into consideration:

– When restricting devices based on hardware/compatible IDs and setup classes, you have the option of preventing devices that have already been installed on the system from loading again. For example, if a user has already connected and installed the driver for the Amazon Kindle device on the system prior to you configuring device installation restrictions, then that means the driver has already been loaded. When you apply the restriction policy to specifically restrict the Kindle from installing, you can specify in the policy to also apply the policy to matching devices that have already been installed. This will immediately force Windows to unload the driver and the user will not be able to use the device again.

– When you apply broad restriction settings such as preventing all removable devices from installing or the policy setting to prevent all devices from installing, devices that have already been pre-installed will able to continue functioning even after the policies have been applied by group policy. For example, if a user plugged in a USB drive to the system prior to the setting of preventing all removable devices from installing takes effect, the user will still be able to use that thumb drive. In order to actually prevent devices that have already been installed from working, you will need to manually uninstall the driver in device manager. This can be a challenge if you don’t actually have that specific device on hand. More on this later.

– If you are serious about deploying device installation restrictions in your production environment, it is imperative that you absolutely perform test after test to make sure that the results are indeed what you are looking for.

– Device installation restrictions is rendered useless if a user has the ability to boot into another operating system. Group policy only takes effect when the computer has booted into the Windows environment. Once the system is booted into a Linux or alternative operating system, it’s all fair game.

Page 2: Device Installation Restrictions –>

VN:F [1.9.22_1171]
Rating: 3.7/5 (3 votes cast)

Pages: 1 2

Group Policy Fundamentals, Security, and the Managed Desktop Review

One of my main love for network administration is group policy. Group Policy technology has grown with each new edition of Windows dating back to Windows 2000. With the introduction of Windows 7 and Windows Server 2008, there are now over 6000+ group policy settings for administrators to play with! While Group Policy Fundamentals, Security, and the Managed Desktop by Jeremy Moskowitz doesn’t go over each and every of those group policy settings with you, his book is really about teaching and helping you, as the group policy administrator, how to efficiently manage your organization’s myriad of group policy objects as well as troubleshooting techniques should things go awry. It doesn’t matter if you are new to the group policy game or not because this book has something for everyone.

When you are reading a technical book, one of the most basic things that will put your mind at ease is to know that it was written by a professional. Well, Jeremy (our author) is a professional and this book is very well written and very easy to follow. As long as you have some basic understanding of Microsoft Active Directory networks, you should be able to follow this book from start to finish. You’ll learn what group policy actually is, what it consists of, how to properly administer it, what to do and what not to do in certain circumstances, etc. Group policy is definitely a big subject matter. Therefore, do not expect to become a master of group policy just by reading this book. However, you’ll still walk away with a ton of knowledge and information to help you better your career when it comes to group policy administration. You can easily follow along through the examples in the book by setting up a mini test lab to perform your group policy experiments. The author will then throughout the book use the same setup to show you the effects of group policy. Therefore, if you want to get the most out of this book, it would be best if you can spare 2-3 computers to dedicate as your test lab. If you don’t have that many physical computers to spare, then you can choose to host virtual machines, providing that your host computer can handle the load. At the minimum, you’ll want to have a Windows Server 2008 computer to serve as your domain controller and a Windows 7 machine to serve as both your management station and client computer. If possible, you’ll also want to join a Windows XP client to the mix as well.

Throughout the book, Jeremy will list many other web resources to get more information on the subject matter at hand. One such website is one that he actually maintains himself and is a great source for group policy materials, Group Policy Answers. Once you register on the site, you’ll have access to many awesome group policy related materials including bonus chapters of this book for download. Other great resources listed include The Group Policy Hub where you can download free group policy tools along with watching free training videos, PolicyPak where you can try out the awesome group policy tool (also created by our author) meant to cover some of the main drawbacks and disadvantages of using the default group policy technology in Windows, and Specops where you can also download other free and paid group policy tools to help you and your organization further expand on the group policy technology.

If you are looking to get into group policy or already have and want to just further your knowledge on it, Group Policy Fundamentals, Security, and the Managed Desktop is an excellent pickup and one that no one should miss!

Purchase here:
Group Policy: Fundamentals, Security, and the Managed Desktop


VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Introduction to Local Group Policy Objects: Part 2

In the first of this two part series, I gave an introduction on Local Group Policy Objects. I explained why you would want to configure a computer’s LGPO, especially if you are tasked with managing them in a unsecured or public location, and how how easily it can be done. Basically, if your computers are not joined to a Active Directory domain which provides centralized administration and you needed some way to lock down those systems, you most likely needed to work with Local Group Policy Objects. In this second article, I will be explaining the concept of Multiple Local Group Policy Objects (MLGPO) along with the why’s and the how’s. I highly suggest you read over part 1 before continuing on.

The Limiting Factor of LGPO

Beginning with Windows 2000 and ending with Windows XP, LGPO’s were very linear and inflexible in nature. Configure the LGPO and it basically applied to everyone using the system, regardless of whether the user had administrator privileges or not. If you were using the computer, the LGPO applied to you whether you liked it or not. This was evident in our example demonstrated in part 1. When I applied the “Prevent changing window color and appearance” policy setting in the LGPO, it immediately prevented me from changing the Window Color scheme in the Personalization applet. This is great and all from a security stand point but I am the administrator of that computer! There was no way for me, by default, to say, only have the setting apply to standard users and exempt administrators. This might not seem like a problem for standard users (as most of the policy settings are to restrict them) but if you are the administrator, you’ll quickly find that some policy settings restrict the way you manage the computer as well. Remember, a LGPO applies to everyone. Here is a very simple example. Let’s say I wanted to prevent users from utilizing the Run command box. I enable the policy titled “Remove Run menu from Start Menu”, which is located in User Configuration/Administrative Template/Start Menu and Taskbar. Now, all users including myself, the administrator, will not be able to open a Run command box along with not being able to type in UNC paths in Internet Explorer to access shares on other computers. Here is the error message I receive when I hit the Windows key + R and try to access my local computer via UNC format in Internet Explorer:


As you can see, the results is exactly what you want to see for standard users who you don’t want messing around with your computer but if you are the administrator, just this policy setting alone can cause a lot of frustration. Being able to use UNC paths to connect to network resources in your workgroup is very important for administrators. With these and other restrictions enabled, do you configure the LGPO to temporarily disable these settings, perform the work needed as a administrator and then re-enable those settings again? Or do you simply find a work around? Well, these were the problems and questions many administrators had to face during the Windows 2000 and Windows XP era when it came to configuring a local computer’s LGPO.

Until now.

Introducing Multiple Local Group Policy Objects

Beginning with Windows Vista, Microsoft introduced the idea of MLGPO for stand-alone workstations. The concept is very easy to grasp. Rather than just having one level of configuration for a given computer, you can now have well, multiple levels instead hence the name MLGPO! This allows for a more granular control over how you configure a workstation in your environment. With MLGPO, you now have 2 or 3 more levels of configuration, depending on how you look at it. I’ll explain them here beginning with the least granular to the most granular configuration level.

1. Standard LGPO. This is the configuration level I have so far been referring to in both articles. Every policy setting configured at this level will affect everyone who uses the workstation, regardless of user account status.

2. Administrator/Non-Administrator. This is the level where all the magic happens. As the name implies, you can now configure two separate LGPO’s. One LGPO can be applied only to user accounts with administrator privileges on the workstation and the other LGPO will be applied only to non-administrator user accounts. It is important to understand here that Non-Administrators basically means everybody else NOT in the built-in Administrators group. Even Backup Operators and Power Users are considered Non-Administrators in this scenario.

3. User specific. For the most granular control, you can now append a separate LGPO to any user account created on that workstation! For example, if a user falls somewhere between a administrator and a standard user (Power Users, for example), than configuring a user-specific LGPO for just this one user account is now possible.

There is a catch though, sorta. By using other configuration level OTHER than the default LGPO, you can only configure policy settings in the User Configuration section of the LGPO. The Computer Configuration section is removed (you will see an example of this later). However, this really can’t be considered a disadvantage because with the Computer Configuration portion, you usually configure security and account policies in general that apply to the computer as a whole anyways. For example, you would configure Account Policies (like password settings and account locout) along with Local Policies (User Account Control, auditing) which apply to the computer as a whole. It is in the User Configuration portion that holds most of the settings you’ll want to configure relating to user accounts (people who actually log in to the computer) in general because it is the most granular and provides the most control, especially in the Administrative Template folder. You will have a better understanding of this after learning about MLGPO precedence described next.

User Configuration Only

MLGPO Processing and Precedence Order

With the new capability to create more than one LGPO, processing them also takes a new turn. Before MLGPO showed up, a workstation needed to process just one LGPO and call it a day. However, with multiple LGPO’s in the picture, how does the processing method change as well? Very simple. It’s called precedence order. Basically, a LGPO have a link order value applied to it which the computer uses to determine which one to apply first, second, and so on. The LGPO that is least specific will have a link value higher than one’s that is more specific. When speaking of MLGPO, we have three LGPO link values to determine (the values basically stay the same so don’t worry there). We have the LGPO, the Administrator/Non-Administrator LGPO and the user specific LGPO. So, the link values for them will look like this:

User specific LGPO = Link value 1
Administrator/Non-Administrator LGPO = Link value 2
LGPO = Link value 3

First the LGPO will be applied because it is the least specific. Then, whether if you are an administrator or non-administrator and if you have a LGPO configured for that level, it will apply next. Lastly, if there is a LGPO configured specifically for a user account, then that will apply last. Precedence is important if you have more than one LGPO with same policies configured. However, this really shouldn’t be a problem when speaking of a stand-alone workstation. Unlike computers connected to a Active Directory domain in where dozens of GPOs can be applied to a computer or user account, here in a workgroup environment, you only have to worry about one or two at most. Policy conflicts occur when two different LGPO levels applying to the computer/user having the same policy settings configured but with different values. For example, if the LGPO has the policy setting to disallow changing of wallpaper enabled but the Non-Administrator LGPO (which the user logging in is a part of) has the policy setting set to disabled, than what happens? To solve this conflict, we go back to precedence order. The most specific LGPO will win the conflict. Because the Non-Administrator LGPO is more specific and has a lower link value, the policy setting will be set to Disabled and the user will be allowed to change the wallpaper. However, you’ll see soon that you really shouldn’t be dealing with policy setting conflicts in a small workgroup environment.

MLGPO Possibilities

Now that you have a better understanding of how MLGPO operates, let’s take a look at some of the possibilities of when you should use MLGPO:

A) Separating administrators from others. As written earlier, one of the biggest headache of configuring LGPO prior to Windows Vista was due to how it applied to everyone on the computer. With the introduction of the Administrators/Non-Administrators separate LGPO, most if not all of the problems disappeared just like that. In most small workgroup environments, you were either a administrator or you were a standard user. Because you wanted to only limit what standard users were able to do on the computer and not the administrators themselves, all you have to do now is simply configure the Non-Administrator LGPO and that would be it! The standard users will be restricted while you, the administrator, will still be able to log in and perform whatever administrative tasks needed because the Non-Administrators LGPO doesn’t apply to you.

B) Special users. Think of them as users that should have different policies applied to them, rather more restrictive or more relaxed than the rest. For example, let’s say you’ve configured a pretty restrictive LGPO for Non-Administrators. Bob, who is in the Power Users group, needs many of the restrictions taken off but some to remain because he doesn’t have the need to join the Administrators group just yet. In this case, you can configure a specific user LGPO for just Bob’s user account with the specific settings.

As you can see, these two scenarios match the two new LGPO levels introduced in Windows Vista. Although we have more granularity, LGPO is still limited in scope. However, that should be obvious because Microsoft needs to make money as well and providing centralized management in a workgroup environment doesn’t give much incentive for other smaller businesses to upgrade to a domain environment! But that’s a debate for another day and another article.

Configuring MLGPO

Alright, it’s time to get down to business and see how to actually configure the different levels of LGPO. As you’ll see, it’s not hard at all.

1. By default, opening the Local Group Policy Editor by typing in gpedit.msc into your Start menu’s search bar only allows you to configure the default LGPO (link value 3) of the computer. You know, the one that will apply to everyone. Here, you’ll usually want to configure settings only in the Computer Configuration section. Remember, both Administrator/Non-Administrator and User Specific LGPO only allows you to configure the User Configuration settings. The Security Setting’s policy portion is where you’ll mainly want to look in.

Security Settings

2. Now, we will be configuring the Administrators/Non-Administrators LGPO. What we need to do is open up a blank MMC (Microsoft Management Console). Simply hit your Start Menu and type in MMC in the search box. Once you have the blank console opened, hit File –> Add/Remove Snap-in. You will now be presented with all the available snap-in’s to add to your custom console.

Adding Snapin

Scroll through the list until you find the Group Policy Object Editor snap-in. Select it and hit the Add button. The Group Policy Editor wizard should then appear. Hit the Browse button. We need to instruct the snap-in to focus on a specific LGPO level. So, in the next window, select the Users tab. Here you’ll see a list of all the users on the local computer along with the Administrators and Non-Administrators group. In my example, I will add both the Non-Administrators group and the user account for my sister, Jennie. Hit OK and then Finish.

You’ll have to re-add the snap-in and browse for the each target one by one. In the end though, they will all be present in that one console for you to configure. It’s a good idea to save the custom console so you don’t have to manually add the snap-in each time you need to configure the LGPO in the future.

Local Users and Groups
Specific User

3. It’s always easier to configure policy settings from least specific to most specific. So, I’ll go ahead and configure the Non-Administrators group first, which my sister’s user account is a part of. In this test, I’ll disable the ability for Non-Administrators to peek in the Programs Control panel. Basically, I don’t want them to view/uninstall/change/repair a program or the other abilities as listed in the description of the policy setting.


Since I am the administrator, this policy will not effect me. As evident, I can roam around in the Programs Control panel as if nothing changed.

Admin Not Effected

Now, let’s head over to her account and see what happens.

Policy In Effect

As expected, she is denied access.

4. Now, let’s pretend I have many other standard users on the computer and I want all of them to be denied in the Programs Control panel except for my sister. I will now configure a specific LGPO linked to only her user account with the same setting as above, but set to Disabled this time around. If you haven’t already, you must first add the LGPO targeting the specific user in your MMC console by following the steps listed earlier. Once in the console, you drill down to the settings under the specific user portion of the LGPO. In my example, I will disable the setting. Keep in mind, I did not re-alter the Non-Administrators LGPO. The policy setting in that LGPO is still set to Enabled. Now, let’s log on to her account again and see what happens.


Once again, we got the desired results. Why? It all goes back to precedence order, remember? The most specific LGPO will win out against the least specific LGPO when there are conflicts.

Some Notes to Remember About LGPO

Careful planning. As with all things, careful planning of LGPO implementation in your workgroup environment will on be to your benefit. You wouldn’t want to just randomly disable/enable a policy setting just because you have the power to do so. Think about each and every setting before making the final decision. If you have several computers that need the same LGPO configuration, it is best to keep some type of documentation on all the settings you have made. Because LGPO is ‘local’ to speak of, you will need to manually configure each and every LGPO on each workstation. This can be time consuming but once they are set, you really don’t have to touch it again unless changes need to be made.

Keep it simple. Like mentioned earlier, most workgroup environments consists of just administrators and standard users. Therefore, in most cases, you’ll mostly want to restrict just standard user accounts and leave the administrators alone. By configuring just the Non-Administrators LGPO, you’ll have that accomplished. For other users that fall in between, you can consider configuring a user-specific LGPO. Remember that if you set restrictions for the Administrators group LGPO, other administrators configured on that same workstation can equally disable them if they have the knowledge. Therefore, take careful consideration in who you give full power to!

Workarounds. Just because you’ve enabled some policy setting doesn’t mean it’s final. Some users are smart enough to actually find methods to bypass or work-around the restrictions you have put in place and it can hurt you if you don’t take them into consideration. For example, just because you enabled the policy to remove the Run box from the Start Menu doesn’t prevent someone from opening a command prompt to run the desired commands for them. Just because you removed the Programs Control panel doesn’t prevent users from uninstalling programs via the program’s uninstaller executable or from a third-party uninstaller application. Locking down Internet Explorer is a good practice but if you allow users to use other third party browsers like Firefox or Google Chrome, those settings will be worthless.

Read the description. I can’t stress about this enough. Although we like to think we know everything, that’s usually not the case! Just because a policy setting seems simple enough by reading just the name of it, enabling it can have other effects as well. Using the remove Run menu from Start Menu policy setting again as an example, enabling this will also deny users the ability to type in UNC paths (\servershare) in Internet Explorer’s address bar. You certainly wouldn’t have figured that out just by reading the policy setting itself!

Read the requirements. This is another huge point to remember when configuring LGPO. Each policy setting has a requirement in which operating system version(s) it can apply to. For example, the Remove Run Menu from Start Menu setting has a requirement of ‘At least Windows 2000’. Therefore, Windows 2000 and above operating systems (XP, Vista, 7) can have the setting be applied to it. However, policy settings in User Configuration/Administrative Templates/Control Panel/Add or Remove Programs mainly have settings that apply only to Windows Server 2003, XP, and Windows 2000. That means enabling these settings on a Windows Vista or Windows 7 machine will have no effect whatsoever.

In the End…

I hope everyone reading this 2 part article series on Local Group Policy Objects will get some sort of idea on how powerful (although limited in scope) it can be for workstations in a workgroup environment. Hey, not everyone has the money to dish out for a Windows Server 2003/2008 server and licensing. In fact, in certain scenarios, deploying one can actually do more harm than good. Sometimes, we just want something simple and effective in locking down systems. With the introduction of MLGPO configuration, local administrators have much more freedom in choosing how to lock down workstations they manage without being affected themselves on the same computer. What’s not to like about it?

VN:F [1.9.22_1171]
Rating: 4.5/5 (2 votes cast)

Introduction to Local Group Policy Objects: Part 1

Have you ever used a computer whether in a cafe, kiosk, or just about any other public location when you had the sudden urge to do a little ‘exploration’? For example, ‘s say you wanted to visit the Task Manager to see what’s going on with the computer when all of a sudden you find out you can’t access the Task Manager applet! You calm down for a bit and decide to head into the System Properties menu to see how much RAM and CPU juice the computer got. Just like that, you find out that you can’t access that as well! What in the world is going on? You most likely should have already realized that although you are logged in as a standard user, you should still be able to access both the Task Manager and the System Properties menu. Well, you’re correct in that sense. However, you didn’t think Microsoft would ship a operating system without some way of letting people (usually the owners or administrators) locking it down, right? And before you smart bunch answer back, I’m clearly talking Windows 2000 and beyond! Dears readers, welcome to the awesome world of what can be considered one of Microsoft’s greatest operating system technology and feature, Group Policy.

This article is mainly intended for computer users/owners/administrators that need a way to secure their computers in a workgroup environment. For example, if you are in charge of a couple of computers in a computer lab where random students come and go, or computers in a public location like kiosks, you can utilize Local Group Policy to lock down those systems and maintain better control over them. Many casual home users have no need to configure Local Group Policy settings. However, if your main computer is shared by many others in your household and you are the sole person responsible for the welfare of the system, you can also utilize Local Group Policy for better control. Local Group Policy has been a feature within the Microsoft operating system since Windows 2000.

What is Group Policy?

Have you also ever wondered how companies seem to manage the hundreds and thousands of computers and users in their organization? Well, not surprisingly, the answer to that is Group Policy as well. Hopefully by the end of this article, you’ll see just why. The topic of Group Policy (GP) is definitely a huge one and to gain a complete understanding of it certainly requires one to venture way beyond what you read here. GP is a technology that allows central configuration of computers and users in a Microsoft network. If you are familiar with how the registry works, than you already have a head start. For example, when you configure some settings in the Control Panel, behind the scenes, you’re actually altering your registry because that is where all of your computer settings are stored and read by the computer. Because the registry is considered hands-off for casual users (or basically anyone who doesn’t know what they are doing), Microsoft allows us to work in the registry area via a GUI (graphical user interface) which is much more user friendly and less prone to errors.

With GP, it can be considered the same to some degree however, GP allows for much, much, much, more deeper customization than just the Control Panel offerings or any other interface for that matter. To put it another way, GP is the central location for configuring a computer. From controlling how a desktop behaves, security controls, configuring certain Microsoft applications like Internet Explorer, what the user/computer is allowed and not allowed to do, to what the user see’s or doesn’t see, GP is the key to everything. Here is a sample picture of the Local Group Policy Editor. Notice all of the settings that I can configure on a computer relating to just Internet Explorer application in the Delete Browsing History category:

Group Policy Settings

How Local Group Policy Works

Now that you have a little understanding of what GP is, let’s see talk about how it works. Every time you power-on your computer, it processes the Local Group Policy Object (LGPO). In simple terms, think of a LGPO as the file containing all of the settings that may or may not have been configured in the Local Group Policy Editor. Because I am referring to a stand-alone computer in this article, the computer by default, only processes the Local Group Policy Object (one file, in simple terms). As I’ll explain later on though, with the release of Windows Vista and Windows 7, we now have the option of configuring multiple LGPOs on the same local machine. If your computer was connected to a Microsoft Active Directory domain, a computer would usually process a lot more GPOs.

In a LGPO, there are two major sections, although they both produce the same results. The first section contains GP settings that pertains to your computer’s account. In a nutshell, settings configured in this section applies to everyone who logs on the computer, regardless whether you are an administrator or standard user (once again, this changes with Vista and Windows 7 as I’ll explain in part 2 of this article). The second section contains GP settings that applies to user accounts on the computer. Because we are not talking about Active Directory domains and organizational units here, the user configuration portion of a LGPO will also apply to all user accounts who log in to the computer, regardless of status. Basically every setting you configure, no matter which section, will apply to anyone and everyone who logs in to the computer. Despite what you’re thinking, the two sections do contain different settings. With a default installation of Windows, most of the settings and policies in your LGPO configuration is set to Not Configured. This makes sense because you wouldn’t like Microsoft locking you out of some part in your operating system would you?!

Computer and User Configuration

Local Group Policy settings that you configure are stored in the %systemroot%>system32>grouppolicy folder. You will see two folders labeled Machine and User. Each of these two folders stores the appropriate settings you’ve configured in the Local Group Policy Editor for each respective section. Every time your computer boots up or during logon, these files are read to apply the appropriate policy settings. If you have many computers in your environment that requires the same LGPO settings, you’ll have to manually configure each and every LGPO on each and every stand-alone computer. However, if you copy the contents of this folder to the same location on the target machine (export,import), you might be able to get away with it. However, this is not recommended and the method is not supported by Microsoft so try this hack on your own. Once you’ve imported the files to the target machine, reboot the computer for the changes to take effect. However, many settings don’t migrate over with this hack and needs to be configured via another management tool. In the end, it’s best to manually configure every machine. Just be sure to create a checklist of all the settings you’ve made in your base LGPO so that you won’t have to remember them all! Chances are, you’ll forget a policy setting or two when configuring the other machines and so you’ll have to revisit each one again at a later time to reconfigure the LGPO properly.

Group Policy Files

How to Configure Local Group Policy

Alright, let’s try and configure some Local Group Policy settings to see how it affects our computer. By seeing the results of configuring an LGPO, it should hopefully give you a better understanding of the technology.

1. To begin configuring our LGPO, all we need to do is open the Local Group Policy Editor. Do so by first opening your Start Menu and typing in gpedit.msc and hitting Enter. If the UAC prompt appears, accept it or provide an account with administrator privileges.

2. The Local Group Policy Editor should then appear. You should now see the two sections I’ve mentioned earlier. What I failed to mention before is that there are basically thousands of options to configure. Therefore, the hard part is actually finding out where the setting you want to configure is located. You can usually ignore the Software Settings folder in both sections. Under Computer Configuration, you will be most interested in the Windows Settings/Security Settings policies and the Administrative Templates policies. Under the User Configuration portion, stick with the Administrative Templates as most of the policies you’ll configure will be located there. Remember though, every setting/policy you configure will apply to every person logging into the computer.

In our simple example, let’s try enabling the “Prevent changing window color and appearance” policy. Once enabled, all users should then be denied the privilege of changing the Windows color theme via the Personalization Control Panel or elsewhere. In the policy editor, drill down to User Configuration/Administrative Template/Control Panel/Personalization to find the policy. Once you highlight the policy, notice what is written in the Description panel. This is very useful because there will be times when you’re not quite sure just what the setting or policy does so reading the description will help you a lot. Trust me.

Group Policy Configuration

3. To enable the setting, simple double click on it first. Next, click on the Enabled radio button to configure the policy and hit OK to apply it. Other settings might require you to add or choose other pieces of information before it can be enabled.

Enable or Disable

4. Sometimes a setting configured in the policy editor may not take effect immediately. Therefore, to instruct the computer to refresh the LGPO, we need to use the gpupdate command. Fire up a command prompt window and enter in the gpupdate command. Alternatively, you could simply just type in the command in the Search box of the Start menu and it will have the same effects. Also, there are some settings that require a re-login or even a computer restart before the configured policy settings to take effect. Basically if entering the gpupdate command didn’t do the trick, logoff and log back in. If nothing happens still, restart your computer. If still nothing happens, you’ve most likely configured the wrong policy setting.

Group Policy Update

Now, let’s head into the Personalization menu and see what’s changed! Here is an before and after shot:


As you can see, I (along with any other user that logs in) no longer have the option to change/customize my Windows color theme! This is perfect because if you go back to step number 2, this is the exact setting we chose to configure/enable. That means everything worked like it suppose to! By also disabling the ability to change themes, Windows color, screensavers and/or desktop wallpapers, you’ve gotten the personalization category pretty much locked up from abuse by random users.

The Possibilities with Using LGPO

There are certainly many aspects of your local computer that can be controller via configuration in the LGPO. When it comes down to everything, it’s about experimenting. Some policy settings are very granular in nature so you have to be sure that the setting, when Enabled or Configured, does exactly what you want it to do. If you have a lot of stand-alone workstations to configure, it is best to test out all of your LGPO settings on one machine first. This way, you’ll be able to see if everything works accordingly before making the same changes to the rest of the workstations. Remember, you’ll have to manually configure each LGPO on each workstation (unless you go with the import and export hack mentioned earlier). If you applied the same settings on every computer and later find out that it’s not what you actually wanted, you’ll have to revisit each computer and manually reconfigure the settings again!

In the End…

Although very limited in scope, configuring LGPO’s to accommodate your computing environment and situation can still be very helpful for stand alone workstations. Not only can you lock down settings you don’t want to be changed, as seen in our personalization example above, more importantly, we can more tightly secure the computer via many of the security options and policy settings as well.
What I have demonstrated here is just a really, really, small example of what LGPO can do for you. Like I’ve said earlier, there are many policy settings for you to configure. Sometimes (actually, most of the time is more like it) it can be difficult to find the exact setting we are looking for. Therefore, my advice to you is that when in doubt, Google it!

In the second part of this article, I’ll be talking about how to utilize and take advantage of Multiple Local Group Policy Objects on your workstation computer, which is a new feature in Windows Vista and Windows 7.

Read Part 2 to Learn About Multiple Local Group Policy…

VN:F [1.9.22_1171]
Rating: 4.8/5 (2 votes cast)

Creating a Custom Windows Logon Message

This is a neat little trick that allows you to create your own personalized logon message for your computer users. Although this is mainly used in corporate environments, there is nothing preventing you from taking advantage of it on your home computers as well as other computers you manage as well. Creating a custom message allows you to relay a note to all of your users before they logon to the computers. This reminder of sort can of course be customized to your liking. For example, you can remind users that there will be consequences if they download illegal material or if they use it to browse explicit sites on the computer. As you can imagine, this is a perfect way for companies to remind their corporate users that they are being monitored and that they shouldn’t do anything ‘bad’ on the computer. You can treat this as a legal warning as users can’t use the excuse that they ‘didn’t know’ the rules beforehand. The custom message will always appear before logon and the ‘OK’ button must be pressed in order to continue.If you work in a computer lab or have to manage a group of computers where users come and go, this is one way to notify the users of your most strict house rules. However, this is only a message and the user can immediately click on the OK button to close out the message and continue with their usual logon procedures. Therefore, you’ll want to make the message short and right to the point.

In the last article, I wrote about laptop theft and encryption. However we may actually accidentally lose our laptop instead. Not all people are bad in this world and some actually want to return the laptop to its rightful owner but have no way of contacting them. You can create a custom logon message (in hopes that they at least turn it on once and get to the logon screen) with your contact information and maybe offering a small cash reward in hopes that the person will do the right thing.

Configuring Your Message

This trick can be configured in Windows XP, Windows Vista, and Windows 7 but depending on which edition you have, the steps may vary. The custom logon message can be configured in both Group Policy and in the registry. Because Windows XP Home and Windows Vista Home (and lower editions) don’t have a group policy editor, you’ll need to configure the setting in the registry.

Windows 7 Professional/Ultimate, Windows Vista
Business/Ultimate, Windows XP Professional

Group Policy can be considered a front-end interface to the registry. Therefore, the options you set in Group Policy is actually editing the corresponding registry keys behind the scenes.

1. Open a Run box and type in gpedit.msc.


2. Once the Group Policy editor opens, drill down to the two group policy settings as shown in the picture.

Logon Message

3. Double click on the ‘Interactive Logon: Message title..’ to type in the title or header of your message. This is not the main body text so do not type in your entire message here!
Next, open the ‘Interactive Logon: Message text..’ setting. It is here that you type out your message to your users. Remember, you generally want to make this short and sweet.

Message Title
Message Text

4. Restart your computer and behold your new custom message!

Logon Message

Windows XP Home, Windows Vista Home Premium/Basic

The Registry plays a very vital role in a computers operation. One wrong tweak can render a system completely un-bootable! Therefore, it is of utmost importance that you make a backup of the registry by creating a system restore point! I will not be held responsible for your system should anything go wrong by following these registry tweaks.

1. In Windows XP Home, open a Run box and type in regedit. Do the same if you are using Vista.

2. For XP Home, you’ll want to drill down to:
HKEY_LOCAL_MACHINE – SOFTWARE – Microsoft – Windows NT – CurrentVersion – Winlogon

For Vista, drill down to:
HKEY_LOCAL_MACHINE – Software – Microsoft – Windows – CurrentVersion – PoliciesSystem

Once you are in place, look for two registry keys called LegalNoticeText and LegalNoticeCaption, which corresponds to your message body text and message tittle, respectively. Double click on the key and type in your data in the ‘Value data’ box.

3. Once finished, close the registry and reboot your system. Your message will appear at the logon screen.


While creating a custom logon message is quite pointless if you’re the only one using the computer, if your job requires you to manage public computers (computer lab, public library computers, college lab computers, corporate computers etc), this is a good and simple method of relaying simple rules and other warnings that users should know about before using the computer.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)