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.

VBScript to name computers during OSD

Determining a computer name during an imaging process has always proved to be a challenge. One of my favorite methods is to utilize WMI to obtain the serial number of the computer that is being imaged. This way, if all your hardware is from a particular vendor, Dell, HP, Panasonic, you can guarantee that no two computer names will ever be the same and you can name them automatically during the imaging process. Not to mention you can quickly look up the computer information on the vendor website.

The following vbscript I wrote will determine the serial number, append a “C” to the front of it, then populate the OSD task sequence variable called “OSDComputerName”. It is one of the first tasks in all my task sequences. One of the extras I wrote in will actually prompt you to enter the computer name if it detects it is a VMware, Citrix or Microsoft Virtual machine, because they do not have a serial number in WMI. Enjoy!

GetComputerName.txt

Just rename to .vbs