RPC over HTTP, Microsoft solution

From: Allen Durie (adurie_at_americanlegacy.org)
Date: 07/22/04 

Date: Thu, 22 Jul 2004 14:18:29 -0400

Here is the official Microsoft solution to the problem, that i still cant
get to work.

HI Allen
Here is some Documents we will follow.
Exchange Server 2003 RPC over HTTP Deployment Scenarios
<http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3rpc
.mspx>
http://www.microsoft.com/office/ork/2003/three/ch8/outc07.htm

Installing Certificate Authority
To install the CA, follow the steps below:
1. Open 'My Computer' > 'Control Panel' > 'Add/Remove Programs'
2. Click on 'Add/Remove Windows Components' on the left hand side
3. Place a check in the box next to 'Certificate Services' and click 'Yes'
when the warning message appears about naming of this box, click Next

5. When prompted for the CA Type, choose 'Enterprise root CA', leave all
other boxes unchecked there, click Next
Note: Choosing CA Type may differ in actual customer environments depending
on their plans and any existing CAs they may already have.

6. Complete the 'CA Identifying Information' dialog with information
specific to your environment and click 'Next'.
7. Verify the 'Data Storage Location' is suitable for your server and click
'Next'.
It will then install all the required files, it may prompt you to stop IIS
(if its installed and running) choose Yes on that prompt to continue.

Global Catalog Server
You will need to do this on all GC Servers in your organization which are
listed under "Directory Access" tab for all the Exchange Servers hosting
users' mailboxes. To check this, perform these steps on all of your Exchange
Servers hosting mailboxes:

1. Bring up Exchange System Manager (ESM) on your Exchange Server
2. Expand and go to the actual server (Exchange Server will be listed here
by its NetBIOS Name)
3. Right Click on its name, choose Properties
4. Go to Directory Access tab
5. Note down the names of all Global Catalog Servers, these are the servers
we will work on in this section
Reg Key Configuration on GC Server (This can ONLY be done manually, no
automatic procedure to do this)
Please configure the following Reg Key manually on ALL your GC Servers, the
names of which we got working on the procedure described above (See
Directory Access tab on Exchange Server hosting mailboxes)

The following "NSPI Interface protocol sequences" parameter registry key
needs to be added to the registry on ALL Windows 2003 Global Catalog
Servers. Again, This is a manual entry not configured automatically by any
mechanism/feature.

1. On the Global Catalog Server, start Registry Editor: Click Start, click
Run, type regedit and hit OK.
2. Navigate to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
3. From the Edit menu, point to New, and then click Multi-String value.
4. In the details pane, create a multi-string value with the name "NSPI
Interface protocol sequences".
5. Right-click the "NSPI Interface protocol sequences" multi-string value,
and then click Modify.
6. In Edit String, in the Value data box, type "ncacn_http:6004"
Important: Restart the Global Catalog Server now. (Highly Recommended, it
most probably will NOT as expected work without a restart)

RPC Proxy Server
To configure RPC Proxy Server to use RPC over HTTP component:
1. On this server running Windows Server 2003, click Start, click Control
Panel, and then click Add or Remove Programs.
2. In Add or Remove Programs, click Add/Remove Windows Components in the
left pane.
3. In the Windows Components Wizard, on the Windows Components page,
highlight Networking Services, and then click Details.

4. In Networking Services, select the RPC over HTTP Proxy check box, and
then click OK.
5. On the Windows Components page, click Next to install the RPC over HTTP
Proxy Windows component.
Configure RPC Virtual Directory Under IIS
Make sure that IIS has been installed and running on RPC Proxy Server, if
its not, please do so now and then proceed with the instructions below.

To configure the RPC Virtual Directory with Basic Authentication:
1. Click Start, point to All Programs, point to Administrative Tools, and
then click Internet Information Services (IIS) Manager.

2. In Internet Information Services (IIS) Manager, in the console tree,
expand the server you want, expand Web Sites, expand Default Web Site,
right-click the RPC virtual directory, and then click Properties.

3. In RPC Properties, on the Directory Security tab, in the Authentication
and access control pane, click Edit.
4. Under Authenticated access, select the checkbox next to Basic
authentication (password is sent in clear text), and then click OK.

5. To save your settings, click Apply, and then click OK.
Your RPC Virtual Directory is now set to use Basic Authentication method.
Microsoft recommends to use Basic with SSL, thus you should also require SSL
here.

Enabling SSL on RPC Virtual Directory
The different paths to go from here would be:
A. IF there is already a certificate published at Default Web Site level
under IIS on this server, then follow the directions here
<http://xcsi/rpc-http-call.htm>

B. IF there is no certificate published at Default Web Site level, then you
will need to get and publish one, so follow the instructions over here
<http://xcsi/rpc-http-call.htm>

A Certificate is already published as Default Web Site Level
All we need to do now is enable SSL on RPC Virtual Directory under IIS, to
do that just follow the steps below:
To Enable SSL on RPC Virtual Directory:
1. Click Start, point to All Programs, point to Administrative Tools, and
then click Internet Information Services (IIS) Manager.

2. In Internet Information Services (IIS) Manager, in the console tree,
expand the server you want, expand Web Sites, expand Default Web Site,
right-click the RPC virtual directory, and then click Properties.

3. In RPC Properties, on the Directory Security tab, under Secure
communications section, click Edit.
4. In Secure Communications window, check the two boxes for Require secure
channel (SSL) and Require 128-bit encryption (highly recommended for more
security, RPC Over HTTP will work if we do not check this box) and then
click OK.

5. To save your settings, click Apply, and then click OK.
Certificate is not there at Default Web Site Level
There are two ways to go from here.
1. Get a certificate for Default Web Site from some Publicly Known Root
Certification Authority like VeriSign, discussed here
<http://xcsi/rpc-http-call.htm>, then apply it by going to RPC Proxy Server
> IIS Manager > Default Web Site > Properties > Directory Security > Secure
communications > Server Certificate > Follow the appropriate path there

2. Get a certificate from a Private Root Certification Authority of your
own, installation of such an authority is discussed here
<http://xcsi/rpc-http-call.htm>, then get and apply the certificate using
the instructions below

Obtaining and Installing A Certificate
Follow these steps:
1. Go to RPC Proxy Server
2. Bring up IIS Manager
3. Go to Default Web Site, take Properties, go to Directory Security tab
4. Under Secure communications section, click on Server Certificate button
5. Click Next on Welcome screen
6. On Server Certificate screen, choose Create a new certificate and then
click Next
7. On Delayed or Immediate Request screen, choose Send the request
immediately to an online certification authority and then click Next

8. On Name and Security Settings screen, leave all settings to default i.e.
under Name field, you should have Default Web Site, under Bit length field,
you should have 1024, leave the box for Select cryptographic service
provider (CSP) for this certificate unchecked and then click Next

9. On Organization Information screen, put in details per your desire, for
e.g. under Organization name, type Contoso Corporation, under Organizational
unit, type Head Office and then click Next

10. On Your Site's Common Name screen, under Common name field, type the
Public URL of RPC Proxy Server (i.e. a valid DNS name which should be
resolved by any internet browser out there in the world to this server) and
then click Next

Quick Test: Make sure that you can hit your customer's RPC Proxy Server
using this Public URL using IE on your own machine - This is very important!

For e.g.: If Common name here is fe.contoso.com, check it in IE using URL =
<http://fe.abc.com>, you should get the Default Web Site, after entering a
user's domain credentials if and when prompted, you may get the page hosted
as default page for Default Web Site or the usual Under Construction page,
if yes then your test is successful, otherwise work to troubleshoot this
issue using our IIS Support Team Resources.

11. On Geographical Information screen, put in details as per your desire,
for e.g. under Country/Region, type in US (United States, under
State/province, type in Texas, under City/locality, type in Dallas and then
click Next

12. On SSL Port screen, under SSL port this web site should use, leave the
default port of 443 or modify it as per your preference for your environment
and then click Next

13. On Choose a Certification Authority screen, under Certification
authorities dropdown window, choose your appropriate private certification
authority server and then click Next

14. On Certificate Request Submission screen, make sure all the info listed
there is correct, if not then go back and modify/edit it, if yes then click
Next and then Finish on the next screen to complete this procedure

15. You will come back on Directory Security tab where we started. Now you
have a certificate issued to your Default Web Site, to view that click on
View Certificate button and make sure all information there is accurate.
After that click OK.

Now we need to enable SSL on RPC Virtual Directory, to do that follow the
instructions over here <http://xcsi/rpc-http-call.htm>.

Configuring Specified Ports on GC, Exchange and RPC Proxy Servers
Remember, the following ports are the required ports for RPC over HTTP:
Server Ports (Services)
Exchange BE Servers hosting mailboxes 6001 (Store) 6004 (DS Proxy)
Global Catalog Server 6004 (DS Proxy)
1. GC Server
We have already configured the port 6004 earlier
<http://xcsi/rpc-http-call.htm> on Global Catalog Servers.
2. Exchange Server
Three ports related to Exchange 2003 Server hosting mailboxes are configured
automatically during the setup of Exchange 2003 on a server machine, we do
not need to configure them manually but its good to confirm if they are
there with correct values and they are:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Parameters
System
Parameter: Rpc/HTTP Port
Type: REG_DWORD
Value: 0x1771 (Decimal: 6001)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
Parameter: HTTP Port
Type: REG_DWORD
Value: 0x1772 (Decimal: 6002)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters
Parameter: Rpc/HTTP NSPI Port
Type: REG_DWORD
Value: 0x1774 (Decimal: 6004)
3. RPC Proxy Server
Now we will configure the RPC Proxy Server to use a specific number of ports
to communicate with the servers in the corporate network.

To configure ValidPorts Reg Key on RPC Proxy Server, follow the steps below:
Start Registry Editor: Click Start, click Run, and then type regedit.
1. In the console tree, navigate to the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy
2. In the details pane, right-click the ValidPorts subkey, and then click
Modify
3. In Edit String, in the Value data box, type the following information:
For Multiple Servers
ExchangeServerNetBIOSName:6001;ExchangeServerInternalFQDN:6001;
ExchangeServerNetBIOSName:6004;ExchangeServerInternalFQDN:6004;
GlobalCatalogServerNetBIOSNAME:6004;GlobalCatalogServerInternalFQDN:6004

NOTE: Inclusion/Exclusion of Port 6002: We are not putting in a mapping for
Port 6002 here as it is not required and recommended by Exchange Product
Group. We are seeing connection issues being reported by customers where if
they put in a mapping for Port 6002, it resolves the connection issues in
Outlook, especially for clients trying to connect from outside of corporate
network.

If you want to test with Port 6002 mapping in there, then the entry would
be:
ExchangeServerNetBIOSName:6001;ExchangeServerInternalFQDN:6001;
ExchangeServerNetBIOSName:6002;ExchangeServerInternalFQDN:6002;
ExchangeServerNetBIOSName:6004;ExchangeServerInternalFQDN:6004;
GlobalCatalogServerNetBIOSNAME:6004;GlobalCatalogServerInternalFQDN:6004
For All on One Box Solution
ServerNetBIOSName:6001;ServerInternalFQDN:6001;
ServerNetBIOSName:6004;ServerInternalFQDN:6004
NOTE: Inclusion/Exclusion of Port 6002: We are not putting in a mapping for
Port 6002 here as it is not required and recommended by Exchange Product
Group. We are seeing connection issues being reported by customers where if
they put in a mapping for Port 6002, it resolves the connection issues in
Outlook, especially for clients trying to connect from outside of corporate
network.

If you want to test with Port 6002 mapping in there, then the entry would
be:
ServerNetBIOSName:6001;ServerInternalFQDN:6001;
ServerNetBIOSName:6002;ServerInternalFQDN:6002;
ServerNetBIOSName:6004;ServerInternalFQDN:6004
Where,
ExchangeServerNetBIOSName and GlobalCatalogServerNetBIOSName are the NetBIOS
names of your Exchange Servers hosting mailboxes and Global Catalog Servers
(corresponding entries for all of them need to be here).

Hint: To get this name, go to that machine, bring up command prompt, type
"ipconfig /all", hit enter, this will give you that machine's NetBIOS name
listed as "Host Name" there in its output (very first entry).

ExchangeInternalFQDN and GlobalCatalogInternalServer are the Internal Fully
Qualified Domain Names (FQDNs) of your Exchange Servers and Global Catalog
Servers. (corresponding entries for all of them need to be here).

Hint: To get this name, go to that machine, bring up command prompt, type
"ipconfig /all", this will give you your computer's "Host Name" and "Primary
DNS Suffix", combine both of them to get your machine's internal FQDN.

For e.g. Lets say Host Name is "mymachine" and Primary DNS Suffix is
"mycompany.com", then Internal FQDN will be "mymachine.mycompany.com"

Important: To communicate with the RPC Proxy server, ALL servers accessed by
the Outlook Client must have ports set. If a server, such as an Exchange
Public Folder Server, has not been configured to use the specified ports for
RPC over HTTP communication, the client will not be able to access the
server.

Important: Reboot the RPC Proxy Server now. (Highly Recommended, it most
probably will NOT as expected work without a restart)

Everything is setup now on servers side. Now let's work on the client
machine. Make sure it has all the prerequisites
<http://xcsi/rpc-http-call.htm>.

Steps To Take on a Client Machine
Follow the steps below:
1. On client machine, bring up Internet Explorer and hit the RPC Virtual
Directory on your RPC Proxy Server.
For e.g.: Browse to <https://fe.abc.com/rpc>
A. IF you get a credentials prompt, enter your domain credentials in the
format "domain\username" in the username field and password and you should
get:

The page cannot be displayed
There is a problem with the page you are looking for and it cannot be
displayed. This error can occur if you are trying to display an HTML page
that resides in a directory that is configured to allow Execute or Script
permissions only.

----------------------------------------------------------------------------
----

Please try the following:

Contact the Web site administrator if you believe this directory should
allow read access.
HTTP Error 403.2 - Forbidden: Read access is denied.
Internet Information Services (IIS)
B. IF NOT, then we need to do some troubleshooting. See this page
<http://xcsi/troubleshooting-rpc-https.htm> for troubleshooting options.

C. IF you get a Security Alert about the Server Certificate which this RPC
Proxy Server is sending to your browser, then it means you don't trust the
Root Certification Authority which has issued that certificate to this RPC
Proxy Server. This will surely happen if the certificate was issued to RPC
Proxy Server by a Private Root Certification Authority. You will need to
trust the Root Certification Authority.

Note: Do NOT install this certificate from this Security Alert screen! We
don't need this certificate rather the one explained below. Instead check
this out:

1. On the Security Alert screen, click on View Certificate button
2. Go to Certification Path tab, see if you can see the Root Certification
Authority there (it will have a red cross "X" beside its name)

3. IF yes, then double click on its name, you will get to view the
certificate which the CA Authority issued to itself, this is the certificate
we need. Use the Install Certificate button to install this certificate.

4. IF not, then follow the steps below. This can happen due to several
reasons, most probably because you are not logged on to your Windows Domain
or you don't have access to any DC/CA Authority Server as you are at an
external location (out of your Corpnet) physically or logically (i.e. not
having VPN Access to it either)

Get the certificate which was issued by Root Certification Authority to
itself at the time of installation of Windows Certificate Authority
component. To find it hit your Certificate Authority Share, like for e.g.
\\GC <file:///\\GC>, this will bring up all default shares on this server,
here you will find a folder by the name of CertEnroll. Inside this folder
look for a certificate by the name of
"Internal-FQDN-of-This-Server_NetBIOS-Name-of-Server.crt", like for e.g.
"gc.contoso.com_GC.crt", other files you will find here would be of CRL
type - Certificate Revocation List.

Customer can use various methods to have his users install this certificate
in their IE, some of them are:
i. Rename the certificate by including ".txt" at its end (as ".crt"
extension is blocked in Outlook by default as its a Level 1 file extension)
and send this certificate to users using Outlook MAPI Client. They will need
to be present inside Corpnet or have VPN Access to Corpnet for this to work.

ii. Users can also use Outlook Web Access (OWA) rather than Outlook MAPI
Client if they are present at remote locations and do not have VPN access to
Corpnet.

iii. Administrator can put this certificate on a Web or FTP Site, available
to the users thru internet. Users can go there and download and install it.

How to Install Root Certification Authority Certificate
Ask your users to follow these steps:
1. If you are accessing it thru Outlook or Outlook Web Access (OWA), save it
on your desktop and rename the certificate by taking off ".txt" from its end

2. Double click on it to open it up (it may take few seconds)
3. Under General tab, click on Install Certificate button at the very bottom
to start the Installation Wizard
4. Follow the prompts in the Installation Wizard to install this
certificate. You don't need to change any default settings in that
installation wizard.

5. At the end of it, you will get a confirmation message, click Yes to
confirm the installation of this certificate.
After installing this Root Certification Authority Certificate, please
perform the same test again, i.e. browse to RPC Virtual Directory on your
RPC Proxy Server. Make sure this time you do get the credentials prompt and
then upon entering credentials you get "HTTP Error 403.2 - Forbidden: Read
access is denied" error.

Configure Mail Profile in Outlook For RPC Over HTTPS
In order for your users to use RPC over HTTPS from their client computer,
they must create an Outlook mail profile that uses the necessary RPC over
HTTPS settings. These settings enable Secure Sockets Layer (SSL)
communication with Basic Authentication, which is necessary when using RPC
over HTTPS.

Although optional, it is highly recommended that you use the "Use Cached
Exchange Mode" option for all profiles that will connect to Exchange using
RPC over HTTP. However, it is better for initial testing at this moment that
you do not use it. Our main objective here is to test it first, you can
always turn Cached Mode on later when you will have time to synch your
mailbox contents to your local OST file which Outlook in Cached Mode.

To create an Outlook profile to use with RPC over HTTP:
1. Click Start and then click Control Panel.
2. In Control Panel, perform one of the following tasks:
- If you are using Category View, in the left pane, under See Also, click
Other Control Panel Options, and then click Mail.

- If you are using Classic View, double-click Mail.
3. In Mail Setup, under Profiles, click Show Profiles.
4. In Mail, click Add.
5. In New Profile, in the Profile Name box, type a name for this profile,
(for e.g.: Outlook RPC Over HTTP) and then click OK.

6. In the E-mail Accounts wizard, click Add a new e-mail account, and then
click Next.
7. On the Server Type page, click Microsoft Exchange Server, and then click
Next.
8. On the Exchange Server Settings page, perform the following steps:
9. In the Microsoft Exchange Server box, type the Internal FQDN of your
Exchange Server where your mailbox resides.
10. Do not check the checkbox next to Use Cached Exchange Mode (for testing
purposes only at this time).
11. In the User Name box, type the user name.
12. Click More Settings. (Outlook may try to resolve the name now using the
"Check Name" process, give it some time to come up with an error message,
click Cancel on any error message you get, if you get a "Check Name" window,
click Cancel on that too as we don't want to perform "Check Name" process
here)

13. On the Connection tab, put a dot in Connect using Internet Explorer's or
a 3rd party dialer then in the Exchange over the Internet section, select
the Connect to my Exchange mailbox using HTTP check box.

14. Click on Exchange Proxy Settings button.
15. On the Exchange Proxy Settings page, under Connection Settings, perform
the following steps:
a. Enter the Public URL of the RPC Proxy Server in the Use this URL to
connect to my proxy server for Exchange box.
b. Check the Connect using SSL only box.
c. Check the Mutually authenticate the session when connecting with SSL box
(optional)
d. Enter the Public URL of the RPC Proxy Server in the Principle name for
proxy server box. Use the format: msstd:Public URL of RPC Proxy Server.
(optional)

e. For testing purposes right now, check both boxes, i.e.
On fast networks, connect to Exchange using HTTP first, then connect using
TCP/IP (its not checked by default)
On slow networks, connect to Exchange using HTTP first, then connect using
TCP/IP (its checked by default)
To extend upon this Outlook cannot connect using HTTP unless it is properly
configured. Given that you're configured to use HTTP, Outlook has two
separate behaviors depending on network adapter speed.

IF Outlook detects a fast connection (>128 kbps, defined by your network
adapter):
We first attempt TCP and then failover to HTTP if unsuccessful.
IF Outlook detects a slow connection (<=128 kbps, defined by your network
adapter):
We first attempt HTTP and then failover to TCP if unsuccessful.
This logic allows us to always successfully connect when there's a network
connection available with access to your RPC Proxy Server.

16. On the Exchange Proxy Settings page, in the Proxy authentication
settings section, in the Use this authentication when connecting to my proxy
server for Exchange dropdown, select Basic Authentication.

17. Click OK
Your user is now configured to use RPC over HTTPS in Outlook 2003.
18. Launch Outlook with this switch, Start > Run > type here "outlook
/rpcdiag", this will launch Outlook with Connection Status window, there you
can see if Outlook is using HTTPS of TCP/IP under "Conn" tab. It should say
"HTTPS" for RPC Over HTTPS working for you here successfully!

19. Remember to put in credentials in the format "domain\username" when
Outlook prompts you for that upon its launch, otherwise it will not work.
Providing credentials in UPN format, for e.g.: "username@domain.com" is not
going to work at this moment. This is a known issue and is discussed in the
KB Article 830355 <http://support.microsoft.com/?id=830355>.

Yours truly,
Farooq Zamir
Enterprise Messaging Support - Exchange CSI
Phone: 905-568-0434 Ext 23987
Email: v-fzamir@microsoft.com
Hours: 8:00am - 4:30pm EST (Sunday to Thursday)

Herbert Hernandez
XCSI Team Manager
Phone: 905-568-0434 ext 25278
Mobile: 416-896-6203
E-mail: v-hhern@microsoft.com

Delighting our customers is our top priority. We welcome your comments and
suggestions about how we can improve the support we provide to you.

Please visit http://www.microsoft.com/protect today! IT Professionals should
visit Security Information for IT Professionals on Technet for additional
tips.

Please visit <http://www.microsoft.com/protect> today! IT Professionals
should visit Security Information for IT Professionals
<http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security
/tips/pcprotec.asp> on Technet for additional tips.