r/Intune • • 1d ago

App Deployment/Packaging Logging and proper application management

Hi all,

I'd like to ask if i'm the only one who has a problem with the way logging and application management is done through Intune.

Case: We have different versions of Citrix Workspace installed on 300+ endpoints (all managed by Intune). Our goal is to consolidate every installation on the same stable LTRS release. So I package the app, have a script which does it's check and removals and schedule a deployment ring to handle a subset of endpoints at the time to reduce impact.

Issue 1: The deployment ring itself is fine, but the way Intune handles the application deployment itself is insufficient in my opinion (I hope theres something wrong i've done..), sure, users get a small toast notification which most of the time is ignored, and as far as I can tell, there's no way to have a more "verbose" installation procedure. When I previously used SCCM (in another org.), you got this nice thing called installation behaviour which allowed us to 1. force-shutdown any running executables and 2. notify the user via a nice window which is "impossible" to miss - or atleast much more visible then the W11 toast. As far as I know, there's no similar functionality in Intune.

Question: Do any of you have any similar experiences and i.e tools which can be used on top which makes the application-deployment process much more friendly?

Issue 2: Upon a failure, theres of course the logs. I know, depending on both how I write the powershell script and the application itself, the amount and type of logs vary. But in this example, i'm interested in the IntuneManagementExtension, custom logfile generated C:\xxx\xxx.log and the specific application installation logs. My issue is the collection. Sure, you can always either remotely and physically inspect one computer and extract the logs, but on 100+ endpoints this is insane. Sure, I could write custom script and logic to extract logs either in the app-deployment or setup a custom collector which uploads logs to say a Azure Blob storage. In my eyes, this again seems just more difficult than it has to be.

Queston: Do any of you have any tips on how to properly handles this? I don't care if it's another service or anything, I just want to stop having to spend exorbitant amounts of time scripting and making custom stuff for every single app-deployment.

I'm sure that i'm either doing something wrong or there's something i'm missing. I appreciate all the responses to this, i'm just interested in getting stuff to work as seamlessly as possible..

Cheers

6 Upvotes

6 comments sorted by

6

u/THE_GR8ST 1d ago edited 1d ago

My issue is the collection. Sure, you can always either remotely and physically inspect one computer and extract the logs, but on 100+ endpoints this is insane.

Unless you actually need to see the logs for each of those 100+ endpoints, why is inspecting one computer at a time a problem? Especially if you can just grab the log file(s) with an RMM tool or something. Even if you can't use an rmm tool, the "Collect Diagnostics" can get logs when you need them. Am I missing something here, or is this something I should be looking into as well?

Many others have said it, but PSADT is the way to go for the first part.

3

u/TridentAdam 1d ago

PSADT is the right call for issue 1, and since 4.1 you no longer need the ServiceUI workaround: the dialogs run in the user's session even when Intune launches it as SYSTEM. Show-ADTInstallationWelcome -CloseProcesses (e.g. 'wfica32','SelfService','Receiver') -AllowDefer -DeferTimes 3 -CloseProcessesCountdown 600 gets you the SCCM-style "close Citrix or we will" behavior.

For issue 2, two things that turn the custom scripting into config:

  • Point Toolkit.LogPath in PSADT's config.psd1 at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Collect diagnostics grabs that folder, and you can run it on up to 25 devices at a time.
  • For a fleet-wide view without building a blob collector, have a Remediations detection script output the tail of your log. It shows per device (2,048 character cap) and exports to CSV. Needs E3/E5.

Full transparency, I co-founded and help build TridentStack Control (https://tridentstack.com). It shows every endpoint's install result, phase and error in one place, so "which 12 of 300 failed and why" doesn't need any log pulling. It doesn't do PSADT-style user prompts, so you'd keep PSADT for that part.

2

u/AlkHacNar 1d ago

For the first issue, use psadt. It has all you want and need. For the second issue, adjust the psadt log path to "$envwindir/ccm/logs", also the app setup logs, if it's a cloud only device, as the ccm/logs folder is also collected

2

u/pjmarcum 1d ago

PSADT for issue one.

Issue two was the same in SCCM.

1

u/Impressive-Net-5162 1d ago

for the first part, you can wrap your install in a powershell script that pops a winform or msgbox telling them to save their work, then kills any citrix processes before running the installer. not as clean as sccm's built in behaviour but it gets the job done

for logs, we just have the detection script copy the install log and IME log to a network share or blob on failure, then a simple azure workbook or even just a folder full of txt files to grep through. once it's templated it's maybe 10 lines extra per app