Some customers have reported to us that the AGPM 3.0 client can sometimes take up to 30 seconds to start before it gives you access to the console. While its doing that, the GPMC snap-in essentially looks like its hung. We only ever see this issue in isolated environments such as virtual machine test environments and GPMC clients that don’t have an Internet connection.
So why is it doing that?
AGPM uses a fair amount of managed code (that means .NET code). Our code is always signed with Authenticode signing so you can be sure it came from us. When the GPMC snap-in loads and AGPM snaps into that, Authenticode invokes a CRL check. There are some hard coded timeouts built into signature checking - of 15 secs for the first signature and 20 seconds for cumulative signature checks. When you’re in an isolated environment each of these timeouts gets hit which explains the 30 seconds (actually 35 seconds to be exact).
What can I do about it?
If you know that certain machines will always be isolated and never able to check the CRL lists then you can set some Group Policy options to modify these timeouts - these will affect anything else in Windows that does a CRL check so its entirely possible that other timeouts you may be mysteriously hitting in managed code will also be "fixed" by this change. Here’s what you do:
Bear in mind the implications of what you are doing here. This essentially means that CRL’s will not be looked up by any machine that is affected by this policy!! Only do this if you know that these machines will never be connected to the Internet.
That said, a couple of customers have tested this and report that it works well. Let me know if it fixes it for you!
It would be great if somewhere in the system it would use NLA to skip CRL checks when there was no hope of them succeeding.
Just sayings all.
Could be wrong but I didnt think NLA checked for Internet availability...