If you are using an EnterpriseServices/COMPlus Application Proxy that connects to an EnterpriseServices/COMPlus Server Application on another box, you definitely want to consider using a firewall between the two. When you go from Box A to Box B using ES/COMPlus and an Application Proxy to a Server Application , .Net EnterpriseServices will use DCOM as its remoting channel.
There are a couple of ways to set up this communication through a firewall: 1) Open a range of ports for RPC communication, or 2) Open two ports for ES/COMPlus. The first method has been detailed in this much quoted article by Michael Nelson, "Using Distributed COM with Firewalls", found at http://www.microsoft.com/com/wpaper/dcomfw.asp .
Essentially, for the first method, you set up your RPC port range under the HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet registry key. If you pick too small a range of ports, you can effectively hinder RPC from working at all on your server. A good range would be to use 20 ports or so, but that can still be too little depending on the number of other RPC-dependant services you may be running. After setting up the port range, you reboot the server, open up the firewall to port 135 (for RPC initial calls), and the multiple-port range that was set above.
The second solution, which I am now favoring for ES/COMPlus, is to open two ports on your firewall. The first port is 135 (of course, for RPC initial calls) and a second port. As with above, it is recommended to use a port not already in use above 5000 in order to minimize conflict with existing applications on the server. The ES/COMPlus FAQ mentions this solution:
With Windows 2000 (SP3 or QFE 18.1) or Windows Server 2003 COMPlus applications can be configured to use a static endpoint. This allows you to open only 2 ports in the firewall. Port 135 for the RPC and the specific port for the COMPlus application.
For more information see Q312960 - Cannot Set Fixed Endpoint for a COMPlus Application
To use the second method, you assign the endpoint port to the Application Id (AppId) of the Server Application. This is done by creating the registry key HKEY_CLASSES_ROOT\AppID\{GUID of Server Application} and creating a REG_MULTI_SZ value name called "Endpoints" with the value string "ncacn_ip_tcp,0,port". You do this only on the server. One interesting thing I found, unlike the first method above, is that I don't have to reboot the server after making the change to the registry as the port is picked up dynamically when the Server Application is first started.
Helpful Tip: Of course, when you uninstall and re-install your ES/COMPlus components into a Server Application, a new GUID (Application Id) is generated for you. That is, unless you use the ApplicationIDAttribute in your assembly metadata. I now routinely put the following information in my Server Application AssemblyInfo meta data file (a sample, obviously -- you would need to change the names for your project):
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationName("ServerApp")]
[assembly: ApplicationID("{Generated GUID}")]
[assembly: Description("Server App")]
where "Generated GUID" is obtained by using the Tools\Create GUID option in Visual Studio.Net or running the "guidgen.exe" application from a command prompt.
