Microsoft KB Archive/310594

From BetaArchive Wiki

Article ID: 310594

Article Last Modified on 2/22/2007



APPLIES TO

  • Microsoft Exchange 2000 Server Standard Edition



This article was previously published under Q310594

SUMMARY

This step-by-step article describes how to hard code the reach version of Microsoft Outlook Web Access (OWA) for Microsoft Internet Explorer 5.0 and later.

back to the top

Hard Coding the Reach Version of OWA

There are two versions of OWA, the "rich" version, and the "reach" version. The one that you receive depends on the Web browser that you use to access OWA. With Microsoft Internet Explorer version 5.0 or later, you receive the rich client; with all other browser versions, you receive the reach version. The server determines the browser that the client is using from the User-Agent HTTP header that the browser sends to the server with every request.

The rich client version of OWA takes advantage of the Microsoft XML control on the client side and makes custom HTTP-DAV requests to the server by using verbs such as SEARCH and PROPFIND. Some older proxy servers do not support these verbs and block requests, which results in the Web browser failing to access OWA. The reach client is not affected because it only uses standard HTTP verbs such as GET and POST.

There are a few workarounds to this issue:

  • If Secure Socket Layer (SSL) is used to connect to the Exchange server, the traffic is encrypted and so the proxy server cannot determine which verbs are being used.
  • You can hard code the server to send all clients the reach client experience.For additional information, click the article number below to view the article in the Microsoft Knowledge Base:

    296232 XCCC: Empty Inbox When Using Internet Explorer 5 and Later to Gain Access to OWA

  • You can write an Internet Services API (ISAPI) filter, which is an extension to Internet Information Services (IIS) that rewrites the User-Agent header on incoming requests to that of a reach client. The difference between this and option 2 is that in this case, it can be performed on a per-HTTP virtual server basis whereas you can only perform option 2 on a per-Exchange server basis.

The filter receives the HTTP requests before Exchange does and sets the User-Agent header to that of a reach client so that even Internet Explorer 5.0 and later will receive the reach OWA.

back to the top

How to Write the Filter

Microsoft provides programming examples for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and with the tools that are used to create and to debug procedures. Microsoft support engineers can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific requirements.

To write such a filter, use the ISAPI Extension Wizard in Microsoft Visual C++ 6.0:

  1. Start Visual C++, and click New on the File menu.
  2. Click ISAPI Extension Wizard, give the project a name, such as UserAgent, and click OK.
  3. Click to select Generate a Filter object, click to clear Generate a Server Extension object, and then click Next.
  4. Click to select Post-preprocessing of the request headers, click Finish, and then click OK.
  5. In step 4, a new workspace is created in Visual C. This workspace has one main file that is named CUserAgentFilter(). Double-click this file in the workspace.
  6. Scroll down to the DWORD CUserAgentFilter::OnPreprocHeaders function.
  7. In this function, above the RETURN value, insert the following text:

    Note: The following example hard codes the User-Agent to that of Internet Explorer.

       char* sz;
       sz = "Mozilla 4.0 (compatible; MSIE 4.0; User-Agent Filter 1.0)";
       pHeaderInfo->SetHeader(pCtxt->m_pFC, "User-Agent:", sz); 
                        
  8. On the Build menu, click Build UserAgent.dll, or press F7 to build a dynamic link library (DLL). This DLL is usually placed in the C:\Program Files\Microsoft Visual Studio\MyProjects\UserAgent folder, or something similar. Copy this DLL to your Exchange server.
  9. On the IIS server, start Internet Services Manager.
  10. Right-click the virtual server on which you want to hard code the client, and then click Properties.
  11. On the ISAPI Filters tab, click Add, and then browse to the DLL that you created in step 8.
  12. Click OK, and then click Apply.
  13. Restart the IIS administrative service and W3SVC.

Microsoft provides programming examples for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and with the tools that are used to create and to debug procedures. Microsoft support engineers can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific requirements. back to the top

Additional Uses

You can also extend this template to perform other modifications, such as:

  • Allowing the user to choose the user interface languages from a separate Web page rather than having to configure it in the browser.
  • Allowing the user to choose the OWA version from a separate Web page. By doing this, users can choose the reach client when they browse to clients that access OWA through proxy servers with this problem, but the users will still have the option of having the rich user experience when they are not behind the proxy server.

back to the top

Troubleshooting

  • After you complete the steps, connect to that virtual server with a Web browser and you should always receive the reach OWA, regardless of the client browser that you are using.
  • You need to install this filter on every Exchange 2000 virtual server to which clients will be connecting directly. If you are running the servers in a front-end/back-end configuration and clients will never connect to the back-ends directly, you only need to install the filter on the front-ends.

back to the top

REFERENCES

For information about how ISAPI filters work, refer to the following MSDN Web site on ISAPI Extensions:

back to the top

Keywords: kbhowto kbmsg KB310594