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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
citrix over internet
- Thread starter Ian18
- Start date
puxfanatic
MIS
If the app won't run as a published app, publish the desktop and make that available via NFuse.
- Thread starter
- #4
A Published desktop is just like a Program Neighborhood connection before there was an Nfuse.
But why won't your published app. work? You say you are new to Nfuse, maybe you have not set up the app. correctly?
What is it and what is your problem? If you publish the desktop you let your users have full access to your server and network and have to do alot of stuff to secure it.
Jon
There is much pleasure to be gained from useless knowledge. (Bertrand Russell)
But why won't your published app. work? You say you are new to Nfuse, maybe you have not set up the app. correctly?
What is it and what is your problem? If you publish the desktop you let your users have full access to your server and network and have to do alot of stuff to secure it.
Jon
There is much pleasure to be gained from useless knowledge. (Bertrand Russell)
CitrixEngineer
Technical User
If the app won't "run over NFuse", it probably won't run within a Published Desktop.
I agree with Jontmke - it sounds like there is a fundamental problem with the application, or the way it was installed.
TEST:
Can you log in over the LAN as a regular user and run this application
1) via a Terminal Services Session
2) via a Citrix Session
3) as a Published Application
If 3) works, then it'll work via NFuse.
If none work, then you need to check the installation of this application - do the vendors certify that it will work with Terminal Services? Does it use *.ini files? Does it require a single IP address to run?
Hope some of this helps
CitrixEngineer@yahoo.co.uk
I agree with Jontmke - it sounds like there is a fundamental problem with the application, or the way it was installed.
TEST:
Can you log in over the LAN as a regular user and run this application
1) via a Terminal Services Session
2) via a Citrix Session
3) as a Published Application
If 3) works, then it'll work via NFuse.
If none work, then you need to check the installation of this application - do the vendors certify that it will work with Terminal Services? Does it use *.ini files? Does it require a single IP address to run?
Hope some of this helps
CitrixEngineer@yahoo.co.uk
- Thread starter
- #7
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
Richard
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
Richard
- Status
Similar threads
- Locked
- Question