Laurie Rhodes' Info

I’ve written a fair bit about automating SCCM application creation by script.  Most of this has originated from the need to use Enhanced Detection Methods for determining when Applications are installed as I know from many years of Application Packaging that unless an official “package” produces a standard file or registry based flag when it’s installed, it becomes impossible to tightly manage a software environment. 

It's now been a decade since I've supported Zenworks in a commercial environment... it really was a gret product.  There was no PowerShell and every engineer used a bag full of DOS type utilities to overcome limitations with supporting machines.  

The code snippet below is an example of how to recursively list all of the requirements that have been set against SCCM Applications within an environment.

There can be many reasons for needing site specific data related to an IP address.  I had a recent requirement for Orchestrator to configure machines when the only input was the IP Address of the target machine.   This solution uses PowerShell to compare an IP Address to an XML based lookup table of site information.  By finding the right site, other locale details can be used through Orchestrator.  The XML below represents the site information needed by my particular process.

Resolving file paths within MSI databases can be a complex piece of coding.  It involves linking files to components and components to the directory table.  The complexity is due to the flexibility of Windows Installer in determining how directory table entries are referenced.

A number of previous posts have provided examples of how to script against SCCM 2012 Applications.

The script below is an example of how to attach a Deployment Type dependency rule to a scripted application.  If you havent done so, take the time to have a look at my recent blog into SCCM rules to get a better idea of what is happening.

System Center heavily uses rules for definining how software elements relate with each other.  They aren't extensively documented but must be understood by anyone trying to script SCCM applications.   At the highest level, a rule can be seen to comprise of an Expression and an Annotation that are combined with an overall severity level for noncompliance.  The same structure I used throughout System Center so the severity level of noncompliance changes on the type of rule being used. 

System Center Orchestrator has a built in activity for running SSH on remote machines.  You may find that working runbooks start failing on new distributions of linux or with hardened machines.

Orchestrator’s ssh is simply calling the command-line version of putty (called plink) from the C drive of the Runbook Server.  The executable is located in:

An area of current difficulty with technology management is the inability to rely on particular versions of Dot Net being uniformly available across the enterprise.  I’ve used Dot Net for the standardisation of software packages as it allows for standardised interfaces with software management to occur.