Dirk Van den Berghe SharePoint Blog

Clean Out Temporary ASP.Net Files on your MOSS servers

This article is all about the C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files folder on your MOSS systems.....

I was alerted by one of my systems this morning that I am running out of diskspace on the systemdrive. After running my favourite tool for this kind of situations, TreeSizeFree.exe, I discovered it was hanging while enumerating a sub-sub-sub.... folder of the Temporary ASP.Net Files folder. Don't you hate it when a tool you have always relied on hangs like that? Well, I do. Of course copy/paste the path into a cmd window and runing the dir command showed me what was wrong. After endless enumeration of that particular folder I discovered that there were 182000 (that is One hundred and eighty two THOUSAND) files in the folder. No wonder my tool hanged a while. So what's next? How will I clean this up. Here are the commands I used to cleanup that mess:

1. Stop IIS
     iisreset /STOP

2. cleanup the folder(s).

The problem here is that there are a lot of subfolders in there that need to be cleared as well, so you have two options:

A. using the rd command in combination with a for statement:

for /d %i in ("%systemroot%\Microsoft.Net\Framework64\v2.0.50727\Temporary ASP.NET Files\*") do RD /q/s %i

B. using robocopy. Just create an empty folder in some place and them run robocopy with /MIR. For example:

md %TEMP%\empty
robocopy %TEMP%\empty "%systemroot%\Microsoft.Net\Framework64\v2.0.50727\Temporary ASP.NET Files" /MIR
rd %TEMP%\empty

(Found this trick on a comment on a blog article of Doug Steward who actually wrote another way to do it)

3. Finally restart IIS

iisreset /START

Some of you might prefer to reboot the system because IIS is down anyway at this time.

So hope this helps you out somehow if you discover a lot of files in there

Speed up SharePoint spin-up and stsadm execution time by Jeroen Ritmeijer

Here is the lifesaver of the month! Jeroen's post was sent to me by Cedric Carrette (Thanks ).

Original post content;

Ever since SharePoint 2007 was introduced I have been really disappointed with the 2 minute spin-up time of the sites and the 30 second wait when launching STSADM.

How could Microsoft have released this? I thought, What is wrong with these people? Why is there no uproar in the SharePoint Community at large?

As it turns out this problem does not occur on all SharePoint installations, it only happens under a certain combination of circumstances. Fortunately I have identified the root cause as well as a solution.

Symptoms for STSADM:

• You start STSADM without any parameters
• There is a delay of about 30 seconds
• While you are waiting, and tearing your hair out because your deployment script has about 60 STSADM commands, there is no CPU activity, swapping or significant network traffic. 

Symptoms for SharePoint sites:

• You make the first request of the day, the first request after yet another SharePoint crash or the first request after recycling the app pool because you are developing assemblies that sit in the GAC.
• There is a delay of about 2 minutes
• While you are waiting, and tearing your remaining hair out because you know you have to do this at least 50 times today as you are trying to work your way around the various event receiver bugs and limitations, there is no CPU activity, swapping or significant network traffic.

So, what is going on here? Quite a few, but not that many, SharePoint developers are complaining about this on the Internet, but no-one has a real solution. Is there a solution or should I start looking for a new job?

After yet another night of Googling around I found the solution in a posting about SQL Server 2005, which appears under certain circumstances to suffer from the same problem as SharePoint 2007. (Note that in my particular situation the problem is caused by SharePoint being slow, not SQL Server.)

The problem is that when loading signed assemblies the .net Framework checks the Internet based certificate revocation list. As our servers have, like most secure environments,  no outgoing connections to the public Internet the connection to crl.microsoft.com times out after what appears to be 30 seconds. It probably does this a couple of times in succession, causing a 2 minute wait when spinning up SharePoint.

After the timeout the assembly is still loaded and the software works as expected, though very slow every time a new signed assembly is loaded for the first time, which happens a lot. The worst thing is that no entries are written to the event log and no exceptions are thrown so you are left completely in the dark about why your application is so bloody slow.

There are a couple of workarounds, which one works best is for you to decide:

1. Add crl.microsoft.com to your hosts file and point it to your local machine. Some people have reported success with this, but it didn't work for me.
2. Allow your servers to directly connect to crl.microsoft.com. If your environment dictates the use of a proxy server, configure it using proxycfg.
3. Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Find yourself a group policy wizard to help you out or manually modify the registry:
   
   [HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
   "State"=dword:00023e00
    
4. Download the CRLs and add them to the server manually (I haven't tested this, but it may work):
    
   
   1. Download: http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
      http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
       
   2. Add them:
      certutil -addstore CA CodeSignPCA.crl
      certutil -addstore CA CodeSignPCA2.crl

We decided to go for Option 3 (disable CRL check) and life is good again..... well as good as it gets when you are doing SharePoint development.

Update - VBScript to apply registry change:

The following script applies the registry change to all users on a server. This will solve the spin-up time for the service accounts, interactive users and new users.

const HKEY_USERS = &H80000003
strComputer = "."
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" _
   & strComputer & "\root\default:StdRegProv")
strKeyPath = ""
objReg.EnumKey HKEY_USERS, strKeyPath, arrSubKeys
strKeyPath = "\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing"
For Each subkey In arrSubKeys
    objReg.SetDWORDValue HKEY_USERS, subkey & strKeyPath, "State", 146944
Next

With thanks to Nik Shaw for the script.

Relevant links:

• Original article on the Microsoft Connect site that pointed me in the right direction.
• Microsoft KB article for resolving the problem in SQL 2005
• Proxycfg documentation

Changing a web application URL and dealing with requests for the old URL by Brendan Griffin

Adobe PDF iFilter 64 bit finally released spotted by Brendan Griffin

Hi,

I just came across a post by Brendan Griffin on the From the Field Blog ( great blog by the way!) about this long awaited release of a 64bit iFilter for pdf from Adobe. It is finally there. Read more about it on http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025 

The installation procedure for SharePoint is available which requires you to play around in the registry to make it actually work.

This release will probably be bad and sad news for Foxit Software that was until now one of the only suppliers of a 64bit PDF iFilter on the market.