Alan Burchill author of the Group Policy Center blog has posted 2 great articles on Best Practices for Active Directory Structures.

Best Practice:Active Directory Structure Guidelines – Part 1

Best Practice: Group Policy Design Guidelines – Part 2

If you get tasked to do some system troubleshooting and you just want to get as many information possible from a client, then have a look at the Microsoft Product Support Report Tool and the Product Support Reports Viewer.

The Microsoft Product Support Reports Viewer 2.0 can be downloaded from here and the Microsoft Product Support Reports from here

First launch the Microsoft Product Support Tool, which is a self-extracting executable (no installation needed). Once launched you can select the diagnostics you want to execute, then select Next to get the Diagnostic (Data Collection) started. Note that depending on the diagnostics selected, this process can take a while (up to 25 minutes).

Once the Diagnostic process has completed you can browse, e-mail or save the results. When saving the results, all data is stored in a single CAB file.

The Microsoft Product Support Report Viewer provides an interface to view the collected diagnostic data, which consists of several individual XML files.

While the diagnostic tool was running on my client, I copied the content of the temporary folder that the tool creates within the users TEMP folder into another folder. (if you have many folders in your TEMP folder just sort by date, and open the one with the newest date).

Within that folder you will find a Tools folder which contains all the executables and scripts used by the Diagnosis Tool.

So next time you get one of these famous calls to help solving a system problem, consider using this tool to gather detailed system information data.

Back in 2008 I wrote about Extending User Information in AD. Today I came across a blog post mentioning that there is now an unsupported 64 bit version available. More details and download here

Managing ActiveX Components within an enterprise sometimes can be a pain. Users with standard user privileges by default can’t install ActiveX components, hence whenever a larger group of users require an ActiveX component you usually end up creating a software package and distribute it via Software Distribution or you provide them with temporary Administrative rights. But if the clients are running Windows Vista or Windows 7 there is another solution available I noticed many people aren’t aware of, hence that’s why I am writing this article.

The Solution is the Windows ActiveX Installer Service. Using the Windows ActiveX Installer Service allows Enterprise Administrators to manage the deployment of ActiveX controls through Group Policy Settings. On Windows Vista the ActiveX Installer Service is not installed by default but can be added as a feature. On Windows 7 the Service is installed by default.

Configuring the ActiveX Installer Service through Group Policy can be done in two ways. Either by specifying the ActiveX Control installation URL or by configuring trusted sites. I am going to use the first option to demonstrate the configuration and behavior of the ActiveX Installer Service.

Most of you will be familiar with the Microsoft Connect, MSDN Subscriber Download or TechNet subscriber download Site that uses the File Transfer Manager for downloading content. When trying to download content from one of the above mentioned web sites for the first time with a standard user you will be prompted with a message as shown in the picture below.

But as soon as you allow the Add-on to be installed, you will be prompted to provide a user name and password of a user that has administrative privileges to allow the installation to continue. 

This is what would happen in an enterprise environment where users access a website that requires the installation of an ActiveX control. So let’s create a Group Policy that allows the installation of the Microsoft File Transfer Manager through the ActiveX Installer Service.

First we need to know the URL that points to the ActiveX Control installation file, which is usually a CAB file but can be an OCX or DLL file as well. To find out the URL of the Microsoft File Transfer Manager I open the web site’s source and search for the word “CODEBASE”.

Now that I know the location that points to the CAB file, I open the Group Policy Management Console and create a new GPO called GPO_ActiveX_Management. Within the new created GPO I navigate to the ActiveX Installer Service which is located under Computer Configuration, Policies, Administrative Templates, Windows Components.

I then enable the "Approved Installation Sites for ActiveX Controls” setting and add the Site name https://transfers.ds.microsoft.com/FTM/TransferSource/grTransferCtrl.cab and set the Installation control value to 2,1,1,0.

To ensure that the GPO settings is applied to my client I run GPUPDATE at the command prompt. Now when i launch the website again that tries to install the Microsoft File Transfer Manager there is no User Account Control prompt anymore, this because i have now configured this site as an approved site to install an ActiveX control.

When opening the Services list within the Microsoft Management Console, I can see that the Service has been started and looking at the Windows Application log I can see that the URL was identified as a secure location.

So after a few seconds, the Microsoft File Transfer Manager is successfully installed without having to provide administrative privileges.

If you’re interested in using the ActiveX Installer Service in your environment I recommend that you also read the below referenced articles.

Additional Resources
The ActiveX Installer Service in Windows Vista
Microsoft TechNet – ActiveX Installer Service
NirSoft – ActiveXHelper

This is an excellent article written by Darren Mar-Elia author of gpoguy.com and founder of sdmsoftware. The article provides guidance for optimizing Group Policy Performance. Read the entire article here

When joining a Computer to an Active Directory domain using the Domain Join UI in Windows or a command line tool such as NETDOM.EXE, by default the computer object is stored in the Computers container which is defined as the default Container in Active Directory for new created Computer objects.

The disadvantage of this is that you cannot link any Group Policies to the Computers container which prevents you from applying any Computer security or configuration settings to these clients.

Before we’re going to change this behavior let’s have a look at where this information is actually stored. Open the Active Directory Users and Computers or the ADSI Edit snap-in and select the Domain Properties from the context right click menu, then select the Attribute Editor Tab.

The default Container data for new Computer objects is stored within the wellKnownObjects attribute.

But when you double click the Attribute, you will get an error that there is no editor registered to handle that attribute type. I did not look any further into this, but assume that this attribute is protected against manual changes. To still get access to the data that is stored within this attribute I used the Active Directory Explorer from the Sysinternals Suite.

The wellKnownObjects Attribute contains the following data:

98 39 240 175 31 194 65 13 142 59 177 6 21 187 91 15, CN=NTDS Quotas,DC=LABHOME,DC=local
244 190 146 164 199 119 72 94 135 142 148 33 213 48 135 219, CN=Microsoft,CN=Program Data,DC=LABHOME,DC=local
9 70 12 8 174 30 74 78 160 246 74 238 125 170 30 90, CN=Program Data,DC=LABHOME,DC=local
34 183 12 103 213 110 78 251 145 233 48 15 202 61 193 170, CN=ForeignSecurityPrincipals,DC=LABHOME,DC=local
24 226 234 128 104 79 17 210 185 170 0 192 79 121 248 5, CN=Deleted Objects,DC=LABHOME,DC=local
47 186 193 135 10 222 17 210 151 196 0 192 79 216 213 205, CN=Infrastructure,DC=LABHOME,DC=local
171 129 83 183 118 136 17 209 173 237 0 192 79 216 213 205, CN=LostAndFound,DC=LABHOME,DC=local
171 29 48 243 118 136 17 209 173 237 0 192 79 216 213 205, CN=System,DC=LABHOME,DC=local
163 97 178 255 255 210 17 209 170 75 0 192 79 215 216 58, OU=Domain Controllers,DC=LABHOME,DC=local
170 49 40 37 118 136 17 209 173 237 0 192 79 216 213 205, CN=Computers,DC=LABHOME,DC=local
169 209 202 21 118 136 17 209 173 237 0 192 79 216 213 205, CN=Users,DC=LABHOME,DC=local

Now that we know where the information is stored, let’s change it. I mentioned before that editing the wellKnownObjects Attribute through the AD snap-in tools isn’t possible, and that’s probably for a good reason. But Microsoft has been kind enough to provide a command line tool for this called redircomp.exe which is located in the %SystemRoot%\System32 folder on Windows Server 2003/2008 systems.

Before running redircomp.exe a new Organizational Unit must be created where we want to store the computer objects. For this example I created an OU called StagedComputers. I then ran the following command:  redircmp OU=StagedComputers,DC=LABHOME,DC=local

Now let’s go back to the Active Directory Explorer and open the wellKnownObjects Attribute where we will see the change.

170 49 40 37 118 136 17 209 173 237 0 192 79 216 213 205, OU=StagedComputers,DC=LABHOME,DC=local
98 39 240 175 31 194 65 13 142 59 177 6 21 187 91 15, CN=NTDS Quotas,DC=LABHOME,DC=local
244 190 146 164 199 119 72 94 135 142 148 33 213 48 135 219, CN=Microsoft,CN=Program Data,DC=LABHOME,DC=local
9 70 12 8 174 30 74 78 160 246 74 238 125 170 30 90, CN=Program Data,DC=LABHOME,DC=local
34 183 12 103 213 110 78 251 145 233 48 15 202 61 193 170, CN=ForeignSecurityPrincipals,DC=LABHOME,DC=local
24 226 234 128 104 79 17 210 185 170 0 192 79 121 248 5, CN=Deleted Objects,DC=LABHOME,DC=local
47 186 193 135 10 222 17 210 151 196 0 192 79 216 213 205, CN=Infrastructure,DC=LABHOME,DC=local
171 129 83 183 118 136 17 209 173 237 0 192 79 216 213 205, CN=LostAndFound,DC=LABHOME,DC=local
171 29 48 243 118 136 17 209 173 237 0 192 79 216 213 205, CN=System,DC=LABHOME,DC=local
163 97 178 255 255 210 17 209 170 75 0 192 79 215 216 58, OU=Domain Controllers,DC=LABHOME,DC=local
169 209 202 21 118 136 17 209 173 237 0 192 79 216 213 205, CN=Users,DC=LABHOME,DC=local

Finally I joined a Windows XP client called VMXP-001 to the LABHOME domain and the Computer object was automatically created within the StagedComputers OU.

Note that the same can be done for User Objects as well. For more Information read the Microsoft KB Redirecting the users and computers containers in Active Directory domains

I’m just about to expand my knowledge a bit around App-V. I haven’t done any hands-on yet, because I usually first focus on gathering all the useful resources available on the net, and then start reading these. By doing so, I found these fantastic videos on The Blogcast Repository.

Deployment Scenarios with App-V 4.5
Planning Considerations before Implementing App-V 4.5
The App-V Client (part 1)
The App-V Client Part 2- Deep Dive

By the way, if you are not familiar with The Blogcast Repository but like video based trainings, have a look at the Repository, there is lots of other Microsoft related Technology training material there.

As we move towards the end of the year I thought it’s a good time to do some housekeeping activities within the lab infrastructure in which we work on a daily basis. Throughout the year we often create test user and computer objects within Active Directory and of course sometimes we forget to delete them.

As I don’t want to reinvent a wheel again I searched the web and soon found a whole bunch of tools and scripts that would help me identifying unused user accounts. I decided that I wanted to use a script. I first found the Last Logon Dates scripts from Richard L. Mueller which are written in WSH. But then I found the Managing AD User Accounts with PowerShell article on WindowsITPro and decided to use the opportunity of using PowerShell to accomplish my task.

Unfortunately the administration console I use hasn’t been migrated to Windows 7 yet, so I installed PowerShell 2.0 onto that Windows Vista client and then installed the Quest AD cmdlets.

On PowerShell.com I found the following script that I modified a bit so that the output is written into an HTML file.

Get-QADUser -sizeLimit 0 | where {$_.lastlogontimestamp -lt (get-date).AddDays(-30)} | Select NAme,description,lastlogontimestamp | convertto-HTML | Out-File c:\temp\adlastloggedon.htm

I wanted to do the same to find old computers, but it appears that the Get-QADComputer cmdlet has a bug, as it doesn’t return any LastLogonTimestamp values and I found various comments that this was identified as a bug which should have been fixed by now, but either the bug is still there or I might be doing something wrong. However I found a “find old computer objects” script on the Microsoft TechNet Script Center Gallery it just has a bid more lines of code

Note that your Windows domain must be at Windows 2003 Domain Functional Level for updates to the llastLogontimeStamp to occur.

If you are looking for a command-line tool to find Old Computers in your domain, I recommend the OldCmp tool from Joe.

Related content:
The LastLogonTimeStamp Attribute” – “What it was designed for and how it works

One of the things to consider when deploying Windows 7 clients is to update the Central Store on your domain controllers. If you haven’t created a Central Store yet, I recommend you watch the video or read the documentation I have listed at the end of this post.

If you do have a Central Store already, updating it with the Windows 7 Group Policy Administrative templates is very straight forward. You simply copy the templates that are stored under C:\Windows\PolicyDefinitions on your Windows 7 client to the Central Store which is located at \\FQDN\SYSVOL\FQDN\policies\PolicyDefinitions (FQDN = fully qualified domain name)

A good alternative for copying the files manually is the Vista Central Store Creator Utility from Darren Mar-Elia which automates the whole process of creating and updating the Central Store.

 Related Content
Screencast: How-To Configure the Central ADMX Store
How to create a Central Store for Group Policy Administrative Templates in Window Vista
Group Policy Settings References for Windows and Windows Server

63EHNFN6ZWK8

The AppLocker Technical Documentation for Windows 7 and Windows Server 2008 R2 provides technical guidance about understanding how AppLocker works and how to effectively plan and deploy AppLocker policies.

The download contains two documents:

BETA – AppLocker Frequently Asked Questions.pdf
BETA – Planning and Deploying Windows AppLocker Policies.pdf

Download here

When creating objects in Active Directory you can set a flag that prevents accidental deletion of an object.

While this setting is visible in the UI by default when creating an Organizational Unit, for other objects like Users, Groups and Computers, this flag is not set by default and can only be set if the Advanced Features are enabled within the Active Directory Users and Computers Console.

So assume you would create some important user accounts that are used for critical back-end systems, you should consider enabling the “Protect object for accidental deletion” flag.

Once you have this flag set, anyone who would try to delete the user account would receive a message as shown below.

In the video below Brian Desmond and Laura talk about the new things that come with Windows Server 2008 R2 AD.

Group Policies and Group Policy Preferences are great technologies to manage your enterprise desktops. But what if you want to go beyond the features Microsoft has build into the Group Policy Management Console?

With PolicyPak you can consistently manage ANY application’s settings using the Windows native Group Policy technology. have a look at the PolicyPak introduction video below to learn what PolicyPak can do and how it works.

Learn more about PolicyPak and watch the video tutorials.

Other resources

Group Policy Preferences Overview

Microsoft Group Policy site

TechNet Magazine – Expanded Control with Group Policy Preferences

Group Policy Settings Reference for Windows Server 2008 and Windows Vista SP1

In preparation of doing some Group Policy related things, I decided to extend my Home Lab AD infrastructure running on Windows Server 2003, with  Windows Server 2008 and Windows Server 2008R2 domain controllers.

Because at some stage I want to get rid of the Windows 2003 Server I also moved the FSMO roles from the Windows 2003 domain controller to the Windows 2008 domain controller.

I used the steps described in the “Transferring FSMO roles” article. Additional information can also be found in the “How to view and transfer FSMO roles in Windows Server 2003” article.

By searching documentation on how to move FSMO roles, I found the FSMO Roles utility from dovestones software,, that simply shows you who owns the FSMO roles within your current AD infrastructure. 

Those who prefer scripts use the code described in “How to Find the FSMO Role Owners Using ADSI and WSH”.

Those interested in managing Active Directory with PowerShell, have a look at the Active Directory Power Shell Blog.