Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

Things to know when your servers don't have internet access

Created: 13 Jul 2012 • Updated: 01 Aug 2012 • 3 comments
Ludovic Ferre's picture
+2 2 Votes
Login to vote

If you have followed the Package Server saga [1][2] on my Connect Blog you will be happy to hear that we got it all working today, but not without a last twist, that takes us to this blog post subject.

In this customer the SMP and Site Servers do not have access to the Internet. This is a not a real problem for our products however it (the lack of Internet access) has one major impact related to a security feature of the Microsoft .Net framework that I will resume in three points:

Assembly signing, assembly loading and CRL.

To ensure that .Net code is globally and securely accessible on a workstation (i.e. for an assembly/dll to be stored in the Global Assembly Cache - also known as the GAC) Microsoft enforces assembly signing. This means the assemblies are protected against tampering.

Now comes assembly loading. In our products we use code that is shared amongst many part of the product. This code leaves in DLL that are signed and added to the GAC. When a process needs to access the code in the dll .net (fusion) will lookup wherer the assembly resides and load it in the process memory space. This loading, for signed assemblies, includes a verification of the signatures, which comes in part 3.

CRL stands for Certificate Revocation List. This is the process used to ensure certificates that were once trusted are no longer used. This is a very import feature that is enforced in browsers (where we are well aware of TLS and SSL) and also in operating systems (and Windows in this particular case).

Putting it all together, and in context:

When your Task Server is severed from the Internet it local CRL store will remain active and valide for a number of days. However after a period the store cache data is invalidated, and accessing code in signed assemblies will cause the Framework to attempt to refresh the CRL store by accessing the Internet.

But because Internet access is not availbale this will time out after a short while (10 to 30 seconds).

This is extremly important for the SMP server and for Task Servers because both use signed assemblies in various locations.

For SMP the problem will show itself by impacting the console [3], making it randomly slow with parts of the console loading in 15 to 45 seconds, at different locations.

For the Task Server this will show with a CTDalaLoader service failing to start in a timely manner. No matter how you try to start the CTDataLoader service then - the service manager will just return an error indicating that the service failred to start in a timely manner.

How to fix this?

This fix was found and documented in SMP 7.0 [4] (but for SIM and the SMP server only) however the 7.1 platform comes in a 64-bit only flavour and this fix need to be applied to the 64-bit framework.

[1] Some problems with the default access to the Deployment Share on package server
[2] Can you install .Net 4.0 on a Package Server?
[3] Using the Altiris Profiler to Research "Blackholes" (Where Time Disappears Between Events)

Comments 3 CommentsJump to latest comment

Ludovic Ferre's picture

I am currently off-net, on a retreat of some kind. I'll be back real soon, and you sure will hear from me then ;-).

Ludovic FERRÉ
Principal Remote Product Specialist

Login to vote
Ian_C.'s picture

Thank you. This is helpful.

Hopefully we are not affected, but the slow console is driving everybody nuts. Will have to investigate if this is contributing.

Please mark the post that best solves your problem as the answer to this thread.
Login to vote
AltirisJunkie's picture



I am glad I ran into your article.  I could not understand why the CTDataLoader service would not stay started on my new Site Server.

I wanted to try to get it working with out disabling the CRL lookup  Since we use a proxy here in my company, it has to be set in the browser for each user to get access to the internet.

But for system level accounts it is a bit trickier.  all I did was add this at an elevated command promt.


netsh winhttp set proxy "Our-Proxy-IP:8080" "<local>"

This allowed the system itself to get out to the internet to do the CRL lookup.  As soon as this was enetered, I started the CTDataLoader services and it stays working.





Login to vote