The situation
A critical desktop client was the last work application that still required IT to install it manually. It was no longer supported, its deployment options were limited and the procedure crossed pre-reboot, post-reboot, machine and user contexts. At first glance, it was an excellent candidate for leaving alone.
What I found
The vendor installer was only one part of the real procedure. Runtime DLLs had to be placed correctly, machine registry settings applied, the client rebooted and launched elevated once, then user-specific settings applied to existing profiles. Removal had another problem: vendor prompts needed to appear on the signed-in user’s desktop even though the deployment ran under SYSTEM.
What I changed
I worked through the manual process with the most experienced colleague, documented why each step existed and divided the automation into clear stages. PowerShell handled initial installation and machine configuration, local staging and a scheduled task carried work beyond the reboot, user-profile settings were translated deliberately, and a separate removal path handled the interactive handoff. Logging and cleanup were part of the workflow rather than an afterthought.
What happened
The application became available through Company Portal for both installation and managed removal. IT no longer had to repeat the eight-step process on each laptop, including devices provisioned away from the office, and support staff had enough logging and structure to identify where a failure occurred.
What I’d do differently
The original solution used ServiceUI as the practical bridge for interactive SYSTEM-context removal. PSAppDeployToolkit 4.1 later introduced a client/server UI model designed for that interaction. For a new implementation, I would revisit that layer rather than preserve the historical workaround.