I - Introduction
Certain types of customer environments may experience either perceived slowdowns or console 'freezes' now and then.
These tend to be often caused by outdated root-certificates and/or an inability of the relevant device(s) in question to update their root certificates automatically.
Once the root certificate issue is resolved, the performance improvement can be quite dramatic and lead to a much better quality of life user experience.
II - Symptoms & Issue Details
LANDesk Management Suite 9.6 continues the trend of previous releases of increased & tightened security features around the product. One of the greatest changes in regards to security in 9.6 concerns all of the binaries on the Core / Console - primarily so as to prevent use/injection of malicious binaries. In short - LANDesk Management Suite will only work with official, LANDesk binaries.
In certain environments where direct access to the internet is not readily permissible or certain other limitations apply, a side-effect of this enhanced security is that it can cause performance problems.
This is a feature of Microsoft(*)'s .NET Framework(*) - one of the key pre-requisites of the LANDesk remote console. And it is down to .NET which is ultimately responsible for the delays experienced here - albeit purely motivated by doing "its defined security job"
II.A - Common Symptoms
General symptoms of problems experienced tend to include :
- After leaving the remote console for longer periods (20+ minutes), clicking back into the console causes it to freeze (with 0-low CPU activity) for ~10 seconds (this is the most common give-away around this issue).
- Frequent "console slow down" experienced (this is highly subjective though and can be caused by a veritable multitude of related & unrelated issues)
For this particular issue, the above symptoms are usually seen on REMOTE Windows Consoles (Consoles not hosted on the Core itself) primarily.
See below on how to track down / diagnose for yourself whether or not this is the issue you're experiencing.
III - Causes & Resolution
One of the easiest ways to verify if "this is your problem" is by running a tool such as Fiddler (which can be gotten here -- Fiddler free web debugging proxy ) to monitor the (attempted) www-connections made from the device.
There's other tools that'll do the same sort of thing - by and large you're checking for outgoing connection attempts to a windowsupdate (or related) server.
NOTE -- once the root certificates are up to date, those connections will NOT be made (until the certs are deemed to be out of date again).
III.A - Example Fiddler trace with highlight:
Here's an example screenshot of the sort of thing you're looking for.
Please note that the outgoing connection(s) might not necessarily go to windowsupdate directly.
It's quite possible that you might see a connection towards "akamaitechnologies.com" as well and probably others too. There's various hosts that are all associated with windows update locations / root certificates.
III.B - Why would a LANDesk process connect to windowsupdate?
It's not the LANDesk code which does, actually.
From a technical detail point of view, it's actually down to the .NET API's that get called by CONSOLE.EXE and they can/do certain things as Microsoft(*) had coded them. This is why it appears that CONSOLE.EXE is opening the connection (when it's really a .NET call under the hood).
Given that various calls around digital signatures that need to be verified for validity are made, it should not be too surprising that the .NET Framework tries to ensure that the system it's running on has up-to-date root certificates when such API's are indeed called (as is the case with the Windows Console).
III.C - Is there a brute-force solution?
Yes - there is. It is *NOT* recommended (as having up-to-date root certificates is a good thing), however.
But the information is listed in the Microsoft(*) Technet article below. For completeness sake, however, here it is.
You can disable the Windows Update check around root certificates via a registry entry on the system in question. Here's how:
set/add a DWORD called “DisableRootAutoUpdate” to “1”.
IV - Additional Information
You can find detailed information from Microsoft(*) around root-certificates in this technet article:
This includes information on how to update root-certificates across various kinds of dark / disconnected networks, and - if need be - straight up disabling the relevant root certificate check.
The article also lists configuration solutions via active directory / administrative templates and pointing towards alternate certificate-update servers.
V - In Conclusion
This article should cover all (or at least - most) of the questions that might arise around this issue. It should equally cover the relevant steps you need to take to identify whether or not you're actually affected by it & how to resolve them.
(*)3rd party names and trademarks are property of their respective owners.