Robert Hurlbut's .NET Blog

If you are using an EnterpriseServices/COM+ Application Proxy that connects to an EnterpriseServices/COM+ 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/COM+ 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/COM+.  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/COM+, 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/COM+ FAQ mentions this solution:

With Windows 2000 (SP3 or QFE 18.1) or Windows Server 2003 COM+ 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 COM+ application.

For more information see Q312960 - Cannot Set Fixed Endpoint for a COM+ 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/COM+ 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.