Hi Rene,

See - www.elevenforum.com/.../

In short,  ForegroundLockTimeout  is a Registry Setting that controls the ability of new processes to "Take Focus".
By Default, we set to "0", to ensure apps launched from ZAPP take Focus.

However, changes to this value only take place after Explorer.exe is restarted.

When the user's log into a PC, is is normally via a FRESH Profile because they move alot or are using Volatile DLU?
If so, you may need to update the Default Profile so new profiles have this value....

Further, as a Test check the value of ForeGroundLockTimeout and verify it's 0.
Then restart Explorer.exe and test to see if you see the same issue.

Did it work after restarting Explorer.exe?  Was the Value already 0 as expected?

Hi Craig,

I just checked the value of ForeGroundLockTimeout and it is looking good:

So just to be sure I also restarted the explorer.exe as well as the machine but still no change in behaviour.

Any further ideas?

Thanks and regards
René

I will think about it.....

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.

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.

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 anyone is still seeing this issue.....Please let me know....

I may have something for folks to test....No it's not a ZENworks Code Fix Yet....But if it works....I can try and get Dev to implement it.

Basically...The ForeGroundLockTimeOut RegKey no longer works, but I have another way to set it.  

I can confirm the effective value does update...just not sure it fixes the issue....

See -  ZENworks: Understanding and Resolving ZAPP Focus issues with Windows 11. 

Attached to an article is a bundle that should resolve the issue.

In regards to an actual fix in Code from MS or OpenText you can follow: (There Might be an MS Defect....OpenText Code can likely do what I do a bit cleaner.)

https://portal.microfocus.com/s/article/KM000029747?language=en_US