Deployment Solution

How do I patch Windows 7 / Windows Server 2008 systems that use Windows6.1-KB******-x64.MSU security update files?  

I have been useing Altiris 6.9 for about two years and very comfortable with creating Altiris jobs that transport WindowXP / Server 2003 jobs to the computer systems and execute using the "/passive /norestart" command-line switches for some time now and and all have worked perfectly.  My environment is very small and older and I have recently added new Windows 7 / Windows Server 2008 systems.  The Server 2008 is not using a "WSUS" updating system and we continue to use Altiris fo the software / patch deployment solution.  

I need help creating a security update job for Windows 7 / Server 2008

Normally the steps for creating a job go a little something like this: 

1) Create a Condition:  Choose Windows 7 OR Windows Server 2008

2) Create a Task based on the condition met:  Generally I have chosen "Distribute Software" in the passed for all WindowsXP /2003 systems and follow likewise.  

2a) Identify the package locaiton and file.  Choose filename:  Windows6.1-KB2744842-x64.msu

NOTE: When choosing the security update I must chage the "file type" to All Files because Altiris 6.9 is naturally looking for a "software package *.exe" type of file. 

2b) Additional command-line switches:  For XP/ 2003 I have used "/passive /norestat" in the passed.  This time I choose "/quiet /norestart" as the syntax. 

3) Choose Return Codes: 

Success: Continue
Default: Stop
Code 3010
     Response: Continue
     Result: Success
     Status: Client must be restarted. Patch installed

4) Afte the above the job is completed.  I select the job, and schedule the task to be performed agains one of the Windows 7 computers.  Then I review the job status.  Using the above settings the job fails with error code 193.  Below is the summerized output of the failed job. 

The job Starts. 
The file is Transfered 100%
Altiris tries to Execute the file "Windows6.1-KB2744842-x64.msu" 
Error 193 installing package.  


Do I need to write these jobs as transfering over the .msu file itself and then transfer anothe .batch file with instructions to use the following
wusa.exe Windows6.1-KB2744842-x64.msu /quiet /norestart  ??

Any help from the pros would be great. 

Hi,

What I usually do is copy the patch (or patches) across and then run a script thru the DS, which can be either a PS script, VBS or a simple CMD script that walks thru the designated folder and installs all according updates with the same parameters. To run this locally could avoid such issues as when running the install as "Distribute Software" as to best of my knowledge, this ends up in a temp file on the client and could cause you trouble.

So your process could look like this:

1. Copy over all patches required for the respective OS into a specific destination folder on the targets;

2. Run a script task which performs the install for each patch found in the target folder on your destination machines;

3. OPTIONAL: I usually then do a reboot to make sure they become active, cleanup the destination folder and run a Get Inventory task so that they can be queried thru DS DB or inventory.

I hope this helps a bit further,

-BBC

BBC,

Thanks for the advice.  I figure that the Distribute Software task fro DS 6.9 must get not be programmed to handle the *.MSU (Windows Update Standalone Installer) for Windows 7 / Server 2008.  First sign of this would be the fact that *.MSU file extensions are unknown will selecting this option as a task. 

Moving on....
I set a job to:

1) Copy the Windows6.1-KB2744842-x64.msu to C:\Patchtemp
2) Copy the script file somescript.bat to C:\Patchtemp
3) Run the script somescript.bat
4) Get Inventory

Basic content of the Script that ran:

:::Install the patch
wusa.exe C:\Patchtemp\Windows6.1-KB2744842-x64.msu /quiet /norestart /log:c:\Patchtemp\UpdateINFO.evtx

The first run for this script all of the files copied over to the target system, but the script execution failed with my fake 3010 code "saying Script Complete"  

I believe the issue was that the patch was already applied to the Windows 7 computer.  I tried the script locally to see what the outcome was not using the /quiet /norestart syntax to see what was happening and it was confirmed that the update was already applied. 

I also noticed that when trying ot use the /log feature and caling the file somelog.log, you have to read it with the EventViewer.  Then it converts the file to a ..evt or .evtx format.  When trying to call the file .evtx directly I can't view the file in EventViewer.  

Getting closer to the goal of a working script.  Im just using command line batch script and not powershell.  If Powershell was used, probably more logic could be used to verify if a scrip was already installed on a system.  I'm weak with powershell right now in order to get that to work. 

I do this sort of thing with DS6.x using an intial script which acts as a detection rule. This allows you to proceed with the a file copy and install only if the patch is not present. You can then rewire a specific error codes to say "Already Installed"

For this IE cumulative update, a simple detection rule would be to look at the value of the registry string value which holds the details of the current cumulative update level.

HKLM\SOFTWARE\Microsoft\Internet Explorer\svcKBNumber

You would then create a fork in your execution to only copy the install the update should this detection rule fail. The job structure would therefore be,

1. Execute Detection Rule Script
   
   

   REM Return code of 5001 means software not present
   
   SET RETURNCODE=5001
   
   :: Detection rule piece of code. If software found, set RETURNCODE to 5000
   reg query "HKLM\SOFTWARE\Microsoft\Internet Explorer" /v svcKBNumber | find /i "KB2744842"
   
   IF "%ERRORLEVEL%"=="0" (SET RETURNCODE=5000)
   
   :: Exit now with the appropriate code
   EXIT %RETURNCODE%

   
   For the exit codes, have set as a master return code 5000 for "Software Detected" and 5001 for "Software Not Detected". Only continue with job execution if software not found. This makes your status looks nice.
    
2. Copy Source Task
   I normally copy installs to C:\Temp\<SOFTWARE>\<VERSION>
   
    
3. Execute Task
   This would be your script,

4. wusa.exe C:\TEMP\IE9\KB2744842\Windows6.1-KB2744842-x64.msu /quiet /norestart /log:c:\Logs\KB2744842.evtx

What I generally do,  is run such updates on my target machines a couple of times. If the update has installed, there is little load on the client as it doesn't actually install again if the update is detected. 

For multiple OS's, you just have to copy this process in each condition fork for the correct update. If space isn't an issue, you can copy all the OS/Architecture variants to the client and have your install script select the correct update. This is a nice option if you want to simplify the conditions in DS and make the install scripts more portable.

Kind Regards,
Ian./ 

@ianatkin

Thanks for the tips and the nice guide.  I will put this into practice and see how it works out.  I haven't used code to work the altiris response codes that you can maunually make.  Look forwarding trying this out.

@ianatkin

I had some questions regarding the first section of code that you displayed in the last response. 
Is code /v svcKBNumber supposed to be replaced with the real KB value? 

Looking around the registry it appears that most of the Windows XP and Windows Server 2003 KB values are found in the following keys:

"HKLM\SOFTWARE\Microsoft\Updates\Windows Server 2003"
- there are subkeys like SP0 (Associated with IE7 updates)
-,SP10 (very few KBs)
- SP3 (general area for the OS KB security patches)

"HKLM\SOFTWARE\Microsoft\Updates\Windows XP"
- there are simuliar subkeys like SP0   (Associated with IE7)
- SP1  (very few KBs)
- SP10  (very few KBs)
- SP3 (very few KBs)
- SP4 (general area for the OS KB security patches)

Without knowing the registry key value name  the above reg query doesn't work.  But if I run the parameter that reviews all the subkeys recursively.

reg query "HKLM\SOFTWARE\Microsoft\Updates\Windows Server 2003" /s | find /i "KB974455"
reg query "HKLM\SOFTWARE\Microsoft\Updates\Windows XP" /s | find /i "KB2491683"

Provides several results and I suppose would produce the errorcode stated in the code above if the KB wasn't present.  However when using a KB that doesn't exist at the command line the command prompt just returns and doesn't given an error using Windows Server 2003.  

For example made up non windows releated KB patch:  reg query "HKLM\SOFTWARE\Microsoft\Updates\Windows Server 2003" /s | find /i "KB2485664"

Provides no results.

I haven't been able to create a reg query that would make since for Windows 7 and Windows Server 2008 in order to get some kind of error results.  When searching for any applied KB artilce with Win7/2008 it seems that there are 15 different areas that can be found for the KB******* patch.

Example Windows Server 2008 R2: A KB article/patch number will appear in the following key
HKLM\Software\Microsoft\Windows\CurrentVersion\Component Based Services\ComponentDetect\
---Then the key are multiple links to referenced  KB  patches applied.
OR

HKLM\Software\Microsoft\Windows\CurrentVersion\Component Based Services\Package Pending\
---under the key are several files with package_for_KB*********
 

So I don't know how a detect registry key and wait for the errorcode and Altiris is going to work out for Win 7 / 2008. 

Yes, the code I gave was specific to the single use case you presented. For different patches, or software items you'd have to customise the detection rule.

If I get you right, you want a generic routine to detect a specific patch? So, you'd like a function of the form,

IF IsPatchPresent("KB12344") = TRUE
THEN PatchDetected=1

I've got something of this form in an app called PatchFinder I wrote a long time ago. I could the core code into a vbscript if it's useful... 

I've created the Altiris package to install the windows 7 / Server 2008 patch on to the system.  However, I cannot get a decent result code description to work correctly with Altiris 6.9. Therefor an Altiris Admin will know know if the patch actually installed correctly without manually checking. 

Below is are the steps used for how the Altiris *.bin transfers the files and executes the script.

I am making these *.bin files with an older Altiris 6.8 version because I still have these servers laying around.  The *.bin is converted to 6.9 formatting after the creation of the *.bin file. 

1. Windows 7 or Windows Server 2008 has to be detected.  This works fine. 
 -- after detection the copy files works.

2. Task: Copy file.  The windows 7 patch is copied to the remote system C:\Temp\SomeFolder 
--No return code created.  Success: Continue,   Default: Stop.      

4. Task: Copy file. The windows batch file that performs the install is copied over to C:\Temp\SomeFolder
---No return code created.  Success: Contine,  Default: Stop

5. Task: Run Script.  Altiris will show the update is executing the script.bat file with the commands but errors out with code "Error 3010 during script execution" 

The actual result code description doesn't make since to me as internally only two codes exsit and have a set status description.

The Altiris server only has the following return codes and are most likly the defaults because you cannot modify the code value ( it is grayed out). You could probalby delete and recreate I suppose

Code: 3010  Response: Continue  Result: Success  Status: Please Restart
Code: 3010  Response: Continue  Result: Success  Status: Done

( I would like to add more once I have a decent detection code that will work for Win 7/Server 2008)

The script that actually runs the has the following syntax in order to install the patch (all in one line):
After some Script descriptions the following command is executed:

wusa.exe "C:\Temp\KB2743555\Windows6.1-KB2743555-x64.msu" /quiet /norestart /log:"c:\Temp\KB2743555\KB2743555.evt"

An Altiris Admin will schedule a job and send the it to a few desktops, but from the Altiris Admin point of view you would think the windows security update had failed.   When you login to the actual remote computer desktop/server and review the *.EVT file created by the executed command; it shows that the log information actually logs that the intallation performed correctly. 

Using powershell you can test it as well:  get-hotfix -id KB2743555  will return the result that the patch is present and installed.

So, the windows 7 / Server 2008 patch installs correctly but Altiris doesn't display this information.  I need help in correcting this issue so that the *.bin will show a successful install.

Perhaps, after the command is exectued, but in the script the following:
SET RETURNCODE=5010     ( or some other number)

Then go to altiris and say  Code: 5010   really means Patch installed?   If the patch is installed I get a very long error code all together, and since I can't get the detection script to work in some logical fashion that absolutely points to the patch being installed I can use the previous logic code shared in an earlier post.  
 

If might be quicker if you export your job folder as a .bin, zip it up and attach it to your post. I can then import that and see what's up?

As suggested I am uploading my working folder Windows 7/2008, Win2k3 and XP patch. 

The Altiris 6.9 bin file should can imported into a Deployment Server 6.9 SP3 and above.  A little readme file and master return code  picture can be found within the zip.

Thank you for your help and look forward to hearing your thoughts on the matter.

Attachment(s)

Needsomehelp.zip   9.81 MB 1 version