In Exchange 2003 SP1 there’s a new, and arguably better way to configure RPC/HTTPS (lots of folks call it RPC/HTTP or RPC-over-HTTP, but let’s be honest… it’s actually over HTTPS, right?).
Back in Exchange 2003 RTM, there was no easy way to configure RPC/HTTPS. There’s a whitepaper and at least a handful of KB articles, but there’s no arguing — the process is complicated.
Two big changes in the way RPC/HTTPS works and is configured in Exchange 2003 SP1:
1) GCs no longer have to be exposed through the RPCPROXY interface. No need to add them to the ValidPorts registry key. This alone may make SP1 worth the upgrade for heavy users of RPC/HTTPS!
This change comes about because the back-end servers no longer give NSPI referrals to GCs if the Outlook connection has come in across the ncacn_http “endpoint”. This is how RPC/HTTPS communicates, so it affects RPC/HTTPS referrals. Instead, for RPC/HTTPS connections the NSPI referral is pointed right back to the Exchange 2003 Sp1 server. This causes DSPROXY to accept the NSPI connections, and do a proxy connection to the GC behind the scenes.
2) If you’ve got the recommended configuration (FE/BE with the RPCPROXY service running on your Exchange FE server), you can configure “managed topology” settings that will automatically keep the ValidPorts registry value up to date on your FE server. If you’re using RPC/HTTPS today and thought Item #1 was cool, this change is probably beyond great!
The way this works is that we stick an extra Heuristics setting on the server object for either Front-end or Back-end servers that you want to have “managed“ by this new process. The Back-end servers just get the heuristics bit set (and ServerRole=0 makes it a BE server). The Front-end servers get the same heuristics bit set, but ServerRole=1 so it’s a front-end managed server.
Every 15 minutes, the managed FE server will go out and check for new (managed) BE servers in the AD and will update its own ValidPorts key with the new info if any exist. This means no more need to run the RPCHTTP.vbs script; it’s all automagic now.
But here’s the rub. What if you have a great, working RPC/HTTPS topology today and you enable the FE servers for “managed“ before you enable the BE servers? Well, within 15 minutes or so, the FE server will be scanning the AD, looking for managed BE servers to add. It won’t find any. By default, none of the servers are configured as managed (even though they’re configured for RPC/HTTPS manually)!
So, it’s going to remove all of your existing (working) RPC/HTTPS entries from the ValidPorts key! Fortunately, it makes a backup of the reg key first, but even if you import the key back in… within 15 minutes, it’ll all be overwritten again!
The solution is — make sure you configure your back-end for “managed topology“ BEFORE you configure the front-end servers. No harm in having the BE servers prepared, and that way, when you switch the FE server over to managed topology, the managed BEs are already in place.
Couple of ways you can get the BE servers configured:
1) Go to properties of each and every BE server through ESM and change the setting on the “RPC-HTTP“ tab
2) Write your own script to toggle the Heuristics setting (set or unset the 0x20000000 bit)
3) Use the great script Graham (of MS) wrote. This script makes it a piece of cake — it reads the existing ValidPorts key from the FE server registry and turns the Heuristics bit on for all of the listed BE servers.