The Deployment Guys

Helping to deploy your world automagically...

Installing Applications Using Active Directory Group Membership

Installing Applications Using Active Directory Group Membership

  • Comments 16
  • Likes

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.

Attachment: Files.zip
  • 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

  • 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.

  • 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

  • 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

  • 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", "dom\user", "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

  • Hi All,

    I'm attempting to execute a script with MDT by utilising the existing credentials in cs.ini.  

    I've got a VB script that will add the AD Group to the computer's (that it's running from) membership and upon next reboot it will install the application.  At the moment this will only work when it's logged in with an domain admin account.  MDT2010 logs in with the local administrator account when it is deploying.  Is there a way to utilize the existing MDT2010 credentials in cs.ini as that already has the credentials inside, and I don't want to be changing credentials in more than one place.

    The piece of code i've got so far is:

    Set objNetwork = CreateObject("Wscript.Network")

    strcomputername = ucase((objnetwork.computername))

    ' Adds computer to "INSTALL - Java" group

    '==========================================================

    Const ADS_PROPERTY_APPEND = 3

    Set objGroup = GetObject _

       ("LDAP://cn=INSTALL - Java,ou=Groups,dc=domain,dc=com,dc=au")

    objGroup.PutEx ADS_PROPERTY_APPEND, _

       "member", Array("cn="&strcomputername&",ou=Computers,ou=_Perth,dc=domain,dc=com,dc=au")

    objGroup.SetInfo

    Thanks in advance!!

    Regards,

    Jon

  • Hi All,

    I'm attempting to execute a script with MDT by utilising the existing credentials in cs.ini.  

    I've got a VB script that will add the AD Group to the computer's (that it's running from) membership and upon next reboot it will install the application.  At the moment this will only work when it's logged in with an domain admin account.  MDT2010 logs in with the local administrator account when it is deploying.  Is there a way to utilize the existing MDT2010 credentials in cs.ini as that already has the credentials inside, and I don't want to be changing credentials in more than one place.

    The piece of code i've got so far is:

    Set objNetwork = CreateObject("Wscript.Network")

    strcomputername = ucase((objnetwork.computername))

    ' Adds computer to "INSTALL - Java" group

    '==========================================================

    Const ADS_PROPERTY_APPEND = 3

    Set objGroup = GetObject _

       ("LDAP://cn=INSTALL - Java,ou=Groups,dc=domain,dc=com,dc=au")

    objGroup.PutEx ADS_PROPERTY_APPEND, _

       "member", Array("cn="&strcomputername&",ou=Computers,ou=_Perth,dc=domain,dc=com,dc=au")

    objGroup.SetInfo

    Thanks in advance!!

    Regards,

    Jon

  • 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

  • Hi Daniel,

    Thanks for the reply!

    I'm just wondering how I could implement Michael's solution into what I'm attempting to do:

    Basically, the user chooses which applications to install, and during the install applications task, it simply runs the script that adds the GP group to the computer's account.  So it's run from stand-alone MDT.  Where/how can I add the call to pull the credentials from the cs file?

    I admit that my vbs skills are very amatuer at best

  • @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

  • 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

  • @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

  • 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!

  • Hi Daniel,

    Nevermind.  I've figured out exactly what I wanted utilizing Ben Hunter's templates.  Dude's a genius

  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment