Innovative Technology Weblog

I noticed that is currently is impossible or at least difficult to apply Disk Quota’s based on Security Groups instead on Folder location / users. In this article I will try to explain a solution for this problem.

 

To successfully apply quota’s to groups, you need the following things:

• Windows 2008 Domain Controllers for Group Policy Preferences
• File Server Resource Manager (available on Windows Server 2003 R2 and Server 2008)
• A single file server
• Security Groups
• Vb Scripts

• Event triggered tasks

 

In this situation, there are 3 quota templates defined in the File Server Resource Manager:

• Bronze (100 MB), applied to the share \\SERVER1\HOME$\BRONZE
• Silver (200 MB), applied to the share \\SERVER1\HOME$\SILVER
• Gold (500 MB), applied to the share \\SERVER1\HOME$\GOLD

  

Ok here we go! This how-to is pretty straight forward, so if I am going to fast plz let me know!

 

1: Create the required QUOTA templates in FSRM (BRONZE, SILVER, GOLD)

2: Create a HOME$ share on a fileserver (in this example SERVER1)

3: For every QUOTA template, create a separate subfolder with the Quota name (BRONZE, SILVER and GOLD).

4: Apply the QUOTA templates on the in step 3 created folders (BRONZE -> BRONZE. SILVER -> SILVER etc)

5: Create three security Groups (in this example BRONZE, SILVER and GOLD)

6: Create a folder redirection policy for Desktop and Documents and configure it as show in the pictures below:

(pictures only show the BRONZE part, also add the SILVER and GOLD Groups\locations)

A while ago Otto Helweg wrote how to use the Task Scheduler shipped with Vista and Windows Server 2008 to create triggers based on certain events logged in the eventlogs. This post explains how to use event specific data in a triggered action to automate almost everything you can think of.

 

For example:

In company X, a drive mapping to a certain UNC share is based upon Group Membership.

There are 2 Groups that map the letter P. If the user is member of the Group Sales, he gets the mapping \\server1\sales. If the user is member of the Group Reception, he gets the mapping \\server1\reception.

 

What happens if the user is member of these 2 groups? Well that depends on the scripting capabilities of the IT department (or the way Group Policy Preferences is used).

I can tell you that something is not right…

 

What would you do?

 

At the moment, you depend on the user to report this so an administrator can remove the user from the other group.

 

 

1: Create the Task

 

Open the Event viewer on the Windows 2008 Domain Controller, and look for the event “4732″. (this is the event generated when a user is added to a domain local group).
This event can be found in the Security container. Right click the event and select “Attach Task To This Event…”

 

You are prompted to fill in a wizard. The only part of the wizard that requires some kind of input is the “Action” part. It doesn’t really matter what you do here, because we will change it later.

After the wizard is complete, open the task scheduler (start, type in task and press enter).
You can see the following is added:

 

 

2: Export the Task

From within Task Scheduler, export the task (as an XML file).

 

 

3: Modify the Task so it only reacts on specific 4732 events.

 

Currently the trigger is activated with every “Local Group membership change”.
We don’t need that!!! To fix this, we need to edit the exported XML with notepad and change the following text:

 

<Triggers>

    <EventTrigger>

      <Enabled>true</Enabled>

      <Subscription>&lt;QueryList&gt;&lt;Query Id=”0″ Path=”Security”&gt;&lt;Select Path=”Security”&gt;*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4732]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>

    </EventTrigger>

  </Triggers>

 

to: 

 

<Triggers>

    <EventTrigger>

      <Enabled>true</Enabled>

      <Subscription>&lt;QueryList&gt;&lt;Query Id=”0″ Path=”Security”&gt;&lt;Select Path=”Security”&gt;*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4732]] and *[EventData[Data[@Name="TargetUserName"]=”SALES”]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>

                </EventTrigger>

   </Triggers> 

 

By adding this line, the scheduled task is only responding to event 4732 if the value TargetUserName equals SALES (in this case this is the Local Security Group Name).

*[EventData[Data[@Name="TargetUserName"]=”SALES”]]

 

For example: If you would like to filter on certain users, you can use “MemberName” instead of “TargetUserName”).

 

 If you look at the XML view of an event, you will see how the filter works (open an event -> details -> XML view).

 

4: Modify the Task so we can use certain data from the event

 

 Now we can add some lines to use the data from the event to pass along to the action we will configure later. First we have to determine which information we want to use.
This is the Event in XML view (for me the only interesting part is the EventData section):

<Eventxmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>
<System>
 <EventData>

                <Data Name=”MemberName”>CN=Benno Zelders,DC=TEST,DC=lan</Data>

                <Data Name=”MemberSid”>S-1-5-21-4012033790-4084158397-284283626-1332</Data>

                <Data Name=”TargetUserName”>SALES</Data>

                <Data Name=”TargetDomainName”>TEST</Data>

                <Data Name=”TargetSid”>S-1-5-21-4012033790-4084158397-284283626-1333</Data>

                <Data Name=”SubjectUserSid”>S-1-5-21-4012033790-4084158397-284283626-1206</Data>

                <Data Name=”SubjectUserName”>administrator</Data>

                <Data Name=”SubjectDomainName”>TEST</Data>

                <Data Name=”SubjectLogonId”>0×55193</Data>

                <Data Name=”PrivilegeList”>-</Data>

 </EventData>

</Event>

 

I personally find it very useful to use <Data Name=”MemberName”>, because it shows which user is added to the group. To allow the eventdata parameter to pass along to the action, we need to add the following lines to the XML just before the </EventTrigger> line:

 

<ValueQueries>
<Value name=”MemberName”>Event/EventData/Data[@Name='MemberName']</Value>
</ValueQueries>

 

 The end result of the <Triggers> part of the XML is:

 

<Triggers>

<EventTrigger>

<Enabled>true</Enabled>  

<Subscription>&lt;QueryList&gt;&lt;Query Id=”0″ Path=”Security”&gt;&lt;Select Path=”Security”&gt;*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4732]] and *[EventData[Data[@Name="TargetUserName"]=”SALES”]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>

 <ValueQueries>
 <Value name=”MemberName”>Event/EventData/Data[@Name='MemberName']</Value>

</ValueQueries>
</EventTrigger>

</Triggers>

 

Now we can use the $(MemberName) variable in an action!.

 

5: Import the “Modified XML” in task scheduler

 

First we have to delete the original task from the task scheduler.

After this is done, we can import the modified XML by right clicking folder “Event Viewer Tasks” and select “Import Task”

 

 

 

6: Create the action using the variable

 

First remove the action created in the wizard (open the task, go to “Actions” and remove the existing action.  Now we can create the action to automatically remove the user from the “RECEPTION” group after he is added to the “SALES” group.  (Click New and select “Start a program”). This can be accomplished running a command by using the Active Directory extensions for powershell from QUEST (to automatically load the Quest snap-in, see this page).

 

 
Program/script:    Powershell.exe
Add arguments:    -command Remove-QADGroupMember –identity RECEPTION –member ‘$(MemberName)’

 

And click ok twice.

 

Now the user is automatically removed from the group RECEPTION after it is added to the SALES group. (if it doesn’t work, check the “Run with highest privileges” option in the tab “General”. UAC can block this action).

 

Of course this can be fine-tuned, but you get the idea right? Now it is possible to create all sort of tasks that use data passed through from an event!

 

Regards,
Benno Zelders