Documents related to System Center Configuration Manager
Over the years I've posted a number of atricles related to using PowerShell with SCCM. The most read of these was about creating SCCM Applications with Enhanced Detection methods - specifically for File Based Detection. A number of people have asked for an example of the same script using Registry based detection for installed applications.
Not to go over old ground - the earlier blogs that may be of interest are found here:
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.
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.
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.
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.
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.
As Orchestrator is guaranteed to grow in importance for most Microsoft based organisations, the need to query the Configuration Manager database becomes more important as well.