Active Directory

The Tiny and The Behemoth

Last week I was having a discussion with a colleague (@LupoLoopy) regarding Group Policy processing times and the ago old question of do you create a small handful of behemoth GPOs, or do you create lots of small targetted GPOs for specific purposes?

In this iteration of the debate, I was on the side of small and targetted and my colleague was on the side of the behemoth.

After the discussion, I did a bit of online digging, and turned up a post on the TechNet Magazine at Microsoft by Darren Mar-Elia, a Group Policy MVP. The outcome of the article is that, in his opinion, and based on research by using User Environment timers for monitoring the processing of Group Policy objects, small and targetted seems to be the best strategy.

When a GPO is updated with a change by an administrator, the client will have to process all of the settings within the GPO to determine which settings have changed and determine which settings it needs to apply, however in small and tightly targetted GPOs, there are much fewer settings per GPO which means even in a high churn Active Directory environment, fewer client-side settings need to be re-evaluated.

In largely static environments where there is a very low rate of churn, it could be entirely suitable to use fewer larger GPOs to apply larger configuration setts in bulk, however this will depend on the environment, and following the advice in the link below will allow you to determine the best scenario for your environment.

For anyone interested in reading the full article, you can see it at http://technet.microsoft.com/en-us/magazine/2008.01.gpperf.aspx.

Accessing BitLocker Recovery Keys in Active Directory

For years, admins have had the ability to store user certificates in Active Directory to help with things like EFS file encryption. One of the more recent technologies from Microsoft is BitLocker Drive Encryption.

To be able to archive the keys to Active Directory instead of storing the keys manually to USB, you need to extend the schema which forms part of the deployment of BitLocker, but when trying to manage BitLocker on-going, you need to be able to access the keys which have been saved.

These keys can be found stored in the Computer objects in Active Directory Users and Computers on a Windows 7 computer with the RSAT (Remote Server Administration Tools) once the BitLocker Password Recovery Viewer feature is enabled.

The problem you will sooner discover is that this in itself isn’t enough to give you access to the new tab in ADUC to see the keys, because the DLL file isn’t registered to allow it to work. To obtain the functionality that you want, you need to enter the command regsvr32 bdeaducext.dll to register the DLL.

Restart ADUC, and you will now have a new tab available on your computer objects for BitLocker Recovery.

Using Group Policy Restricted Groups

Since starting work at Primark, I’ve learnt tonnes, and loving it. Today however, was the exception in that I tried to demonstrate something to a colleague about how to use Restricted Groups in a Group Policy Object ‘in reverse’, but I couldn’t recall how to do it, leaving me feeling somewhat inadequate.

Under normal use, the Restricted Groups component of a Group Policy object allows you to restrict the membership of a particular group to selected members. The most common use case for this is at the end-user desktop level to ensure that no users are able to add themselves by hook or crook to the local Administrators group (assuming you don’t give your users Administrator permissions in the first place).

imageThe flip of this is that in some circumstances , more commonly on servers, you may want to supplement the Administrators group with additional members, but not remove any existing additions to the group.

To achieve this configuration, right-click on the Restricted Groups list item in the MMC Console and select Add Groups. When asked to specify the name of the group you wish to add, under normal circumstances, you would enter the name of the group that you want to control permissions (Eg. Administrators), however in this example you enter the name of the group that you want to add to Administrators.

When the dialog appears, in the “This group is a member of” section, add the Administrators group.

This change is normal configuration allows you to add specified groups to existing groups as desired.

Enjoy.

Access Denied When Approving a Pending WDS Client

With WDS you can configure the server to automatically respond to known clients. You can additionally affect the behaviour for unknown clients.

In my environment I have it configured to answer the clients PXE boot request however they are not automatically served for two reasons:

  1. I may want to assign them to a different image or elect to manually install it without the unattended settings
  2. I may want the client to not automatically join the domain
  3. I want to name the something better than MININT-000000ABCDEF

When an unknown client connects to the WDS server the user is presented with a message to say that their request is pending administrative approval on the server.

Using the WDS console, you select the Pending Devices tree and select the option to Name and Approve a client, however doing so presents you with an Access Denied error.

Read more…