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.

Step by Step Guide for Extending Active Directory Schema for System Center Configuration Manager

Account Permissions

The account that will be used to run the extadsch.exe needs to have appropriate access and be in the “Schema Admins” group. You cannot run the extadsch.exe with alternate credentials using Run As.


Locating ExtADSch.exe

The exe used to extend the AD Schema can be located in the default installation directory under the bin\i386 folder.


If you have installed ConfigMgr to an alternate location, then it will be located in that installation path (installation paht\bin\i386).

Running ExtADSch.exe

You can run the file by either opening a command prompt and running the extadsch.exe, or by double-clicking the file.


Once it’s ran, you are looking for the “Successfully extended the Active Directory schema” output. You can also view the results by viewing the ExtADSch.log that is created on the C: drive.

This log file will detail the changes made to the schema and also show the success of the schema extensions.


Creating the Systems Management Container

After the schema is extended successfully, the Systems Management container needs to be created in Active Directory.

Open ADSI Edit and expand to the “System” container.


Right-click on the System container and select “new” then “object”.


Select “container” from the object list, and then select “Next”.


Next, enter in “System Management” and then click “Next”.


Click “Finish”.


Once you click Finish, you should see the new container listed.


Setting Security on the System Management container

Once the System Management container has been successfully created in Active Directory, the appropriate permissions needs to be set on the object.

With ADSI Edit still open, right-click on the System Management container object and select properties.


Go to the Security tab of the Properties dialog box and then select “Add”. Once the next dialog box opens, add the computer account of the primary site server(s) or the Active Directory group containing the servers. It’s recommended to use an Active Directory group so that you are not required to make this change again. Once you have entered in the required information, select “Ok”


Select “Full Control” for the site server or group you just added.


Next select Advanced, and then configure the server or AD group permissions to apply to “this object and all descendant objects”.


Click “OK” 3 times to save your changes.


Active Directory Group and ConfigMgr Collection Creation HTA

This information is provided as-is, you at your own risk.

Updated my HTA for creating AD groups and collections with a few tweaks and wanted to post the new version.  I originally blogged an older version here.  I had taken an HTA from SMSUtils and heavily modified it to do what I needed.  I have since updated it with some additional appearance changes, and the big change is that I added support for R3’s “Dynamically Add New Resources” to the collection.  You can now select that as an option to set when creating collections.

Updated to V1.6: Added sorting function to drop downs

Updated to V1.5: Added option to pick collection update times

Updated to V1.4: Some other formatting changes were made as well.


New support for ConfigMgr R3:


I also tweaked the logging window so that it’ll automatically scroll as you create multiple entries.


I hope you find this tool as useful as I have over the years.

Download Version 1.6

Download Version 1.5

Download Version 1.4


Improving Your Image: Sector-Based, File-Based, and Sysprep – What Makes the Most Sense? Part 3: Deploy-time Build Automation and Recommendations

Jeremy Chapman has created the third blog in a series on the benefits of using package based imaging tools.

Read the third post here.

“This is the third and final blog in the series . In the last blog, The Pros and Cons, I covered the main benefits and underlying drawbacks of file-based and sector-based core images. I intentionally stuck to core image files (the .WIM, .V2I, .GHO, .TIB, .VHD, etc. files themselves) and purposely left out the automation needed to tailor installations at install-time using automation. The automation will actually play a role into the overall recommendations of what type of image to use – file or sector-based. I would argue that thin, file-based images would make a lot less sense if the automation wasn’t there to support the additional functions.”


Improving Your Image: Sector-Based, File-Based, and Sysprep – What Makes the Most Sense? Part 2: The Pros and Cons.

Jeremy Chapman has created the second blog in a series on the benefits of using package based imaging tools.

Read the second post here.

“Welcome to blog number two in the series where we’ll look at file-based images versus sector-based images. We’ve already done the tools primer and defined the terms again in the last blog post. Now we actually get some real work done by comparing the “tried-and-true approach” of sector-based images that most of us (including me) have grown up with and the relatively newer approach of composing installations with “builds” at deploy time using file-based “core images” (I defined the terms in quotes in the first blog of the series in case you are wondering why I used quotes). Beware, this blog doesn’t have any pictures or pretty screenshots.”


Client Push and Discoveries at Secondary Sites

This is always a good article to review for explaining whether you should enable client push and/or discoveries at Secondary Sites.  I often refer to this post when people ask about whether or not they should enable discovery at a secondary site.

Read more here on Jeff Gilbert’s blog.


Configuring Shared Folder Permissions

I was helping someone configure some shares the other day for Migdata and Logs.  I dug this up from the old BDD 2.5 documentation, it’s a good reference point for creating access to shares in order for computers to put files there.

After you have configured the SMS client access accounts, you need to configure the appropriate shared folder permissions. Ensure that unauthorized users are unable to access user state migration information and the deployment logs. Only the workstation creating the user state migration information and the deployment logs should have access to these folders.

To configure the shared folder permissions for each folder listed in Table 24, perform the following steps for each folder:

1. Start Windows Explorer and navigate to SharedFolder (where SharedFolder is one of the shared folders listed in Table 24).

2. Right-click SharedFolder (where SharedFolder is one of the shared folders listed in Table 24), and then click Properties.

3. On the Security tab, click Advanced.

4. On the Permissions tab, clear the Allow inheritable permissions from the parent to propagate to this object and all child objects check box.

5. When the Remove when prompted to either Copy or Remove the permission entries that were previously applied from the parent appears, click Remove.

6. On the Permissions tab, click Add.

7. In the Enter the object name to select text box, type Domain Computers, and then click OK.

This action allows domain computers to create subfolders.

8. On the Permission Entry for Text dialog box, in the Apply onto list, select This folder only.

9. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Create Folders/Append Data permission, and then click OK.

10. Repeat steps 6– 9 substituting Domain Users for Domain Computers.

11. On the Permissions tab, click Add.

12. In the Enter the object name to select text box, type CREATOR OWNER, and then click OK.

This action allows domain computers and domain users to access the subfolders they create.

13. On the Permission Entry for Text dialog box, in the Apply onto list, select Subfolders and files only.

14. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Full Control permission, and then click OK.

15. Repeat steps 11–13 for each group that you want to grant administrative privileges.

The permissions you set in these steps allow a workstation to connect to the appropriate share and create a new folder in which to store user state information or logs, respectively. The folder permissions prevent other users or computers from accessing the data stored in the folder.

Note   The default permissions on the SMS distribution point shares should provide the appropriate resource access by default.


Custom Boot Wizard – Maximizing the window

I had previously done a bunch of work on making my custom boot wizard a certain size and centered, and it just didn’t always look as good as I wanted it to with various screen resolutions.  So I’ve resorted to simply always making sure the window is maximized 🙂

Open your wizardeditor and go to your global pane.  Then you will want to add a customstatement and put the following text in:

window.moveTo 0,0
window.resizeTo screen.availWidth, screen.availHeight


That’s it, save your changes, update your boot image, and test.  You should now have a front-end that is maximized and no longer need to worry about it being centered or large enough to contain your information.


Another Take On Driver Management

Keith over at Xtreme Consulting has a nice post on driver management in MDT.  He explains the typical Make/Model match, then talks about PNP based matching and then finally touches on a hybrid of the two.  Worth a read, and then you can determine what works best for you.

Read more here:


Mini Monster Mof Builder Updated to 1.11

The Mof builder has been updated to 1.11.  This is a fantastic tool, definitely check this out if you haven’t seen it before.

Here is a snippet:

“For SMS 2003 SP2 and earlier, there were popular downloads available for what were known as "the Monster Mof".  They were great, but in my opinion could be bloated.  For example, it would contain edits for 3 different anti-virus vendors.  Most companies usually only had 1, or if they were really diverse, possibly 2.  As an admin, you either put in the entire monster and lived with the bloat, or edited the Monster anyway, and either removed edits or set them to FALSE.

Since SP2, edits have been accumulating.  Most of which have been blogged on MyITForum, but they are often difficult to find.  There’s a zip file with all of the text snippets here, but even that could be daunting to the admin who rarely edits the mof.

So… here’s another, different way to pick and choose which MOF extensions you might want in your environment.  Download the attached file, unzip it, and rename it from .txt to .hta, and double-click it.  You’ll be presented with the below.  Please look at Misc Notes, and the specific instructions for SMS2003 vs. ConfigMgr.  You can use the ? to get more info on a particular snippet, which may lead you to additional blog entries.  Once you’ve decided which 1 (or 5) extensions you might want in your environment, check those items on, and at the bottom, click "Compile & Display".  You will then have 1 (or 2) text files with your own "mini monster" to add to your mof files on the server.  As useful mof edits continue to accumulate, the download will be updated; at least until a better method for sharing mof snippets appears!”


Restoring Deleted All Systems Collection

Sometimes things just happen, sometimes you accidentally delete the All Systems collection because you were trying to do too many things at once.  I’ll fess up, I did it. 

Here’s how to restore the collection with the appropriate ID.  This solution was given to me by Microsoft Support.

Here is the VBS script that will do the restore:

####begin script

strSMSServer = "."
strParentCollID = "COLLROOT"
‘This example creates the collection in the collection root.
‘Replace COLLROOT with the CollectionID of an existing collection to make the new collection a child.

strCollectionName = "All Systems"
strCollectionComment = "This is the All Systems Collection."
Set objLoc = CreateObject("WbemScripting.SWbemLocator")
Set objSMS = objloc.ConnectServer(strSMSServer, "root\sms")
Set Results = objSMS.ExecQuery ("SELECT * From SMS_ProviderLocation WHERE ProviderForLocalSite = true")

For each Loc in Results
If Loc.ProviderForLocalSite = True Then
  Set objSMS = objLoc.ConnectServer(Loc.Machine, "root\sms\site_" & Loc.SiteCode)
End if

Set newCollection = objSMS.Get("SMS_Collection").SpawnInstance_()

‘Create new "All Systems" collection
newCollection.Name = "All Systems"
newCollection.OwnedByThisSite = True
newCollection.Comment = strCollectionComment
newCollection.CollectionID = "SMS00001"
path = newCollection.Put_

‘Set the Relationship
Set newCollectionRelation = objSMS.Get("SMS_CollectToSubCollect").SpawnInstance_()
newCollectionRelation.parentCollectionID = strParentCollID
newCollectionRelation.subCollectionID = ("SMS00001")

####end script

Once you’ve recreated the collection with the appropriate ID, then you’ll have to import the All Systems query for your membership rules.