VMware Horizon Community
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Running a script during Application startup

Hey all,

Maybe someone can help me out here.

We are trying to run a script when an application is being started. We have some applications that run from a network share so we only need to create a shortcut in UEM (yes, I will still call it that for a long long time.. Smiley Happy, BIG UEM that is Smiley Happy) but we also need to register some .dll and some.ocx files before startup.

We could off course create a startup script in which we load these files but to be honest, if someone has a lot of these files logon will be stalled.

It seems that when you create  an Application Personalization you can start a script by adding User Enviornment settings. What I tried now (just for testing purposes) is to start up Notepad just before I'm startign up Workdpad. Looking at task manager, I can see Notepad being started so the process does seem to work but there are 2 issues with this. First notepad does not show up, it seems as if the Pre-import task is being run by a different account. Second, it seems to take ages before WordPad starts up (up to 10 seconds).

Is this default behaviour? Can we execute a script or application just before starting the application? Is there another way to fix this without using a logon script and withoput compromising in performance??

1 Solution

Accepted Solutions
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi Ray,

DirectFlex pre-import tasks can definitely be used to run scripts – that's exactly what they're meant for! Something like this, for instance:

pastedImage_5.png

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.

View solution in original post

0 Kudos
4 Replies
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi Ray,

DirectFlex pre-import tasks can definitely be used to run scripts – that's exactly what they're meant for! Something like this, for instance:

pastedImage_5.png

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.

0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

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.

0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi Ray,

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?

0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Hi DEMdev,

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!