Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.

Back to Basics: Permissions needed in AD to “mess” with computers during OS Deployment

Mikael Nystrom created a nice post on what permissions are needed in Active Directory for OSD.

Read his post here.


Target Group Policy Preferences by Container, not but Group

Great Group Policy Preferences post over on the Ask the Directory Services Team Blog.

Read the full post here.

Hello again AskDS readers, Mike here again. This post reflects on Group Policy Preference targeting items, specifically targeting by security groups. Targeting preference items by security groups is a bad idea. There is a better way that most environments can accomplish the same result, at a fraction of the cost.


Configuration Manager 2012–Extending the AD Schema Video Walkthrough

Quick video on how to extend the Active Directory Schema for ConfigMgr 2012 Beta 2. This video will also apply to ConfigMgr 2007.


Active Directory System Discovery Method with System Center Configuration Manager 2007 SP2 Hotfix

Read the full post and request the hotfix here.

Consider the following scenario:

  • You enable Active Directory System Discovery or Active Directory User Discovery on a System Center Configuration Manager 2007 Service Pack 2 (SP2) site server.
  • You add a search path to the Active Directory OUslist.
  • You add a second search path to the Active Directory OUslist. This search path contains the string of the first search path you just added.

In this scenario, the second search path is not discovered when the Active Directory System Discovery process or the Active Directory User Discovery process runs.
For example, you create two Organizational Units (OUs) under an OU which is named “Organization Computers”, and then you name the OUs "abc" and "abcd." You add a search path of domain\Organization Computers\abc for the first OU, and then you add a search path of domain\Organization Computers\abcd for the second OU. In this scenario, the second OU is not discovered when the Active Directory System Discovery process or the Active Directory User Discovery process runs.


Hotfix informationA supported hotfix is available from Microsoft. However, this…

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.
If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site: (

Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.


To apply this hotfix, you must have System Center Configuration Manager 2007 SP2 installed on the computer.

Installation instructions

Note The following hotfix package can be installed on a System Center Configuration Manager 2007 SP2 site server that is running an x86-based version of an operating system or an x64-based version of an operating system:


Restart requirement

You do not have to restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.

File information

The English (United States) version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

System Center Configuration Manager 2007 file information notes

ConfigMgr Client IP Check Script

Nice by Jason Sandys for identifying stale systems in AD, read the full post and download the script here.

Troubleshooting client agent health issues at my current customer, I wanted to eliminate all of the stale systems from AD so I didn’t waste my time on them (and of course the customer was no real help here). I decided to write a script to take a list of systems, check if a forward and a reverse DNS entry exists and also compare the DNS reverse entry (if it exists) to the name of the system as specified in the list. Using these checks, I can now identify systems that probably don’t exist anymore and can be deleted from or disabled in Active Directory thus allowing ConfigMgr to be cleaned up.

Sample output:

Name           IP                  Reverse             Status
—-           –                  ——-             ——
xyz1             abc5                IP registered to another system
xyz2           -                   -                   Could not Resolve IP
xyz3             xyz3                OK
xyz4             -                   IP Address not found in reverse zone

Actual/exact interpretations of each of the categories is possibly subjective and based on the configuration of a particular environment but in general, IP registered to another system and Could not Resolve IP are indicative of stale systems. Recall that AD System Discovery also does a forward DNS lookup on systems before it creates a DDR on them so this script follows similar logic as the discovery; however, once the system is discovered, AD Discovery won’t remove it and thus this script. Also, AD discovery doesn’t do a reverse lookup because this may or may not be configured in any given environment.

The script is a PowerShell script and can be run on any system that can query the internal DNS. By default, it pulls the names of systems to check from a file called sys.txt in the same directory as the script; place each system name to query on a separate line.

And then, run it from a PowerShell command prompt. To output the results to a CSV, pipe the output of the script to the Export-Csv commandlet; e.g., .\IPCheck.ps1 | Export-Csv c:\IpCheckResults.csv


Copying Active Directory Group Membership For Software Distribution – Powershell

Through SMS/SCCM we use AD groups for software distribution.  Something that happens often enough is that we need to copy the groups that one computer is a member of to another computer.  Thanks to help from David Crown, I have a nifty powershell script that will do that for me now.  If you just run the script straight, it will prompt for the source computer and the destination computer.  Otherwise you call the powershell straight with the parameters “Script -src source_comptuer -dest destination_computer”

Also have a simple vbscript to call it for you so you don’t have to open a powershell prompt every time you want to run it.

Details below, and files attached to this post.

You will just need to change the “PATH” in the vbscript file to where the script is stored:

Set objShell = CreateObject(“Wscript.Shell”)
objShell.Run(“powershell.exe –noexit &’PATH\copygroupmembership.ps1′”)

Here is the powershell script:

Param ($src, $dest)

Add-PSSnapin Quest.ActiveRoles.ADManagement

if ( ($dest -eq $null) -or ($src -eq $null) ) {


      $src = [Microsoft.VisualBasic.Interaction]::InputBox(“Enter the name of the source computer”, “Source Computer”) 

      $dest = [Microsoft.VisualBasic.Interaction]::InputBox(“Enter the name of the destination computer”, “Destinaton Computer”)

$dest = $dest +”$”

$src = $src + “$”

$Groups = get-QADMemberOf $src

$Groups | foreach {
      if ($ -ne “Domain Computers”) {

            Add-QADGroupMember      $_ -Member $dest




Advanced reporting against Add/Remove Programs (ARP), filtering and appending data – Part 2

I’m not a SQL expert by any means, so if you see something that isn’t quite right, well i already said I’m not a SQL expert 🙂 This process involves custom tables and modifying your SQL database, proceed at your own risk.  Don’t say i didn’t warn you…

This is an extension of Part 1

We made a pretty cool addition to this recently.  We wanted the report to actually tell you if the computer was in the correct AD group and say “Yes/No” in the report web page.  Then we would know if the computer/user was in the correct groups and if anything needed to be done.  If they weren’t then we would know exactly what groups they needed to be added to.  This queries our ADGroup field in our custom table AddRemoveProgram against  SMS/SCCM’s v_ra_system_systemgroupname to find any matches.


Here is an example of the new output:





So in order for this to work, we need to add some new logic to our queries for the reports.



We need to add a new CASE for settings the Yes/No:


WHEN sgn.system_group_name0 IS NULL THEN ‘No’

ELSE ‘Yes’

END as InGroup


And then we need to add a new join statement to match up the AD group names:

LEFT OUTER JOIN dbo.v_ra_system_systemgroupname sgn ON arp.ADGroup = Replace(sgn.system_group_name0,’DOMAIN\’,”) AND arpd.ResourceID = sgn.ResourceID


You will need to modify the “DOMAIN” for your domain, this will allow you to not have to populate the custom table with DOMAIN\AD GROUP NAME, instead it just assumes that for you.


That’s it, pretty simple, yet adds a very nice feature to the report!


Hope this helps,



Custom Front End – Name and OU prompt – ConfigMgr/MDT 2010/Pre-execution hook

This information is provided as-is… proceed at your own risk…

Provided with MDT 2010 SCCM integration is a pre-execution hook that allows for a computer name prompt prior to execution of the task sequence.  This works great for bare metal installs and avoids the MININT% name.  An additional property i wanted to define for bare metal builds was to provide a selection screen where the user can select the target organizational unit (ou) in Active Directory.  What i also wanted was validation on the OU prompt so that the user couldn’t go to the next screen without first selecting an OU.  It took me awhile to figure out the variable i needed for the OU validation, so thanks to Hector for that. (I don’t claim to be a scripting expert, never have… ) 🙂

Here is the computer name promt:


Here is the OU prompt: (blocking out our OU’s)


You’ll need the MDT wizard editor found here:


First thing you need to do is make sure that you have a boot image that was created with MDT and you opted to check the pre-execution hook check box.


The files for the pre execution hook are stored here once you’ve installed MDT 2010:

C:\Program Files\Microsoft Deployment Toolkit\SCCM

You will want to work with the Deploy_SCCM_Definition_ENU.xml file.  I would NOT recommend modifying the one included with MDT.

In my case, i made a copy of the xml and the vbs script to a c:\custom\mdt_custom\ folder  i had created. That is where i worked with the files.  Wherever you run the wizardeditor from and wherever the xml you are working with is, it will put the necessary files in that folder, so don’t run this from your desktop or you’ll see a bunch of new files pop up on your desktop!

I used the same file name so i didn’t have to modify my tsconfig.ini in the boot image, but if you want to use a different file name you can.  Just make sure to change the ZTImediahook.wsf to call the appropriate file.  It’s simple enough to just use the same name and call it a day.

Once you open this file with the wizard editor you will see this:



We need to add a new pane called “machineobjectou”

Then create a validation step, and set the value to MachineObjectOU.Value <> “”



Without going into great detail, MachineObjectOU is the task sequence variable you want set for the target OU.  By setting this variable we are controlling the OU the computer will end up in.

Next you need to create some HTML code and figure out how you want it to display.  You can use the preview pane to see how your changes will work.

Here is the basic HTML code i use:


<H1>Select the Organizational Unit<H1>
<span style=”width: 95%;”>
<p>Select Organizational Unit the computer will be added to</p>
<select id=OUlist size=16 language=VBScript onchange=”MachineObjectOU.Value = OUlist.value” class=wideedit>

<option value=”ou=something,dc=something,dc=com” >OU Display Name</option>
<label class=ErrMsg for=OUList>* Required (MISSING)</label>
<input type=hidden Name=MachineObjectOU />


Which gives you this look:



Next, you will want to click on Wizard – Test


This will let you test the wizard and logic to make sure it acts as expected.

You will be prompted with a list of variables you can set, then you can click run and run the wizard, after going through the wizard panes, you will provided with a list of variables and you should see your new variables listed on the bottom of the list:

First variable list:


Second variable list after running the wizard and you can see the new variables populated:


Now that you’ve hopefully verified your changes work and the wizard runs as expected, we need to get those changes into your boot image.  You need to mount your boot.wim and replace the existing \deploy\scripts files with your modified ones.  Then commit your changes and unmount the .wim.  Then you need to update your distribution points and recreate your task sequence media. That’s the short version at least 🙂 I’m assuming you already know how to mount an image and inject files.




Powershell – Moving computers to known OU

While working on our WSUS Policy, i needed to create a script to move computer objects from whatever OU they were in (unknown) to a known OU.  I decided to embark on powershell for this.  With the help of David Crown from the MSSMS list on myitforum, here is what we came up with.


This script takes a CSV list of computers, target location, and moves the computer objects from wherever they are, to the target location.  One of the struggles we had was getting the command to work with a computer object in the csv list that didn’t exist in AD, the final result accounts for this.


Import-Csv ‘c:\computer exclusions.csv’ | `

Foreach {$computer = get-QADComputer -name $; `

if ($computer -eq $null) {Write-Output "$ bad object`n"}

       else {move-QADObject $computer -to $ }



CSV format is:

Computer, Target