Provide Feedback on this Broadcast

Note This document is based on the original spoken Support WebCast transcript. It has been edited for clarity.

Brad Wilson: I'd like to welcome everybody today to the WebCast. We're going to be talking about the new technology in Microsoft® Office Outlook® 2003 where we can connect to our Exchange servers in the corporate environment only using RPC over HTTP.

Microsoft remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) allows RPC clients to more securely and efficiently connect across the Internet to RPC server programs and execute remote procedure calls (slide 2). This WebCast is going to help us understand the requirements and settings required to connect an Office Outlook 2003 client to a Microsoft Exchange Server 2003 computer using RPC over HTTP.

Let's go ahead and take a look at the agenda for the WebCast (slide 3). We're going to talk about what it is, the requirements that are needed, the Outlook configurations, the server (or servers) configuration, a recommended deployment scenario, additional resources, known limitations, and then we'll take some Q&A.

First let's look through a couple of terms (slide 4). RPC is remote procedure call. This technology has been around for a long time and most people are aware of it when they talk about Outlook and Exchange Server.

Internet proxy server, this is your internal proxy server that allows you to control Internet access. Your RPCProxy Server is the technology built into IIS 6.0 and is used with Internet Information Services (IIS) 6.0 as an extension that allows the processing of RPC over HTTP requests.

Let's go ahead and go on to the next slide (5) and talk about what it is. In a LAN environment, Outlook communicates with the Exchange servers using RPC over TCP/IP. This method provides quick efficient access for a corporate network. However, in previous versions of Exchange Server and Outlook access to the Exchange servers by remote users required a virtual private network (VPN) connection to the corporate network. Now with the new technology of Exchange 2003, Windows Server™ 2003, and Outlook 2003 combined for remote connections Outlook can now offer an alternative to VPN connections. Outlook can connect to an Exchange server through the Internet using RPC over HTTP. This feature allows you to remotely access your Exchange server account from the Internet when you are working outside your organization's firewall without any special connections or hardware, such as smart cards and security tokens.

Let's talk about some of the requirements to make this scenario work (slide 6). As far as client side, we're going to have to have Windows® XP Service Pack 1 with the addition of the Microsoft Knowledge Base (KB) article 331320. This will also be included when Service Pack 2 releases for Windows XP.

As far as the back-end servers, we're going to need Microsoft Exchange 2003 Server running on Microsoft Windows Server 2003. All of your domain controllers and global catalog servers need to be running Windows Server 2003. This is going to be all of the servers that either the client or the Exchange 2003 servers must communicate with.

The next slide (7), we're going to take a look at what it would look like normally in the client configuration screen in your Outlook 2003. As you can see here, this is a new addition to the Outlook client and it represents the method that the client will use to take advantage of the RPC over HTTP technology.

The top section is just talking about that RPC proxy that we defined in an earlier slide. The next section of the dialog box there tells about connecting using Secure Sockets Layer (SSL) only and then using a mutually authenticated session to the RPC proxy server. The two check boxes there allow you, as the end user, to configure what speed or what type of network you'll use with this connection mechanism. So you'll have the choice to use RPC over HTTP on either a fast connection or a slow connection, and we can talk about that in the question and answer section. The bottom portion of the box talks about your proxy authentication settings and most times this will actually be set to the Basic Authentication, which is indicated here.

Go ahead and move on to the next slide (8). The client configuration continued here is talking about some of the things that will be required on the client. The most important thing is the ability to connect to the Internet and browse Web sites. For example, if you're not at your corporate environment and you can still access www.microsoft.com and your administrator has made this technology available to you, you should be well on your way to being able to connect.

Your RPCProxy Server is correct and verified with your Exchange administrator. You'll also need a certificate where the certificate chain is trusted all the way back to the certification authority. We can talk about that a little bit in the Q&A, but basically what this means is that the client's going to have to trust the SSL certificate that it's been issued. If, by chance, you are going to use NTLM authentication, then you'll want to have your LMCompatibilityLevel greater than or equal to 2.

Let's talk about the Exchange 2003 configuration (slide 9). The only configuration that's really needed on the Exchange 2003 server is an active e-mail enabled account. Now, this means that if you can access your Web client through the Web browser, you should already have that part taken care of.

One thing that we'll want to talk about though is we need to verify that the Exchange 2003 server is listening for client connections over RPC/HTTP. This can easily be done using the rpcdump.exe command that is included in the Windows 2003 Resource Kit.

The next slide (10). We'll talk about the global catalog server or servers in your configuration. Until Windows 2003 Server Service Pack 1, it will be a requirement to statically map your NSPI port, which the RPCProxy Server will use to communicate. As you can see, the information here is listed under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry key. It's going to be a multi-string value (REG_MULTI_SZ) with the name of NSPI Interface protocol sequences and the value is going to be ncacn_http:6004.

Let's move on to slide number 11, the RPCProxy Server configuration. Install RPC over HTTP proxy. This is the driving force of allowing the client to actually connect into your corporate environment using this technology. On the Exchange front-end server running Windows Server 2003, in Add or Remove Programs, click Add/Remove Windows Components in the left pane. In the Windows Components Wizard, on the Windows Components page, select Networking Services and then click Details. In Networking Services, select the RPC over HTTP Proxy check box, and then click OK. That's pretty much the installation procedure just to get the technology on the server. On the Windows Components page, click Next to install the RPC over HTTP Proxy Windows component.

Let's continue on with this in the next slide, RPCProxy Server Configuration (slide 12). Now we're going to configure the RPC virtual directory. After we've done the installation of the technology, we have to go into IIS where it resides as an extension and configure it. We'll start the Internet Information Services Manager. In Internet Information Service Manager in the console tree, expand the server that you want, and then expand the Web site. Expand down to the default Web site, right-click the RPC Virtual Directory, and then click Properties. In RPC Properties on the Directory Security tab in Authentication and access control, click Edit. Note that, by default, RPC over HTTP does not allow anonymous access. Under Authenticated access, select the Basic authentication (password is sent in clear text) check box, and then click OK. Now, please note even though that we state this in the slides, this is one of the reasons why we recommend using SSL. To save your settings click Apply and then click OK.

You must also configure the RPC virtual directory to require secure connections because this is the only supported method in which we can allow connections. After this is done your RPC virtual directory is now set to use Basic authentication.

Let's go ahead and move on to the next slide (13), RPCProxy Server Configuration. Now we're going to tackle the process of configuring the ValidPorts registry key. On the RPCProxy Server, start Registry Editor. In the console tree we'll navigate down to the following registry key, HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy. In the Details pane, you'll see a subkey called ValidPorts that you'll right-click, and then click Modify. In the Edit String, in the Value data box, type the following information. First let me explain a little bit about what you see here on this slide. When we say ExchangeServer or ExchangeServerFQDN, what we mean by that is Exchange Server would be the NetBIOS name of your machine for the Exchange server or the Exchange server FQDN would be the fully qualified domain name. So what we'll enter there is ExchangeServer:6001-6002;ExchangeServerFQDN:6001-6002;ExchangeServer:6004;ExchangeServerFQDN:6004;.

Let's pause for just a second before we move on to the actual global catalog information. There are going to be some changes and some recommendations that are going to be available on www.microsoft.com/exchange. Currently we're saying to add the global catalog server both 6004 and the FQDN for 6004 (GlobalCatalogServer:6004;GlobalCatalogServerFQDN:6004). In the near future this may not be a necessary step. Check the Web site for the most up to date information. You should see the bottom of the slide where it says, "Note: If ports other than these are wanted, then additional entries must be made." There's some great information about the RPCProxy on MSDN®. We can talk about that in the Q&A.

Let's go ahead and move on to the next slide (14), Recommended Deployment Methods. For administrators who want to deploy this in their environment it's suggested that they automate the Outlook configuration using either preconfigured profiles or the Custom Maintenance Wizard in the Office 2003 Resource Kit. Never permit a client to connect without using SSL. Deploy the RPCProxy Server behind Internet Security and Acceleration (ISA) Server. Use a trusted certification authority. Configure the ValidPorts registry key to contain only the machine to which the RPC over HTTP clients will connect and never use wild cards in the key.

Next slide (15). An additional resource that you can use to investigate this technology is the MSDN topic, "Remote Procedure Calls Using RPC over HTTP." Other resources are the Office 2003 Editions Resource Kit, the Exchange Server 2003 Deployment Guide, and the Windows Server 2003 Resource Kit Tools (including Rpcdump and Rpccfg).

Let's go ahead and talk about some of the known limitations (slide 16). One thing that I want to make everyone aware of is that there is going to be a new updated, automated script that will be available with Exchange Server 2003 Service Pack 1 that will help customers configure this automatically. Again, keep watch at www.microsoft.com/exchange for this and other up-to-date information.

If you are continuously being prompted for credentials with Office Outlook 2003 while you're trying to use this technology, one of the possibilities that you could be running into is that you're trying to use a UPN logon such as user@<domain>.com, rather than <domain>\user and then the password will not work until Windows XP Service Pack 2.

Another possibility that can cause this is if you're trying to use a system with dual authentication requirements. This can mean that if you're out on a customer site and you're trying to connect to your Exchange servers using RPC over HTTP, but they require you to log on to their proxy server, this can cause some problems and cause the dual authentication prompt.

If your password is expired you'll actually have to connect through VPN; another capability of changing passwords would be to use the IISADMPWD directory in IIS. You'll want to contact your IIS administrator for more information on that or if you are using NTLM and your LMCompatibilityLevel is less than 2.

If in some circumstances you have trouble connecting or staying connected using this technology, you'll want to first and foremost check your application log to see if there's any indication there as to what can be causing the problem. There are some network adapters that do not report their status correctly and their status here means that the adapter will actually show as being either administratively down or administratively unready. And what you'll want to do is check for updated network drivers or upgrade to the most recent Windows XP Service Pack 2 as soon as it becomes available.

If you're not able to configure Exchange over the Internet in your Outlook profile, there's a good chance that you do not have the hotfix 331320 installed on your system or that your system administrator has disabled this process for the time being.

Let's go ahead and go into the summary (slide 17). So what is RPC over HTTP and what can it provide? The best answer for this is that you'll be able to access your corporate Exchange server without the need to create a VPN tunnel into your network. If you have access to Web sites, such as www.microsoft.com and your administrator has configured this correctly, then you should be able to connect to your Outlook Inbox without any other requirements.

There are similar requirements for both the client and the server. Remember that we're going to have to have Windows XP Service Pack 1 with the hotfix 331320 or update to Windows XP Service Pack 2 as soon as it's available. On the server side, we'll want to be running Windows Server 2003 and Exchange Server 2003.

Some of the additional resources that we mentioned: MSDN is a great resource, the Office 2003 Editions Resource Kit, as well as the Windows Server 2003 Resource Kit.

Just be aware that we didn't talk about Rpccfg, but that's a great method to get the information that you have in your ValidPorts key, so if you're working with a Support Engineer and they want to request you to get your ValidPorts information, you can use the rpccfg command-line utility to get that information.

The next slide, I think from here I'm going to turn it over to Marilyn and we can move into the Q&A section.

Marilyn Loftus: Thanks for the presentation, Brad.

Before we move on to the Q&A portion of the Support WebCast, I'd like to share a couple of quick program notes with our listeners. If any of the details on the PowerPoint® slides were difficult to view in your browser today or you would simply like a copy of the slides, they're available for download from the Web site http://support.microsoft.com/webcasts/. Also, if you would like to review the content again, this is where the on-demand streaming media is.

The Q&A portion of the Support WebCast is intended to encourage further discussion of today's Support WebCast topic. In addition, one-on-one product support issues are outside the scope of the Support WebCast. If you do find that you need some more complex technical assistance, please feel free to submit an incident on the Web or call Microsoft Product Support Services directly and speak to a Support Professional.

So let's get started with the questions. The first one is, I am setting up an Exchange 2003 behind an ISA Server. I have one cert on my ISA Server and am using an SSL bridging to the RPC directory on my Exchange server. Is this allowed or do I need a cert on both my ISA server and the Exchange server?

Brad: That is actually allowed and probably the best information to find a scenario like that is in the "What's New in Exchange 2003" guide. On the www.microsoft.com/exchange site, point to Technical Resources on the left-hand side and then click Deployment.

Marilyn: Great. Thank you.

The next question we have, Can you establish the sort of connection RPC over HTTP without using SSL?

Brad: It is a possibility, however, it is strongly discouraged because it's basically using the same type of mechanism as you would with your Web client and you don't want to use your Web client using Basic without SSL.

Marilyn: Thank you. The next question is about a scenario, I am in a pure Exchange 2003 or in a Windows 2003 forest with forest functionality raised to Windows 2003 with a client computer meeting the RPC over HTTP client requirements, but coming from a trusted Windows 2000 forest. Will this work?

Brad: Yes, that should work.

Marilyn: That was quick. The next one, Does this have to be on a front-end server?

Brad: No. Actually, this technology resides in the Windows operating system rather than being an Exchange component. It's going to be a recommendation that we place this on your front-end server because you should already have the infrastructure laid out for the front end, the back end, and the Exchange server. However, the technology itself is actually a Windows operating system component and not an Exchange component.

Marilyn: Okay. The next question, What does msstd stand for?

Brad: That's actually the Microsoft standard for the principal name and if you go to msdn.com it describes what that principal name is and what it would be used for.

Marilyn: Okay. The next question, In the future will the ValidPorts setting on RPCProxy Server be modifiable via GUIs?

Brad: Not that I'm aware of, but keep your heads up for what's going to happen in Exchange Server Service Pack 1, where we will be able to use a script to place the information that's needed in that ValidPorts key. I know that one of the most challenging portions of setting up this infrastructure, is changing the ValidPorts key and making sure that everything is spelled correctly, and that the semicolons and the colons are set up correctly. So we've definitely felt the pain there and we're trying to address that with Exchange Server Service Pack 1. Great question.

Marilyn: Okay. Next question, Do you have to go through ValidPorts configuration limiting the ports that can be used in an intranet-only scenario?

Brad: That's completely up to you. Doing that would be a best practice to adopt, just in case there is a possibility that you might want to move that infrastructure to the open where other users could use that. So that's just a recommended deployment scenario, and you can read more deployment suggestions up on MSDN, but, no, if you're just going to use this internally and you can assure for yourself that no one has access to this environment from external then no. But when you install the RPCProxy, the default ValidPorts will not allow you to connect to Exchange server, so there is going to have to be some manual manipulation of that registry key anyway.

Marilyn: Okay. The next question, When running Outlook in cache mode, the client uses the offline address list as a Global Address List. How often does the client automatically download a new version of the local offline address list? At least in our environment, the updates to GAL seem to take a lot of time before they are seen in the cache-mode client.

Brad: Marilyn, that's actually outside of the scope of this WebCast because if you look at it this way, the RPC over HTTP is just another transport for the Outlook client to use.

Marilyn: Okay. On to the next question, I've always been told that Outlook 2003 will, in its default state, always try RPC over TCP/IP before it tries RPC over HTTP. Since my port 135 is blocked due to the Blaster virus, what is the best way to force Outlook 2003 client into RPC over HTTP mode?

Brad: The easiest scenario to do that is on the settings for the Exchange 2003 over the Internet. Let me go back to slide 7 and I can show you the client configuration page.

This slide actually shows the setting that will allow you to use RPC over HTTP first, whether you are on a fast network or a slow network, so whatever your speed is, whether you're on a dial-up connection or if you're on a fast Internet, then what you would want to do is manipulate these two check boxes to use RPC over HTTP first rather than RPC over TCP/IP.

Marilyn: Okay. The next question, How do you configure RPC over HTTP on a remote new client? Trying the straightforward way causes timeouts.

Brad: Well, there are several different ways that you could manipulate your end user's client. If you're doing it manually then what you'll want to do is just enter the Exchange server information as you normally would, and before doing a check name, go into the More Settings information and then enter the information as you can see here (slide 7) in the Exchange Proxy Settings.

Marilyn: The next question, Are there any other authentication methods supported for RPC/HTTP other than Basic?

Brad: The only two that are available in the client are Basic and NTLM.

Marilyn: All right. The next question, How do the clients log on to Exchange, by just launching Outlook with their normal profile?

Brad: After you've configured your profile to use this technology then yes. All you would have to do is just launch Outlook and it will prompt you for credentials to go through the RPCProxy.

Marilyn: Great. The next question, Will there be an Exchange 2003 Resource Kit?

Brad: That's something I don't know, Marilyn. I'm not aware of yes or no.

Marilyn: Okay. The next question, Do you need to use ISA if you're using a standard firewall like Cisco PIX?

Brad: You do not have to use any particular type of firewall; it's just however you're going to secure your environment. Just be aware that the user will be coming in over port 443.

Marilyn: Okay. I believe these are two questions that go together, hopefully. If it isn't, I would like the listener who asked too let me know. Why am I getting Task MS Exchange Settings Reported Error and then its error number, Unknown Error, when trying to download OAB?

Brad: Again, Marilyn, that's probably something that they would want to contact a PSS Support Professional to take a look at that with them. Just make sure that you're running on the released build of Outlook 2003.

Marilyn: Okay. Why was the Rpc_http.vbs script not released with Exchange 2003 RTM? There was a lot of prerelease chatter about it and now some larger customers are wondering why they need to manually enter the port entries in the registry of a lot of systems. I know Windows Server 2003 SP1 will resolve this, but what can I do for now?

Brad: Unfortunately, you are correct that that script has been under investigation recently and is being updated for Exchange Server Service Pack 1. Unfortunately, what you'll want to do now is look into using the Rpccfg application in the Windows 2003 Resource Kit. That will actually allow you to create your ValidPorts keys once on one machine and then use that to deploy to multiple different machines.

Other than that, that's the only thing that I can really say. It was planned at one point to be released during the release of Exchange Server 2003, but after some investigation they were going to go back and edit it and do a little bit more testing on that.

Marilyn: Okay. The next question is, Do you have to have a front-end/back-end server configuration to use RPC over HTTP or can a single server be used?

Brad: A single server can be used.

Marilyn: The next question, Is there a way to set up an Exchange profile in Outlook via RPC over HTTP?

Brad: There is a way. If you have the hotfix installed, the 331320, then you'll need to go under E-Mail Accounts, if you're already in Outlook, change the properties on your Exchange server, and then go to the Connections tab. You should see the Exchange over the Internet selection at the very bottom of the dialog box. If you do not have that, it is a good indication that you do not have the hotfix installed, or your system administrator or your Exchange administrator is not allowing you, as the end user, to configure those properties. You'll want to contact your Exchange administrator to find out either why or why not.

Marilyn: Okay. In setting up an Outlook client it says to use the format msstd:fqdn of RPCProxy Server. What is the msstd part?

Brad: That is another guarantee that your client is actually connecting to the RPCProxy server that you've indicated and that's just an added security measure that you can use to verify that the Outlook client is connecting to the RPCProxy server that it stated.

Marilyn: Thank you. Is there anything special which needs to be done to get Outlook Exchange 2003 to work over SSL-VPN, SSL Decrypt with HTTP to back-end server?

Brad: I'm not certain that I understand the question, Marilyn. However, what I would suggest is using that "What's New in Exchange 2003" white paper up on Microsoft.com/exchange because it actually does address scenarios such as that.

Marilyn: Okay. Again, I have a couple of questions I believe go together. Is the backslash or default domain not supported anymore in Basic authentication?

Brad: That's actually a question that would be better directed to someone who is using IIS. As far as I know, yes, but if you want to, we can take that off line and I can follow up with that customer.

Marilyn: Okay. Thank you. Will there be an ISA filter for RPC over HTTP?

Brad: I don't know if one is in works or not to be honest with you.

Marilyn: The next one, Can this support two factor authentication, such as secure ID?

Brad: Not at this time, no.

Marilyn: The next question, Why is the Windows 2003 client not supported and when will support for this be available?

Brad: Actually, I should have mentioned that in the slide deck. You can also do this configuration in Windows Server 2003; however, please note that it won't be supported if you're running Exchange Server and the client on the same machine. My mistake; I should have mentioned that this will run on Windows Server 2003.

Marilyn: Okay. The next question, Do you have to have both front end and back end using SSL for RPC to work?

Brad: No you do not.

Marilyn: The next one, How can I set up my home computer for first use of RPC over HTTP to my office? I ask the question because the check box to enable the feature seems to be reachable only after I have already established a connection to my Exchange Server, possibly via VPN.

Brad: That's not actually accurate. Even though it seems to time out, you can still get into the information by going into your profile and changing the options on the Exchange server and then going into the More Settings if you're creating the profile or going into the Connections tab once you're in an existing profile. So you do not have to actually make a connection the first time through VPN or on the corporate network to set up this profile.

Marilyn: Okay. The next question, We want to use secure ID HTTP authentication on the ISA Server as first authentication before allowing access to the Exchange server.

Brad: Okay. That's actually not going to work with the current release of Outlook 2003 on Windows XP. As we stated before, Marilyn, the double authentication will not actually work at this time.

Marilyn: Okay. The next question, I have all of the settings in place and it still doesn't work. The only think I don't have is a front server beyond. My question was with control on the Exchange Outlook and watching the connection. What else can I do to troubleshoot this?

Brad: Probably the best thing to do is either open a Web incident or call in to Microsoft Support. One thing that the customer is indicating there is that there's a great troubleshooting utility now built into Outlook 2003. If you're running Outlook, you can hold the CTRL key down and right-click the Notification icon of Outlook. That will bring up the Connection Status dialog box and that will actually show you the server that you're connecting to and what mechanism you're connecting to. For this customer, I would advise either opening an incident through the Web or calling in.

Marilyn: Okay. The next question, Does this technology add to the system requirements for an Exchange server?

Brad: Well, other than running Exchange Server 2003 that's really it. So there are no additional requirements other than the actual software requirements.

Marilyn: All right. The next one, If we don't want to deploy a front-end server can we install on a back-end server, an ISA Server?

Brad: Yes. Again, remember that the RPCProxy Server is a component of the Windows operating system, so it's not necessarily an Exchange component. We just recommend using the front-end/back-end because we think that you would already have the infrastructure set up for the front-end/back-end Exchange deployment.

Marilyn: The next couple of questions you may not know, but I'll ask them and we'll see if you do.

Brad: Okay.

Marilyn: Do you know when the XP Service Pack 2 and the Exchange Server Service Pack 1 are expected?

Brad: No I don't and the only thing that I can recommend is to keep an eye out on Microsoft.com for both of those.

Marilyn: The next one, Can you connect directly to the Exchange server or do you need an ISA in between?

Brad: You do not need to have an ISA Server in between; however, we do recommend that.

Marilyn: The next question is, Can you explain more about the problem where you have to keep putting in your credentials of the Exchange server itself?

Brad: Oh, okay. Sometimes the users will actually be continuously prompted for credentials and there are a couple of different things that can cause that. Some of the well known ones are if you're trying to use a UPN log on, which is similar to using a <username>@<domainname> rather than the <domainname>\<username>. That's going to be addressed in Windows XP Service Pack 2.

The other thing is that if you are actually trying to use NTLM authentication for this technology and you do not have the LMCompatibilityLevel set greater than 2 in the registry, that that can cause that as well.

I hope that answered it, Marilyn.

Marilyn: Great. Thank you. The next question, How do you limit access to Exchange 2003 by Outlook XP SP1 only?

Brad: That's kind of outside of the scope of this WebCast, if they're talking about Outlook 2002. However, I do know that there is a Knowledge Base article that talks about that specific scenario.

Marilyn: Okay. The next question, Can I use a hardware load balancing unit, such as F5, with SSL acceleration with the SSL taking place on the load balancing device?

Brad: That's something that I'll have to follow up with, Marilyn.

Marilyn: All right. The next question, What type of speed improvement does RPC over VPN and are there any benchmarks on premium versus basic?

Brad: The premium versus basic is actually a topic concerned with the Web client. As far as any type of metrics, I don't know that we've made any. However, the greatest advantage that I can consider is that you don't actually have to create that VPN tunnel. If you have access to the Internet, then you'll have access to your Exchange server environment.

Marilyn: Okay. The next question, I have configured all of the things just as shown in the slides and in the MS development guide. Everything looks fine, but on the client side when I set up the profile e-mail access, I keep getting a prompt for user name and password with no luck to get it passed. I can use the OWA over HTTPS with form-based logon at this same home client. Is this the same question as the one you answered earlier?

Brad: Possibly. The biggest thing that comes to my mind there though, Marilyn, is to make sure on this client configuration slide (7) that the Proxy authentication setting is set to Basic Authentication. If it goes beyond that I would definitely suggest opening up an incident.

Marilyn: The next question, Is support for security pre-authentication for other cookie based pre-authentication planned in the future?

Brad: I really can't address that. I don't know.

Marilyn: The next one, Can you use integrated authentication or only basic with SSL?

Brad: You can use integrated; however, you're not going to be able to use integrated if you go past anything that's going to change the pragma header in the HTTP packet.

Marilyn: Okay. The next question, Our users are all mobile users. Our Exchange box is in a data center. RPC over HTTP has worked well, but password change functionality does not work. Is there a way to force a user to change their password with RPC over HTTP enabled without being connected locally or over a VPN connection?

Brad: No. Currently there is not. One of the things that I would suggest maybe looking into though is using IIS's virtual directory to change passwords. If you query the Knowledge Base on IISADMPWD that should get you started.

Marilyn: Okay. The next question, On the global catalog configuration slide (10) is that registry key one to add or one to configure?

Brad: Previous to Windows Server 2003 Service Pack 1 that is something that you're actually going to have to add. With the release of Windows Server 2003 Service Pack 1 that will actually be added for you.

Marilyn: Okay. The next question, What is the recommended minimum bandwidth for RPC over HTTP?

Brad: I don't really think we have anything like that published to be honest with you, Marilyn. The best thing to realize though is that the greater the bandwidth you have, the greater experience you're going to have, just like in any other type of connection to an RPC resource.

Marilyn: Okay. The next question is, The deployment paper indicates that the RPCProxy Server should be in an Exchange front end. Does Exchange 2003 have to be installed on RPCProxy Server to forward direct requests to Exchange 2003 and/or Windows 2003 DCs and GCs?

Brad: No. Again, the RPCProxy is a component of Windows Server 2003. The only requirement is that you're running IIS 6.0 on Windows Server 2003.

Marilyn: The next question, How do I send a pre-packaged MSI or Outlook with t-code embedded to my user, who will do RPC over HTTP in a hosted Exchange environment?

Brad: That's probably something that's outside the scope of this WebCast, but something that the user can do is either open up an incident or check in the communities.

Marilyn: The next question, We have a client configuration described that our firewall shows that the client tries to access the server on several ports just above 3,000 and of course, they are blocked.

Brad: The only client port that should be coming in using this technology is 443 over SSL. If you're seeing something other than that, you definitely want to work with a PSS engineer to try to figure out what was actually making that call.

Marilyn: Okay. The next one, I came in late. Can you repeat the white paper or KB article that documents the fix?

Brad: What particular fix is that? I see the client configuration is this KB article here, 331320. That is needed on any of the end user, Windows XP Service Pack 1 machines to allow this type of connection mechanism.

Marilyn: Okay. The next question, Does this functionality only exist for Windows XP SP1 and Windows 2003 Server or do previous OS versions have the same ability?

Brad: No. It is only on Windows XP Service Pack 1 and later and Windows Server 2003.

Marilyn: Okay. Earlier apparently I asked a question wrong. The question was, The Windows 2000 client, not the Windows 2003 client. When will RPC over HTTP support be available for Windows 2000 clients?

Brad: My mistake, Marilyn. We don't have plans to allow that at this time. I'm sorry. I apologize. I thought you said 2003.

Marilyn: I probably did. Okay. The next question is, Are there plans of supporting Windows 2002? And I believe you just answered that.

Brad: No there's not. We're going to be using only the 2003 platforms and Windows XP Service Pack 1 or greater.

Marilyn: The next question is, I heard that RPC 135 would need to be open in a firewall to configure a remote Outlook client. Is that true?

Brad: That is not true for this technology. This technology the only inbound port that you should need (or is necessary) is port 443.

Marilyn: Okay. The next question, Why does the patch 331320 state that it is for Exchange Server 2003 beta?

Brad: That's probably just something in the article. We can definitely get that fixed.

Marilyn: The next question, Do you have any information regarding overhead caused by using HTTP/RPC compared to just plain RPC traffic?

Brad: No. Unfortunately, I don't think any metrics like that have been created, but if there are, you'll want to check up on http://www.microsoft.com//exchange/.

Marilyn: Okay. The next question, Will RPC over HTTP work when the Exchange server is installed on a Windows 2000 server and the RPC proxy installed on Windows 2003 Server or does the Exchange server have to be installed on Windows 2003 Server as well for this to work?

Brad: Let me get back to that user, Marilyn. I just want to verify.

Marilyn: Okay. The next question, Is secure ID supported for accessing OWA and what about OMA?

Brad: This WebCast is actually just talking about Outlook using RPC over HTTP, none of the other mobility features. That would be something that the user could submit in the communities and try to get assistance there.

Marilyn: The next question, Does the basic authentication improve the response time for RPC HTTP clients on the NTLM authentication?

Brad: Just speculating, I would expect that the basic would take less time to authenticate than the NTLM, but again, that's just speculation. In most scenarios you will have to use basic authentication anyway.

Marilyn: The next question, Can I use a homemade SSL certificate or does it have to be a registered one?

Brad: You can actually use a built in or inter-organization certificate as long as the client can trust that certification path from the certificate all of the way back up to the CA. What that means, it might just mean a little bit harder deployment scenario for the administrator; however, that will work.

Marilyn: The next question, Does the RPC proxy component part of Windows 2003 Server allow for load balancing?

Brad: Yes it does.

Marilyn: Is 443 required or can you use port 80 instead?

Brad: We highly recommend that you use the SSL; that port is 443. If you do try to attempt it, which is not recommended, to use it over anonymous access then you would use port 80. However, again, it's strongly recommended that you use SSL. If you go to the deployment information on MSDN, you can see some more information about why we recommend using the secure layer.

Marilyn: The next question, Do you recommend RPC over HTTP on the LAN?

Brad: That's something that you'll want to take into consideration. What I normally do on a day-to-day basis is I use my profile configured through RPC over HTTP, but I use the speed options, which are indicated here on the client configuration page (slide 7), to say whether I'll actually be making that connection using that provider rather than TCP. So if you set up your profile using RPC over HTTP, and you change your speed information in here, then it can almost be a seamless integration between when you're working at your desk and when you're lounging around at your house using wireless to connect to your Exchange server.

Marilyn: Okay. The next question, Where is the speed break between fast and slow networks in the client speed?

Brad: A slow connection is anything less than 128 kilobits per second (Kbps), so when your adapter reports to the operating system that it has a speed of 11 megabits per second (Mbps), you would be, of course, greater than that 128 Kbps.

Marilyn: The requirements say domain controllers and global catalog servers are running Windows Server 2003 that either the client or Exchange Server 2003 must communicate with. How can I control which DC/GC an Exchange Server communicates with and how do I control what DC/GC a client communicated with in a mixed Windows 2000 and Windows 2003 DC/GC environment?

Brad: There are some settings that you can configure on the properties of your Exchange server. The Exchange server will have a DSAccess tab and that will actually allow you to configure which global catalog servers and domain controllers the Exchange server uses.

As far as the client side is concerned, there are some registry keys, like DS Server key, that you can configure on the client, to point specifically to a particular global catalog server. However, if you continuously watch the Microsoft.com/exchange/ site underneath the Deployment section there is going to be some more information there stating that we may not necessarily have to use those global catalog keys in the ValidPorts.

{Editor’s note: To find the Exchange deployment information, go to Microsoft.com/exchange, point to Technical Resources, and then click Deployment.}

Marilyn: Our next question is, Which clients are compatible with RPC over HTTP?

Brad: Outlook 2003.

Marilyn: The next one, Is it better to put the RPC proxy in our DMZ or in our internal network?

Brad: That's completely up to however you've already got your infrastructure deployed. We actually recommend just putting the RPC proxy server behind an ISA server.

Marilyn: Okay. Just to confirm, is it possible to change your password through Outlook running RPC over HTTP only through IIS?

Brad: Well, basically what it means is that when you're using the RPC over HTTP transport, we don't provide a mechanism for you to change passwords. That means you would have to go outside the boundaries of the Outlook 2003 client to perform that task. One such example is the IISADMPWD virtual directory that can be used with IIS.

Marilyn: The next question, Can you show the registry entry required for the GC again? When will the slide set be available to download?

{Editor’s note: The slides are available on the Past Support WebCast site at http://support.microsoft.com/default.aspx?scid=kb;en-us;829134.}

Brad: Okay. There's the slide for the GC (slide 10).

Marilyn: Okay. The next one, I understand that you recommend using port 443, but we need this functionality on port 80, but we can't get it to work. The NTLM authentication keeps failing. Is special configuration required for NTLM authentication to work?

Brad: The NTLM authentication is a little bit different from allowing access in on port 80. Just remember though that, when Microsoft went through the testing and evaluation of this product and this technology, we didn't take under consideration a non-secure mechanism like port 80. So even if you did find a problem or were working a problem, when you call in or open up an incident your Support Engineer probably most likely are going to ask you to see if you can duplicate the problem using a secure channel.

The best thing that I can tell you is take a look at the "What's New in Exchange 2003" white paper, as well as the MSDN section on using RPC over HTTP.

Marilyn: Okay. The next question, the customer is getting a prompt for user name and password that are not getting passed. I can, on the same client at the same time, open Explorer and log on with HTTP over OWA in form-based log on. I used <domain>\<username> as username and of course, my password is set up for the client, but there was no luck. I used BTW basic authentication. I have tried to set up two different clients with the same result. They both get prompts for user name and password with no luck to get it passed.

Brad: Probably the best thing there, Marilyn, is to have that customer go ahead and open up an incident and we can work with them to see exactly where that's failing.

Marilyn: Okay. The next question, Brad mentioned a troubleshooting tool in Outlook 2003 that shows how you are connected to an Exchange server. Can you repeat how to do that?

Brad: Sure. There are actually two ways to get to that information and I use this on a day-to-day basis when helping customers troubleshoot this type of connectivity. The first method is before you actually start your Outlook 2003 you can click Start, click Run, type outlook.exe /rpcdiag, and then press ENTER (or click OK). What that's going to do is that's going to start your Outlook client and immediately display the Connection Status window.

Now, if you're already running your Outlook 2003 client, you can hold down the CTRL key and right-click the Outlook icon in the notification area (or the system tray), and then select Connection Status there as well. So there are two different ways to get to that.

Marilyn: Okay. The next question, Can the HTTP name be different from the FQDN of the server, that is, can I use myserver.mycompany.com for my mail server and owa.mycompany.com for the external address or do they have to be the same?

Brad: No, they do not have to be the same, because the RPC proxy can actually even reside on a completely different server than the Exchange server.

Marilyn: Okay. The next question, Is there support for RPC over HTTP introduced into Windows 2000 older clients other than Outlook 2003?

Brad: No. We don't have plans to do that.

Marilyn: The next question, What does NSPI stand for?

Brad: Name Service Provider Interface; that's just basically when you see your client going to access information like the Global Address List or anywhere that you have to go and get information about particular users.

Marilyn: Okay. The next question, Are there any plans to enable password changes with RPC over HTTP? The ability to force a password change through IISADMPWD is broken and I've got an issue open with Microsoft Tech Support.

Brad: Not that I'm aware of. However, if you run into a problem like that, probably one of the best things that you can do is to call your administrator and let them know that your password is expired. They can help you either reset it or go through any other process that you normally do when your password is reset on the network.

Marilyn: Okay. It appears we've answered all of the questions that were submitted today, so that is going to wrap up our session. I want to thank you all for joining us and I hope this information was useful to you and I wanted to thank Brad for coming in today to give us some great information. We hope you have the opportunity to tune in again in the near future. Thanks and have a great day.