Ignoring for a moment my general discomfort with the idea of a script installing an application ... I think that this is a good place to use a child-process.   The application forks, then the child execs the installer.   (Or it forks its own child to do so.)   The parent process(es), meanwhile, wait a while.

If they conclude that something is wrong, very careful means must be taken to notify the installer that it must back out, and to wait for it to do so.   You cannot merely kill it, because this might well leave the entire system in an inconsistent state.

Your strategy would “fall dead” if the update required a system restart, as most Windows changes do.

Before pursuing this project very far at all, I would strongly suggest that you do some very diligent research to explore what existing programs might be available that already do this.   Many companies have to “push” system changes out to hundreds of workstations overnight, and there are already many well-developed architectures in place for doing this very thing.   (And if those tools cost money, even a lot of money, “big deal ... do it anyway.”   A trustworthy tool that can actually push mass changes, and can more-or-less guarantee either “clean success” or “no-change failure,” is worth a lot of money.)   This is a high-risk undertaking, and not a trivial one.