SCCM 2012 R2: Planning the bulk import of applications

  • Article

The problem

We were recently approached by a customer faced with a hard deadline enforced by the end of life of ITCM. They have 3 months to migrate to a new deployment architecture.

They have hired a consultant to sequence all the applications that can be sequenced and the remaining packages will be imported as they are. This work has already commenced but when I asked if they had applied a consistent naming convention I was informed that they had not. Great.

Although this is both encouraging, for the fact that they have done something proactive, and frustrating, because they have implemented it badly or without pre-planning, it is not an insurmountable problem.

The case against the manual method

This one is pretty easy: an SCCM administrator will spend an average of 3 hours per application to import and configure each individual application;

Tasks, multiplied by 400

  1. Create the application in the SCCM console
  2. Customise the command line to include a log file (MSI only)
  3. Distribute the content to the distribution points
  4. Create the per application user collection with membership based upon an AD group
  5. Create the deployment to the new collection

Accumulated time

  • 400 applications x 3 hours = 1200 hours
  • or 150 days
  • or 30 weeks
  • or 7.5 months

Aside from the fact that this would be an horrendous experience for the administrator(s) this would be a massive waste of skilled resource.

Inspiration for Automation

http://www.markallenit.com/blog/wp-content/uploads/2015/10/Professor_Lucifer_Butts-300x212.gifDavid O'Brien has created a wonderful script to import MSI and legacy setup.exe applications based on an XML definition: here.

Deepak Singh Dhami has some useful examples for creating folders and moving applications into them here and another for distributing the content to the distribution point, creating a collection and creating the deployment here and here.

Armed with this inspiration I put together a proof of concept to demonstrate the possibilities. You can see the successful POC script here.

However PowerShell is not the only option. We can use the Configuration Manager SDK and C# to perform many of the same actions. You can see a basic example here and this is also something that we will look at for this mini project.

Preparing for automation

http://www.markallenit.com/blog/wp-content/uploads/2015/10/2015-10-29-16_57_41-System-Center-2012-R2-Configuration-Manager-Connected-to-I01-ICC-HQ-Primary-S.png

In our environment applications are stored in folders according to vendor names as shown to the right, therefore we require the vendor name for each packaged application.

Given the absence of a naming convention we have a conundrum; I know from experience that we can extract MSI details using WMI queries but it is a little trickier with App-V. We can extract information in the package (using something like this) but the application manufacturer is not stored as a separate entity within the package.

This unfortunately means that the process cannot be fully automated but we can delegate a more menial task; organising the directory structure.

We will define a strict naming structure for the directories that contain the packages; we can then traverse this to extract the relevant information. This also gives us a repeatable formula that can be reused in ongoing or future projects.

Proposed automated solution

As with any early stage planning this could change but we will set out with the following process in mind.

http://www.markallenit.com/blog/wp-content/uploads/2015/11/SCCM-app-import-224x300.png

As a prerequisite all packages should be organised according to a predefined folder structure.A strict naming convention should be applied that clearly separates the vendor name, application name and version number.

  1. Packages scanned for structure and naming integrity.
    1. Report issues and break or continue.
  2. Packages scan creates an XML document detailing application properties ready for import.
  3. The XML is processed, each section will import an application into SCCM;
    1. Create the application.
    2. Move the application into the vendor folder.
    3. Create the deployment type.
    4. Distribute the content to the distribution point(s)).
    5. Create the collection.
    6. Deploy the application to the collection.
  4. Report successful and unsuccessful imports.

Next steps?

Planning is one thing but plans are rarely static; they evolve as we experiment and then evolve some more during testing, but this is not a reason to omit planning. Building upon solid foundations ensures that the most value is extracted from the exercise. For instance I can already see possible uses for the code that we will create for this project; the import of future applications on an ad hoc basis could be automated giving further cost savings on an ongoing basis. For this reason we should develop the code with this in mind. A further advantage of automating future application imports would be in ensuring consistency in the environment.

Sometimes the first urge is to jump straight in a write the code but putting a little forethought in is always worthwhile. I always try to write code with reusability in mind; it means that with every piece of code I write my job becomes a little easier, or in case a customer is reading this, I become more efficient.

Next we will develop the script in PowerShell or C#. I will write a followup blog post detailing the decision process and the result. Please let me know your thoughts so far in the comments section or if this post has been helpful for you.