CoNetrix

Blog: ASP.NET

A customer’s Outlook Active Sync stopped working for their phones. I connected to their 64-Bit Exchange 2007 server and found that nothing in IIS was working.

Looking at the event logs found where .NET 1.1 had been installed right before IIS stopped working.

IIS 6.0 supports both 32-bit and 64-bit. However IIS 6.0 does not support running both at the same time. ASP.NET 1.1 runs only in 32-bit mode. ASP.NET 2.0 runs in 32-bit mode or in 64-bit mode. Therefore, if you want to run ASP.NET 1.1 and ASP.NET 2.0 at the same time, you must run IIS in 32-bit mode. However Microsoft Exchange Server 2007 only supports Microsoft.NET 2.0, 64-bit version.

The problem was that Microsoft .NET Framework 1.1 was installed on the Exchange server and broke IIS since it is running in 64-bit mode for use with Exchange 2007.

  • I uninstalled .NET 1.1
  • Went to a command prompt
  • Used the following command to disable the 32-bit mode:
    cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
  • Then used the following command to install the version of ASP.NET 2.0 and to install the script maps at the IIS root and under:
    %SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i
  • Restarted IIS, World Wide Web Publishing Service, and HTTP SSL

[more]After completing the steps above everything began functioning as it should.

I found that the reason .NET 1.1 was installed, was because all the management server sessions were being used and access to the VM host was needed. An installation of Virtual Infrastructure  Client 2.0 was started but canceled on the Exchange server. VI Client 2.0 requires .NET 1.1 which was automatically installed before the VI installation was canceled.

Networking, Exchange, Exchange 2007, IIS, ASP.NET, .NET Framework,
 

I recently ran into a problem on one of our websites where users’ authentication was timing out before the amount of time I had set in the configuration.  I was using ASP.NET forms authentication with the timeout set to 30 minutes and sliding expiration set to true.  After some investigation this turned out to be a two part problem.

This first cause I found was that the sliding expiration functionality for forms authentication isn’t exactly intuitive.  When sliding expiration is turned on, each time a web page is requested, the user’s authentication cookie timeout is supposed to be updated to the expire in X minutes from the time of the page request.  However, even though you set a timeout of X minutes it is perfectly normal for a users authentication ticket to expire before that time limit due to the sliding expiration is implemented in the .NET framework.  From the MSDN .NET Framework Reference:

“If the SlidingExpiration attribute is true, the timeout attribute is a sliding value, expiring at the specified number of minutes after the time the last request was received. To prevent compromised performance, and to avoid multiple browser warnings for users that have cookie warnings turned on, the cookie is updated when more than half the specified time has elapsed. This might result in a loss of precision.”

Basically, if the timeout is set to 30 minutes then the expiration time of the authentication cookie is only updated if 15 minutes have passed when a request is made. [more] If a user signed in at 8:00 and requested a page at 8:14 you would think that their authentication would timeout 30 minutes after their last request at 8:44, but instead it would actually timeout at 8:30.  So if you want the timeout to for sure be at least a certain number of minutes you can increase the timeout to twice the desired time, or write your own code to refresh the cookie after each page request.

The second cause of the problem that I found was that the settings on the Application Pool in IIS was causing the ASP.NET worker process to be recycled after a number of minutes and shutdown after 20 of being idle.  I changed the worker process to recycle at a set time during off peak hours instead of after a number of minutes had passed. I also increased the number of idle minutes before the worker process would shutdown.  I included screen shots of the settings below.

 

General, IIS, ASP.NET,