Modify object in user's context after installation

ak00

Given that the updates are installed/run in the system's context, I'd like to modify/remove something within the user's profile at the time of installation.

Example:

Application installs, but need to replace an .ini file in %userprofile%\appdata\local\application\filename.ini

I am aware that it can be done via GPO and a host of other ways - I'm just curious if it's possible to configure Patch Manager to perform this task as part of the installation process, maybe as part of the packageboot.xml file?

<postexecution>

      <services>

      </services>

      <programs>

<program type="exe" typeaction="runandwait" name="Replace_Application_INI.cmd" successcode="0" failureaction="stop" enabled="true">

    </program>

      </programs>

    </postexecution>

Thanks!

LGarvin

It's not impossible to perform this task in the context of the WUA and PackageBoot; however, the requirements to achieve it are somewhat onerous, and you'd have to build a single self-contained script that can handle all of the necessary requirements of implementing the various copy events to howevermany %userprofile% folders would be affected.

First you'd need to script the enumeration of every %userprofile% on each machine where you want to copy the file.

Once you have the list of %userprofile% to be affected, you can invoke a file copy operation to copy the INI file from the WUA working install folder to the target %userprofile% folders.

You'd probably also have to build logic into that script to make sure you don't overwrite a newer version of that INI file (unless you want to explicitly force the imposition of the supplied file).

All of the above begs the question whether the product installer already provides some capability for inserting a standard INI file into its own installation process using a simple command line parameter.

In the end, I'll say to what you've already read -- if you can't do it from a simple command line option, this is a LOT of work to do something that's much better (and more appropriately) achieved through a simple LOGON script.