ZENworks - Bundles starting via ZAPP are always opening in background (behind ZAPP)

Hi,

I just got reported a strange behaviour, that bundles, which are started via ZAPP, are always starting behind this.
Depending of the application you sometimes just see the icon at the taskbar. So for some people not the best user experience.

They are running Windows 11 22H2, also some machines with Windwos 11 23H2 and with ZENworks 23.3.

I also was able to replicate this (for both windows versions) and now I am just surprised, that now it is the first time I have heard of this. None other customers have reported this.

I know that the support for Windows 11 23H2 is comming with ZENworks 23.4, but since this behaviour also occures with the previous Windows versions, I just wanted to ask if someone else noticed this or if I am missing something?

So far I was not able to find some helpful entries in the Knowledge Base or somewhere else.
I just found the following:
www.novell.com/.../bvj1efc.html

There is the option "DisableForegroundLockTimeoutReset" mentioned to prevent newly launched applications from moving int the foreground, but so far the customer is not using this and in my environment the option is also not setted.


Thanks and regards
René

Parents
  • 0

    Just to confirm we have the same issue on Windows 11 machines. We only have a handful at the moment and it hasn't bothered us enough to create an SR.

  • 0   in reply to 

    I would confirm the same settings....

    There is not much in the code other than setting the above value.  That is the only thing that controls such things, short of setting a particular Window to have the "AlwaysOnTop" value.  MS does not provide any APIs for controlling the "Focus" of any launched process.

    I'm not disputing what you are seeing....Just that if the ForeGroundLockTimeout is set to 0 under HKCU when Explorer.exe starts and you still have the issue...then something may be up with Windows itself and a ticket to MS from outside may be warranted.  There is not much you can really do in code.

    In the past, and possibly/probably still do....We actively update the Explorer process with that value even after starting to avoid needing it set first, but setting first is what recommend especially when troubleshooting.

    Trying to "Code" ZENworks to start the process in front would be virtually impossible to do in a reliable way.

    For Example - If your Bundle Started "Calc.exe"....The actual end process running is Calculator.exe....So if our code search for the Calc.exe process to call any windows to the front.....it would fail.  That being said....If it happened enough, our Devs could engage MS to figure out why Windows was doing or not doing what it should.

    I tried doing some googling....and really found nothing around any changes in how Windows works in this regard.

    --

    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

    Be sure to "Like" My (and a few others) Cool Solutions below! 

    https://community.microfocus.com/members/craigdwilson/bookmarks

Reply
  • 0   in reply to 

    I would confirm the same settings....

    There is not much in the code other than setting the above value.  That is the only thing that controls such things, short of setting a particular Window to have the "AlwaysOnTop" value.  MS does not provide any APIs for controlling the "Focus" of any launched process.

    I'm not disputing what you are seeing....Just that if the ForeGroundLockTimeout is set to 0 under HKCU when Explorer.exe starts and you still have the issue...then something may be up with Windows itself and a ticket to MS from outside may be warranted.  There is not much you can really do in code.

    In the past, and possibly/probably still do....We actively update the Explorer process with that value even after starting to avoid needing it set first, but setting first is what recommend especially when troubleshooting.

    Trying to "Code" ZENworks to start the process in front would be virtually impossible to do in a reliable way.

    For Example - If your Bundle Started "Calc.exe"....The actual end process running is Calculator.exe....So if our code search for the Calc.exe process to call any windows to the front.....it would fail.  That being said....If it happened enough, our Devs could engage MS to figure out why Windows was doing or not doing what it should.

    I tried doing some googling....and really found nothing around any changes in how Windows works in this regard.

    --

    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

    Be sure to "Like" My (and a few others) Cool Solutions below! 

    https://community.microfocus.com/members/craigdwilson/bookmarks

Children
  • 0   in reply to   

    Hmmm....

    My Ramblings just gave me a thought.....What is Good for the Goose is Good for the Gander.

    While Historically we have used code to UPDATE the Value of that Setting to "0" in the Running Explorer.exe process.

    A NON-ZENworks Process could be setting it BACK to something such as 10000.

    Again....I'm not talking about the REGKEY itself here....but rather the ability to change the Effective Value in the Running Explorer.exe process.  So what we may be able to do in code is optionally re-enforce it at different times....Refresh....Bundle Launch, etc....

    So the first thing I would want to do when debugging if I made a ticket was the READ the Explorer.exe process to get the effective VALUE for ForeGroundLockTimeout to verify if it was 0 or another value.  Then we would need to figure out what ELSE is changing it back if it is indeed not the expected value in the running Explorer.exe process.

    --

    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

    Be sure to "Like" My (and a few others) Cool Solutions below! 

    https://community.microfocus.com/members/craigdwilson/bookmarks