Share via

Installing Applications Using Active Directory Group Membership

  • Article

Mike recently posted on how to take an MDT action based on group membership in Active Directory.  At the same time, I was working on something quite similar but using a different approach, so I thought I’d blog it here to offer an alternative method to the one Mike describes; I’ll leave it up to you to decide which one to use!

With this solution you can dynamically install applications during a LiteTouch deployment based on the membership of Active Directory groups, this means that each computer deployment can be uniquely customised, without the need for complex scripting or advanced infrastructure.  All that is required is this blog post, a group created in Active Directory for every application that will be dynamically installed, and all computer accounts pre-created in the domain and added to the relevant application groups.

The process is as follows:

  1. Define global variables
  2. Define application specific variable
  3. Query Active Directory for group membership
  4. If computer is a member of the group, install application.  If not, move to next action.
  5. Clean up variables used

The five steps above can be looped through as many times as required, but steps two to four are required for each application installation.  I created a demo task sequence that implements the working solution, shown below, to help visualise the sequence:

1

As is is not clear from the screenshot above, each step is explained below (note that you can name the actions as you wish, but the task sequence variables must adhere to the specifications here otherwise the script will fail.  As you can see, inside the AppInstall group, there are five actions and a task sequence group for each dynamic application install.  The group “Install – App1” consists of the following (these actions are identical for all subsequent application groups):

  • INSTALLAPP – a task sequence variable, the value set is FALSE.
  • DomUser – a task sequence variable called DOMUSER, the value set is the fully qualified domain name of user in the target domain, i.e. where the computer account exists and also where the group has been created.
  • DomPassword – a task sequence variable called DOMPASSWORD, the value set is the password of the previous mentioned account - stored in clear text.
  • FQDNDC – a task sequence variable called FQDNDC, the value set is the fully qualified domain name of a domain controller in the target domain.
  • NetbiosDC – a task sequence variable called NETBIOSDC, the value set is the NetBIOS name of the previous domain controller.
  • Group – App1 – a task sequence variable called ADGROUP that specifies the fully qualified domain name of the application group to check .
  • Query LDAP – App1 – a “Run Command Line” action that launches the script CUSTOM_AppInstall.wsf using CSCRIPT.exe
  • Install Application – App1 – A standard “Install Application” task sequence action, configured to install App1.  It has a condition set to only launch if the value of INSTALLAPP is TRUE.
  • CleanUp – App1 – resets the value of the task sequence variable INSTALLAPP to FALSE.

To implement this solution in your task sequence, you should first copy the WSF script file into the .\Distribution\Scripts folder, and then create all the task sequence actions as described.  In the attached .ZIP file to this post are screenshots of each action as well as the script file; these should help you configure the actions correctly.  There are a couple of points you should be aware of:

  • The password for the user is stored in the XML file for the task sequence in clear text.  Consequently, do not use any user account that has any rights on the domain, this account should be as limited as possible.  It would not be hard to edit the script file so that you could include encryption, or obfuscation in order to improve security.  I’ll try to post an update of this script in the future in order to include this feature.  You might be able to recycle some of the code from this post if you wish to do it yourself.
  • The script does not log any entries in any of the MDT log files, this can make debugging a bit tricky.  The script has been tested and I have it working onsite with a customer, the only problems you are likely to have are related to incorrect FQDNs specified.  I find the use of ADSIEdit on a domain controller useful to find out the correct FQDN of the user or a group.  Again, the future version of this script will include logging functionality.
  • The solution differs to Mike’s in that it works during the task sequence for computers that are not members of the target domain, or are logged on as a non-domain user account (such as the local administrator account used during the LTI install).  This is the reason for having to include a user account and password in the task sequence, binding is needed with a domain controller in order to run an LDAP query.  Also, Mike’s solution uses the CustomSettings.ini file which means that it can be shared between various task sequences, what I detail here is task sequence specific.  I chose this approach though because I wanted to use a more graphical approach for configuring the variables.
  • All the steps inside the group “Install – App1” are required for every dynamic application installation.  The five previous steps to this group only need to be added to the task sequence once.
  • You can include system reboots in the sequence.
  • This post describes using an LDAP query to dynamically install an application, but it could be easily adapted for any other task sequence action :-)

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

Files.zip

Comments

  • Anonymous
    January 01, 2003
    hi Daniel, great post, i've modified your script slightly and changed the task sequence to work natively in SCCM 2007 sp2, and I've posted a guide for it on windows-noob for anyone that is interested http://www.windows-noob.com/forums/index.php?/topic/1782-how-can-i-deploy-applications-based-on-ad-security-group-membership-for-computers-using-a-task-sequence/ you'll notice that i've reduced the steps in the task sequence by setting the InstallAPP variable within the script itself to FALSE by default, it will only change to TRUE when found in the membership check, cheers niall

  • Anonymous
    January 01, 2003
    Hi Daniel, Nevermind.  I've figured out exactly what I wanted utilizing Ben Hunter's templates.  Dude's a genius

  • Anonymous
    January 01, 2003
    j_seet, Look at the post previous to this one, written by Michael Murgolo.  IIRC, he wrote a script that does the same as this one, but retrieves the credentials from the CustomSettings file

  • Anonymous
    January 01, 2003
    Jake, Nice to hear that you find it useful!  Let me elaborate on your question. In order for the script to work, the groups must already exist in Active Directory.  This means that, being being able to deploy a computer, the computer account must have been pre-created (often called pre-staging) in Active Directory.  Additionally, the groups need pre-creating for each application, and then the correct pre-created computer accounts added to these groups. Once done, the script will read the computers hostname, then run an LDAP query to confirm if a computer account with the same name as the hostname belongs to the specified group. Is that clearer? HTH, Daniel p.s. If you are using ConfigMgr, then you could also deploy applications to groups of computers without the need for my script.  I wrote the script with LiteTouch installations in mind.

  • Anonymous
    January 01, 2003
    Thanks Niall, I had been meaning to update it for SCCM - no need now, you've done it! BTW, I had originally included the InstallApp variable inside the script.  I just took it out and put it in the task sequence for transparency and so people could see how it worked. Thanks, Daniel

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Hi Daniel, This is why i'm wanting to install software via a group policy security groups.  We don't have SCCM/SMS.  I was just hoping that you could help me find a way to get the "install applications" task to add a security group to a computer account. If not, thanks anyways!

  • Anonymous
    January 01, 2003
    @j_seet No, my solution will not force the application to uninstall when taking the computer out of a group.  In order to achieve that you would need to use something like SCCM in order to handle the application inventory on each machine. Daniel

  • Anonymous
    January 01, 2003
    Jake, I am wondering if you are not quite following me.  This solution doesn't use any ConfigMgr groups, nor does it require it.  I wrote it for LTI installs, but it would work with ZTI as well.  Here is the process: 1.) Create a group in Active Directory 2.) Create a computer account object in Active Directory 3.) Add computer object to group created 4.) Add this solution to MDT and specify the DN for the AD group in the task sequence. 5.) Run deployment. 6.) The app will install if the script finds that the computer account (the one for the computer running the install) belongs to the specified group. HTH, Daniel

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    @j_seet I think Iam missing something...  Why not just have the applications in MDT.  Then, when the user chooses the apps to install at the start of the MDT process, they will all get installed - this way you won't need to use Active Directory groups to install the applications. What you want to do seems rather convoluted...  I really wouldn't try to do it your way unless you have a very specific reason for it. Daniel

  • Anonymous
    June 24, 2009
    Daniel - this is exciting and could be a great replacement for role-based deployment scenarios. I have a question about "all computer accounts pre-created in the domain and added to the relevant application groups."  Can you elaborate on this? I want to create an "Engineering" Task Sequence that will install 3 applications based on AD Group.  These 3 Engineer apps are setup so that we can add members to those groups and deploy via ConfgMgr. Can you explain what I need to do to accomplish this? Thanks! Jake

  • Anonymous
    June 25, 2009
    Hi Daniel, Awesome stuff!  So, if I am hearing what I think I am hearing, you're saying that with this solution, before we do a deployment..1) the AD group containing the application needs to exist and 2)The PC name needs to be collected and added as a member to the appropriate AD group? For example, I have an SMSpkg Group containing my engineering app and I would add the PC name for that machine to this AD group?  Is this correct? Thanks for sharing this stuff...it is great! Jake

  • Anonymous
    July 13, 2009
    Is it possible to use this solution with the PutEX or Put Methods of the ADSI objects? I've written a few scripts to test it, and continue to recieve the same "General access denied" errors i recieved when i use a normal ADSI LDAP connection instead of the OpenDSObject method with supplied credentials.   I'm trying to add some build scripts into my process to add PC's to security groups based on make/model and location in some situations (WSUS Policy groups, Wireless policy groups, things like that).  I'm assuming a run-as is still going to be required due to the access denied error i'm still recieving, however there are issues with the RUNAS feature in MDT i've found as well. (maybe not newer versions, but my current revision of MDT2008 is somewhat picky it seems) I've included a quick example: , both Put and PutEx fail with the same error. Set objSysInfo = CreateObject("ADSystemInfo") sComputerName = objSysInfo.ComputerName Set dso = GetObject("LDAP:") Set objGroup = dso.OpenDSObject("LDAP://mydcname/cn=WSUSGroup,dc=subdomain,dc=domain,dc=com", "domuser", "password", ADS_SECURE_AUTHENTICATION + ADS_SERVER_BIND + ADS_FAST_BIND ) objGroup.Put "member", Array(sComputerName) objGroup.SetInfo objGroup.PutEx ADS_PROPERTY_APPEND, "member", Array(sComputerName) objGroup.SetInfo Thanks, -Dustin

  • Anonymous
    November 05, 2009
    The comment has been removed

  • Anonymous
    November 06, 2009
    Hi Daniel, I've opted for this because we want the the software to uninstall if the AD group is taken out of the computer account or falls out of scope (removed from domain etc). I've trialled your suggestion before but it doesn't allow the flexibility of GP scopes.  hope that makes sense