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.
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.
For many years the “OEM” folder has been a method for copying files to the local hard drive of a machine while it was being built.
The idea was simply that anything in a particular folder would be copied to a specific drive during the Windows installation process.
The $OEM$ folder method is no longer available to modern Windows deployments. The next best thing is a replacement process using MDT.
Modern UI (Windows 8) applications differ fundamentally from widows explorer initiated applications prior to the Start Screen because we are initiating the “shell” of explorer with a shortcut instead of directly calling an executable.