Exchange 2003 Routing Engine Service Doesn't Start After Security Patches
Alan comes to the rescue when a client's Exchange services won't start after the client installed the latest security patches from Microsoft.
June 25, 2007
I received a call from a consulting client early this morning stating that his Microsoft Exchange Server 2003 server was down. When I examined the server, none of the Exchange services were started. The server was running Windows Server 2003 with SP1 and Exchange 2003 with SP2. On June 13, Microsoft released some critical security updates that are referenced in the following articles:
"MS07-034: Cumulative security update for Outlook Express and for Windows Mail" (http://support.microsoft.com/kb/929123)
"MS07-033: Cumulative Security Update for Internet Explorer" (http://support.microsoft.com/kb/933566)
"MS07-031: Vulnerability in Schannel could allow remote code execution" (http://support.microsoft.com/kb/935840)
" MS07-035: Vulnerability in the Win32 API could allow remote code execution" (http://support.microsoft.com/kb/935839)
Article 935839 is a hot fix that addresses security problems with the Win32 API. When I tried to start any of the Exchange services except for the Exchange Routing Engine service, I received an error that the service did not start because a dependency service failed to start. When I tried to start the Exchange Routing Engine the System Event log recorded the following error:
Source: Service Control Manager
Category: None
Event ID: 7023
Description:
The Microsoft Exchange Routing Engine service terminated with the following error: Microsoft Exchange Routing Engine is not a valid Win32 application.
For more information, see the Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I noticed in the Event logs that the four security patches mentioned earlier were installed early in the morning and when the server was restarted, the Exchange services did not start. The client has several Exchange servers, but when the patches were installed on the other servers, the Exchange services started fine. I thought perhaps there was a corruption on this Exchange server, but where? I decided to install Windows 2003 SP2 on this server since it only had SP1. When I restarted the server, it still had the same problem. I tried to reinstall Exchange 2003 SP2, but I received an error message that Setup failed while installing the Sub Component SMTP service with Errorcode 0XC103798A. I decided to open up a case with Microsoft Product Support Services (PSS). After performing some initial review, we decided to reinstall Exchange 2003. I inserted the Exchange 2003 CD-ROM, selected Reinstall, and answered No to overwrite any newer files. However, during the reinstall process, I encountered an error when trying to copy over dsaccess.dll onto the server. At this point, I made a backup of the Exchange 2003 databases just in case things went really wrong. After the backup finished, I renamed the c:program filesexchsrvrbin folder to binold and tried another reinstall of Exchange 2003. This time it successfully completed. After the reinstall, I installed Exchange 2003 SP2 and it successfully completed. I restarted the server and all the Exchange services started. Using the Exchange System Manager (ESM), I reviewed the queues on the server and they looked good. I ran a test email to/from the Internet and to/from a different Exchange server and that was successful. I don’t think the security patches directly caused the Exchange server to crash, but I think it was related. I think one or more files were either corrupted or had versions that were incompatible with the security updates. The trick here is to rename the Bin folder before you attempt the reinstall of the Exchange 2003. I’m not sure how widespread this problem is, but it took an entire day to get the server back up and running. If you run into this problem, I hope this article can save you a lot of time.
Tip: MOSS 2007 and Office Infopath 2007
With Microsoft Office Sharepoint Server (MOSS) 2007 and Infopath 2007 you can create forms that users can fill out without having Infopath installed on their workstations. There are some potential landmines that you should know about before rolling out Infopath:
Enterprise Client Access Licenses required for Infopath forms. To use Infopath 2007 with MOSS 2007, you must have MOSS 2007 Enterprise CALs. The MOSS 2007 Standard CAL does not support Infopath.
Enable Enterprise Site Collection Features. Under Site Settings, Site Collection Administration, Site Collection Features, make sure to activate the Enterprise Site Collection Features. If you don't activate these features, you'll receive an error message that your Infopath form isn't browser enabled (even though it is) when you attempt to publish the form using the Infopath 2007 Publishing Wizard. For tips about publishing an Infopath form check out http://blah.winsmarts.com/2006-10-InfoPath_2007_Forms_Server_MOSS_2007.aspx.
About the Author
You May Also Like