Windows Startup Script, MSIEXEC patching, and Rebooting
After much fiddling with syntax with Msiexec and MSP's (/P, /qn, REBOOT= Force, / Forcerestart, etc.), I finally got my script to do what I want it to do...
Which is check for adobe acrobat patch installations, install patches if they aren't installed, reboot the machine after a single patch is installed (then re-processes checking patches.)
It works if I run the vbscript standalone, or as a logon script. However, it will not reboot the machine if it is run as a startup script.
Any ideas?
Here's the vbscript code:
Which is check for adobe acrobat patch installations, install patches if they aren't installed, reboot the machine after a single patch is installed (then re-processes checking patches.)
It works if I run the vbscript standalone, or as a logon script. However, it will not reboot the machine if it is run as a startup script.
Any ideas?
Here's the vbscript code:
On Error Resume Next
'*** Check for Adobe Acrobat ***
Dim Flag
Flag = True
AcrobatReg = "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\68AB67CA330100007706000000000040\"
If RegistryKeyExists(AcrobatReg) Then
'Adobe Acrobat Pro 9 is installed
'*** Check for Patch 1 ***
If Flag Then
AcrobatRegP1 = "HKEY_CLASSES_ROOT\Installer\Patches\68AB67CA28180677ABE7A7C804009001\"
If RegistryKeyExists(AcrobatRegP1) Then
'Patch 1 ins installed - Move on
'Wscript.echo "Adobe Acrobat Pro 9 Patch 1 is installed"
Else
'Install Patch 1 (force Reboot)
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "msiexec /update \\SERVERNAME\Adobe\AcrobatPro9\AcrobatUpd910_all_incr.msp /passive /forcerestart"
'Force Exit Script
Flag = False
'Wscript.echo "Adobe Acrobat Pro 9 Patch 1 is NOT installed"
End If
End If
'*** Check for Patch 2 ***
If Flag Then
AcrobatRegP2 = "HKEY_CLASSES_ROOT\Installer\Patches\68AB67CA055A00005A05A7C804009021\"
If RegistryKeyExists(AcrobatRegP2) Then
'Patch 2 ins installed - Move on
'Wscript.echo "Adobe Acrobat Pro 9 Patch 2 is installed"
Else
'Install Patch 2 (force Reboot - maybe)
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "msiexec /update \\SERVERNAME\Adobe\AcrobatPro9\AcrobatUpd912_all_incr.msp /passive /forcerestart"
'Force Exit Script
Flag = False
'Wscript.echo "Adobe Acrobat Pro 9 Patch 2 is NOT installed"
End If
End If
'*** Check for Patch 3 ***
If Flag Then
AcrobatRegP3 = "HKEY_CLASSES_ROOT\Installer\Patches\68AB67CA055A00005A05A7C804009002\"
If RegistryKeyExists(AcrobatRegP3) Then
'Patch 3 ins installed - Move on
'Wscript.echo "Adobe Acrobat Pro 9 Patch 3 is installed"
Else
'Install Patch 3 (force Reboot)
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "msiexec /update \\SERVERNAME\Adobe\AcrobatPro9\AcrobatUpd920_all_incr.msp /passive /forcerestart"
'Force Exit Script
Flag = False
'Wscript.echo "Adobe Acrobat Pro 9 Patch 3 is NOT installed"
End If
End If
'*** Check for Patch 4 ***
If Flag Then
AcrobatRegP4 = "HKEY_CLASSES_ROOT\Installer\Patches\68AB67CA055A00005A05A7C804009003\"
If RegistryKeyExists(AcrobatRegP4) Then
'Patch 4 ins installed - Move on
'Wscript.echo "Adobe Acrobat Pro 9 Patch 4 is installed"
Else
'Install Patch 4 (force Reboot)
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "msiexec /update \\SERVERNAME\Adobe\AcrobatPro9\AcrobatUpd930_all_incr.msp /passive /forcerestart"
'Force Exit Script
Flag = False
'Wscript.echo "Adobe Acrobat Pro 9 Patch 4 is NOT installed"
End If
End If
Else
'Adobe Acrobat Pro 9 is NOT installed - move on
End If
'************************************
'* Registry Key Exists (Function)
'* Returns a value (true / false)
'************************************
'This function checks to see if a passed registry key exists, and
'returns true if it does
'
'Requirements: The registry key you are looking for (RegistryKey)
'Note: RegistryKey MUST end in a backslash (\), or FALSE will be returned
Function RegistryKeyExists(key)
RegistryKeyExists = False
Dim objShell
On Error Resume Next
Set objShell = CreateObject("WScript.Shell")
objShell.RegRead (key)
Set objShell = Nothing
If Err = 0 Then RegistryKeyExists = True
End Function
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
Jsaylor
14 years ago
I'd imagine using the /forcerestart switch in the context of a startup script (via GPO?) would behave differently than if it's run under a user context. If you really want to force a restart, I'd recommend calling it out directly after the msiexec lines with either a WMI call or, if you're a little lazier, just using shutdown.exe.
I would also question whether a patch to adobe acrobat really requires a restart in the context of a startup script. You may be better off suppressing restarts altogether for the startup version.
I would also question whether a patch to adobe acrobat really requires a restart in the context of a startup script. You may be better off suppressing restarts altogether for the startup version.
Posted by:
W.Allen
14 years ago
ORIGINAL: Jsaylor
I'd imagine using the /forcerestart switch in the context of a startup script (via GPO?) would behave differently than if it's run under a user context. If you really want to force a restart, I'd recommend calling it out directly after the msiexec lines with either a WMI call or, if you're a little lazier, just using shutdown.exe.
The test machine has had local policy edited and is using the startup script section.
When the machine starts up, the first dialog does pop-up over the normal "runing startup scripts" dialog, then the rest of the patch installation doesn't appear. (Although it is successful).
If I place it in the logon script section, all the patch dialogs / progress bars appear and the machine reboots after the patch is installed.
There are a couple of reasons I want it in the startup script area.
One, startup scripts run under the system account. I'm not sure a standard user would have rights to install a patch (msp) through a logon script.
Two, the way this script is written, all our techs have to do is add the newly imaged machine in the Adobe Acrobat GP, reboot to install, reboot once again and the startup script will keep patching adobe (and rebooting between patches) until the machine is up to date.
Three, slipstreaming acrobat patches is a nightmare, then having to move machines in new GP causes complete re-installs... which isn't good for our lower bandwidth sites.
EDIT: I did try forcing a reboot later in the script with a shutdown command (also removing /forcerestart)... but it doesn't wait for the patch to be done installing... in fact, the patch never really gets a chance to get started... so if I were to put that in the startup script area (and it worked), the machine would be in a reboot loop.
ORIGINAL: Jsaylor
I would also question whether a patch to adobe acrobat really requires a restart in the context of a startup script. You may be better off suppressing restarts altogether for the startup version.
The first patch and last patch definitely require reboots. I have witnessed acrobat installs getting messed up if you patch more after the first one without a reboot. So, in my opinion, it is better to be safe than sorry, and reboot after each patch.
Thanks for the reply!
Posted by:
anonymous_9363
14 years ago
Notwithstanding your points about slipstreaming and low bandwidth sites, this rather neatly demonstrates why patching clients is A Really Bad Idea. What you ought to have done at the outset is create an Administrative Installation Point for Acrobat. You could then have patched the AIP and re-installed the clients. It's generally quicker that way, too.
If you want to persist with script, I'd use the patching properties and methods of the WindowsInstaller.Installer object for patch detection etc.
If you want to persist with script, I'd use the patching properties and methods of the WindowsInstaller.Installer object for patch detection etc.
Posted by:
Jsaylor
14 years ago
ORIGINAL: W.Allen
EDIT: I did try forcing a reboot later in the script with a shutdown command (also removing /forcerestart)... but it doesn't wait for the patch to be done installing... in fact, the patch never really gets a chance to get started... so if I were to put that in the startup script area (and it worked), the machine would be in a reboot loop.
This is happening because you're using the run method to install your patches without specifying whether you want it to wait for the program to complete or not. The MSDN page on the Run method is quite handy, but it boils down to just adding a couple arguments to the end of your run lines, like this:
WshShell.Run "msiexec /update \\SERVERNAME\Adobe\AcrobatPro9\AcrobatUpd910_all_incr.msp /passive /forcerestart",1,True
This will wait for the command to execute before moving on to the next line. This way you can add a shutdown command afterwards without hosing your patch.
Posted by:
W.Allen
14 years ago
ORIGINAL: VBScab
Notwithstanding your points about slipstreaming and low bandwidth sites, this rather neatly demonstrates why patching clients is A Really Bad Idea. What you ought to have done at the outset is create an Administrative Installation Point for Acrobat. You could then have patched the AIP and re-installed the clients. It's generally quicker that way, too.
If you want to persist with script, I'd use the patching properties and methods of the WindowsInstaller.Installer object for patch detection etc.
Thanks for the reply.
Could you explain how a 600MB+ re-install is faster than a 50MB - 100MB patch?
EDIT: Let me further explain the setup here.
A newly imaged machine is done locally in this building. So a tech waiting for a machine to be done with all of it's reboots / patching (including WSUS patches) is standard procedure before deploying the machine.
That means that all of the machines out in other sites are fully patched before they are deployed. With this method, it also means that there is one less thing for them to babysit / manually launch patches, as they are imaging multiple machines. Creating extra Gps with slipstreamed patches also creates inconsistencies in AD. We use security groups and GPO as a back up way to count licenses, so it would be better if the machines were all consistantly in one GP per product. While we could slipstream and maintain one GPO, we'd be back to the complete re-install issue on 200+ machines that have this product, with many at a low bandwidth site.
As a new patch comes in to play, and I add it to the startup script, the deployed machines should only get the latest patch once scheduled to reboot. This means they would only have 50MB-100MB pushed every couple of months (in this case) vs. a 600MB re-install. We have 7 main sites that are using DFS for Software pushes and 3rd party application patches, and roughly 50 remote sites that are low bandwidth and do not have a DFS server. They are, of course, mostly connected to the closest DC and DFS site.
I appreciate input on better ways to do things, so please don't take this as being argumentative. I felt that you needed the overall picture to know why I'm thinking along the lines that I am. We've tried several methods, and this is just the latest one that I've come up with.
Thanks.
ORIGINAL: Jsaylor
This is happening because you're using the run method to install your patches without specifying whether you want it to wait for the program to complete or not. The MSDN page on the Run method is quite handy, but it boils down to just adding a couple arguments to the end of your run lines, like this:
WshShell.Run "msiexec /update \\SERVERNAME\Adobe\AcrobatPro9\AcrobatUpd910_all_incr.msp /passive /forcerestart",1,True
This will wait for the command to execute before moving on to the next line. This way you can add a shutdown command afterwards without hosing your patch.
That worked. My VB scripting is a bit rusty since I've been using powershell for the last 8 months and didn't ever really get in too deep with VB scripting. Until we push powershell to all of our machines, I can't use it for startup scripts.
Thanks!
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.