Get-ADTApplication

The Toolkit General Discussion
1

I have been using PSADTv4 to install Microsoft Visual Studio code (User). As the app name would suggest, this installs into the user space. I use Start-ADTProcessAsUser to install it into the current logged on user’s profile/ARP. My issue comes in when I try to use Get-ADTApplication. It appears it only gets per-machine applications, but nothing per-user. Is there a way to run the Get-ADTApplication command as the user? or, am I just missing something on how to use the command?
The attached image shows the app installed, but the command is not seeing it…

Get-ADTApplication
Get-ADTApplication1074×394 25.8 KB

All suggestions/direction would be appreciated. Thanks.

2

It's on the roadmap.

3

I’d strongly discourage peforming user-context installs from the system account via Start-ADTProcessAsUser. Instead, make your entire deployment user-context, then Get-ADTApplication will work as intended.

4

Dan, I do get what you are saying, but sometimes packages are just not as ‘cut and dry’ as that. Sometimes we may need to also perform actions that would require the system account.
I guess we could make a separate package to do the System based portions, but that requires another MECM object and a dependency tree. Not optimal, in that it adds overhead to MECM.

I accept that your team has it on their RADAR to possibly add this as a feature update in a future version. Until then I will accept this as the resolution. Thanks for your input and direction.

Fingers crossed this makes it into future version.

5

I hit the same gap and wrote a couple PSADT extension functions that expand detection to cover user-context installs by scanning HKU\…\Uninstall (native + Wow6432Node), so things like VS Code (User) show up even when running as SYSTEM. I also have optional helpers for AppX/MSIX (installed + provisioned) with extra metadata to support removal.

One caveat: this doesn’t fully handle per-user MSIs that appear in HKLM as Dan mentioned in the feat request, those require additional Windows Installer context checks to reliably determine which user(s) actually have it installed.

From a central management perspective, I generally recommend detecting/removing per-user installs and replacing with a machine-wide/system-context install as part of the PSADT flow (converge to a consistent/supportable state). If anyone wants the functions, happy to share (below) please test thoroughly before production, as I put them together quickly for immediate use and work well for my use cases, but may not for yours. THere is room for improvement and may contain bugs.

6

That's actually exactly what you should be doing here. I'm on holidays and didn't properly read your initial post before replying but Dan is 100% correct.

There's a lot of things in PSAppDeployToolkit that are there to empower packagers, but I'd consider running any user deployment from the SYSTEM account as abusive. The Start-ADTProcessAsUser function is there more for simple requirements like restarting explorer or running some small amount of code as the user in support of a SYSTEM-based deployment. It's worth mentioning that in multi-user environments such as terminal servers, it'll just apply to one single user and the user that gets nominated may not necessarily be the user that you think it'll be.

You're not the only one doing this, so don't worry. There's many out there that feel like they're deploying in some kind of superior way by deploying user apps from the SYSTEM account, etc. All they're really doing is limiting the toolkit because giving more power towards esoteric but legitimate ways to start processes changes from being handy to being dangerous in the wrong hands, therefore we just won't implement them.

7

Thanks mjr4077au and Banshii
On Wednesday I began looking into a different method to package VSCode. Our original intent was to install it per-machine, but when it comes to autoupdates a regular user doesn’t have rights to install the update. I think I may use a Scheduled task to run a winget command to do the update. I will still package the base app with PSADT, but that app will install the per-machine version of VSCode, that will run a portion of code (only on initial install) to setup the scheduled task. I am thinking of just running the scheduled task daily (when there is network connectivity). This way it checks to see if there is a new version, and if not exits, and retries the next day. I believe I can make this work. It will get us out of the per-user complications and it should allow us to keep VSCode up to date. One big win is it will be much easier to report on which machines have it.

8

Most of what I use Start-ADTProcessAsUser for is for cleaning up user-context installs (usually so they can be replaced with the system / enterprise managed version), or for a few other user-session-specific actions. The big caveat is that it only affects the currently logged-on user (a good thing, and by design).

For example, my PSADT workflow for VS Code looks like this:

If a user is logged on:

  1. Prompt for close/defer if VS Code is running.
  2. Remove the user-context install (if detected).
  3. Install/update the system-context (machine-wide) version.

If no user is logged on:

  • It won’t remove any per-user installs (no interactive user to target), but it will still install/update the system-context app.

Also worth calling out: in Intune, the detection script is what determines whether the PSADT app runs in the first place. In my environment, if a user is logged on, detection is able to account for user-context installs and trigger an update when they’re out of date, so the user gets the expected close/defer flow and everything stays consistent.

One nuance that helps here: the user-context apps I do centrally manage at scale are mostly AppX/MSIX family apps (MSIX/AppX/MSIXBundle/AppXBundle, etc.). Those are supported via my PSADT extensions and are straightforward to manage centrally from system context, while still living in user-context land and supporting auto-update behavior. So user-context installs aren’t inherently a problem... it depends on the installer type and how you design detection + remediation.

In my environment, most endpoints are single-user, so I’m not trying to sweep multiple profiles. On shared/multi-user devices we avoid per-user EXE installs and stick to system-context installs.

For Winget it may work in your case if you’re okay treating it as per-user app management and you ensure it runs as the interactive user. I don’t use winget for centralized management because I need more control and better coverage for edge cases (and some other security related reasons), but it might be sufficient depending on your requirements. Then as you said, centrally manage the system-context version with PSADT separately.

One thing I didn't mention, is that between different app versions, editions, system vs user context, etc... you can end up with multiple different versions and editions installed simultaneously... which also need factored in to your workflow (some of what I meant by better control and coverage of edge cases). Many apps are like this, and is why many 3rd party solutions don't cut it, unless you're greenfield (not really ever the case) and/or eveyrthing can be kept 100% consistent globally across the entire fleet (rare).