I have written an AP to silently install software to some Windows 10 endpoints.
For all targeted endpoints (all identical Laptops) the AP runs without error but for some devices the software does not get installed.
How do I troubleshoot this as the AP clearly works on other endpoints?
Just some general techniques if I were building it:
* Use WriteProcedureLogEntry() liberally - I would add a row after basically every step to easily see where the Agent Procedure is breaking down.
* Disable the delete command while troubleshooting. Just having the file on the machine with the correct size will let you know it is writing the file correctly.
* I would move your executeFile() and executeShellCommand() steps into a PowerShell script; then I would use executeFileToVariable() [I think that's the name, from memory]. Your PowerShell script can do various tests and write output to the console, then you can write that output to the procedure log.
* Finally, my best guess on why a procedure this simple is failing to install is the "Execute as System and Continue", immediately followed by a delete command. I think you want to execute as system and wait so the procedure blocks there until the install is finished. If this isn't it, you can try the useCredential() and execute as user.
msiexec is rubbish at returning a success/fail response.
i include a log file and then query it afterwards to see whether it succeeded and if it failed the log may* indicate why.
Also I agree with not deleting your installer immediately. Try "execute as system and wait".
I do this to ensure i get the full log file to parse.
Thanks for the responses and tips. This is a big help.
Comments about your script:
• If True() has not been needed since VSA 7 was released - ditch it!
• You're using C:\Temp but not checking that it exists. Defining agentDrv to define the TEMP folder is a good practice, but if the folder isn't there, you'll write each file to C:\temp (as a file!).
• Use a sub-folder of Temp for your work, not the root of temp, so you can clean up after your own work and not affect others.
• Use a batch file to execute the install command so you can check ERRORLEVEL.
• DO NOT delete the entire temp directory! This is why you create your own install subfolder and use it for all install operations. You are potentially interfering with other system processes by recursively and forcibly deleting everything in Temp.
• You're hard-coding the C:\Temp folder in the deletion command, but using variables elsewhere. Be consistent (with variables).
Our best practices for Agent Procedure based app installers:
• Agent Procedures should log each major step as well as the result of any logic choices or Managed Variables used.
• Identify the Agent Drive, check that \Temp exists on that drive, create it if not present.
• Create a subfolder in the temp folder for your work.
• Copy an install.bat and the install exe or msi to the subfolder.
• Deploy the installer from VSASharedFiles, not from a public Internet download. This prevents any Internet security apps from blocking the download, but just as important, makes sure that you deploy a consistent version with args as expected.
Deploying directly from vendor websites creates a maintenance task requiring constant checking that their app is available and args haven't changed. It can also create an environment with multiple versions of an app deployed, making other admin tasks more challenging.
• Keep it simple - CMD.EXE and a bat file work reliably and anyone with basic skill levels can create and troubleshoot it. Our automation platform has well over 300 Agent Procedures and not a single PowerShell script for installation or basic tasks.
• Use Managed Variables to pass customer-specific data to the install.bat.
• Install.bat should write to it's own log - "starting", optional args, or even the entire command line, then the results via %ERRORLEVEL%.
• Install.bat should check ERRORLEVEL and echo PASS or FAIL-%ERRORLEVEL% so the procedure can check status.
• Agent Procedure should execute install.bat via executeShellCommandToVariable.
• Agent Procedure should use GetFile to upload the two log files - one from the install.bat and one from the installer app.
• Agent Procedure should log the shell command result for review of any failure status.
• Agent Procedure should evaluate the PASS/FAIL result and force the agent procedure to fail. Having an Agent Procedure report success when the task it performed failed is pointless and misleading.
• Never use the #agentTemp# folder for deployments. We've worked with clients where dozens of old app installers were present, some creating a security vulnerability. Use TEMP\appname so it can be easily and completely removed when the install is complete (after gathering logs).
• Recursively delete the TEMP\appname folder when complete. Disable this step during testing/troubleshooting.
• Use Applications\AppName on the VSASharedFiles structure to better organize, manage, and update supported applications.
Replicate that structure on the local network for easier management, then after updating locally, simply copy the new files up to replace the originals.
Never include version info in install files - this requires constant updating of install scripts. Remove the version info from the file name and write it to Version.txt for reference. Use separate app folders if you must support multiple versions.
The KaseyaSharedFiles folder is not a file repository - it should not have old versions - only currently active files should be placed there. You can retain old versions on your local repository if necessary.
When supporting 32/64-bit platform-specific installers, include the platform id in the file names, such as AldusPagemaker_x86.exe and AldusPagemaker_x64.exe. Copy these to the system as "AldusPagemaker.exe" so the install script doesn't have to determine which to run. This can be done easily by the Agent Procedure.
When troubleshooting, don't delete your folder. Check that the files are written and are correct sizes. Internet Security Services will often block downloads from public websites, replacing the content with a "blocked" message. If logs aren't present, the commands aren't running or are failing before the log can be created. This is important diagnostic information.
Chris, if this is working on some machines, but not all. It is very possible that there are pre-requisites that some of the machines don't have enabled/installed. I've seen this with C++ versions or .net 3.5, etc.
Thanks again for all the comments. Boy I have a lot to learn!.
Got to the bottom of the issue in the end.
For the failed machines it was done to some not being restarted for several weeks (Windows updates pending), timeouts due to slow internet downloads, and open .exes preventing execution of the installer.