Our last article about Loopback Policy Processing probably left you with some questions unanswered. Questions like:
- What’s the difference between merge and replace?
- Does Loopback require a reboot?
- Is this setting a per GPO kind of thing or a per computer kind of thing?
- Is there a downside to loopback?
- Are there any special permissions with loopback?
- Why do I have to make loopback sound so creepy?
So without further ado, your Loopback Policy Processing questions – answered!
What’s the difference between merge and replace?
Loopback policy processing has two modes: merge and replace. When loopback is set to merge mode, user side settings that are linked to computer objects are interwoven with the user’s normal RSOP. This mode is great when you have user side settings but you don’t know where your user will log in. For example, you might have a printer in a lab that needs to be the default printer for every user in the lab. You will need to use loopback in merge mode for situations like this.
Loopback policy processing in replace mode as a more specific role. In any case that I’ve seen, replace mode is used for kiosk machines. When you have a kiosk machine (such as a terminal), you generally do not want any user side settings as they might interfere with the kiosk. Replace mode will prevent the user’s normal RSOP from being applied.
Does Loopback require a reboot?
When you enable loopback, you’ll enable it under Administrative Templates. This is a policy (registry) based CSE. Most settings under Administrative Templates do not require a reboot to take effect. When you enable loopback in a GPO, it will take effect on the very next GPUpdate. Building on that, any GPO using loopback will also apply on that very same GPUpdate.
Is this setting a per GPO kind of thing or a per computer kind of thing?
This is common point of confusion with loopback. If you create a GPO named “Enable: Loopback Policy Processing” and link it to your domain, every computer in your domain is “loopback enabled”. Any user side settings linked to a computer will apply on the next GPUpdate.
If you will only need loopback within a few GPOs, enable the setting within that GPO only. To make troubleshooting easier, I will also prefix the GPO name with Loopback. For example, I might have a GPO named “Loopback: IE Settings”. If you plan to use loopback a good bit, you might want to create a general “Enable: Loopback Policy Processing” GPO and link it to the computers needing it.
Is there a downside to loopback?
There are two downsides. First, loopback increases the complexity of Group Policy processing. This will make troubleshooting more difficult if a problem ever crops up. Second, loopback will slow down Group Policy processing.
When we first started using loopback in our environment, we had our domain logon scripts linked to the domain… When a user logged in, they would process the logon script. Because loopback was also enabled, the computer also processed the logon script. This noticeably slowed down our logons. Of course, this downside can be mitigated by properly planning your GPO links and security scopes.
Are there any special permissions with loopback?
In order for Group Policy to process, the object (computer/user) must have certain permission to the GPO. The object must be able to read and apply the GPO. If you have a GPO requiring loopback (and your OS is Vista+), both the user and computer will need to read/apply the GPO. If the GPO is scope to Authenticated users, you are good to go. If not, be sure to add a security group (or two) that contain the objects.
Did I answer all of your questions about loopback? If not, leave me a comment below and I will write up an answer!