Please tell me about Creating WebBrowser Objects?
Every logon the WebBrowser Objects was created! It Need's over 10 seconds for every logon.
For what is this process required? The logon process is far too long for my feeling.
Is it possible to Switch it off, if not really needed?
09:37:51 Creating WebBrowser Objects...
09:38:04 'slBrowser' is ready for use!
In reply to Quest-Mac:
i have to disappoint you, we have installed a new PC with Windows 10 Enterprise, we have neither anti-Virus Software nor Windows Defender nor a Firewall to run.
And we have the same behavior. No improvement.
10:19:12 Copying [\\XXXXXXXXX\netlogon\FireFoxPrefOverrides.ini] to [C:\Program Files (x86)\Quest\Desktop Authority\Common\] with [Y R C H]   [Force32BitPath=0] 10:19:12 Creating WebBrowser Objects... 10:19:27 'slBrowser' is ready for use! 10:19:27 Calling slBrowser.Init(0) 10:19:27 'slFolderRedirect' is ready for use! 10:19:27 'slIEConfig' is ready for use! 10:19:27 OnOffNetworkStatus = ON_NETWORK
~~~~~ REMOVED DUE TO SENSITIVE ENVIORNMENTAL INFO ~~~~~~~
sltrace_logoff - the same behavior and see the delay!
10:16:48 Creating WebBrowser Objects... 10:17:03 'slBrowser' is ready for use! 10:17:03 Calling slBrowser.Init(1) 10:17:03 'slFolderRedirect' is ready for use! 10:17:03 'slIEConfig' is ready for use! 10:17:03 OnOffNetworkStatus = ON_NETWORK
It's your turn!Thats not ok and we use Standard Windows 10 Installation, please tell me what on a standard installed pc should be configured wrong? I'm curious :-)A Statement to make something wrong was configured is already very strange.Same behaviour under Standard Windows 7, well synonymous misconfigured?
In reply to werner.partmann:
In reply to m.morawietz:
Update: As of this posting, we have received a report of this issue from only three customers. The issue manifested itself on every logon as a consistent 15 or 16 second delay in the script at the point where the slBrowser COM object is registered. We were unable to recreate this issue internally despite numerous attempts. Finally, our development manager was able to reproduce this problem by disabling his Internet connection (and even then, only experienced the delay when the publisher evidence was due to be updated) and that is the reason that it was difficult to reproduce. He was never able to produce a consistent 15 or 16 second delay, but was able to produce a delay of 4 seconds and that led to the discovery of a setting in .Net Framework 2.0 where the option to check the Internet for publisher evidence is enabled by default. Once the setting is disabled, the delay is resolved. In .Net Framework 4.0, the default was changed by Microsoft not to check publisher evidence. To fix this issue, edit the WKix32.exe.config file that resides in the replication source directory of Desktop Authority and paste the line below just under the line beginning with “<NetFx40”: <generatePublisherEvidence enabled="false"/>
Note: this line will automatically be added to the Wkix32.exe.config file in any future builds beginning with 10.2.