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:
- Define global variables
- Define application specific variable
- Query Active Directory for group membership
- If computer is a member of the group, install application. If not, move to next action.
- 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:
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