DirectFlex pre-import tasks can definitely be used to run scripts – that's exactly what they're meant for! Something like this, for instance:
What DEM/UEM tasks are not meant for, is launching interactive applications like Notepad... Tasks are launched "invisibly", so you cannot interact with them. That's why you don't see the Notepad window, even though it's running as the normal user. Also, pre-import tasks run synchronously, "blocking" the launch of the real DirectFlex app until they finish. Notepad, however, won't just finish by itself, which is why Wordpad does not launch immediately.
And off course that worked like a charm. I was unaware of the fact that it ran silent. But it does run in user context right?
If you do kick off a script that takes a long time to finish, will it wait for the script to end before it does start up the application? If so we really need to look at how to do this and make it as lean as possible.
Yes, it runs as the logged-on user, just invisibly. Pre-import tasks are typically used to configure things that are required for the "real" app, so we wait for that to finish before allowing the real app to start.
If your requirements are different, you could use something like cmd.exe /c start "" your-real-command – that cmd.exe will be launched synchronously, but it will exit immediately after asynchronously launching your-real-command, so there won't be any noticeable delay in launching your real app.
Still, if your use case is that you need to register some DLLs, I guess that needs to run to completion before the "dependent" application can be launched successfully?
Yes, your assumption is right. These DLL's need to be registered before we run the application. Otherwise the application will not run at all.
Thanks for the tips!