Help - MSI installer does not get transfered to client
Hi Everyone, I'm stumped.
I'm running KACE appliance v12.1 & Client is updated
I created a managed installer to push an upgrade for Pulse Secure VPN client to my test machine.
- Windows 10 21H2 x64
- has a previous version of Pulse Secure installed, I'm testing an in-place upgrade
- Target machine is on the outside with an active VPN session
- Execution: At bootup
- Associated File: 'pulsesecure9.1.15819_r15_x64.msi'
- Installation Options: Default Installation with msi switches '/qn / i'
- Managed Operating Systems: Windows 10 (all)
After multiple forced check-ins for the target machine, I don't see a new folder created in C:\ProgramData\Quest\KACE\Downloads\ on my target
For kicks and giggles, I restart the target machine. I see the KACE ambush message immediately after the the Windows lock screen appears.
The KACE ambush message is there for 1-2 seconds, then returns to the Windows Lock screen, thus allowing me to login.
So I know the target has recieved the managed installer instructions. (to attempt the install on restart, but the .msi is missing)
This is the head scratcher!
When I set the Managed installer > Execution: Anytime
I have no issues! I do a forced check-in for the target, a few minutes later I see a new folder created C:\ProgramData\Quest\KACE\Downloads\ with the .msi installer I want.
After that, I see the Pulse Secure launcher exe drop from task tray (killing the VPN session, & indicating the in-place upgrade is underway)
The Pulse Secure splash screen then appears (indicating the new version has launched and is running)
I need it to install on next restart, before the user is able to sign in into Windows, and connect to VPN.
The majority of my users are on VPN, I do not want the VPN session to drop when the msiexec kicks off and the users are in the middle of tasks.
- Unstalling the Ampagent on my target machine (elev CMD: amptools uninstall all-kuid); restart; manually delete C:\ProgramData\Quest & C:\Program Files (x86)\Quest\Kace; restart; reinstall the KACE agent. No dice
- Configured a never before seen in KACE target machine with the same OS and same previous version of Pulse, added it to the managed installer did a forced check-in, No dice
- Configured a Device SmartLabel to be more specific
- [Software Title] = [Pulse Secure]
- [Software Version] != [9.1.15819] (thats the version I want to upgrade too)
- [System Name] = [my target machine HostName(s)]
- Tried re-associating a zip file instead of the msi (with an embedded 'install.bat' that consists of a simple 'msiexec.exe /qn /i "pulsesecure9.1.15819_r15_x64.msi"'
and refconfigured the installation options - Override default installation, calling out the install.bat.
Nothing seems to work.
Anyone have any ideas?
Yes, when the Managed installer is set to 'Anytime' it works without issue.
maybe my issue is:I expected the .msi to get transferred to the target during or shortly thereafter the last active check-in. (when connected to VPN) - the same behavior when its set to 'Anytime'
But... its probably not.
Could it be, the .msi gets transferred when the Managed installer instructions are set to kick off (on the restart) but there's no tunnel to get it from my KACE SMA server?
I spun up a VM testbox in my vCenter, connected to the my internal LAN, and there were zero issues with the managed installer when set to 'at Bootup'
Things that make you say 'Hmmm.." -mikey
A simple online KScript was put together and executed to my target test machine
<?xml version="1.0" encoding="utf-8" ?>
<config name="Pulse Upgrade Pre-req" type="policy" id="361" version="1658869066" description="Copies prerequisite files for Pulse Install">
<dependency name="/packages/kbots/361/copyPulse.bat" checksum="58101f360513099326fde6e7e10351d3" />
<dependency name="/packages/kbots/361/ps-pulse-win-9.1r15.0-b15819-64bit-installer.msi" checksum="8f9da1466cb5415a45a512341549b12e" />
<execute disconnected="false" logged_off="true">
<verify on_failure="break" attempts="1">
<launch_program path="$(KACE_DEPENDENCY_DIR)" program="copyPulse.bat" wait="true" visible="false" parms="" />
"CopyPulse.bat" basically just moves the MSI package
to C:\Temp\ (because the '361' folder gets deleted after next check-in)
Verified the MSI is in C:\Temp
Modifiied the Managed Installer:
- Associated File: ps-pulse-win-9.1r15.0-b15819-64bit-installer.msi
- Installation Options:
- Override default installation - Full Command Line: c:\windows\system32\msiexec.exe /qn /i "C:\temp\ps-pulse-win-9.1r15.0-b15819-64bit-installer.msi"
- Run Command only (do not download file)
- added my test box in the Devices list
- removed the link for the SmartLabel (for now)
Ran the Managed installer to force a check-in of my target. and validated the new check in
Did a restart of my target, same behavior.
KACE installer ambush message appeared after the restart for about 1 second then dropped.
Signed into the machine, observed no Pulse upgrade. Grrrr.
Could it be that Microsoft (in its infinate wisdom) is not allowing Msiexec.exe to run when no user is signed in?
My patience is nearing its end LOL!
At this point in troubleshooting, the original issue is resolved.
MSI installer transfered to client - Good
Execute the Managed installer on 'at bootup' (off VPN) - Not Good, still pending
And...The Saga continues
Thanks for the suggestion! It like that solution better, its cleaner, thanks!
I have the File Sync package dropping my msi into C:\ProgramData\Quest\KACE\Installers\Pulse.
After verification the installer exists in that location, I tweaked the Managed installer:
- Override Default Install / Full command Line: msiexec.exe /qn /i "C:\ProgramData\Quest\KACE\Installers\Pulse\ps-pulse-win-9.1r15.0-b15819-64bit-installer.msi"
- Run Command Only (do not install)
- Alernate location (ticked)
- Path: C:\ProgramData\Quest\KACE\Installers\Pulse\ps-pulse-win-9.1r15.0-b15819-64bit-installer.msi
- Checksum: [copied from the KScript]
- Credential: (Windows Builtin Local Administrator Account) - ".\administrator"
Managed Installer - Saved then 'Run Now', to force a client check-in
Rebooted the client.
Same behavior is observed. (KACE ambush message is seen then quickly drops)
I think the root cause of this failure are the creds to authorize the install.
Like in internal combustion engine, 3 barebones basic things are needed:
- Power, Hardware, and running OS (Air)
- the MSI installer (Fuel)
- Credentials (Spark)
No matter what, the client needs the creds from my KACE server at the time of execution, but like before, No VPN tunnel, no KACE server, and getting the cred fails.
It requires the cred at execution only because its an MSI installer.
I have another Managed Installer configured 'at bootup' that uses an .exe and it works fine when the client is off VPN.
To my knowledge, Ivanti has never built an .exe version of the Pulse Secure, only an .msi. (bummer)
Back to the brainstorming table.
An offline KScript was built to handle the installer (Managed Installer eliminated)
---Description: install Pulse Secure, in-place upgrade, just after user signs into Windows 10; No VPN
step 1- KScript is executed; Copies Dependency files to temp location in: C:\ProgramData\Quest\KACE\kbots_cache\Packages\kbots\364\ folder on the client machine.
step 2- Execute 'Phase_1.bat'.
step 2a - the .bat copies .msi installer & Pulse91R15_Inst.bat to C:\Temp\
step 2b - and merge 'pulse.reg' snippet into the registry, silently
new string name "InstallPulse9115" value="C:\Temp\Pulse91R15_Inst.bat"
step 3 - [Machine Restarts]
step 4 - RunOnce triggers the 'Pulse91R15_Inst.bat' in C:\Temp\ then Registry String is removed.
Pulse91R15_Inst.bat = msiexec.exe /qn /i C:\Temp\ps-pulse-win-9.1r15.0-b15819-64bit-installer.msi
The issue: This works only if an local administrator or a domain admin is signed into Windows on the target. If a domain user is signed in, Step 1 is successful, but that's as far as it gets; Step 2 doesn't trigger.
Next train of thought: configure a task in Windows Task Scheduler via Powershell (pushed by a the KScript) so it runs the subsequent steps as the local administrator, but I don't believe there's a way to clean up the task after running once.
Back to the brainstorming table, again
Ivanti is engaged to see if they can build an .exe installer for Pulse.
The other avenue is submitting a support Request with Quest.