Failed installer helper

Does anyone know of a way to do the following, or if it can be done.

when a app fails to install, gather the logs in creates in c:\windows\logs\software\name.log
and email those to me.

This won’t directly answer your question, but if you are using Intune to do your deployments, you can change the default log path of PSADT wrapped apps to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
Then you can use the Intune ‘Collect diagnostics’ feature to download all diagnostic data from a device which includes the above folder.
This:


creates a zip file which can then be subsequently downloaded - Very useful!

I’d strongly advise anyone against ‘emailing’ logs from a device via a script - as you would technically need to have an unauthenticated SMTP server running to be able to relay this mail (or store username and password to authenticate the mail relay) to you (via your mail system), which is a bit of a Cyber Security no-no.

SCCM has a log gathering feature also.

Somebody has put a PR in to (optionally) automatically change the log folder to one of the above if detected as running from an Intune or SCCM cache location, which I think is a great feature.

Change default log location based on deployment system by ITsVeritas · Pull Request #921 · PSAppDeployToolkit/PSAppDeployToolkit (github.com)

1 Like

@DanGough Without getting off subject of the OP, I’d +1 this PR change to PSADT, as IMHO it would give it more cross platform support, and could reduce the need for newbies to understand where to make these customisations - although it could be necessary to handle alternative default log paths for other popular software deployment platforms too (e.g. https://www.g2.com/products/microsoft-intune/competitors/alternatives) :person_shrugging:

1 Like

thanks all for the suggestions, i will look into this.

You can already override the log path via AppDeployToolkitConfig.xml for any other random deployment platforms. If there are any really popular ones that have a defined log path and a way to detect they’re in use (e.g. we can detect Intune vs SCCM from the location where the package is executing from), then they could be added also.

This PR is most likely going to be parked until the big overhaul for 4.0 is complete, then the functionality implemented there.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.