locked
Exchange 2007 OWA killed by Windows Update this Tuesday RRS feed

  • Question

  • I have an Exchange 2007 running on Windows 2003 R2 64. Virgin installation.The installation went perfect. Ran MS Update to get all SP & Hotfixes. OWA was working, Messages flowing in and out. Passed the Exchange Best Practices with flying colors. I was pleasantly surprised.

    This is an IBM Xeon 5050

    Then the Tuesday Automatic Updates ran, box rebooted on it's own (caused by the Update. First reboot, none of the Exchange services would load except for System Attenedent. All services would start manually. On manual shutdown and restart all services came up but OWA and IIS won't load.

    I need to get OWA working again, pronto since we had already switched people tothis system from an outside POP3 service.

    An HTTP://LOCAHOST reports the following for the root site and the EXCHANGE directory.

    Service Unavailable

    The IIS service is loaded, the Web site is started

    The Application log reports these errors.

    Evernt ID 2274

    ISAPI Filter 'C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_filter.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a AMD64 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

    This is not an AMD processor, did AutoUpdate install the wrong update?

    The System log reports these errors:

    Application pool 'MSExchangeOWAAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.

    A process serving application pool 'MSExchangeOWAAppPool' reported a failure. The process id was '4164'.  The data field contains the error number.

    A process serving application pool 'MSExchangeOWAAppPool' reported a failure. The process id was '3384'.  The data field contains the error number.

    A process serving application pool 'MSExchangeOWAAppPool' reported a failure. The process id was '3264'.  The data field contains the error number.

    A process serving application pool 'MSExchangeOWAAppPool' reported a failure. The process id was '4532'.  The data field contains the error number.

    A process serving application pool 'MSExchangeOWAAppPool' reported a failure. The process id was '3652'.  The data field contains the error number.

    Friday, January 26, 2007 1:17 AM

Answers

  • Took me two days and 8 hours on the phone with MS to get this answer. However Offline Address Book is still broke.

    The ultimate Answer was to stop IIS, delete OWA, Restart IIS. In the Exchange 2007 Manager, under Server Configuration, Client Access, pick the right hand option to Disble Outlook ANywhere. Restart IIS, then run Enable Outllok Anyware. Restart IIS again.

    IIS worked, OWA worked.

     

    The KB article is about OWA commandlets. http://technet.microsoft.com/en-us/library/dcfb7291-a7fb-4ec5-975b-1d980f9fb06d.aspx

    Friday, February 9, 2007 6:10 AM
  • It's back.... Another Tuesday Patch and the Exchange web site reports Service Not Available. No Outlook Anyware, no OWA

    Event logs tell me that ISAPI can't load because an Athelon module is loaded.

    The .Net 1.1 and .Net 2.0 will not coexisit and have the Exchange web siite running.

    So remove .Net 1.1, force .Net 2.0 to run in 64 bit mode. http://support.microsoft.com/kb/894435 

    IISRESET.

    In IIS, remove OWA directory.

    Run Commandlets for creating OWA http://technet.microsoft.com/en-us/library/dcfb7291-a7fb-4ec5-975b-1d980f9fb06d.aspx 


    Remove-OwaVirtualDirectory

    New-OwaVirtualDirectory

    In Exchange Manager, disable Outlook Anywhere, IISRESET, Enable OutlookAnywhere, IISRESET

    In EM set the path properties and set Forms Authenticaion, disbale Anonymous access, Turn on Require SSL in IIS

    IISRESET

    This is a real PIA for Exchange 2007.

     

    Thursday, February 15, 2007 6:03 AM

All replies

  • Well following http://support.microsoft.com/kb/894435/en-us I remove .Net 1.1 and registered . Net 2.0 and restarted IIS, I now can get to the OWA login page.

    Now fighting authentication issues, won't let the domain administrator in.

    Sigh.... Noting like an Automatic Update to ruin your day.

    Friday, January 26, 2007 2:36 AM
  • I am having this exact same problem! Need help!
    Thursday, February 8, 2007 4:50 PM
  • Took me two days and 8 hours on the phone with MS to get this answer. However Offline Address Book is still broke.

    The ultimate Answer was to stop IIS, delete OWA, Restart IIS. In the Exchange 2007 Manager, under Server Configuration, Client Access, pick the right hand option to Disble Outlook ANywhere. Restart IIS, then run Enable Outllok Anyware. Restart IIS again.

    IIS worked, OWA worked.

     

    The KB article is about OWA commandlets. http://technet.microsoft.com/en-us/library/dcfb7291-a7fb-4ec5-975b-1d980f9fb06d.aspx

    Friday, February 9, 2007 6:10 AM
  • It's back.... Another Tuesday Patch and the Exchange web site reports Service Not Available. No Outlook Anyware, no OWA

    Event logs tell me that ISAPI can't load because an Athelon module is loaded.

    The .Net 1.1 and .Net 2.0 will not coexisit and have the Exchange web siite running.

    So remove .Net 1.1, force .Net 2.0 to run in 64 bit mode. http://support.microsoft.com/kb/894435 

    IISRESET.

    In IIS, remove OWA directory.

    Run Commandlets for creating OWA http://technet.microsoft.com/en-us/library/dcfb7291-a7fb-4ec5-975b-1d980f9fb06d.aspx 


    Remove-OwaVirtualDirectory

    New-OwaVirtualDirectory

    In Exchange Manager, disable Outlook Anywhere, IISRESET, Enable OutlookAnywhere, IISRESET

    In EM set the path properties and set Forms Authenticaion, disbale Anonymous access, Turn on Require SSL in IIS

    IISRESET

    This is a real PIA for Exchange 2007.

     

    Thursday, February 15, 2007 6:03 AM
  • My owa appears to be up and running again by uninstalling .net 1.1. After this I disabled the 32bit mode ("cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0")

    Hereafter I installed .net 2.0 using the below command:

    %SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i
     
     
    After an iisreset site came up again. Cant remember if I had to disable and then enable require ssl on the site.
    • Proposed as answer by LoganK Wednesday, April 18, 2012 7:32 PM
    Wednesday, March 14, 2007 3:00 PM
  • John

    I noticed just doing the first steps (i.e. uninstalling .net 1.1 and running those kb commands) actually did the job of restoring the owa~!

    :Tongue Tiedigh:: oh ms, why you torture us exchange admin souls!
    Tuesday, April 3, 2007 10:06 AM
  • I did:

     

    Uninstalling .net 1.1 + hotfix 1.1

    run the script

    registering 2.0

    iisreset

     

    Works lilke a charm

     

    Erik.

    Wednesday, May 30, 2007 3:48 PM
  • My OWA is working again.

    "Thank all you dude, i use a little bit of everything you post here."

    1) Uninstall all .NET framework versions, reinstall .NET 2 framework and its updates
    2) Uninstall IIS, Reinstall IIS from zero (0) only a new and empty "Default Web Site" may be there.
    3) Run:
    cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
    then
    %SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i

    4) Don't be afraid! Open Control Panel -> Add or Remove Programs -> Microsoft Exchange 2007 -> Click on [Remove], next, uncheck
    "Client Access Rules", next, uninstall.

    After unistalling
    "Client Access Rules", go again to
    Control Panel -> Add or Remove Programs -> Microsoft Exchange 2007 -> Click on [Change],
    next, check
    "Client Access Rules", next install.

    5) After this, pray for everything goes well. And when you go back to Exchange everything will be there!  OWA will be working again.

    []s

    bye
    Wednesday, June 6, 2007 2:11 PM
  • Done it simplest, hacks IIS Metabase.xml(C:\WINDOWS\system32\inetsrv\metabase.xml)

     

    Code Snippet
    <IISFILTER&NBSP;LOCATION
      FilterDescription="ASP.NET Cookieless Session Filter"
      FilterEnableCache="TRUE"
      FilterFlags="0"
      FilterPath="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_filter.dll"
      FilterState="4"
     >

     

    to:

    Code Snippet

    <IIsFilter Location ="/LM/W3SVC/Filters/ASP.NET_2.0.50727.0"
      FilterDescription="ASP.NET Cookieless Session Filter"
      FilterEnableCache="TRUE"
      FilterFlags="0"
      FilterPath="C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_filter.dll"
      FilterState="4"
     >
    </IIsFilter>

     

    Exchange 2007 OWA works fine.

     

    Thanks for David Wang's blog posts:

    http://blogs.msdn.com/david.wang/archive/2005/12/14/HOWTO-Diagnose-one-cause-of-W3SVC-failing-to-start-with-Win32-Error-193-on-64bit-Windows.aspx

    Monday, June 11, 2007 7:59 AM
  • I ran into this issue as well this week after applying the June critical updates. The server in question is running Windows 2003 X64 R2 and Exchange 2007 Enterprise and had been working fine prior to the updates.

    How frustrating! In any case, I used the steps to install the 64 bit version of Asp.net 2 from the MS article 894435 and that took care of it for me.

    http://support.microsoft.com/kb/894435

     

    Sunday, June 17, 2007 5:17 PM
  •  

    I think this update needs to be blamed.

     

    Microsoft Security Bulletin MS07-040 - Critical

    Published: July 10, 2007

    Version: 1.0

     

     

     

    Thursday, July 12, 2007 9:43 AM
  • I can confirm that this is all about .NET 1.1. It does not play nice with the 64 bit version of .NET 2.0. Within IIS, it is an exclusive relationship. You can have .NET 1.1 functional or you can have .NET 2.0 functional but not both.
     
    I have 2 Windows 2003 R2 x64 servers that have .NET 1.1 installed so that Group Policy Management Console can be installed (and it works just fine, by the way, but that is another story). As it turns out, GPMC.msc could care less if .NET 1.1 is available in IIS but .NET 1.1 mucks with IIS a lot. The answer is that the .NET 2.0 x64 has to be reinstalled every time a .NET 1.1 "improvement" shows up from Microsoft. After each patch or fix or whatever, the Certificate Services Web site fails on the server that has Certificate Services installed on it and WSUS 3.0 x64 fails on the other server. It gets a little darker too in that 3rd party applications that can run with .NET 2.0 may "overconfigure" .NET and set it into 32 bit compatibility mode and "break" .NET 2.0 x64 in a similar way. The bottom line is that any server with .NET 2.0 x64 installed and required by an application is "fragile". This includes a lot of 3rd party server products such as (xxxxx AV server console) that require .NET 2.0 but that are not x86/x64 aware and make inappropriate configuration changes to .NET 2.0 x64 instead of .NET 2.0 x86 or in addition to .NET 2.0 x86. In fact, SEVERAL MICROSOFT RELEASES that are .NET 1.1 aware (such as the patch/update/security fix above) are not .NET 2.0 x64 aware and make inappropriate changes to .NET x.x or to IIS during installations or updates. So many products have web service interfaces these days that it becomes problematic keeping .NET 2.0 x64 functional with or without .NET 1.1 in the mix!
     
    I guess this means that we all go back to the days when you install ONLY 1 application or 1 including Microsoft Server applications (such as Certificate Services) per SERVER because of the fragility of .NET 2.0 x64. The original install (perhaps it may be order dependent!) may seem to go OK but every patch brings another round of fixing the server and potentially requires a complete uninstall/reinstall of either .NET 2.0 x64 or the x64 application to get the server back to operational status!
     
    Seems MICROSOFT could, at minimum, make all of it's patches, updates and product upgrades .NET 2.0 x64 "friendly" and help us out just a bit!
     
     
    Friday, January 18, 2008 11:32 AM
  • Hi All

     

    I went thought all your Posts and comments, checked all the submitted URL in this topics but didn't solve my issue.

     

    Accutly my issue a little differ from this the OWA is working and i can log on to the OWA page but when doing any action (open new mail, clieck on the inbox, Reply) it gives me this Error Message: “Microsoft Exchange issued an unexpected response (404)”

     

    I go beyond this and make a new Virtual Directory for the OWA using the Exchange Shell cmd: New-OWAVirtualDirectory

     

    the only solution i have now is to uninstall the Client access rule and uninstall the IIS then reinsatll them again.

     

    Any suggestion could help me avoid this solution

     

    by the way,I didn't find a usful info all over the web more than this topics

     

    Many thanks

    Wednesday, February 27, 2008 12:34 PM
  • Hi, 

     

    Followed your instructions and all seemed to work except I am missing some virtual directories from OWA...specifically

     

    1. exadmin

    2. exchange

    3. public

     

    Anyone know how I can get these back?

     

    thanks

    Friday, March 14, 2008 5:12 PM
  •  

    Please tell me WHY you would REQUIRE framework 1.0 to install Exchange 2007? Then only to have it break the server. I just did a brand new roll-out and this is very frustrating! I tried to redirect it in the XML file, lets' hope that works.
    Monday, March 17, 2008 2:51 PM
  • Hi Brian123456,

    As far as I know, you need .NET 1.1 to use the ExBPA tool.
    Sunday, March 23, 2008 9:01 AM
  • hi all,
    server 2003 &exchange 2007 was installed the framework 1,1 in order to use GPC . but owa was stopped responding.
    Same problem differnet solution, 
    I was follow the intractions at http://support.microsoft.com/kb/894435/en-us
    everyting now at OWA seems to be working...


    Thursday, April 10, 2008 8:28 AM
  •  aadupre wrote:

    Hi, 

     

    Followed your instructions and all seemed to work except I am missing some virtual directories from OWA...specifically

     

    1. exadmin

    2. exchange

    3. public

     

    Anyone know how I can get these back?

     

    thanks



    Hi, you can recreate them from the powershell command line, using the new-owavirtualdirectory command. The syntax is displayed here : http://technet.microsoft.com/en-us/library/bb123752(EXCHG.80).aspx
    Friday, April 18, 2008 7:38 AM
  • Sir..... you are a genious.

     

    Thanks

    Monday, June 16, 2008 11:33 PM
  •  This also worked for me.  My problem started after foolishly attempting to install BlackBerry Professional on Exchange 2007 server.  Had to until BB, reboot, uninstall .net 1.1 and then run the two commands below, then run iisreset.  Thanks for posting this info.  -Bob

    <=== Quoted =====>
    My owa appears to be up and running again by uninstalling .net 1.1. After this I disabled the 32bit mode ("cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0")

    Hereafter I installed .net 2.0 using the below command:

    %SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i
     
     
    After an iisreset site came up again. Cant remember if I had to disable and then enable require ssl on the site.
    Thursday, January 8, 2009 3:07 PM
  • I had the same issue with Windows Server 2003 x64 running Exchange 2007. 

    After installing .NET Framework v1.1 and patches in order to try to get GPMC v1.1 working, Outlook Web Access (OWA) died with "Service Unavailable" error message.

    I first uninstalled GPMC and .NET Framework v1.1 and then used the info from Microsoft here:
    http://support.microsoft.com/kb/894435/en-us

    to run:
    cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

    and also run:
    %SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i

    and this was sufficient to bring OWA back from the dead.
    Thursday, August 13, 2009 2:31 AM