Just a heads up to whomever may find this blog...

Phil and I have both moved on in our careers and the updates to this blog have ceased. Phil has shifted focus more to the application developement side of IT, I have shifted focus to the implementation of the System Center products.

I will be maintaining a new blog focused primarily on System Center Operations Manager & Configuration Manager, and to a degree application packaging. My new blog can be found here:

http://systemcenterinfo.blogspot.com/

It is newly created as of today, however it will be updated frequently as I encounter new solutions and behaviors of SCCM/OpsMgr. Stop by and check it out.

Regards,
Will Kaiser

Query: Build collection to exclude members of another collection

This has proven to be quite useful. Here's how to create a query-based collection that will exclude members of another collection:

1. Create a collection that will contain all clients to be excluded from another collection (we'll call it 'ExclusionsCollection' for this example.)

2. Once you have that, go into the Collections table in the SMS SQL database and find the row that contains 'ExclusionsCollection'. Note the cooresponding 'ResultTableName'.

3. In the collection that you want to exclude the members of 'ExclusionsList' from, copy and paste the following query:

select SMS_R_System.ResourceID,SMS_R_System.ResourceType,
SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,
SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client
from SMS_R_System where Client = 1 and ClientType = 1 and
ResourceId not in (select ResourceID from SMS_CM_RES_COLL_XXXxxxxx)

4. Replace the item above in red with your ResultTableName.

So, machine will be manually entered into 'ExclusionsCollection' will be excluded from the collection with the above query. So say that you wanted to deploy a package to all XP machines except for a specific few, you'd create a collection and limit it to the 'All XP Machines' collection, and then add the above query.

SMS: Useful...stuff

Here's a few useful things to note when deploying packages:

- Use "CMD.EXE /C" in front your command to run it from the command prompt.

- Need to apply a patch to an application that you are deploying, but need a reboot in between? Try creating 2 advertisements, one for the main application and one for the patch. Set the main application install to run as soon as possible and set the patch to run at Logon. The machine will not receive the second advertisement until after they next log on to their machine.

- When deploying an MSI file use the ‘Create package from definition’ option. This will create attended and unattended installation programs, as well as an uninstall program.

- Good practice: Build an uninstall program for your package when you build the install program. You’ll thank yourself later when you don’t have to spend a few hours testing the install and determining the best route to uninstall.

- Suppress the annoying reboot notification box that still appears after a patch installation, even though the reboot has been suppressed with this command: net stop wuauserv

- A word on patches. In the event that your environment has a large number of individual patch packages with individual advertisements, try rolling all the patches into a single package with a single advertisements. The reason? The patch management system in SMS is intelligent enough to roll numerous patches into a single install. So in effect, if you have 15 patches in 15 packages with 15 associated advertisements, new clients in the environment are going to experience quite a bit of processing overhead b/c of those advertisements. Take those 15 patches and roll them into a single package with a single advertisement, and clients will install the patches faster and experience less of a slow-down.

How best to handle Microsoft re-release of security patches

From time to time, some security patches need adjustments to correct issues that have been discovered. Microsoft attempts to resolve this by releasing a new version of an existing patch or by releasing a new patch the replaces a previous patch.

To date, I have encountered 4 different ways that a re-release patch can show up in the DSUW.

1. Direct replacement.

What this means is that the re-release patch appears in the DSUW as the same patch number of the original patch. So the scan tool has the new criteria for the patch but the patch package does not. What kind of impact can this have? Your systems will continue to try to install the patch, even if it is the old one installed. In some cases you may see or hear about systems continually applying patches. The best method of managing this is to de-authorize the patch in the package and test the new patch and implement according to the patching guidelines established by your organization. Unfortunately, I can not recall the last time and exact patch that I have seen this, but it wasn’t that log ago.

2. New version of an existing patch and this patch overwrites the original one.

What this means that the scan tool is aware of the new patch, but the patch package is not. There would be no impact on your systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Unfortunately, I can not recall the last time and exact patch that I have seen this, but this too wasn’t that log ago.

3. New patch that requires the old patch to be uninstalled.

What this means is that efforts outside of the DSUW patching process have to be performed to uninstall the original patch, thus allowing patching to occur via the normal patching process. There is no direct impact to the systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Patch MS06-025 would be an example of this.

4. Patch to a patch or a hotfix to an existing patch.

What this means that a fix is needed to correct an existing patch. This will usually require actions outside of the DSUW. There is no direct impact to the systems when the scan tool is updated. You would need to authorize this and test the new patch and implement according to the patching guidelines established by your organization. Patch MS06-015 & MS06-042 (hotfix released prior to the re-release) would be examples of this.

One of the best things that can be done to control the possible impact of these re-release patches is to control how often the scan tool checks in for updates. As some of you may have noticed, the wsusscan.cab is updated between patching cycles. Usually these updates are to correct something within the cab, like a misspelling of words or a clarification of statement made in the patch description. Often these updates go without notice or warning.

The next thing that can be done is to monitor your patch compliance. If compliance numbers go down or there is a second listing of a patch (for the same OS) that wasn’t there before, or you notice that a patch that has been authorized in your patch package, but your compliance number are not going up. Then you may have a re-release patch on your hands.

Reference: Setup.exe commands

Setup.exe Command Line Parameters

Special Installation Modes
* /a : Administrative installation
* /j : Advertise mode
* /x : Uninstall mode
* /uninst : Uninstall product (InstallScript MSI projects only)

Silent Installations
* /p : Specify password
* /r : Record mode (InstallScript MSI projects only)
* /s : Silent mode
* /f1 : Specify alternative response file name (InstallScript MSI projects only)
* /f2 : Specify alternative log file name (InstallScript MSI projects only)

SMS Data
* /m : Generate MIF file (InstallScript MSI projects only)
* /m1 : Specify serial number in MIF file (InstallScript MSI projects only)
* /m2 : Specify locale string in MIF file (InstallScript MSI projects only)

Download and Cache Locations
* /ua : Specify URL for InstMsiA.exe
* /uw : Specify URL for InstMsiW.exe
* /us : Specify URL to ISScript.msi
* /um : Specify URL to .msi package
* /b : Cache installation locally

Passing Data to the Installation
* /v : Pass arguments to Msiexec
* /z : Pass arguments to CMDLINE variable

Debugging
* /d : Debug InstallScript (InstallScript MSI projects only)
* /verbose : Generate verbose InstallScript engine log file (InstallScript MSI projects only)

Miscellaneous
* /f : Specify alternative compiled script (InstallScript MSI projects only)
* /h : Clone release to a temporary location and run from that location
* /L : Setup language
* /w : Wait
* /SMS : Wait (InstallScript MSI projects only)

Special Installation Modes
*/a : Administrative installation
*/j : Advertise mode
*/x : Uninstall mode
*/uninst : Uninstall product (InstallScript MSI projects only)

Silent Installations
*/p : Specify password
*/r : Record mode (InstallScript MSI projects only)

In order to run an InstallScript MSI project installation program in silent mode, one must first run Setup.exe with the /r switch to generate a response file, which stores information about the data entered and options selected by the user at run time. Running an InstallScript MSI installation program with the command Setup.exe /r displays all the run-time dialog boxes, and stores the data in a file called Setup.iss, created inside the system's Windows folder. To specify an alternative response file name and location, use the /f1 argument, described below. Basic MSI projects do not create or use a response file for silent installations.

*/s : Silent mode - For an InstallScript MSI project, the command Setup.exe /s runs the installation in silent mode, by default based on the responses contained in a response file called Setup.iss in the same directory (response files are created by running Setup.exe with the /r option). To specify an alternative file name or location of the response file, use the /f1 option, described below.

The command Setup.exe /s also suppresses the Setup.exe initialization window for a Basic MSI installation program, but does not read a response file. To run a Basic MSI product silently, run the command line Setup.exe /s /v/qn. (To specify the values of public properties for a silent Basic MSI installation, you can use a command such as Setup.exe /s /v"/qn INSTALLDIR=D:\Destination".)

*/f1 : Specify alternative response file name (InstallScript MSI projects only) - Using the /f1 argument allows one to specify where the response file is (or where it should be created) and what its name is, as in Setup.exe /s /f1"C:\Temp\Setup.iss". The /f1 switch is available both when creating a response file (with the /r option) and when using a response file (with the /s option).

*/f2 : Specify alternative log file name (InstallScript MSI projects only) - When running an InstallScript MSI project installation program in silent mode (using the /s argument), the log file Setup.log is by default created in the same directory as the response file. The /f2 argument allows one to specify an alternative log file location and file name, as in Setup.exe /s /f2"C:\Setup.log".

SMS Data
*/m : Generate MIF file (InstallScript MSI projects only) - The /m switch causes Setup.exe to generate an SMS Management Information Format (MIF) file. A typical command is Setup.exe */m"SampleApp". (Including the “.mif” file extension is not necessary.)
/m1 : Specify serial number in MIF file (InstallScript MSI projects only) - Using the /m1 parameter (along with /m) enables you to specify a serial number to be written to the MIF file. A typical command is Setup.exe /m"SampleApp" /m1"1234-5678".
*/m2 : Specify locale string in MIF file (InstallScript MSI projects only) - Using the /m2 parameter (along with /m) enables you to specify a locale string to be written to the MIF file. A typical command is Setup.exe /m"SampleApp" /m2"ENU".
*/b : Cache installation locally - In the Release Wizard, for a Downloader build, you can specify whether to cache the contents of a compressed package on the local system. With the /b argument, the user can specify the directory in which to cache the installation files, as in Setup.exe /b"C:\CacheDirectory".

Passing Data to the Installation
*/v : pass arguments to Msiexec - The /v argument is used to pass command line switches and values of public properties through to Msiexec.exe.
*/z : Pass arguments to CMDLINE variable - The /z argument is used to pass data to the InstallScript system variable CMDLINE, as in Setup.exe /z"My Custom Data", after which the variable CMDLINE would contain the string "My Custom Data".
*/verbose : Generate verbose InstallScript engine log file (InstallScript MSI projects only)
For an InstallScript MSI project installation program, you can create a verbose InstallScript-engine-installation log file using the /verbose argument followed by the path to the log file you want to create. A typical command is Setup.exe /verbose"C:\IS.log". The log file generated can help you troubleshoot errors in installing the InstallScript engine on a target system. The /verbose option requires a full path to the log file, and not a relative path.