At the last three Configuration Manager Deployments that I’ve done, the customers have each asked the same question about OSD: is there a way to interactively choose applications to install at deployment time. Tired of saying no, I built the following small, yet hopefully flexible application appropriately titled the “OSD Application Chooser”.
What is it:
A small application that allows applications to be interactively chosen at deployment time during an OSD Task Sequence.
How to:
- Create an XML configuration file based on the supplied sample. The configuration file defines the following items:
- A Timeout value. This specifies how long to wait for user input before moving on. The value is specified in number of seconds. If you specify 0, the GUI will not timeout.
- A Task Sequence Variable. This specifies the base variable name to use for the Install Software task. This can be any valid task sequence variable name. This variable gets populated with the application choices that the user makes.
- Application Sets. These are sets of applications that the user can choose from. Each AppSet is displayed in the combo-box at the top of the GUI. When the user changes the AppSet the set of applications shown in the list box changes. Users may only choose applications from one AppSet. If you set the task sequence variable OSDAppSet to one of the defined AppSets, only that AppSet is displayed to the user and the combo box is disabled.
-Applications. These are the actual applications that you select during the deployment. Each Application is part of an AppSet. You must specify the package ID and program name for each Application. Make sure that the programs specified have the Allow this program to be installed from the Install Software task sequence without being advertised check box on.
- Put OSDAppChooser.exe and OSDAppChooser.xml into a software distribution package and install it onto the appropriate distribution points; no programs are necessary.
- Insert a command-line task in your task sequence with OSDAppChooser.exe specified as the command-line. If your task sequence is configured to download all source files first, this task must come after the partition and format task if you are deploying to a bare-metal system. Otherwise, you can place the task anywhere.
- Insert an Install Software task into the Task Sequence after the command-line task that you just created, preferably near the end; follow the example of the built-in task sequence types. Set the base variable name to the one you configured in the configuration file.
- Deploy your Task Sequence.
Troubleshooting:
A log file named OSDAppChooser.log is placed in the same directory as the SMSTS.log file and is formatted the same as other ConfigMgr log files. You can also run OSDAppChooser.exe outside of ConfigMgr to test your configuration file. In this case, a log file will be created in %temp%.
Download:
This zip file contains the executable (OSDAppChooser.exe), a sample xml configuration file (OSDAppChooser.xml), and the two AutoIt v3 source files.
The ConfigMgr Prerequisite checker typically does a good job of making sure that everything is in place for an installation of ConfigMgr. It also usually does a good job of telling why a check failed. Unfortunately, this week I started an implementation at a client and ran into the following results:
The double whammy, both “SQL Server sysadmin rights” and “SMS Provider Communication”.
I chased after just about everything including SPNs, kerberos, name resolution, account permissions, UAC, and more. I ended up creating a near replica of the environment in my home lab to experiment and test a working theory. Here’s a quick run-down of the environment:
- Windows 2003 Active Directory Domain
- Windows 2003, 4 node, SQL Server 2005 Cluster
- Non-default Instance of SQL
- Windows 2008 Primary Site Server
After trying endless permutations with varying, seemingly inconsistent results, I finally realized that the prerequisite checker was being blocked by the Windows 2008 firewall. Once I realized that, and was able to consistently reproduce the behavior, it was easy to figure out why:
- By default, SQL Server listens on TCP port 1433. The non-default instance of SQL Server was not listening on 1433.
- In order for SQL client applications to discover non-default instances of SQL or instances not listening on TCP port 1433, the SQL Browser is contacted by the SQL client.
- The SQL Browser listens and responds on UDP port 1434.
- Thus, the prerequisite checker (or any SQL client) contacts the SQL Browser to find the TCP port number of the non-default instance of SQL.
- The reply, being UDP, is blocked by the Windows firewall and thus the instance is never actually found by the checker and a ripple effect occurred causing error messages that really had nothing to do with the issue at hand.
The solution is to allow UDP traffic on port 1434 from all nodes of the cluster through the Windows firewall. One interesting thing is that once a SQL client finds the port number for an instance of SQL, it caches this and no longer needs to rely on the SQL Browser to find the instance.
One big take away for me is to always temporarily disable the firewall when troubleshooting any type of potential communication issue. I stress temporarily because the firewall is a good thing. If you determine that the firewall is indeed blocking traffic, the next step is to figure out what holes to create in the firewall, re-enable it, and test again.