w08_outlook2003

Contents

Overview 1

Lesson 1: Cache Mode 3

Lesson 2: RPC Over HTTPs 5

Lesson 3: Troubleshooting 24

Lab A: Outlook 2003 41

Review 49

Appendix A 50

Appendix B 57

Module 8: Outlook 2003

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2005 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows 2000, Active Directory, ActiveX, BackOffice, FrontPage, Hotmail, Jscript, MSN, NetMeeting, Outlook, PowerPoint, SQL Server, Visual Studio, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States, and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Module 8: Outlook 2003 1

Overview

*****************************illegal for non-trainer use******************************

The new version of Microsoft® Office Outlook® 2003 has added a number of new features to the mail client that are only exposed when combined with Microsoft® Exchange Server 2003. The following table highlights some of these:

Outlook Improvement

Exchange 5.5 Exchange 2000

Exchange 2000 SP 3 +

Exchange 2003

Cache Mode supported supported supported supported

Best body download

unsupported unsupported unsupported supported

Sync associated messages with headers


Recursively register for notifications on hierarchy table


Reduced blob size


RPC compression


Skip bad item unsupported unsupported unsupported supported

Sync cost reporting (number of items and total size)


Introduction

2 Module 8: Outlook 2003

ICS retrieval of PR_ABSTRACT


Copy Messages Flag


Buffer Packing


This module is going to discuss some of the new features here and how to troubleshoot them.


Lesson 1: Cache Mode

When an Outlook account is configured to use Cached Exchange Mode, Outlook works from a local copy of a user's Exchange mailbox stored in an Offline Folder file (OST file) on the user's computer, along with the Offline Address Book. The cached mailbox and Offline Address Book are updated periodically from the Exchange server.

This feature can only be configured for Microsoft Exchange Server e-mail accounts. While Cached Exchange Mode is supported on Microsoft Exchange Server 5.5 and later, users will have the best supported experience using Cached Exchange Mode with Exchange Server 2003 or later.

When a user starts Outlook for the first time with Cached Exchange Mode configured, Outlook creates a local copy of the user's mailbox by creating an OST file (unless one already exists), synchronizing the OST with the user's mailbox on the Exchange server, and creating an Offline Address Book. (If a user is already configured for offline use with an OST and an Offline Address Book, Outlook can typically download just the new information from the server, not the whole mailbox and Offline Address Book.)

The primary benefits of using Cached Exchange Mode are the following:

Shielding the user from troublesome network and server connection issues.

Facilitating switching back and forth from online to offline for mobile users.

By caching the user's mailbox and the Offline Address Book locally, Outlook no longer depends on on-going network connectivity for access to user information. In addition, users' mailboxes are kept up to date, so if a user disconnects from the network — for example, by removing a laptop from a docking station — the latest information is automatically available offline.

In addition to improving the user experience by using local copies of mailboxes, Cached Exchange Mode optimizes the type and amount of data sent over a connection with the server. For example, if On Slow Connections

Introduction

Note

How Cached Exchange Mode can help improve the Outlook user experience


Download Headers Only is configured, Outlook will automatically change the type and amount of data sent over the connection.


Lesson 2: RPC Over HTTPs

This module will describe the architecture, usage and troubleshooting of the new connection method using Remote Procedure Call Protocol (RPC) wrapped in HTTP.

RPC over HTTPs enables Outlook to have the same mailbox functionality when connect over the Internet as in the office.

Introduction


Architecture of Client (1)

Traditionally, clients connect to their Exchange server using RPC over TCP or another transport. With Microsoft® Windows® XP, the client now has the ability to wrap these RPC calls in an HTTP wrapper, thus allowing the traffic to be more easily transmitted over the Internet.

Outlook 2003 can connect to a Microsoft Exchange server only by using either RPC over TCP/IP or RPC over HTTP

Protocol name RPC protocol string

TCP/IP ncacn_ip_tcp

HTTP ncacn_http

Introduction


Architecture of Client (2)

Outlook 2003 does not try to use named pipes or any other RPC binding method to establish a connection to an Exchange server.

The interaction between the client and servers can be seen in the following diagram.


Architecture of Server

Please see the Exchange 2003 Getting Started Guide for the most up to date information:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/exchange/Exchange2003/proddocs/library/DepGuide.asp

RPC-over-HTTP enables client programs to use the Internet to execute procedures provided by server programs on distant networks. RPC over HTTP tunnels its calls through an established HTTP port. Thus, its calls can cross network firewalls on both the client and server networks.

RPC over HTTP routes its calls to the RPC proxy located on the RPC server's network. The RPC Proxy establishes and maintains a connection to the RPC server. It serves as a proxy, dispatching remote procedure calls to the RPC server and sending the server's replies back across the Internet to the client application. This process is illustrated in the following diagram.


RPC Over HTTP Architecture

The diagram above shows a firewall on the client application's network. This is not required for RPC over HTTP to operate.

When Outlook 2003 issues a remote procedure call using HTTP as the transport, the RPC run-time library on the client contacts the RPC proxy.

Depending on whether the RPC client was asked to use HTTP or HTTPS (HTTP with SSL) port 80 or port 443 is used, respectively. The RPC proxy contacts the RPC server program and establishes a TCP/IP connection. The client and the RPC proxy maintain their HTTP or HTTPS connection across the Internet. The only supported connection for Outlook 2003 using RPC/HTTP is through an SSL session.

The client's HTTP or HTTPS connection to the RPC proxy can pass through a firewall (subject to appropriate access permissions) if one is present. The server can then execute the remote procedure call and use the connection through the RPC proxy to reply to the client. The RPC proxy is an Internet Server Application Programming Interface (ISAPI) extension running in the context of Internet Information Services (IIS).

If either the client or the server disconnects for any reason, the RPC proxy will detect it and end the RPC session. As long as the session continues, the RPC proxy will maintain its connections to the client and the server. It will forward remote procedure calls from the client to the server, and send replies from the server to the client.

The RPC client program can tunnel its RPC calls through the Internet by creating a string binding of the form:

[object_uuid@]ncacn_http:rpc_server[endpoint,HttpProxy=proxy_server:http_port,RPCProxy=rpc_proxy:rpc_port] Where:

object_uuid specifies an RPC object universal unique identifier (UUID). For more information, see Generating Interface UUIDs and String UUID.


ncacn_http selects the protocol sequence specification for RPC over HTTP. For more information, see Protocol Sequence Constants and String Binding.

rpc_server is the network address of the computer that is executing the RPC server process. The server address must be specified in a form visible and understandable by the RPC proxy computer, not by the client. Since the client does not connect directly to the server, it does not need to be able to resolve the name of the server, or establish a connection to it. The RPC proxy will establish the connection on the client’s behalf, and therefore, rpc_server must be a name recognizable by the RPC proxy.

endpoint specifies the TCP/IP port that the RPC server process listens to for remote procedure calls. For more information, see Finding Endpoints.

HttpProxy optionally specifies an HTTP proxy server on the RPC client's network, such as Microsoft Proxy Server. If a proxy server is selected, no port number is specified, the RPC stub uses port 80 by default if SSL is not requested, and port 443 if SSL is specified.

RPCProxy specifies the address and port number of the IIS computer that acts as a proxy to the RPC server. You only need to specify this if the RPC server process resides on a different computer than the RPC proxy. If you do not specify a port number, the RPC client stub by default uses port 80 if SSL is not specified, and uses port 443 is SSL (HTTPS) is specified.

For more information on creating string bindings, see Binding and Handles.

The RPC server program can accept tunneled RPC calls by listening on the ncacn_http protocol sequence.

Microsoft has two major implementations of RPC over HTTP: Version 1 and Version 2.

Version 1 (called RPC over HTTP v1) is supported through Microsoft® Windows® XP. Version 1 of the RPC proxy is supported through Microsoft® Windows® 2000.

Version 2 (called RPC over HTTP v2) is the current version.

The two versions have different capabilities and limited interoperability. A summary of the differences is provided here. For interoperability considerations, see System Requirements and Interoperability for RPC over HTTP.

RPC over HTTP v1 requires SSL Tunneling to be enabled on all HTTP proxies/firewalls between the RPC over HTTP client and the RPC proxy. RPC over HTTP v2 has no such requirement. However, it is recommended and only supported when using an SSL connection.

RPC over HTTP v1 cannot establish an SSL session to the RPC proxy. The RPC over HTTP v2 can send all RPC over HTTP traffic within an SSL session; by default v2 requires the data be sent within an SSL session.

RPC over HTTP v1 cannot authenticate to the RPC proxy. RPC over HTTP v2 can authenticate; by default v2 requires authentication to the RPC proxy.

RPC proxy v1 does not operate correctly when the IIS machine on which it is installed is part of a Web farm. RPC proxy v2 operates properly when the IIS machine on which it is installed is part of a Web farm.

Versions


If Microsoft® Internet Explorer is installed on the client program's computer and your client does not specify an HttpProxy in its string binding, the RPC client stub will search the registry on the client computer for an HttpProxy entry. If it finds one, it will use the proxy specified in the registry entry.

Suppose, for instance, your client program needs to connect across the Internet to an RPC server on a computer called Server7.microsoft.com. Further, suppose that the RPC proxy runs on Major7.microsoft.com. The RPC server program listens to port 2225. Your client would use the string binding:

ncacn_http:Server7.microsoft.com[2225, RPCProxy=Major7.microsoft.com]

If the RPC proxy can resolve the server name as Server7, without requiring a fully qualified domain name, you can also specify:

ncacn_http:Server7 [2225, RPCProxy=Major7.microsoft.com]

If the client network uses a firewall and an Internet proxy server called myproxy, and Internet Explorer on the client is not configured to use that proxy, you would need to modify the client's string binding to:

ncacn_http:Server7.microsoft.com[,HttpProxy=myproxy:80,RPCProxy=Major7.microsoft.com:80]

This directs the client to connect to the RPC server program on Server7.microsoft.com. To do this, the client will first use port 80 (or port 443 if SSL is used) to connect to myproxy. This will give the client program access to the Internet. Using the Internet, the client program next connects to the RPC proxy on Major7.microsoft.com. The RPC proxy will establish a connection to the RPC server program running on Server7.microsoft.com.

The vast majority of computers today are configured for Web browsing. Therefore, most clients do not need to specify the HttpProxy, because it will be pulled from Internet connectivity settings.

The following subjects will be examined as well as methods to successfully determine the fault(s) if it does not work as expected.

1. Prerequisites required for successfully deployment.

2. Installation and configuration of the RPC Proxy Server Service.

3. Configuration of the Exchange 2003 Server components.

4. Deploying RPC over HTTP with ISA Server.

5. Using RPCPing to identify source of the problem(s).

Note


Prerequisites for RPC/HTTP

Microsoft® Office Outlook® 2003

Windows XP with Service Pack 1 + Q331320

RPC over HTTP requires the QFE referenced in Q331320 installed on the client workstation. This fix will be included in Windows XP Service Pack 2 (SP2).

Ensure %windir%\system32\RPCRT4.DLL is 5.1.2600.1142 or above. This build and later builds addresses an apparent delay in the client. This problem is more noticeable when connecting via a slow network link and the "Bypass proxy server for local addresses" check box is selected in the Microsoft®

Internet Explorer options and the HTTP connection to Microsoft Exchange Server 2003 can be made through the HTTP proxy server on the network to which you are connected. Outlook 2003 has issued a local RPC call that is waiting for a remote RPC call to complete.

After installing the fix the client will need to be rebooted.

1. Exchange 2003 on Microsoft® Windows Server™ 2003 for front-end (if front-end is deployed)

2. Exchange 2003 on Windows Server 2003 for back-end

3. Exchange 2003 on Windows Server 2003 for Public Folders

4. Exchange 2003 on Windows Server 2003 for System Folders

5. Windows Server 2003 for global catalog server(s)

6. Windows Server 2003 for RPCProxy.

7. The NSPI interface protocol sequences parameter needs to be added to the registry on ALL Windows Server 2003 global catalogs. This is a manual entry not configured by RpcHttp_Setup.vbs; the contents of the correct .reg file are included in Appendix B.

Client-side

Note

Server-side


RPC Over HTTP Setup

The RPCProxy server, the server with the RPCProxy protocol installed, must be a Windows Server 2003 server. However, it does not have to have any Exchange components installed. Many will choose to have their front-end servers act as the RPCProxy server because this will eliminate hardware and administrative costs. The RPCProxy protocol will work installed on a Microsoft Internet Security and Acceleration (ISA) server as well.

Exchange 2003 server adds the following registry entries to every Windows Server 2003 server on which it is installed. These registry entries determine the ports that RPCProxy will use. The installation sets a fixed port for the protocol and this reduces security risks with regard to TCP port control.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Parameter: Rpc/HTTP Port Type: REG_DWORD Value: 0x1771 (Decimal: 6001)

And then for the System Attendant:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters Parameter: Rpc/HTTP NSPI Port Type: REG_DWORD Value: 0x1774 (Decimal: 6004)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters Parameter: HTTP Port Type: REG_DWORD Value: 0x1772 (Decimal: 6002)

Exchange Server Registry


RPC Over HTTP Setup

The registry setting for Windows Server 2003 global catalog servers is not automated by Exchange 2003 setup. This setting must be configured either manually or programmatically for RPC over HTTP to work. This is scheduled to be included in Windows Server 2003 Service Pack 1 (SP1).

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters Parameter: NSPI interface protocol sequences Type: REG_MULTI_SZ Value: ncacn_http:6004 The RPC/HTTP Proxy server(s) must have the following registry entry to communicate with the Exchange 2003 server and the Windows Server 2003 global catalog(s).

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\’rpcproxy’ Parameter: ValidPorts Type: REG_SZ

The string data in this registry value should contain all the Windows Server 2003 global catalogs and Exchange 2003 in the Exchange Organization. This key can be configured manually, but the RpcHttp_Setup.vbs utility will configure this value for every Exchange 2003 server installed on Windows Server 2003 server and every Windows Server 2003 global catalog server. The contents of the registry key should be similar to the one below.

Global Catalog Registry

RPCProxy Server Registry


Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\’rpcproxy’] "Enabled"=dword:00000001 "ValidPorts"="Back-End:593;Back-End.concsi.lab:593;Back-End:6001;Back-End.concsi.lab:6001;Back-End:6002;Back-End.concsi.lab:6002;Back-End:6004;Back-End.concsi.lab:6004;GC:593;GC.concsi.lab:593;GC:6004;GC.concsi.lab:6004"

It is highly recommended that you use the setup script to configure the ‘rpcproxy server’ and then remove any global catalog servers that should not be included in the RPCProxy topology.


The RPC Virtual Directory in IIS

The RPC virtual directory is created under the default Web site when the RPCProxy service is installed. The RPC virtual directory should be configured with Basic Authentication if the server is adjacent to the Internet and with Anonymous access if the RPCProxy server is behind a firewall; ISA for example.

Selecting the “Require secure channel (SSL)” option will force encryption of all network communication to and from this socket.


Client Setup and Requirements

Profile Configuration can be done manually or through regular deployment options.

This topic will show the manual configuration method.

1. New User Interface Changes to access component.

2. From More Settings:

The Exchange over Internet portion of the above screen will not appear if you have not installed Windows XP SP1 + Q331320. It looks for rpcrt4.dll being at least build 5.1.260.1142.

3. After selecting Connect to my Exchange mailbox using HTTP.

a. The option for Connect using HTTP first, then connect using my Local Area Network (LAN):

b. If this option is checked, the client will always try to create an HTTP tunnel instead of using the connection method designated in the client profile. This will force Outlook to never try traditional RPC connections, which is especially relevant in hosting environments.

c. The URL to connect to my proxy server will change from standard HTTP to HTTPS based on the checkbox for Connect using SSL only.

i. When the checkbox is selected, the URL will indicate https://.

ii. When it is not selected, the URL will be http://.

The URL in use above will be the URL to access the RPC Proxy server, which will be used to authenticate the HTTP tunnel.

The user can choose to enable mutual authentication only when establishing an SSL connection to the front-end RPC Proxy Server. The RPC layer allows you to perform a mutual authentication to verify the identity of the server based on the Proxy Server’s Expected Principal Name in the Certificate used to establish

Profile Configuration

Note


an SSL connection. The RPC layer does not support mutual authentication without SSL since the Server Certificate is not requested.

For more information on MSSTD format of the principal name. Please see: http://msdn.microsoft.com/library/en-us/rpc/rpc/principal_names.asp.

The Proxy Authentication settings drop-down menu allows the user to select which authentication to use when connecting to the RPC Proxy server. Please note there is not a way to recover from NTLM if it fails. If you are using a reverse proxy server similar to ISA, then Basic will be the supported connection authentication.


Setting It All Up

This is a quick-fire guide on the basic steps to install and configure RPC/HTTP.

The examples given here were set up on a three-machine setup (all running Windows Server 2003 RTM and IIS 6):

Server Server Name Running IP Address

domain controller/global catalog

rpchttp-dc Outlook 2003 RTM 10.10.1.1

Front-End rpchttp-fe Exchange 2003 RTM 10.10.1.2

Back-End rpchttp-be Exchange 2003 RTM 10.10.1.3

The steps have been broken down into five parts:

1. Install Certificate Authority on Global Catalog.

2. Install Certificate on Front-End Server.

3. Configure Forms-Based Authentication.

4. Install RPC/HTTP Proxy and configure Global Catalog + Front-End for RPC/HTTP usage.

5. Configure Outlook 2003 to use RPC/HTTP.

For detailed steps on configuring RPC/HTTP see Module 8 Appendix A.

Introduction


1. Go to Add/Remove Programs and install Certificate Services.

2. Select Enterprise root CA.

3. Enter the common name, keeping the current distinguished name (DN) suffix

[e.g. CN=CA,DC=domain,DC=com]

4. Keep the default database paths [winnt\system32].

5. Open Administrative Tools, select Certification Authority, and right-click Certification Authority.

6. Select Retarget Certification Authority, then select Local Computer.

7. Reboot the Front-End server to see the new CA in place.

1. Select the properties of Default Web Site, and the Directory Security tab.

2. Select Server Certificate under Secure Communications.

3. Create a new certificate and send immediately.

4. Enter a certificate name, then enter the Organization and organizational unit details.

5. In order to prevent users from being prompted when using SSL, the common name of the certificate MUST be the fully qualified domain name (FQDN) of the Front-End server

[e.g. fe.domain.com]

6. Enter the Country, State, and City details.

7. Select the SSL port that has been configured for the Web site (default is 443).

8. Select the Certification Authority that was set up on the Global Catalog as the authority to process certification requests.

9. You can verify that the certificate has been successfully issued by checking the Certification Authority on the Global Catalog.

**This step is not necessary to install RPC/HTTP, but is useful to have**

1. Within Exchange System Manager on the Front-End server, expand Protocols, HTTP and select properties for the Exchange Virtual Server.

2. On the settings tab, select Enable Forms-Based Authentication.

3. From IIS, on the directory security tab within the properties for the Exchange site, select the Require Secure Channel (SSL) checkbox.

4. Outlook Web Access will now only work on HTTPS and will display the login screen, rather than a pop-up message prompting for credentials.

1) Install Certificate Authority on Global Catalog

2) Install Certificate on Front-End Server

3) Configure Forms-Based Authentication


1. On the Front-End server, within Add/Remove programs, install the RPC over HTTP Proxy under Networking Services from Windows Components.

2. Check that the following registry keys have been automatically set on the Back-End server:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\

MSExchangeIS\ParametersSystem]

“Rpc/HTTP Port”=dword:0x1771 (decimal: 6001)


MSExchangeSA\Parameters]

“Rpc/HTTP NSPI Port”=dword:-x1774 (decimal: 6004)


MSExchangeSA\Parameters]

“HTTP Port”=dword:0x1772 (decimal: 6002)

3. To configure the additional ports, set the following registry keys: - FE:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy]

"Enabled"=dword:00000001

"ValidPorts"="be:593;be.domain.com:593;be:6001;be.domain.co

m:6001;be:6002;be.domain.com:6002;be:6004;be.domain.com:600

4;gc:593;gc.domain.com:593"

- GC:


NTDS\Parameters]

"NSPI interface protocol sequences"=Reg_Multi_SZ:

"ncacn_http:6004"

4. On the Front-End server, within the RPC virtual directory in IIS (this

should already exist), under the Directory Security tab, edit Authentication and Access Control, allow Basic and Integrated authentication, and clear Anonymous access.

1. Install the hotfix for KB 331320 on the Outlook 2003 client – this addresses the performance problems that have been experienced when using Outlook 2003 to connect to Exchange using RPC/HTTP.

2. Open Outlook 2003 normally, and hold down Control and right-click the Outlook logo in the taskbar. Select Connection Status.

This will show that normal TCP/IP communication is taking place between Outlook and the Exchange servers.

3. Close Outlook, then within RegEdit set the following keys:

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\

Outlook\RPC]

"EnableRpctunnelingUI"=dword:1 <-- set to 2 by default [HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\

Outlook\RPC]

"DisableRpcTcpFallback"=dword:1

4) Install RPC/HTTP Proxy and configure Global Catalog + Front-End for RPC/HTTP usage

5) Configure Outlook 2003 to use RPC/HTTP


The second key will prevent TCP being used, even if HTTP is available. So for troubleshooting purposes this can be set to ‘0’ if HTTP is unavailable, and you want to use TCP/IP instead.

4. Restart Outlook, select Tools – E-mail Accounts and modify your existing account. Select More Settings, and on the Connection tab, click Connect to my Exchange Mailbox using HTTP.

5. Click Exchange Proxy Settings and enter the FQDN of the Front-End server. Allow Exchange to connect using HTTP on fast networks.

6. The Mutual Authentication checkbox can also be selected to pass the credentials to the RPC Proxy server when connecting using HTTP. The server will need to be configured to authenticate certificates/Smartcards on the client machine. The syntax for this field is :

msstd:FQDN-of-RPC-Proxy-server

This will only work using SSL.

7. Restart Outlook, hold Control and right-click on the logo again. Select Connection Settings, and this time HTTPS will be used to connect to Exchange, rather than TCP/IP.

Note

Note


Certificates and Client Problems

Configuring and publishing Certificates to servers is out of the scope of this document. See the following article for more information: http://support.microsoft.com/?id=281106. However, the following points must be taken on board.

In order for the client machine to successfully use SSL, the client’s certificate must be validated.

This step is only needed when the RPC/HTTP client has requested an SSL/Transport Layer Security (TLS) connection to the RPCProxy. However, note that using SSL/TLS for RPC/HTTP is a recommended security practice and it is likely that most applications will ask RPC/HTTP to perform this step.

In order for this step to succeed, the server must send a valid, not expired certificate issued by a trusted certification authority. In RPC/HTTP, there are two most common ways that this step fails – the RPC/HTTP client does not recognize the certification authority that issues the certificate or it does not recognize the certificate itself. Both causes exhibit a common symptom, when you run RPCPing against the RPCProxy server you will see error 12175 (ERROR_WINHTTP_SECURE_FAILURE).

If you were to point Internet Explorer to an HTTPS resource on this server, you will get somewhat more verbose information. Note that since the SSL connection happens before any resource is retrieved, you can check the validity of the server certificate by browsing any virtual directory.

It has been known that you can have certificate issues if you used the FQDN or NetBIOS name for the certificates common name.

Introduction

FQDN vs. NetBIOS Name


Lesson 3: Troubleshooting

The following illustrates what stages Outlook and Exchange 2003 will go through to successfully establish an HTTP/RPC connection:

1. Client needs to be able to resolve DNS to the RPCProxy Server.

2. Client needs to be able to connect to RPCProxy Server via HTTPS (HTTP).

3. Client’s Internet Explorer needs to be to process the Certificate issued by the RPCProxy Server.

4. Client needs to successfully authenticate.

5. Checks to make sure that Anonymous Access is disabled on the RPC virtual directory.

6. RPCProxy needs to know destination servers (Exchange 2003, domain controllers, Global Catalogs).

7. RPCProxy needs to be able to resolve DNS for destination servers.

8. RPCProxy needs to establish a TCP connection to the destination servers.

9. Credentials from the client are authorized.

10. Send credentials to the Exchange 2003 store and log on.

Overview


RPCPing

One of the applications used to troubleshoot connecting to an Exchange server using RPC/http is rpcping.exe.

The syntax for RPC ping is:

rpcping [-t <protseq>] [-s <server_addr>] [-e <endpoint> | -f <interface UUID>[,MajorVer]] [-u <security_package_id>] [-a <authn_level>] [-i <#_iterations>] [-l <log_filename> [-p]] [-r <report_results_interval>] [-v <verbose_level>] [-N <server_princ_name>] [-I <auth_identity>] [-C <capabilities>] [-T <identity_tracking>] [-M <impersonation_type>] [-S <server_sid>] [-P <proxy_auth_identity>] [-F <RPCHTTP_flags>] [-H <RPC/HTTP_authn_schemes>] [-o <binding_options>] [-B <server_certificate_subject>] [-b] [-E] [-q]

The -P, -F, -H, -B, -b, -R, -E options require Microsoft Windows Server 2003, Windows XP Service Pack 2 or Windows XP Service Pack 1 with hotfix found in Knowledge Base article Q331320.

Overview

RPC Ping: Syntax

Software requirements


Troubleshooting Server Configuration

1. Check to make sure Anonymous Access is disabled on the RPC Virtual Directory.

2. The RPCProxy Server needs to know destination Servers:

• Exchange 2003 Back-End Servers.

• Domain Controllers.

• Global Catalog Servers.

3. RPCProxy needs to able to resolve DNS for Destination Servers.

In order to check communication from the RPCProxy Server the main utilities to use will be:

Ping and Tracert, but primarily check that DNS is working correctly.

4. RPCProxy needs to establish a TCP Connection to destination Servers.

In order to check this, using Netstat, NBTStat and Netmon will help troubleshoot if there are any problems with communication from the RPCProxy Server to the destination servers.

5. Credentials are authorized.

Check using RPCPing against the’rpcproxy’:

rpcping -t ncacn_http -s ExchServer -o RPCProxy=Proxy -P "user,domain,*" -I "rpcuser2,bajdom,*" -H 2 -u 10 -a connect -F 3 -v 3 -E -R none

6. Send Credentials to Exchange Store.

Check using RPCPing:

rpcping -t ncacn_http -s ExchServer -o RPCProxy=ProxyServer -P "user,domain,password" -I "user,domain,password" -H 2 -u 10 -a connect -F 3 -v 3 -f a4f1db00-ca47-1067-b31f-00dd010662da,0


It is useful to prevent this behavior when troubleshooting RPC/HTTP problems. Setting the following registry value on the client workstation will disable the failover from RPC/HTTP to TCP connection.

[HKCU\Software\Microsoft\Office\11.0\Outlook] “DisableRpcTcpFallback”=dword:1


Troubleshooting Client-Server Connectivity

The following list illustrates the steps involved in the successful connection of an Outlook 2003 client to an Exchange 2003 server via RPC over HTTP:

1. Client must be able to resolve the RPCProxy server in DNS.

2. Client requires SSL to connect to RPCProxy server.

3. Client’s Internet Explorer must have the certificates installed into the certificate store such that there is no prompt when browsing the http://rpcproxy_server/rpc. Outlook has no mechanism to prompt to accept the certificate and will fail to connect. RPCPing will return a 12175 error if when the certificate is not trusted.

4. Client needs to successfully authenticate.

5. Check to make sure that Anonymous Access is disabled on the RPC virtual directory.

6. RPCProxy needs to know destination servers (Exchange 2003 server, domain controllers, global catalogs).

7. RPCProxy needs to be able to resolve DNS for destination servers.

8. RPCProxy needs to establish a TCP connection to the destination servers.

9. Credentials from the client are authorized.

10. Send credentials to the Exchange 2003 server store and log on.

The following section provides recommend steps to successfully resolve problems that can occur at the given point in the client-server connection attempt.

The client must be able to contact the RPCProxy server before it can authenticate.

If the client (RPC) is asked to decide the use of an HTTP proxy, it retrieves that information from Internet Explorer Proxy settings. The HTTP Proxy settings are available from the Tools | Internet Options | Connections tab in Internet Explorer.

Client must be able to resolve RPCProxy Server in DNS


From this dialog, you can choose what HTTP proxy settings an RPC/HTTP client will use.

The “Automatically detect settings” and “Use automatic configuration script” options are not supported by RPC/HTTP client in Windows XP SP1 or Windows Server 2003. Anything that is entered there will be ignored by the RPC/HTTP client.

The options that will be used by RPC/HTTP are in the “Proxy Server” section. If the “Use a proxy server for your LAN” check box is not checked, RPC/HTTP will not use an HTTP proxy. If the “Use a proxy server for your LAN” checkbox is checked and the “Bypass proxy server for local addresses” is not checked, RPC/HTTP client will always use the HTTP proxy specified in the “Address:” field to contact the RPCProxy.

Up until now, the logic used by RPC/HTTP for establishing connections is the same as the logic used by Internet Explorer. However, if both checkboxes are checked as in the graphic above, the RPC/HTTP client will need to perform some additional steps in order to determine if an HTTP proxy needs to be used, and these are different from what Internet Explorer does.

When both checkboxes are checked, Internet Explorer will look at the name entered in “Address field” when trying to determine if the name belongs to a local server and thus whether an HTTP proxy should be used. If the name contains a dot, the address will be assumed to be fully qualified domain name address or an IP address and an HTTP proxy will be used.

Hence, if you enter http://server-name in the address bar, Internet Explorer will not use an HTTP proxy. If you enter http://server-name.de.mo, a FQDN in the address bar, Internet Explorer will assume the name does not belong to a local server and will use an HTTP proxy. Internet Explorer determines whether or not to use the HTTP proxy based on the way the URL is entered.

RPC/HTTP on the other hand never takes direct input from the user; RPC is called by a program which acts on behalf of the user. Since the user rarely enters the DNS name of the RPCProxy server, chances are it is stored by the program and retrieved automatically every time. RPC does not get the benefit of the hint expressed a URL. Hence, RPC cannot use the same logic as Internet Explorer.

RPC sends two small echo packets to the RPCProxy server to achieve a similar result. One of them is sent directly, the other through the HTTP proxy specified in the “Address:” field of the browser.

When the RPCProxy receives this echo packet, it responds with a short echo. When the RPC/HTTP client receives the response, the route to the RPCProxy server is chosen. The route is using either using a HTTP Proxy, proxy route, or direct communication with the RPCProxy, direct route. The route will be used for the lifetime of the session.

Once the above configuration has been configured, communication can be tested.

Ping <Server-IP-Address>; this will tell you immediately whether you have basic network connectivity. To take it a step further you could run TRACERT to view the network path to the RPCProxy Server.

Note

Note

Ping


Ping <Server-FQDN>; this will verify that DNS is working.

RPCPing is the utility to use to test RPC connectivity. This utility sends RPC packets to the destination server. This is exactly what the Outlook client does, although the command set is more sophisticated.

The default configuration of HTTP/PRC requires SSL. However, you need to make sure that the RPC virtual directory on the RPCProxy server is accessible. Accessibility proves two things:

1. The RPCProxy.dll is functioning correctly.

2. IIS as a whole is functional.

Browsing the URL, https://’rpcproxy-server/RPC, of the RPCProxy server the client uses will test accessibility.

The correct URL is identified in the Exchange Proxy Settings of the Outlook client on the Connection Tab. The dialog is shown below.

If you were to enter the correct URL for the RPCProxy Server, then a HTTP Error 403.2 should be displayed.

This is a positive sign as you now know that IIS on the RPCProxy Server is functioning and that the RPC Virtual Directory is being accessed. IIS is stating that you do not have read permissions against the virtual directory, but are, in fact, trying to access it. It is important that you see the HTTP Error 403.2 from the same client that you are trying to connect Outlook 2003 to Exchange 2003 via the RPCProxy server.

It is quite hard to distinguish a machine without a Web server installed from a machine that is down or non-existent. Fortunately, the presence or absence of a Web server can be easily established by checking the configuration on the server, so usually this step is not problematic.

RPCPing

Outlook is hardcoded for SSL connection to RPCProxy Server


Outlook Troubleshooting

1. An internal Outlook 2003 Troubleshooting course does exist.

a. Event Tracing Logging

iii. For more information see http://bow.

b. SCANOST and Properties of Profile.

c. Event IDs that will be thrown.

d. Connection Status window. Outlook.exe /rpcdiag.

2. This dialog box includes the following information in a table format:

a. Server name of connection.

b. Type of connection.

c. Which network interface is in use for this connection.

d. Whether connected via ncacn_http or ncacn_ip_tcp.

e. Status of the connection.

f. Total number of requests and those that failed.

g. Average Response of connection.

h. Average Proc – Time it took the server to process the current request.

i. Version – Store version connected to.

You can also see this dialog if you hold down Ctrl and right-click the Outlook icon in the tool tray and select Connection Status.

Introduction


Event Logs and Performance Logs (1)

The first line of troubleshooting Outlook issues should be looking in the Application Event Log after enabling Mail Logging in the Outlook client. A majority of connectivity and problems should be logged here, which should help indicate the problem. Outlook 2003 also provides counters for Outlook specifically to help look at performance during usage. These application event logs will only be created once the user selects to enable mail logging by enabling it via Tools / Options / Other / Advanced Options, as seen in the following screenshot.

Here are some examples of the type of error messages you might see in the Application Log: Most of these errors can be determined by using err.exe or rover.exe, etc.

Introduction

Application Event Log


Event Type: Information Event Source: Outlook Event Category: None Event ID: 19 Date: 4/30/2003 Time: 9:26:03 PM User: N/A Computer: THINBOX01 Description: Rpc to server (df-fetch.platinum.corp.microsoft.com) failed with error code (6ba). For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 9c 00 00 00 02 00 00 00 œ....... 0008: 0c 00 00 00 13 00 00 40 .......@ 0010: d0 1c 8e a1 80 0f c3 01 Ð.�¡�.Ã. 0018: 78 00 00 00 2c 00 00 00 x...,... 0020: 00 00 00 00 00 00 00 00 ........ 0028: ba 06 00 00 64 00 66 00 º...d.f. 0030: 2d 00 66 00 65 00 74 00 -.f.e.t. 0038: 63 00 68 00 2e 00 70 00 c.h...p. 0040: 6c 00 61 00 74 00 69 00 l.a.t.i. 0048: 6e 00 75 00 6d 00 2e 00 n.u.m... 0050: 63 00 6f 00 72 00 70 00 c.o.r.p. 0058: 2e 00 6d 00 69 00 63 00 ..m.i.c. 0060: 72 00 6f 00 73 00 6f 00 r.o.s.o. 0068: 66 00 74 00 2e 00 63 00 f.t...c. 0070: 6f 00 6d 00 00 00 00 00 o.m..... 0078: 00 00 00 00 00 00 00 00 ........ 0080: 00 00 00 00 00 00 00 00 ........ 0088: 00 00 00 00 00 00 00 00 ........ 0090: 00 00 00 00 00 00 00 00 ........ 0098: 00 00 00 00 .... err 6ba # for hex 0x6ba / decimal 1722 : RPC_S_SERVER_UNAVAILABLE winerror.h # The RPC server is unavailable. # 1 matches found for "6ba"


Here is an example of the user canceling a request to the server:

Event Type: Information Event Source: Outlook Event Category: None Event ID: 17 Date: 23/02/2004 Time: 12:26:46 User: N/A Computer: PAULFL001 Description: User canceled request against server (EUR-MSG-10.europe.corp.microsoft.com) after waiting (31) ms. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: a0 00 00 00 02 00 00 00 ....... 0008: 01 00 00 00 11 00 00 40 .......@ 0010: 79 5d b0 4d 08 fa c3 01 y]°M.úÃ. 0018: 7c 00 00 00 30 00 00 00 |...0... 0020: 00 00 00 00 0d 00 00 00 ........ 0028: 1f 00 00 00 d3 04 00 00 ....Ó... 0030: 45 00 55 00 52 00 2d 00 E.U.R.-. 0038: 4d 00 53 00 47 00 2d 00 M.S.G.-. 0040: 31 00 30 00 2e 00 65 00 1.0...e. 0048: 75 00 72 00 6f 00 70 00 u.r.o.p. 0050: 65 00 2e 00 63 00 6f 00 e...c.o. 0058: 72 00 70 00 2e 00 6d 00 r.p...m. 0060: 69 00 63 00 72 00 6f 00 i.c.r.o. 0068: 73 00 6f 00 66 00 74 00 s.o.f.t. 0070: 2e 00 63 00 6f 00 6d 00 ..c.o.m. 0078: 00 00 00 00 76 00 00 00 ....v... 0080: 76 00 00 00 00 00 00 00 v....... 0088: 01 00 00 00 00 00 00 00 ........ 0090: 00 00 00 00 18 0c 00 00 ........ 0098: 01 00 00 00 cc 00 00 00 ....Ì...

You can see that Outlook will utilize the application event log to indicate problems. These logs can help when trying to determine why you can no longer connect by looking at which servername you are trying to connect to. One of the easiest tools to use when trying to decipher these error messages is err.exe which can be found at http://ToolBox/details/details.aspx?ToolID=839.

An alternative is rover.exe which can be found at http://ToolBox/details/details.aspx?ToolID=409

Articles: 238119 INFO: List of Extended MAPI Numeric Result Codes

http://support.microsoft.com/?id=238119


Event Logs and Performance Logs (2)

Outlook 2003 will include its own set of Performance counters to assist in troubleshooting connections and latency.

Here are the counters which are included with Outlook 2003. These counters can be used to assist in determining whether there is a connectivity or latency issue from the client’s perspective. These counters can be seen in Performance monitor by adding counters from the Outlook object.

Count obj connection: The number of connection objects that are currently being used.

RPCs Attempted: Number of RPCs that Outlook attempted to send to the server.

RPCs Attempted – user interface (UI): Number of RPCs that Outlook attempted that blocked the UI.

RPCs Cancelled: Number of RPCs that were sent to the server, but the user cancelled.

RPCs Failed: Number of RPCs that were attempted, but failed.

RPCs Succeeded: Number of RPCs that Outlook successfully sent to the server.

RPCs UI Shown: Number of RPCs that were sent to the server, and took long enough to show progress UI.

Time Avg (10): The average amount of time (ms) it took for the last 10 RPCs to complete successfully.



Time Avg (all): The average amount of time (ms) it took for all RPCs to complete successfully.

Performance Counters included with Outlook 2003


Time Max: The maximum amount of time (ms) it took for an RPC to complete successfully.

Time Min: The minimum amount of time (ms) it took for an RPC to complete successfully.


EXTOP

This tool in conjunction with ExTop and Microsoft® Operations Manager allows administrators to have the greatest control over their clients.

ExTop – The above is a screenshot of Extop in use.


RPC Tracing

With all versions of Outlook, if you wanted to discover what Outlook is actually doing, you could get a debug version of emsmdb32.dll.

With Outlook 2003, you do not need to do this anymore. The debugging is enabled in the code, but not captured.

The Dev team has created two files to help with debugging. These are rpclog.zip and ewt.zip. Basically you send the customer rpclog.zip and follow the instructions in the readme file. Once the customer has reproduced the issue and run rpclog, they can send you the resulting two files for you to process using ewt.zip and create an HTML file. This HTML file contains the rpctrace information.

Introduction


RPCLOG

RPC log is an RPC wire analysis tool that collects identifiable information like folder names, message subjects, and server names.

It does not collect the content of messages.

1. Copy the files tracelog.exe, msmapi.guid, logrpc.vbs to C:\RPClog.

2. Rename logrpc.txt to logrpc.vbs.

3. Make sure that Outlook is running before you start.

4. Run the logrpc.vbs script. You will get a STOP LOGGING dialog. Do not click this now.

5. Perform your test that generates RPCs.

6. Click OK in the "Stop Logging" dialog.

7. You will get a "CREATED LOG FILE" dialog. Note this file name and send it for post processing.

This is an optional step. You can make your logs better if you obtain Folder Names for the Folder IDs in the log from the Exchange server.

This utility will fetch folder names from the server. Note: it would also fetch Public Folder names up to two levels deep.

1. Rename getfoldername.txt to getfoldername.vbs.

2. Run getfoldername.vbs.

3. Wait for the FidExtract utility to complete. This might take a long time.

4. You should see a <username>.fid file in C:\RPClog.

This will leave the customer with two files – an .etl and .fid

Rpclog

Note

Rpclog: Obtaining a log

Rpclog: Obtaining a Folder ID file from the Exchange server.


EWT

The customer should send you these two files. You then need to run the EWTool to generating HTML from the customer’s data

1. Click on processewt.vbs.

2. Select the file to process.

3. If you have a Folder ID (FID) file available, click yes; otherwise click no (default).

4. Select FID file if clicked yes above.

5. Finally you are asked "Open HTML File?" Click OK to this, and you see the results in HTML.

For more information about reading these files go to http://bow

EWT

Processing


Lab A: Outlook 2003


Lab A: Outlook 2003

After completing this lab, you will be able to:

Setup RPC over HTTP.

Enable Outlook logging.

This lab focuses on the concepts in this module and as a result may not comply with Microsoft security recommendations.

Objectives

Note

Estimated time to complete this lab: 45 minutes


Exercise 1 Setup RPC over HTTP Lab Setup

This is a quick-fire guide on the basic steps to install and configure RPC/HTTP.

The examples given here were set up on a 3-machine setup (with DC-1 and Exchange running Windows Server 2003 RTM and IIS 6):

VPC Name Server Server Name Running IP Address

DC-1 domain controller/global catalog

GC DC/GC/DNS 10.0.0.10/8

Exchange Back-End EX2 Exchange 2003 RTM 10.0.0.30/8

XP-Client Outlook Client Basewxpa Outlook 2003 RTM 10.0.0.40/8

The steps have been broken down into four parts:

1. Install Certificate on Back-End Server

2. Configure Forms-Based Authentication

3. Install RPC/HTTP Proxy and configure Global Catalog + Back-End for RPC/HTTP usage

4. Configure Outlook 2003 to use RPC/HTTP

Tasks Detailed steps

1. Start the following Virtual Machines.

a. Start the following Virtual Machines by opening Virtual PC Console (click Start, All Programs, Microsoft Virtual PC) and select each one and click Start.

• DC-1

Wait until DC-1 has fully started before starting the following VPCs:

• Exchange

• XP-Client

Note: The following tasks are to be completed on the Back End Server (Exchange).

2. Install Certificate on Back-End Server.

a. Log into Exchange as Administrator with password Passw0rd1

b. From the task bar click, Start | All Programs | Administrative Tools | Internet Information Services (IIS) Manager.

c. Expand EX2 (local computer) | Web Sites.


d. Right click Default Web Site, select Properties, and then click the Directory Security tab.

e. Select the Server Certificate button under Secure Communications.

f. Click the Next button when the Welcome Wizard appears.

g. Select Create a new certificate| click Next.

h. Select Send the request immediately to an online certificate authority| click Next.

i. Click Next on Name and Security Settings window.

j. Type Contoso in Organization.

k. Type Redmond in Organizational Unit.

l. Click Next.

m. Type mail.contoso.com in Your Site’s Common Name

In order to prevent users from getting prompted when using SSL, the common name of the certificate MUST be the fully qualified domain name (FQDN) of the Front-End server.

• [e.g. mail.contoso.com]

n. Click Next.

o. Type Washington in State/Province.

p. Type Redmond in City/locality.

q. Click Next.

r. Click Next on SSL Port.

s. Click Next on Choose a Certificate Authority.

t. Click Next on Certificate Request Submission.

u. Click Finish.

v. Click OK.

3. Install RPC/HTTP Proxy and configure Global Catalog + Exchange for RPC/HTTP usage.

a. Click Start | Control Pannel | Add or Remove Programs.

b. Click the Add/Remove Windows Components button.

c. Double-click Networking Services, select RPC over HTTP Proxy, and click the OK button.

d. Click the Next button to continue installing the RPC Over HTTP Proxy.

e. On the Files Needed screen, click OK and set the path to C:\I386 and click OK.

f. Click the Finish button after installation is complete.

g. Close Add or Remove Programs.

4. Configure the following registry settings on Exchange.

a. To configure the additional ports, set the following registry keys by clicking Start, Run and type regedit.

Expand HKLM | Software| Microsoft| Rpc| RpcProxy and set the following values:

Enabled=dword:00000001

ValidPorts = Ex2:593;ex2.contoso.com:593;ex2:6001-6002;ex2.contoso.com:6001-


6002;ex2:6004;ex2.contoso.com:6004;gc:593;gc.contoso.com:593;gc:6004;gc.contoso.com:6004

5. Enable SSL on the RPC Virtual Directory.

a. Sitch to Internet Information Services (IIS) Manager or click Start| Administrative Tools| Internet Information Services (IIS) Manager.

b. Expand Web Sites| Default Web Site.

c. Right-click Rpc, and then click Properties.

Note: You may need to press F5 to refresh the Default Web Site listings in order for the Rpc site to appear.

d. Click the Directory Security tab, and then click Edit under Secure communications.

e. Click to select the Require secure channel (SSL) check box and the Require 128-bit encryption check box.

Note: We recommend that you click to select the Require 128-bit encryption check box. However, RPC over HTTP functions correctly even if you do not require 128-bit encryption.

f. Click OK.

6. Setup Authentication on the RPC Virtual Directory.

a. Under the Directory Security tab, edit Authentication and access control, and check Basic and Integrated authentication, and clear the Enable Anonymous access.

b. Click Yes on the warning.

c. Click OK.

d. Click OK.

Note: The following tasks are to be completed on the Global Catalog Server (DC-1).

7. Add the following Registry Entries to the Global Catalog Server.

a. Switch to DC-1 virtual machine.

b. Log in as Administrator with the password of Passw0rd1.

c. From the task bar click, Start | Run | type regedit | click the OK button.

d. Expand HKEY_Local_Machine| System | CurrentControlSet | Services | NTDS | Parameters

e. Right Click on Parameters, point to New, and then click Multi-String Value.

Note: Make sure that you select the correct value type for the registry subkey. If the registry subkey type is set to anything other than Multi-String Value, you may experience problems.

f. Name the new registry value NSPI Interface Protocol Sequences

g. Right-click NSPI Interface Protocol Sequences, and then click Modify.

h. In the Value data box, type ncacn_http:6004, and then click OK

i. Close Registry Editor, and then restart DC-1. Click Start, Shutdown. In the drop-down box for What do you want the computer to do? make sure you select Restart. Type Exercise 1 complete in the Comment box and then click OK to restart DC-1.

Note: Wait for GC to come back online before continuing with the lab.


Note: The following tasks are to be completed on (XP-Client).

8. Configure Outlook 2003 to use RPC/HTTP

a. Log into XP-Client as Administrator with password Passw0rd1.

b. Open Outlook 2003.

c. Hold down the Ctrl key and right-click the Outlook logo in the taskbar. Select Connection Status.


d. Close Outlook.

e. From the task bar click, Start | Run | type regedit | click the OK button.

f. Expand HKCU | Software | Microsoft | Office| 11.0| Outlook.

g. Right-click on Outlook.

h. Click on New| Key.

i. Type Rpc.

j. Right-click on Rpc.

k. Click on New | Dword.

l. Type EnableRpcTunnelingUI

m. Double-click EnableRpcTunnelingUI and set the Value data to 1.

n. Right-click on Rpc.

o. Click on New | Dword.

p. Type DisableRpcTcpFallback

q. Double-click DisableRpcTcpFallback and set the Value data to 1.

r. Close the Registry Editor.

Note: The second key will prevent TCP being used, even if HTTP is a not available. So for troubleshooting purposes, this can be set to ‘0’ if HTTP is unavailable, and you want to use TCP/IP instead.

9. Configure Outlook 2003 to use RPC/HTTP.

a. Open Outlook.

b. Select Tools | E-mail Accounts.

c. Select View or Change existing e-mail accounts and click Next.

d. Click Change.

e. Select More Settings, and on the Connection tab, and click Connect to my Exchange mailbox using HTTP.

f. Click the Exchange Proxy Settings button and enter the FQDN of the RPC Proxy Server server (mail.contoso.com). Click the On fast networks, connect using HTTP first then connect using TCP/IP check box.

g. Select Basic under Proxy authentication settings.

h. Click OK.

i. Click OK.

j. Click OK on Microsoft Outlook Warning.

k. Click Next.

l. Click Finish.


m. Enter Administrator and Passw0rd1 for the Password. Click OK.

n. Close Outlook.

o. Reopen Outlook and type Passw0rd1 for the Password and click OK.

p. Hold Ctrl key and right-click on the Outlook logo again. Select Connection Status, and this time HTTPS will be used to connect to Exchange, rather than TCP/IP.

q. Close Outlook.


Exercise 2 Enable Outlook Logging

In this exercise, you will Enable Outlook Logging.

Scenario Make Sure Outlook is not running in Offline or Cached mode for this lab to function properly.

Tasks Detailed steps

Note: The following tasks are to be completed on XP-Client.

1. Enable Mail Logging in Outlook 2003.

a. On XP-Client open Outlook 2003.

b. From the menu bar click, Tools | Options | Other tab | Advanced Options button.

c. Select the Enable logging (troubleshooting) checkbox.

d. Click the OK button, click the OK button, and click OK once again.

e. Close Outlook 2003.

f. Open Outlook 2003.

2. Create an environment to log Outlook Events in the Application Log, by disabling network connectivity to the Exchange Server.

a. Switch to Exchange and click on Action, Pause on the Virtual PC 2004 menu to simulate a failed network connection.

Note: Outlook has now lost connectivity to the Exchange Server.

b. Switch back to XP-Client.

c. Maximize Outlook 2003.

d. Press F9 (to Send/Receive All) Ignore any errors that are displayed

3. View the Outlook 2003 event in Event viewer.

a. Click Start | All Programs | Administrative Tools | Event Viewer.

b. Click on the Application node.

c. View the new log entries, notice the new events relate to Outlook loosing connectivity with the Exchange Server.

d. Close Event Viewer and Outlook.

e. Switch back to Exchange and click Action, Resume on the Virtual PC 2004 menu.

<Leave all VPCs running for the next lab.>


Review

1. What hotfix do you need for Windows XP SP1 to work with RPC over HTTPs?

2. What is the current version of RPC over HTTPs?

3. What type of authentication should an RPC proxy have that is adjacent to the Internet?

4. What does this regkey do on a client workstation HKCU\Software\Microsoft\Office\11.0\Outlook\DisableRpcTcpFallback?

5. What file(s) does EWT convert to an HTML file?

50 Appendix A

Appendix A

Setting up RPC/HTTP detailed steps

1. Go to Add/Remove Programs and install Certificate Services.

2. Select Enterprise root CA.

3. Enter the common name, keeping the current distinguished name (DN) suffix. [e.g. CN=CA,DC=domain,DC=com]

4. Keep the default database paths [winnt\system32].

5. Open Administrative Tools, select Certification Authority, and right-click Certification Authority.

6. Select Retarget Certification Authority, then select Local Computer.

7. Reboot the Front-End server to see the new CA in place.

1) Install Certificate Authority on Global Catalog

Appendix A 51

1. Select the properties of Default Web Site, and the Directory Security tab.

2. Select Server Certificate under Secure Communications.

3. Create a new certificate and send immediately.

4. Enter a certificate name, then enter the Organization and organizational unit details.

5. In order to prevent users from being prompted when using SSL, the common name of the certificate MUST be the fully qualified domain name (FQDN) of the Front-End server

6. [e.g. fe.domain.com]

7. Enter the Country, State, and City details.

8. Select the SSL port that has been configured for the Web site (default is 443).

9. Select the Certification Authority that was set up on the Global Catalog as the authority to process certification requests.

10. You can verify that the certificate has been successfully issued by checking the Certification Authority on the Global Catalog.

** This step is not necessary to install RPC/HTTP, but is useful to have**

2) Install Certificate on Front-End Server

3) Configure Forms-Based Authentication

52 Appendix A

1. Within Exchange System Manager on the Front-End server, expand

Protocols, HTTP and select properties for the Exchange Virtual Server.

2. On the settings tab, select Enable Forms-Based Authentication.

3. From IIS, on the directory security tab within the properties for the Exchange site, select the Require Secure Channel (SSL) checkbox.

4. Outlook Web Access will now only work on HTTPS and will display the login screen, rather than a pop-up message prompting for credentials.

1. On the Front-End server, within Add/Remove programs, install the RPC over HTTP Proxy under Networking Services from Windows Components.

2. Check that the following registry keys have been automatically set on the Back-End server:

4) Install RPC/HTTP Proxy and configure Global Catalog + Front-End for RPC/HTTP usage

Appendix A 53

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeIS\ParametersSystem] “Rpc/HTTP Port”=dword:0x1771 (decimal: 6001) [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeSA\Parameters] “Rpc/HTTP NSPI Port”=dword:-x1774 (decimal: 6004) [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ MSExchangeSA\Parameters] “HTTP Port”=dword:0x1772 (decimal: 6002)

3. To configure the additional ports, set the following registry keys:

- FE:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy] "Enabled"=dword:00000001 "ValidPorts"="be:593;be.domain.com:593;be:6001;be.domain.com:6001;be:6002;be.domain.com:6002;be:6004;be.domain.com:6004;gc:593;gc.domain.com:593"

- GC:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ NTDS\Parameters] "NSPI interface protocol sequences"=Reg_Multi_SZ: "ncacn_http:6004"

54 Appendix A

4. On the Front-End server, within the RPC virtual directory in IIS (this

should already exist), under the Directory Security tab, edit Authentication and Access Control, allow Basic and Integrated authentication, and clear Anonymous access.

1. Install the hot fix for KB 331320 on the Outlook 2003 client – this addresses the performance problems that have been experienced when using Outlook 2003 to connect to Exchange using RPC/HTTP.

2. Open Outlook 2003 normally, and hold down Control and right-click the Outlook logo in the taskbar. Select Connection Status.


3. Close Outlook, then within RegEdit set the following keys:

5) Configure Outlook 2003 to use RPC/HTTP

Appendix A 55

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\ Outlook\RPC] "EnableRpctunnelingUI"=dword:1 <-- set to 2 by default [HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\ Outlook\RPC] "DisableRpcTcpFallback"=dword:1

Note: The second key will prevent TCP being used, even if HTTP is available.

So for troubleshooting purposes this can be set to ‘0’ if HTTP is unavailable, and you want to use TCP/IP instead.

1. Restart Outlook, select Tools – E-mail Accounts and modify your existing account. Select More Settings, and on the Connection tab, click Connect to my Exchange Mailbox using HTTP.

2. Click Exchange Proxy Settings and enter the FQDN of the Front-End server. Allow Exchange to connect using HTTP on fast networks.

56 Appendix A

3. The Mutual Authentication checkbox can also be selected to pass the credentials to the RPC Proxy server when connecting using HTTP. The server will need to be configured to authenticate certificates/Smartcards on the client machine. The syntax for this field is :

msstd:FQDN-of-RPC-Proxy-server

Note: This will only work using SSL.

4. Restart Outlook, hold Control and right-click on the logo again. Select Connection Settings, and this time HTTPS will be used to connect to Exchange, rather than TCP/IP.

Appendix B 57

Appendix B

Troubleshooting RPC/HTTP with RPC Ping

When starting to troubleshoot RPC over HTTPs using RPCPing, it would pay to review the following Knowledge Base (KB) article:

831051 How to Use the RPC Ping Utility to Troubleshoot Connectivity Issues with.

SUMMARY This article discusses how to use the RPC Ping Utility to troubleshoot connectivity issues for Microsoft Office Outlook 2003 using Exchange over the Internet by the nesting of Remote Program Calls (RPC) in HTTP packets.

MORE INFORMATION You can use the RPC Ping Utility to confirm the RPC connectivity between the computer that is running Microsoft Exchange Server and any of the supported Microsoft Exchange Client workstations on the network. Additionally, you can use the RPC Ping Utility to verify that the Microsoft Exchange Server services are responding to RPC requests from the client workstations through the network.

The RPC Ping Utility is part of the Microsoft Windows Server 2003 Resource Kit Tools. You can download the Resource Kit from the following Microsoft Web site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

Default Ports, Services and RPC Service UUIDs The following table lists the standard services and their associated port IDs, UUIDs and major version:

Service Default Port

UUID Major Version

Store 6001 a4f1db00-ca47-1067-b31f-00dd010662da

0

DsProxy 6004 | f5cc5a18-4264-101a-8c59-08002b2f8426

56

End Point Mapper

593 n/a n/a

DsReferral 1544 f5e0-613c-11d1-93df-00c04fd7bd09 1

58 Appendix B

Directory 6004 f5cc5a18-4264-101a-8c59-

08002b2f8426 56

Simulating Common Outlook 2003 RPC/HTTP Requests The following table lists the various arguments that are used by the RPC Ping utility that you can use to simulate the type and kind of RPC requests that are used by Outlook 2003 to communicate with Exchange over the Internet.

Arguments When to use

-B Mutual authentication. Must specify the server certificate subject being used.

-H 1 ?F 3 Basic authentication with SSL. This is the most common connection method

-H 1 ?F 2 Basic authentication with no SSL. You will be prompted to confirm (unless ?q is specified).The RpcProxy server must be configured to allow anonymous logons.

-H 2 ?F 3 or 2 NTLM authentication with or without SSL.

Note NLTM cannot be used through reverse proxies if they end the TCP session.

-I & -P Always specify. If you use the asterisk (*) wildcard character for the password the RPC Ping utility will prompt for a password.

-e Port Most common ports to test are:

6001 (store)

6004 (dsproxy)

-E Test only RpcProxy. Use this for determining where connection problem lies.

-R Do not use by default. Picks up the clients HTTP Proxy settings. Can be used to override HTTP Proxy settings; for example, Internet Explorer proxy settings.

?R none Forces no proxy to be used. RPC Ping utility will ignore Internet Explorer proxy settings and try direct connection to server specified in the ?o switch.

-f (or no ?e) Used to test individual UUIDs on computers behind an RPCProxy server.

Note: Will not work unless End Point Mapper is published.

Cannot be used in default configuration as ?f requires the Rcp Ping to query the End Point Mapper.

Also if ?e is not specified this will also fail. Without ?e, RPC Ping utility will only try to access the End Point Mapper (port 593). Again, this may not be published.

Appendix B 59

Testing the RPC Proxy Server When troubleshooting Exchange over the Internet connectivity problems, it is a good idea to first determine if the RPC proxy server is responding correctly. The following sample shows how to do this:

Syntax:

"rpcping -t ncacn_http -s <ExchServer> -o RpcProxy=<RPCProxyServer> -P "<user>,<domain>,*" -I "<user>,<domain>,*" -H 2 -u 10 -a connect -F 3 -v 3 -E -R none" (without the quotation marks)

You will be prompted to enter your password for your Exchange server, and then you will be prompted for your password for the RPC proxy server. If the RPC Ping test was successful, you will receive the following reply:

RPCPinging proxy server <ExchServer> with Echo Request Packet Sending ping to server Response from server received: 200 Pinging successfully completed in <Response_Time> ms

Verbose Response This table lists some of the more common verbose responses and why you may receive them from RPC Ping tests.

Verbose Response Possible Cause

Response from server received: 200

Pinging successfully completed in 4106 ms

Successful test.


Test failed. Client is not authorized to ping RPC proxy.

Http accessed denied.

Incorrect credentials on ?P switch.

User does not exit.

Error 12029 returned in the WinHttpSendRequest.

Test failed. Could not contact ProxyServer.

Port 80 (-F 2) or 443 (-F 3) blocked.

W3Svc stopped. Server down.


Test failed. The RcpProxy.dll could not be contacted.

Wrong virtual root folder (vroot) being accessed.

An RPCProxy has not been installed.

60 Appendix B

Vroot not accessible.

Error 12175 returned in the WinHttpSendRequest

Test failed. Certificate is not trusted.

Does not trust the certificate/root authority.

The server certificate subject from the RPC proxy does not match the one specified by –B.

Verifying That the Client Can Contact Back-end Ports By default, the RpcProxy server does not publish the End Point Mapper port location. Therefore, you cannot ping the End Point Mapper from outside your intranet or use the UUID of the service.

Instead you can specify the backend port that you want to test. By default, the Store is on port 6001, and DsProxy on port 6004. If these have been changed they can be verified by using the RpcDump utility. The RpcDump utility is available from the Windows Server 2003 Resource Kit package. Additionally Microsoft does not recommend publishing the global catalog Directory Service or the Exchange referral service.

Using Basic Authentication and SSL to connect to the Store’s port. Syntax :

"Rpcing ?t ncacn_http ?s <ExchangeMBXServer> -o RpcProxy=<RpcProxyServer> -P "<user>,<domain>,<password>" -I "<user>,<domain>,<password>" -H 1 ?F 3 ?a connect ?u 10 ?v 3 ?e 6001 " (without the quotation marks)

Using Basic Authentication, SSL and Mutual Authentication to connect to the Store’s port. Syntax:

"Rpcing ?t ncacn_http ?s <ExchangeMBXServer> -o RpcProxy=<RpcProxyServer> -P "<user>,<domain>,<password>" -I "<user>,<domain>,<password>" -H 1 ?F 3 ?a connect ?u 10 ?v 3 ?e 6001 ?B msstd:<server_certificate_subject >" (without the quotation marks)

Using NTLM Authentication and non-SSL to connect to DsProxy service Syntax:

"Rpcing ?t ncacn_http ?s <ExchangeMBXServer> -o RpcProxy=<RpcProxyServer> -P "<user>,<domain>,<password>" -I "<user>,<domain>,<password>" -H 2 ?F 2 ?a connect ?u 10 ?v 3 ?e 6004 " (without the quotation marks)

Appendix B 61

Verbose Response Possible Cause

Completed 1 calls in 60 ms

16 T/S or 60.000 ms/T

Test succeeded

Exception 1722 (0x000006BA)

RPC Server is unavailable

The RPC service can not be contacted. This can be for many reasons. Problems with the Rpcproxy server itself may cause this. Use the ?E option to check that the RpcProxy server is available.

Service stopped on Exchange 2003 Back-End server (for example store).

Exchange 2003 BackEnd server down.

ValidPorts regkey does not permit access to this server.

ValidPorts regkey does not allow this port.

Attempting to access End Point Mapper when not published (e.g. no ?e switch and port 593 not available).

Trying to access UUID when End Point Mapper not published (for example used ?a switch without port 593 available).

Exception 5 (0x00000005)

Access denied.

Incorrect ?P credentials.

Incorrect ?I credentials.

Disabled user account.

Mutual Auth failed. Use the ?E option for more details.

Verifying that the Client can contact Back-end server and Back-end services through UUID By default the End Point Mapper (port 593) will not be published. Therefore, these samples are of limited use. However if the End Point Mapper is published, the following commands can be used:

Testing the End Point Mapper Syntax:

"Rpcing ?t ncacn_http ?s <ExchangeMBXServer> -o RpcProxy=<RpcProxyServer> -P "<user>,<domain>,<password>" -I "<user>,<domain>,<password>" -H 1 ?F 3 ?a connect ?u 10 ?v 3 ?B msstd:<server_certificate_subject>" (without the quotation marks)

62 Appendix B

Testing the Store UUID

Syntax: "Rpcing ?t ncacn_http ?s <ExchangeMBXServer> -o RpcProxy=<RpcProxyServer> -P "<user>,<domain>,<password>" -I "<user>,<domain>,<password>" -H 1 ?F 3 ?a connect ?u 10 ?v 3 ?f a4f1db00-ca47-1067-b31f-00dd010662da,0 ?B msstd:<server_certificate_subject>" (without the quotation marks)

w08_outlook2003

Documents