Thursday, November 17, 2005

Exchange 2000/2003 Front End Server Logon Process

Tim Hackbart with PSS explains the basic OWA logon process... 

Working in Support Services, I get to explain this subject a lot, so I thought I’d share it here too. This blog post will explain what the flow of the client access a BE server through a FE server looks like, including access to domain controllers that has to happen as part of this process. The illustration shows the steps, which are then covered in more detail further down:



Step 1. The client makes a Http request to the Front End sever




In this case the request is made over port 80-Http.  The client must first resolve the Host name and then attempt a connection to the returned IP address.


Step 2. The firewall has port 80 open to allow Http traffic


Note: Port 443 would be required for SSL traffic.


Step 3. The IIS server is listening on Port 80 and responds to the http request made by the client.  IIS will first determine which Web site to direct the http request to.  If there is only a Default Web site then ALL http requests will be sent to the Default Web site.  If there are multiple Web Sites configured then IIS will determine the appropriate web site to direct the request to depending on the Port, IP address or host header that uniquely identifies the individual web site.


Step 4. Once the http request has been sent to the correct web site, then that web site will send the request to the correct directory, in our case "\exchange".  IIS will then enforce the logon method using the Authentication Method specified in the Directory Security Tab- Anon, Basic or Integrated.  IIS will contact a Domain controller using RPC to authenticate the user and get a SID for that user using LogonUserEX API.  Note: Authentication will only be enforced at the Virtual Directory level.  We do NOT have to Authenticate to the Default Web Site, just to the specific resource requested, in our case the “Exchange” virtual directory.


Step 5. After the logon method is enforced by IIS the request is sent to the Exchange directory.  For this example the Exchange virtual directory has Basic authentication selected.  Since Exprox.dll is set as the application mapping for all (*) mappings Exprox will handle every request that is not picked up by the listed Application Extensions.  (In Exchange 2003 only Exprox.dll will then build a Kerberos Ticket and NTLM hash to send to the Back End Server.) Exprox will take the SID that IIS got and use Dsaccess to query the Global catalog returned by DNS over port 3268 for information about the user logging in.  The Global Catalog will respond to the LDAP queries with user information including the users Home MDB and SMTP proxy addresses.


Step 6. Exprox now knows the users home mailbox server and smtp addresses.  Exprox will then compare the Exchange path of the virtual directory and make sure that the user has an smtp address that matches.  If no matches are found, the user is returned an error message. (In Exchange 2003 SP1 this behavior changes, and you no longer need to have an SMTP address that matched the Exchange path).  If there is a match then exprox will proxy the request to the users home mailbox server over port 80.


Step 7. IIS on the back end server then has to again determine the correct web site to send the http request to. Then the request is sent to the Exchange directory, where it must be Authenticated again using the LogonUserEX API, then Davex.dll intercepts the request.  Davex will then once again use Dsaccess to query for the users Home mdb and smtp proxy addresses.  Davex will also check to make sure the user has an smtp address that matches the Exchange path (Unless you are at Exchange 2003 SP1, as mentioned before).  Davex will then send the request through Epoxy, Epoxy then talks to Exoledb which then talks to the store.  The data is then returned through the same process to Davex.  Davex then returns the web content to the user.  The response is sent to the Fe server over port 80


Step 8. The FE server receives the response and proxies the response to the client.


That is basically it! Hope this was useful!


Exchange Service Management Guide


Microsoft Exchange Service Management is a top-down, business-driven approach to managing a messaging environment. It specifically addresses the strategic business value that an Exchange team generates and the need to deliver a superior messaging service.

The guidance will help you implement process and team best practices within the corresponding components of the Exchange Service Management solution: Microsoft Operations Manager 2005 SLA Scorecard for Exchange and Systems Management Server 2003 Desired Configuration Monitoring.

This guide, along with SLA Scorecard and Desired Configuration Monitoring, targets the most critical areas for managing computers running Microsoft Exchange Server and for performing configuration and performance management.

Send questions or feedback to us directly at

News Source:

Wednesday, November 16, 2005

Microsoft Exchange 12 roadmap from IT Forum

The pic speaks for itself, click on it for large view.

Exchange 12 Roadmap

Friday, November 11, 2005

Are large messages slowing your Exchange server down?

Dave Mills has recently posted this article on EHLO to help admins understand some of the logic for why Exchange handles NDR's and large messages the way it does.  It also shows good reasons why message size limits are so important.  I know for me this is a change of perspective I have had over the last couple of years.  I used to not believe in message size limits, but over the last 4 - 5 years have changed my mind and fully recommend them. 

As Ewan mentioned a little while ago, there are some pretty extreme things going on in some our customer’s Exchange environments.  One of the things that I could definitely relate to was the customer who sent a message that was 2.4GB that was successfully delivered.  While Exchange is quite capable of transferring huge messages, using it to do so usually results in severe performance issues.  In fact, one customer that I worked with was experiencing major problems due to a 6 GB message traveling through their Exchange server.  To make things even more interesting, the 6 GB message that we found was actually a non-delivery report (NDR) that was generated to tell a user that the 6 GB message that they had sent was over the maximum message size allowed for the organization.


Once we had the server back up there were a number of questions to be answered…


Why did the Exchange Information Store accept the message in the first place if it exceeded the configured size limits?

The Exchange Information Store accepts the message since it can’t tell whether a message exceeds configured size limits until it receives the entire message.


Why can’t we just modify Exchange’s behavior to stop accepting data as soon as it knows that the message is too big?

Doing this would actually result in a bigger problem – Outlook would just try to send the data again and again, resulting in a never-ending stream of data being sent to the Exchange server.  In addition to the obvious performance problems, this would result in a large amount of transaction log files being generated in a manner similar to the problem that Jeremy Kelly describes here.


Why did the Exchange Information Store pass it off to the categorizer?

Prior to Exchange 2003 SP1 and the Exchange 2000 Post-SP3 August 2004 hotfix roll-up the Information Store only performed size checks against per-user limits and not the global limit.  This greatly exaggerated the performance impact of large messages being sent through the system since the check against the global limit was performed much later in the message submission process.


With current versions of Exchange the check is now performed by the Information Store immediately upon message submission.  What this means is that Outlook clients in online mode will receive an immediate failure upon trying to send a message that is too large.  If Outlook is in cached mode, offline mode, or configured to connect to an Exchange server and use a PST as its delivery location then an NDR will be generated by the Information Store; since the message goes no further the impact on server performance will be much less.


Won’t that large NDR for non-online mode clients cause performance issues on the client, server, and network?

Yes, it will.  So, like all good software companies, we listened to our customers and have done a significant amount of work in both Outlook and Exchange to address this problem.  Here are the changes we made….


The first change we needed to make was to provide Outlook with a way to ask the Exchange server what limits have been configured.  We added this functionality to Exchange and you can get it today by installing any of the following:


-          Exchange 2003 SP2

-          The most recent Exchange 2003 post-SP1 update available from Microsoft Update.  This update contains the specific Exchange 2003 post-SP1 hotfix for this issue

-          This post-SP3 hotfix for Exchange 2000.


The second part of the solution was for Outlook to use this newly exposed functionality in Exchange to determine whether a message is over configured size limits before sending it.  This work has also been completed, and you can get it today by installing Office 2003 SP2.


Once your Exchange servers and your Outlook clients have been updated you will start seeing the new behavior.  Specifically, if a message is sent that is over configured size limits, either per-mailbox or global, an error will be displayed as when Outlook goes to send the message to the server; no additional data will be sent across the wire and no load will be placed on the Exchange server.


As an added bonus, Outlook will also check to make sure that the mailbox is not over its quota before sending the message.  This keeps data from being sent to the server if Outlook knows that the message would be rejected with an NDR as soon as it is received by the server.  In addition, if your mailbox is over its quota then you will be presented with mailbox cleanup dialog to help you get it back under quota.


Where can I find more information?

Read KB 894795 for detailed information on the exact messages that users may see with this new functionality, a full description of the exact order of checks performed, and a description of how global vs. per-user limits are evaluated.


November 2005 Update for Outlook 2003 Junk Email Filter (KB907492)

Well, it's that time again!  Your monthly Junk Email Filter update! You can get specific information about this update in the Microsoft Knowledge Base article Description of the Update for Outlook 2003 Junk Email Filter (KB907492).

Note: Users of Indonesian, Malay, Urdu, and Vietnamese language versions of Outlook 2003 can download and install office2003-kb904631-fullfile-enu.exe. Refer to the Instructions section at source for details.

Download the update at::


Saturday, November 05, 2005

New additions to the 'Analyzer' Tool Family

The Microsoft Exchange Operational Support Tools Team has released two new Exchange tools (ExDRA and ExPTA). 

Last year, they delivered the Microsoft Exchange Server Best Practices Analyzer, or ExBPA for short.  Since then they've made several upgrades to that tool as well as published monthly updates to the validations the tool does.  They hope to establish this same kind of success for a couple of new tools they have released: the Microsoft Exchange Server Disaster Recovery Analyzer (ExDRA), and the Microsoft Exchange Server Performance Troubleshooting Analyzer (ExPTA).  These two tools build on the framework of ExBPA and allow them to define a set of iterative steps to be performed to achieve a particular goal.  In the case of ExDRA, that goal is to guide an admin through the disaster recovery process, automating as much as possible.  For ExPTA, the goal is to move from a symptom of a performance problem to a root cause and resolution. 

The two tools are built off the same framework: a configuration driven engine that knows how to execute a series of steps.  Those steps are of two kinds: present UI to the user to get information from them, or execute the ExBPA engine to get information from the system.  It then applies ExBPA analysis to the results and determines what step to take next.  This provides MS with a very flexible framework that they can use to do any number of complex tasks.  While ExDRA and ExPTA are initial offerings, more will probably be released in the future.


For more info, see


Also in this web release is the next version of ExBPA (v2.5), and an "official" release of PFDAVAdmin.


Happy troubleshooting...

Friday, November 04, 2005

E2K3 SP2 DSProxy Behavior Microsoft Documentation

As some of you may know, at Ranger Training I have been working on a project to document the behavior of the SP2 changes to DSProxy.  Microsoft has officially released a good description of these changes at .  I hope to publish my paper soon as well.  Keep watching...


Thursday, November 03, 2005