Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Can NFUSE and CSG exist on the same server?

Essential Concepts

Can NFUSE and CSG exist on the same server?

by  BeerGood  Posted    (Edited  )
Simple answer is yes.

The long answer (from Citrix) is:

Although not recommended by Citrix for large production environments, it is possible to configure a single Windows 2000 server to run Internet Information Services (IIS) with NFuse Classic and the Citrix Secure Gateway (CSG) service concurrently. In such a setup, the server becomes a self-contained gateway to your MetaFrame server farm. It may also be desirable to load-balance between two or more such servers, so that if any one server ever fails, an NFuse Classic web server and Secure Gateway service are always available.

The following issues surface when attempting to co-locate IIS and Citrix Secure Gateway on the same machine:

Both IIS and CSG, by default, attempt to obtain an exclusive handle on TCP port 443. If one or the other component is configured to use a port other than 443, traffic may not be permitted to traverse firewalls between the client and the server.

If multiple TCP interfaces or IP addresses are available on the server, IIS binds to all interfaces by default, preventing the Citrix Secure Gateway service from starting. This is discussed in Microsoft Technet article Q238131.

The following steps can be carried out to overcome these obstacles and allow CSG to co-exist with IIS.

Open the Network and Dial-up Connections control panel and view the properties of your Local Area Connection.

View the Internet Protocol (TCP/IP) properties and ensure that a static IP address (not DHCP) is being used. Click the Advanced button and add a second IP address to this interface.
Alternatively, you could add a second network card to the server, each with its own static IP address.

At this point your server should have two IP addresses. For example, IP1 is 203.12.216.50 and IP2 is 203.12.216.51. Type ipconfig at a command prompt to confirm. Stop the Citrix Secure Gateway service and the IIS Admin service, along with all its dependent services.

Run the CSG Secure Gateway Service Configuration tool. On the panel that says Select interface, remove the option to listen on all interfaces (0.0.0.0:443) and add only the first server IP address, on port 443. For example, the panel should show only 203.12.216.50:443 as the listening interface. Continue through the configuration wizard and restart the Citrix Secure Gateway service.

As discussed in Q238131, perform the following commands at the server command prompt:

cd \InetPub\AdminScripts
cscript adsutil.vbs set w3svc/disablesocketpooling true


The following output should be returned:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
disablesocketpooling : (BOOLEAN) True



Setting IIS to listen on the correct IP Address

Open the Internet Services Manager snap-in, right-click the Default Web Site and view its properties. On the Web Site tab beneath Web site Identification, change the IP address from (All unassigned) to the second IP address on your server, for example 203.12.216.51 (the one that CSG is NOT configured to use). Click OK. From a command prompt, type IISRESET.

Your server should now be capable of accepting Citrix Secure Gateway requests on IP1 and IIS/NFuse requests on IP2.

In order to support HTTPS connections to IIS and SSL connections to CSG, each IP address on the server should have its own Fully-Qualified Domain Name (FQDN) and its own corresponding SSL server certificate with the appropriate FQDN listed as the subject of each certificate. For example:

csg.company.com resolves to 203.12.216.50
nfuse.company.com resolves to 203.12.216.51

Please note that while it may be possible to configure this same machine to act as the Secure Ticket Authority (STA) as well, this should only be done for demonstration purposes. In a production deployment, the STA should not be exposed to the Internet. If server consolidation is a priority, consider hosting the STA on a combination MetaFrame/IIS server.

Cheers
Register to rate this FAQ  : BAD 1 2 3 4 5 6 7 8 9 10 GOOD
Please Note: 1 is Bad, 10 is Good :-)

Part and Inventory Search

Back
Top