How do I patch Windows 7/2008 with Altiris Deployment Server 6.9 SP5 MR1

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.

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.

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 ??

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.

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

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,

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.

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./

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which assist you most in resolving your problem, and give a thumbs up to useful articles and downloads

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.

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.

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.

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.

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.