If I watch in sysinternal's process explorer any w3wp.exe process (linked to a SharePoint 2007 application pool), I recognice TCP-connection trials to ip addresses 84.53.175.26 and 84.53.175.27. Access to such Internet addresses aren't allowed for processes running on our intranet servers and therfore they don't succeed. The w3wp.exe process tries two times, timing out after 20 seconds during each attempt. The w3wp.exe process doesn't answer incoming requests in this time period. nslookup solves these FQDN to the above mentioned ip addresses: crl.microsoft.com: CName = crl.www.ms.akadns.net crl.www.ms.akadns.net: CName = a1363.g.akamai.net a1363.g.akamai.net: A-Record = 84.53.175.26, 84.53.175.27 How can I deactivate those requests to Microsoft's certificate revocation list server? I am thankful for every piece of information you are able to give to me.

The common language runtime (CLR) tries to verify the Authenticode signature at load time to create Publisher evidence for the assembly. However, by default, most applications do not need Publisher evidence. Standard CAS policy does not rely on the PublisherMembershipCondition. You should avoid the unnecessary startup cost associated with verifying the publisher signature unless your application executes on a computer with custom CAS policy, or is intending to satisfy demands for PublisherIdentityPermission in a partial-trust environment. (Demands for identity permissions always succeed in a full-trust environment.) <?xml version="1.0" encoding="utf-8"?> <configuration> <runtime> <generatePublisherEvidence enabled="false"/> </runtime> </configuration> If your application is hosted in IIS, change one of the following: C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet.config C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config Note On x64 machines, you must also change one of the following: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet.config C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config reference http://msdn.microsoft.com/en-us/library/bb629393.aspx Or Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Create a GPO to help modify the registry: [HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing] “State”=dword:00023e00 -IvanIvan Sanders My LinkedIn Profile, My Blog, @iasanders.

Ivan, thank you for this hint! I will try it tomorrow and come back to this thread to report success or failure. Mathias

Hello Ivan, sorry that it lasts so long for me to answer. I changed the file machine.config on out test-sharepoint-server but I am not able to sniffer all the network traffic on this server. Therefore all I can tell is that when the app-pool starts and the browser accesses the website for the first time, the w3wp.exe process no longer tries to access the ip-address mentioned in my first post. On the other hand the access-times to our sharepoint frontend still are lousy. May be there is more than one reason for those delays. Mathias