Policy is applied when the computer starts up. When a user turns on the computer, the system applies DeviceLock’s policy.

Policy can be optionally reapplied on a periodic basis. By default, policy is reapplied every 90 minutes. To set the interval at which policy will be reapplied, use the Group Policy Object Editor. For more information, refer to the Microsoft Knowledge Base at support.microsoft.com/kb/203607.

Policy can also be reapplied on demand. To refresh the current policy settings immediately, administrators can call the gpupdate.exe /force command-line utility provided by Windows.

When applying policy, the system queries the directory service for a list of Group Policy Objects (GPOs) to process. Each GPO is linked to an Active Directory container to which the computer or user belongs. By default, the system processes the GPOs in the following order: local, site, domain, then organizational unit. Therefore, the computer receives the policy settings of the last Active Directory container processed.

When processing the GPO, the system checks the access-control list (ACL) associated with the GPO. If an access-control entry (ACE) denies the computer access to the GPO, the system does not apply the policy settings specified by the GPO. If the ACE allows access to the GPO, the system applies the policy settings specified by the GPO.

Any unconfigured settings anywhere in a GPO can be ignored since they are not inherited down the tree; only configured settings are inherited. There are three possible scenarios:

If a GPO has settings that are configured for a parent Organizational Unit, and the same policy settings are unconfigured for a child Organizational Unit, the child inherits the parent’s GPO settings. That makes sense.

If a GPO has settings configured for a parent Organizational Unit that do not conflict with a GPO on a child Organizational Unit, the child Organizational Unit inherits the parent GPO settings and applies its own GPOs as well.

If a GPO has settings that are configured for a parent Organizational Unit that conflict with the same settings in another GPO configured for a child Organizational Unit, then the child Organizational Unit does not inherit that specific GPO setting from the parent Organizational Unit. The setting in the GPO child policy takes priority, although there is one case in which this is not true.

If the parent disables a setting and the child makes a change to that setting, the child’s change is ignored. In other words, the disabling of a setting is always inherited down the hierarchy.

When the Windows BitLocker To Go option is enabled (see Encryption), the DeviceLock Service can prevent the application of administrative templates from GPOs, because this option prevents enabling the Group Policy setting “Deny writing to removable drives not protected by BitLocker” in Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Removable Data Drives. As a result, any Group Policy with a conflicting value for this setting will not be applied to the computer.

To resolve this issue, disable the option Windows BitLocker To Go (enabled by default). If DeviceLock Service settings come from a GPO or from a server policy object (see DeviceLock Enterprise Server Policies), then the Windows BitLocker To Go option must be explicitly disabled in that object; otherwise, this option will be set by default, that is, it will be enabled. If using local settings for the DeviceLock Service, just disable this option in the DeviceLock Management Console.