If you have followed the Package Server saga  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 , 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  (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.
 Some problems with the default access to the Deployment Share on package server
 Can you install .Net 4.0 on a Package Server?
 Using the Altiris Profiler to Research "Blackholes" (Where Time Disappears Between Events)