Powershell related code snippets
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.
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.
Windows Installer has been the default installation format on Windows machines for well over a decade now. The technology was elegant and powerful but proved too complex for the subtle quirks to be fully understood by many people working with technology.
SCCM 2012 R2 is a great product but I have some strong disagreements with some elements of how it deals with software management. By default, the product suggests that a Windows Installer Product Code can be used to uniquely identify when a package is installed to a machine. This is a misunderstanding that “Product Codes” are not unique to Windows Installer packages – “Package Codes” are. It also overlooks that the same utility or product may be installed in an organisation as different variants such as the “HR package” or the “Spanish package” or the “me
I recently was on site in an organisation that needed the ability to remotely run commands against each of their deployed workstations. As the organisation didn't have a software deployment system, powershell remoting appeared to be the answer.
There is a problem however. Even though Group Policy allows Windows Remote Management to be enabled on remote machines, you'll find it doesn't actually work.