Rolling out a hotfix

[acl03]

I downloaded a hotfix (not a standard windows update) from Microsoft. It's purpose is to allow the shutting off of the "Previous versions" tab on the file/folder properties window.

I tried packaging it useing WinINSTALL LE, so i could roll it out using an .MSI with group policy, but it doesnt seem to work.

Is there a simple way to roll out a non-msi, or to create an MSI out of the hotfix .exe file?

All i need to do is run:
WindowsXP-KB888603-x86-ENU.exe /noreboot /quiet

I could do it in a login script, but I'd rather not run it every time a user logs in, especially because after a day most users will already have it.





Thanks,
Andrew

 

[GVN]

You could use psExec to do it from your computer to all the other ones. Not sure of the exact syntax.

 

[GVN]

PsExec v1.71 - Execute processes remotely
Copyright (C) 2001-2006 Mark Russinovich
Sysinternals -

http://www.sysinternals.com

PsExec executes a program on a remote system, where remotely executed console
applications execute interactively.

Usage: psexec [\\computer[,computer2[,...] | @file][-u user [-p psswd]][-n s][-l
][-s|-e][-i][-c [-f|-v]][-w directory][-d][-<priority>][-a n,n,...] cmd [argumen
ts]
-a Separate processors on which the application can run with
commas where 1 is the lowest numbered CPU. For example,
to run the application on CPU 2 and CPU 4, enter:
"-a 2,4"
-c Copy the specified program to the remote system for
execution. If you omit this option the application
must be in the system path on the remote system.
-d Don't wait for process to terminate (non-interactive).
-e Loads the specified account's profile.
-f Copy the specified program even if the file already
exists on the remote system.
-i Run the program so that it interacts with the desktop on the
remote system.
-l Run process as limited user (strips the Administrators group
and allows only priviliges assigned to the Users group).
-n Specifies timeout in seconds connecting to remote computers.
-p Specifies optional password for user name. If you omit this
you will be prompted to enter a hidden password.
-s Run the remote process in the System account.
-u Specifies optional user name for login to remote
computer.
-v Copy the specified file only if it has a higher version number
or is newer on than the one on the remote system.
-w Set the working directory of the process (relative to
remote computer).
-priority Specifies -low, -belownormal, -abovenormal, -high or
-realtime to run the process at a different priority.
computer Direct PsExec to run the application on the remote
computer or computers specified. If you omit the computer
name PsExec runs the application on the local system,
and if you specify a wildcard (\\*), PsExec runs the
command on all computers in the current domain.
@file PsExec will execute the command on each of the computers listed
in the file.
program Name of application to execute.
arguments Arguments to pass (note that file paths must be
absolute paths on the target system).

You can enclose applications that have spaces in their name with
quotation marks e.g. psexec \\marklap "c:\long name app.exe".
Input is only passed to the remote system when you press the enter
key, and typing Ctrl-C terminates the remote process.

If you omit a user name the process will run in the context of your
account on the remote system, but will not have access to network
resources (because it is impersonating). Specify a valid user name
in the Domain\User syntax if the remote process requires access
to network resources or to run in a different account. Note that
the password is transmitted in clear text to the remote system.

Error codes returned by PsExec are specific to the applications you
execute, not PsExec.

 

[acl03]

Only problem with PSexec is that it can only be done on machines that are on.

It is a good idea though. I always forget about PSExec.



Thanks,
Andrew

 

[GVN]

> I could do it in a login script, but I'd rather not run it every time a user logs in, especially because after a day most users will already have it.

Try this then:

REM -- This process checks for a flag file named FLAG_FILE1.TXT, and if not found runs INSTALL_PATCH.BAT which
REM -- installs WindowsXP-KB888603-x86-ENU.exe /noreboot /quiet.
IF NOT EXIST "C:\FLAG_FILE1.TXT" CALL "\\MyServer\NETLOGON\INSTALL_PATCH.BAT" ELSE GOTO PATCH_END
ATCH_END

This script will only run once per machine, unless you or the user deletes the C:\FLAG_FILE1.TXT file.

GVN

 

[GVN]

> I could do it in a login script, but I'd rather not run it every time a user logs in, especially because after a day most users will already have it.

Try this then: (Put this in your logon script)
=======================

REM -- This process checks for a flag file named FLAG_FILE1.TXT, and if not found runs INSTALL_PATCH.BAT which
REM -- installs WindowsXP-KB888603-x86-ENU.exe /noreboot /quiet.
IF NOT EXIST "C:\FLAG_FILE1.TXT" CALL "\\MyServer\NETLOGON\INSTALL_PATCH.BAT" ELSE GOTO PATCH_END
ATCH_END

=======================

Put this file in the \\MyServer\NETLOGON directory as well, and name it INSTALL_PATCH.BAT:

=======================

@ECHO OFF
REM -- DEPLOYS THE PATCH ONTO EVERYONE'S DESKTOP --
REM -- INSTALL_PATCH.BAT pushes the client installation to the end-users workstation. --

REM -- The FLAG_FILE1.TXT file is dropped onto the user's hard drive once the process is --
REM -- complete, making the process only run once. --
REM
@ECHO OFF

ECHO Installing patch... Please wait...
CALL "\\MyServer\NETLOGON\PATCH_DIR\WindowsXP-KB888603-x86-ENU.exe /noreboot /quiet"

ECHO.
ECHO Patch installed.

REM -- Drop the FLAG_FILE1.TXT file onto the user's hard drive.
COPY "\\MyServer\NETLOGON\FLAG_FILE1.TXT" "C:\"



=======================

This script will only run once per machine, unless you or the user deletes the C:\FLAG_FILE1.TXT file.

GVN

 

[acl03]

Does anyone know a way to package up a simlpe exe to an MSI?



Thanks,
Andrew

 

[GVN]

You don't need an MSI to do what I've given you either. Just run the exe...

Thanks!

GVN

 

[acl03]

I know

I'd just rather roll this out through group policy, so I can just stick it there and never worry again.

I know doing it in the logon script accomplishes that too, but it's extra stuff in the logon script that doesn't need to be there. I like to keep the script to as barebones as possible.



Thanks,
Andrew

 

[GVN]

Cool!

You should be able to use WinINSTALL LE to build your MSI. I think there's a setting during the build to specify that. What you do is point WinINSTALL LE to a machine without the Hotfix, then install the Hotfix, then basically take a snapshot of the system. WinINSTALL LE should be able to create the MSI with that info provided from that system.

GVN

 

[acl03]

That's exactly what i did, it builds the MSI. When i install the MSi on another pc, it doesn't shut off the previous versions tab like it does if I install the original exe...



Thanks,
Andrew

 

[Markus0815]

Instead of adding GVN's script to your logon script (which requires user permissions to install the patch locally), you could run it as a computer startup script via a group policy (Computer Configuration - Windows Settings - Scripts - Startup) which executes the update before logon time.

However, we experienced that you might have to wait for up to 3 machine startup's before the script is executed, also when pressing Ctrl-Alt-Del to early the *.exe might interrupt but the script itself might still be executed to it's end, setting the *.txt (or pointer of your choice) to flag the finished installation of the *.exe file.

Alternatively, you might wrap your *.exe file into a *.msi using the Windows Installer Wrapper Wizzard (WIWW). The downside of this tool is, that it only can be used to publish *.msi installations to users. Wrapped *.msi packages cannot run assigned to users or computers -> If someone else has found a solution for this matter I would be glad to hear it...!!

Hope this helps
Markus

 

[GVN]

Marcus-
Can you clarify what you were saying about:
>Wrapped *.msi packages cannot run assigned to users or computers

Are you saying that there is no way to "push" MSIs to users via AD?


GVN

 

[GVN]

Also, I know many don't "like" the antiqueness of logon scripts because they don't think that they are "cutting edge" enough, but 99% of the time they do the job and do it quickly instead of trying to figure out some fancy way of doing the same thing. If you do run it as a computer startup script via a group policy (Computer Configuration - Windows Settings - Scripts - Startup), it will be the same script, just a different way of executing it... Have a great weekend.

GVN

 

[Markus0815]

No, this special kind of *.msi packages cannot be pushed out to users - they are treated like Microsoft *.zap files, which are working basically by the same principles as these wrapped *.msi files.

We wanted to roll out several legacy applications which we tried to convert to a *.msi with before/after snapshot as well as installation monitoring with professional software (InstallShield), but without any success at all... that lead us to *.msi wrapping and using StartUp scripts as the last option...

If someone knows a better solution for this, please let us know. But reading your threat might indicate, that there is no other option than using "the good old scripts".

Markus