This example uses PowerShell to call an Orchestrator runbook and display the results.
To demonstrate the scripting, I have created a simple runbook that will accept a string input. It’s titled “Input1”.
System Center Configuration Manager collects a surprising amount of data from both Linux and Windows based client machines. Normally the collected data may be viewed through the SCCM utility Resource Explorer but the data exists within the SCCM database and may be queried against with SQL Reporting by directly. To create custom SQL reports, knowledge of which table holds related data is a requirement.
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.
Orchestrator can be used to automate the installation of SCCM on template deployed Linux machines. Microsoft’s growing support for Linux platforms allows SCCM to be used for centralised reporting while opening the door for SCCM to become a unified platform deployment system at some stage in the future.
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.