SCCM Report Comparing Add/Remove Programs on two Computers

Yes, I know that the builtin Report 97 lists differences between the software inventory reported for two selected computers. BUT! That is not what I want, as this report lists only the discrepancies, and more importantly it is based on software file collection, not for Add/Remove programs. I want a list that shows me what is different (on each computer), and what is the same between two computers in regards to Add/Remove Programs. This SQL query I created utilizes multiple subselect queries and requires 2 prompts. I have found this report to be a great help when troubleshooting, especially when looking at 2 Citrix servers that should be the same and ask myself, what is different?

First, when creating the report, paste in the SQL statement found at the very bottom of this post. Then, click on the Prompts button to open the next dialog.

Click on the New button, which will open the new prompt dialog. We need to create 2 prompts so that we can enter 2 computer names. The first variable we want to enter is Computer1, with Prompt text as shown. Next, we also want to Provide a SQL statement so that we can use wildcards to find our computer names a little easier. Use the following SQL statement for the “Prompt SQL statement”:

begin if (@__filterwildcard = ”)   SELECT DISTINCT SYS.Netbios_Name0 from v_R_System SYS WHERE SYS.Client0=1 ORDER By SYS.Netbios_Name0 else   SELECT DISTINCT SYS.Netbios_Name0 from v_R_System SYS WHERE SYS.Client0=1   and SYS.Netbios_Name0 like @__filterwildcard   ORDER By SYS.Netbios_Name0 end

Afterwards, make another prompt just like above and name it Computer2. When finished, your prompts should look like this.

Hit OK, finish the wizard, and take it for a spin!

************* SQL STATEMENT BELOW HERE ************

SELECT     one.Computer1Name AS [Computer 1 Name], one.Computer1Display AS [Display Name], one.Version0, two.Computer2Name AS [Computer 2 Name],                       two.Computer2Display AS [Display Name], two.Version0 FROM         (SELECT     v_GS_ADD_REMOVE_PROGRAMS.DisplayName0 AS Computer1Display, v_R_System.Netbios_Name0 AS Computer1Name,                                               v_GS_ADD_REMOVE_PROGRAMS.Version0, v_GS_ADD_REMOVE_PROGRAMS.InstallDate0                        FROM          v_GS_ADD_REMOVE_PROGRAMS INNER JOIN                                               v_R_System ON v_GS_ADD_REMOVE_PROGRAMS.ResourceID = v_R_System.ResourceID                        WHERE      (v_R_System.Netbios_Name0 = @Computer1) AND (v_GS_ADD_REMOVE_PROGRAMS.DisplayName0 IS NOT NULL))                       AS one FULL OUTER JOIN                           (SELECT     v_GS_ADD_REMOVE_PROGRAMS_1.DisplayName0 AS Computer2Display, v_R_System_1.Netbios_Name0 AS Computer2Name,                                                    v_GS_ADD_REMOVE_PROGRAMS_1.Version0, v_GS_ADD_REMOVE_PROGRAMS_1.InstallDate0                             FROM          v_GS_ADD_REMOVE_PROGRAMS AS v_GS_ADD_REMOVE_PROGRAMS_1 INNER JOIN                                                    v_R_System AS v_R_System_1 ON v_GS_ADD_REMOVE_PROGRAMS_1.ResourceID = v_R_System_1.ResourceID                             WHERE      (v_R_System_1.Netbios_Name0 = @Computer2) AND (v_GS_ADD_REMOVE_PROGRAMS_1.DisplayName0 IS NOT NULL)) AS two ON                       one.Computer1Display = two.Computer2Display ORDER BY [Computer 1 Name], [Computer 2 Name]

What the HAL is going on with these E6510 and E6410s?

At my place of employment, we recently ran into some issues integrating Dell’s newer model of laptops, the E6510 and the E6410, into our imaging process for the deployment of Windows XP SP3.

We experienced 3 varied issues that are described as follows:

  • ·         The first occurs on both the E6410 and 6510 XP SP3 is related to the ST Micro Accelerometer driver (Version 1.0.0.3 1/4/2010) that is included with the E6510 and E6410 XP SP3 x86 driver cab file downloads. If at any point this driver is installed, regardless of installation method, the system will lock up at shut down and sporadically during startup. Simply disabling this driver in SCCM fixed the issue. I also downloaded this driver individually and ripped it apart. I found that it is the same version and modify date as the one included in the CAB files. I can only tell you what I know, which is I have never seen this driver installed without the side effect of random lock ups. I am assuming this is a problem with the driver. As of now, the workaround is to avoid this driver entirely.
  • ·         The second issue we are experiencing is related only to the E6510 model. When utilizing only the drivers provided in the CAB file, ours locks up during the sysprep process. Reviewing the setupapi.log reveals that it is indeed locking up during the installation of the “Intel(R) Active Management Technology – SOL” (Version 6.0.0.1169 9/17/2009) driver. Disabling this driver in SCCM was a workaround this issue for us and presented a new problem. Now it will finish sysprepping and run the image, however the mouse and keyboard will not work due to an IRQ conflict. We are still troubleshooting this issue with Microsoft, as we are trying to get this driver to install properly.
  • ·         The third issue we are experiencing is related only to the E6410 model. When utilizing only the drivers provided in the CAB file, we experience a lockup when resuming from standby. We are utilizing Intel(R) 82567LM-3 Gigabit Network Connection (Version 11.5.10.0 12/10/2009). We were able to develop a workaround by downloading a later version from the Intel website (Version 11.8.75.0 9/29/2010) and creating a software package for installation, as the driver would not natively plug-n-play for this device. This is a temporary workaround, but we are watching for the latest version to be approved on the Dell website. We found this article to be very useful. http://communities.intel.com/thread/15350?start=0&tstart=0

The root cause ended up being the version of the HAL that was in our base image. You can read up on the different versions here. In short, we were building our gold standard image on Microsoft Virtual PC, which is an addition to Windows 7 and the successor to Virtual PC 2007. When we built our image on the Microsoft Virtual PC, the HAL type chosen by Windows when installing XP SP3 was “Advanced Configuration and Power Interface (ACPI) PC”. Based on some recommendations on the Dell Techcenter site, (Thanks Warren!) and the evidence that others were having success with a HAL switching script, we decided to rebuild our gold standard image on a VMware based machine, which will choose “ACPI Uniprocessor PC”. After we made this change we no longer had the issues listed above. To check what version of the HAL is installed on your installation, you can simply go to device manager, and look under the computer node.

VB Scripting Installations and Exit Code Statuses

One of the problems when using a script to perform multiple installation actions is getting success or failure statistics for all the actions. One of the big things to remember is quitting the script with the proper exit code. For example, here is a simple script I wrote to install Visio 2003, then apply the SP2 update, which was in a subfolder called “patch”. I didn’t really care if SP2 ran successfully or not, because the update is also in the software update cycle. But I did want to know if the installation failed.

On Error Resume Next Set sho = Wscript.CreateObject(“Wscript.Shell”)

strCommand = “msiexec.exe /i VISPRO.MSI /qn” intRet = sho.run(strCommand,0,True)

‘*** Set step into patch directory, run MSP file. currdir = sho.currentdirectory sho.CurrentDirectory = currdir & “\patch\” strCommand = “msiexec.exe /update Visio2003-KB840663-FullFile-ENU.MSP /qn” sho.CurrentDirectory = currdir ‘Set current directory back to root folder

‘*** Quit with exit code from MSI installation wscript.quit(intRet)

The bolded sections are the ones we want to focus on. Here we’re simply setting a variable with the installation command line to run, called strCommand. Then in the next step, we’re setting a variable intRet equal to the exit code of run command. Finally at the end, we’re quitting the script with the intRet variable as the exit code.

This way we can effectively take many actions in a script and still deliver an exit code to SCCM, so that failed installations will show up as failed in SCCM reporting. Obviously this is an extremely simple script, but you can modify it from here to enable exit code passing for multiple actions. But don’t take my word for it.

Configuration Manager v.Next Beta 1 Requirements

Well, it looks like it’s time to test a new version of the Configuration Manager product. Below are the highlights of the system requirements for v.Next, for any that are planning or building a lab like I am.

  • When released, all site systems except for Distribution Points and Branch Distribution points must be on any version Windows Server 2008 64 Bit, or R2. For Beta 1, R2 is not supported.
  • v.Next requires a 64-bit version of SQL Server 2008
  • Each Configuration Manager v.Next site requires its own instance of SQL Server, which cannot be co-located on the same computer with another instance of SQL Server that is also being used for Configuration Manager

A another interesting note, migration will only be supported from ConfigMgr 2007 sites.

Gentlemen! Start your virtuals!

SMS 2003 to SCCM 2007 Side By Side Migration

I want to share a recent migration experience I had from SMS 2003 to SCCM 2007 SP2 R2 with you all, some of the situations I encountered and what I did to remedy them. I relied heavily on the SCCM technet documentation which is linked on my side bar. Open for conversation are any possible improvements or any other ways you would have performed the migration.

Because nobody wants to die of boredom while reading this post, I will borrow a quote from Inigo Montoya: “Let me splain…there is too much…let me sum up”.

The environment in question was a single site SMS 2003 site with approximately 4500 users and 3400 computers. The upgrade was performed side by side, meaning that the installation of the SCCM server and site was done while SMS 2003 was still an active site. I’d like highlight some of the things I would have done differently if I could have done it again.

Client Deployment

I created a package for the SCCM client in SMS 2003 and deployed it to all SMS 2003 clients. If I could go back, I would have simply enabled client push for workstations and migrated boundaries. I ended up enabling it after all the clients were deployed, and it proved to be a very reliable source of client installation.

Remote Control

With the changes that came about in regards the Remote Control portion of the software from SMS 2003 to SCCM 2007, I wish I had made it more clear to the users of the remote control software what changes and new limitations were going to be imposed. No more “Send CTRL+ALT+DEL”, and a dual monitor bug that they’re not addressing until v.Next were 2 of the biggest complaints.

Package Migration

I used the free 1E package migration utility to migrate several of the packages from SMS 2003 to SCCM 2007. Initial testing only proved successful for more than half the packages for normal deployments or deployments during OSD. We ended up re-creating more than half of the imported packages by hand. If the environment had been used more extensively, I would have created a secondary site server in the SMS 2003 site, made it a child site in the new SCCM 2007 site, then either upgraded it using the SCCM console, or the setup wizard to preserve package quality.

There are more, but that’s all I can think of at the moment. Next on my agenda is the migration from WSUS to SCCM for update deployment.