SMS Security Delegation: Getting Granular

So more than a few of my customers (especially HED customers – you know who you are!) seem to struggle a little bit with SMS’ security delegation features. I have to admit that the current way SMS presents security and the delegation of tasks is something that you need to get used to but can be very powerful once you get the hang of it. The following is a common SMS delegation scenario I have seen in more than one environment and thought it would be worth posting here for those that may be struggling with the same or very similar needs from a delegation perspective in their environments…

One SMS Site: Many Departmental SMS Administrators

In many HED environments, the network consists of essentially one fast and mostly flat network. Therefore, it would be very easy to implement SMS in its simplest form which is one big SMS site that includes all subnets and/or AD sites as local boundaries. But the problem with this comes from the perspective of security delegation. How do you effectively delegate autonomous departments to control their users, groups, and systems in one shared SMS site? The answer to this takes a little bit of planning and coordination but can be accomplished in SMS 2003. The following scenario below assumes the following about the security delegation requirements:

  • All departments (or units) will share one central SMS site

  • All departments wish to have visibility and control of only their resources. ‘Control’ would be being able to perform software distribution, remote control, creating packages and advertisements pertaining to their department, etc.

  • Although not a requirement, it is helpful if all systems belong to the same AD forest, AD Discovery is being used, and that an AD domain/OU structure is already in place that segments resources properly.


Step 1: Create AD Groups that will contain the Departmental SMS Administrators

    To make delegation easier, create specific AD groups which will house users that will act as Departmental SMS Administrators. For example, you could call the Psychology Department SMS Administrators ‘psych-smsadmins’, the Electrical Engineering Department ‘ee-smsadmins’, etc. – you get the idea.


Step 2: Add the AD groups created in Step 1 to the SMSAdmins local group on the SMS Site Server

    Note that this alone does not give these users Admin rights into SMS. It simply gives them the needed WMI access so that they can interface with SMS via the SMS Administrator console.


Step 3: Create top-level SMS Collections based on the OU hierarchies that represent each group’s resources.

    These Collections don’t necessarily have to be based on just OU membership. What you want to do here is create Collections that will contain each departments’ users, groups, and systems. If you already have this organized via an AD OU structure, the simplest way to do this is to create Collections based on a dynamic query that specifies the appropriate OU criteria. To include users, groups, and systems in this collection, you would need at least three queries as shown in the example here:

Essentially, each of these three queries are the same but simply point to a different resource type (user, group, and system). Let’s take a closer look at the criteria for the User Resource:

As you can see, when AD discovery is run, any user object that is within the ‘Psych’ OU hierarchy will be added to this Collection (note the % wildcard – so if you had sub OU’s it would iterate through and find these as well). If you need to add ‘straggler’ resources – i.e. those that for whatever reason do not belong to the OU structure, you can always add them with a ‘direct’ rule or other type of dynamic query such as “All systems that have an IP address starting with” or “All Systems with a NetBios Name is like ‘Psych%’

Step 4: Create a ‘template’ SMS Admin Account and Assign the proper Class Rights in SMS.

This template user account can be used to save you time when you wish to bring on more department groups into SMS. It saves you from having to add each individual right (which all department SMS Admin groups should possess) as you can simply copy this user’s rights during that process. This user account should be created in AD and disabled as there is no need to actually use the account – we just need it as a placeholder. You should assign the following SMS Class rights to this account in SMS:

  • Site: Read

  • Collection: Administer***, Advertise, Create, Delegate

  • Packages: Create, Delegate

  • Advertisement: Create, Delegate

  • Query: Create, Delegate

  • Status Messages: Read (Optional)

  • Report: Read, Create, Delegate (Optional)

  • Metered Software: Create, Delegate (Optional)

  • Software Updates: Create, Delegate (Optional)

These rights should look something like this in the SMS Admin GUI:

Step 5: Assign the proper rights to the Departmental SMS Admins AD groups you created in Step 1

Now it’s time to delegate. To do this, run through the ‘Manage SMS Users’ Wizard from the SMS Administrator console and perform the following actions:

  • Add the appropriate Dept. SMS Admin AD group you created in Step 1 as a ‘new user’

  • Copy the template user’s rights you created in Step 4 to this group

  • Add a ‘Collection – Instance’ right for the appropriate Dept. Collection you created and give full instance rights

To follow with our ‘Psych’ example above, this might look something like this in the GUI:

Note how the rights include all of the Class rights copied from the template user as well as the one Class Instance right of the ‘Psych’ resources collection. The last action of giving the user ‘Collection – Instance’ rights is the key part which delegates them to only their resources. Doing this will allow them to only see and perform actions to just their resources. From there, they are free to create sub-collections, create their own packages, advertisements, etc. However, they can only manipulate THEIR resources and no one else’s. Note that I marked some of the ‘template’ Class rights as optional. If you do not wish for delegated SMS administrators to run reports or see status of their actions, then you do not have to give them these rights. However, I have found that most do wish to allow delegated SMS administrators to have visibility in these areas – but it is certainly not required.

Step 6: Profit. I mean, you’re done!

Users that you have added to the appropriate AD groups from Step 1 will now be able to fire up the SMS Administrator console and will only have visibility to their resources. 

UPDATE:  A few folks that have followed the steps above have told me that you also need to be sure to set the appropriate DCOM parameters as well as firewall exceptions (if needed) to allow a non-Administrator access to SMS from a remote Admin console running on Windows XP SP2.  For more information, follow the guidance found in Q317872.

*** - So if you were paying attention to the above, you are probably asking yourself: “Wait – if I give them Administer rights at the Collection Class level, then what is stopping them from giving themselves rights to ALL Collections?” The answer is: Nothing. Upon firing up the SMS Administrator, they will not be able to see the other Collections, however, they will have the ability to delegate themselves to other Collections. Another somewhat annoying issue with the above is that when a delegated SMS Admin creates a Collection or Advertisement, by default only they (and the real SMS Admins) have rights to what they created. Because of this, they then have to go back to what they created and delegate rights to their own group if they wish the other delegated SMS Admins see what they have created! This tends to get old after a while!!!

However – there is hope! Stefan Geisler, an MCS consultant out of Germany, has created a set of SMS Status Filters and VB scripts which work together to take care of BOTH of these two issues. When implemented on the SMS site server (BTW, implementation is VERY easy), SMS will immediately stamp any sub-collection or Advertisement that is created with the security rights of the Collection at which it is based. What this means is that with these filters and scripts, there is no need to give the delegated SMS Admin the Administer right at the Collection Class AND the delegated group will automatically have full control of the new Collection or Advertisement upon creation! If interested in these filters and scripts, send me a note – these are not officially supported MSFT products but have proven to work in many SMS environments.

Comments (7)

  1. Anonymous says:

    Hi Kevin,

    does the scripts apply to SCCM 2007 R2 or was those scripts packages differently. Could you provide either the scripts or a link to get them!


    Philippe (

  2. Anonymous says:

    Hi Kevin,

    We’re configuring rights in SCCM 2007 along exactly the lines you’re suggesting in this article – AND we’re having the same headache you describe.

    We’re interested in having the scripts you’ve mentioned, if they work for SCCM 2007…

    If you’re able to send them to us, we’d appreciate it…


    Tim Whitehead (

  3. Anonymous says:

    Hi Kevin,

    this is what I’m looking for. Could you please provide the SMS filter and VB scripts?

    Thank you very much

    Dirk (

  4. Anonymous says:

    Hi Kevin,

    thanks for that article. Can you send me the scripts you’ve mentioned please.


    Martin Hoppe (

  5. Anonymous says:

    Kevin, I have followed the delegation w/ the scripts and it works perfect!

    I have a question on how to delegate the reports.  How would i delegate a department to only report on their resources?


    Dan Hanson

  6. amdsid says:

    Hi Kevin,

    Could you please send me the SMS filter and the VB scripts.


    ASid (

  7. Renjith says:

    Hi Kevin,

    Thanks for this post.

    Could you please send me the SMS filter and the VB scripts to (



Skip to main content