- Component Overview
- Application Launching and Embedding
- Citrix NFuse: Program Neighborhood for the Web
- Citrix ICA Web Client Configuration
- MetaFrame Server Configuration for Web Computing
- Web Server Configuration
- MetaFrame and Firewall Considerations
MetaFrame Server Configuration for Web Computing
The changes required to your MetaFrame server configuration depend on where your users are located and whether you'll be implementing NFuse. If users will be within the corporate intranet and will access applications directly from links on a Web page (no NFuse), you probably won't be required to make any changes. Here are a couple of general configuration points to check:
-
Ensure that TCP/IP ICA connections exist. Web clients can access a MetaFrame server only over TCP/IP connections.
-
Make sure that you have properly published the application that you'll be making available to the Web clients. Chapter 19, "Application Integration," explains how to create a published application.
If you plan to provide access to users over the Internet, you need to review both your server and network configuration to ensure that you have adequate security measures in place. Some areas to review include the following:
-
Make sure that you have implemented the suggested system security, as discussed in Chapter 12, "Terminal Server Configuration and Tuning."
-
Try to position your MetaFrame servers behind a firewall, and preferably within a subnet that has access to only specific resources located on other internal networks (or no access, if possible). Provide access to only specific MetaFrame ports (1494 for application connections) through the firewall. In this situation, you'll most likely use network address translation (NAT). As a result, you'll be required to perform some additional configuration on your MetaFrame servers to ensure that users can access the servers properly. Consider implementing a virtual private network (VPN) solution between the clients and the network where the MetaFrame servers reside. See the later section "MetaFrame and Firewall Considerations" for more information on the MetaFrame requirements for firewall access.
-
Establish rigorous monitoring practices for the security logs on these MetaFrame servers. This can provide valuable early-warning information in case of any potential security issues.
-
Restrict connections on the MetaFrame servers to run only published applications, and do not publish any complete desktop scenarios. In this situation, a full desktop should be accessible only from the console.
-
Involve the people from within your business who are responsible for corporate security, specifically Internet security.
NFuse MetaFrame Server Configuration
Only one main change is involved in configuring your MetaFrame servers to support NFuse—installing the NFuse MetaFrame service on one or more MetaFrame servers within your environment. This service provides the communication link between the NFuse Java objects on the Web server and the Program Neighborhood and browser services, which manage the user authentication and application-set information, as shown in Figure 15.14.
){kind=link}
Figure
15.14
The NFuse MetaFrame service's role in the communication process.
Installing the NFuse MetaFrame Service
The installation file for the NFuse MF service is contained in the file NFuseForMF.exe, which can be downloaded from the Citrix Web site (http://www.citrix.com/).
Author's Note - Although NFuse requires that this service be installed on only one MetaFrame server, consider using multiple servers for redundancy and fail-over. If you're implementing dedicated ICA master browser servers, I recommend adding the NFuse service to each of these servers. I discuss NFuse redundancy in the next section.
The NFuse service is installed as follows:
-
Log on to the MF server where you will install this service. Change to installation mode by typing change user /install at a command prompt. Alternatively, you can launch NFuseForMF.exe from the Add/Remove Programs applet in the Control Panel.
-
Accept the terms of the license agreement. The component selection screen appears next, in which you can choose to install the NFuse service and the Web Site Wizard. You don't need to install the wizard on a MetaFrame server. This application will run in any Win32 environment. You normally won't run this from an MF server; more likely, you'll run it on a Web development machine. Deselect Web Site Wizard, and then click Next.
-
The next screen prompts you to select a listening port for the NFuse service, as shown in Figure 15.15. The default port is 80, which is the well-known port for HTTP. This was selected as the default because most firewalls already have this port open for HTTP services. I recommend using this port unless you also have your MetaFrame server operating as a Web server, in which case you're required to select an alternate port.
-
After you select the port, a summary screen indicates the actions that will be taken. Click Next to complete the NFuse service installation. The service starts operating immediately. You're not required to restart the MF server. You can verify that the service is running by typing NET START from a command prompt. You should see Citrix NFuse Service in the list.
){kind=link}
Figure
15.15
NFuse service listening port selection.
Tip - You can use the NETSTAT -A command from a command prompt to get a list of currently active TCP/IP ports on your MetaFrame server. If you're selecting an alternate port for the NFuse service, make sure that it's not already in use or a "well-known" port such as Telnet (23) or FTP (21), unless you're certain that those services won't be required on your MetaFrame server.
You can find a list of well-known ports in the services file located in the directory %systemroot%\system32\drivers\etc.
After installation, you can change the port number used by this service by stopping the service, typing NFUSE.EXE /Rxx (where xx is the new port number), and restarting the service. You can also update the information directly in the registry. The NFuse service properties are maintained in this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CtxHttpThe NFUSE.EXE /U command can also be used to completely remove this registry key.
Redundancy and Fail-Over Considerations
One of the shortcomings with the first release of NFuse is the lack of redundancy available as an integrated part of the NFuse Java component on the Web server. Currently, you must hard-code (either for all Web pages or for each individual page) the address of a MetaFrame server running the NFuse service. Although this may be acceptable for managing load distribution between a few servers, it doesn't provide any protection against the failure of one of these servers, resulting in a loss of service for the associated Web page(s). Figure 15.16 shows the error that a user would receive if the specified MetaFrame server (or the NFuse service) were unavailable.
){kind=link}
Figure
15.16
Error received when the NFuse service is unavailable.
Fortunately, there are some options for providing some simple redundancy to help improve the availability of the NFuse service. Here are two of the options:
-
Employ Microsoft network load balancing. Although this would provide load balancing and fail-over management for the NFuse service, the additional complexity involved may not warrant its use.
-
DNS round-robin. A means of providing simple redundancy and very basic load distribution, implementing DNS round-robin allows you to specify multiple servers under a single DNS name. Although it doesn't dynamically remove a failed server from the list (users would still periodically attempt to hit that downed server), it allows the user to eventually establish his or her NFuse session. Figure 15.17 demonstrates how this could be configured using Windows 2000 DNS. Notice that in this example I've created a virtual hostname (nfusesvc.noisyriver.com) that I'll use when configuring my Web server. The hostname can be associated with one or more MetaFrame servers running the NFuse service.
){kind=link}
Figure
15.17
Configuring DNS round-robin for multiple NFuse-enabled MetaFrame servers.
If you'll be using DNS round-robin and your Web server is a Windows 2000 server, you will need to make two changes to ensure that round-robin will work properly. The first is a change on the Web server itself, and the other is with the DNS server.
On the Web server, you need to modify the time-to-live (TTL) for the server's local DNS cache. Otherwise, repeated hits to a DNS name will result in attempts to contact the same host. All Windows 2000 products employ a local DNS cache that was not present in previous versions of Windows. The registry key is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
The value to modify is MaxCacheEntryTtlLimit. Setting this value to 1 causes cached entries to time out after one second, forcing a query of the DNS server for repeated lookups of the same hostname. You must stop and restart the DNS Client service for this change to take effect. You should also flush the existing contents of the cache using the command
ipconfig /flushdns
You can view the current contents of the cache by typing this:
ipconfig /displaydns
If you're using a Windows DNS server, you need to ensure that LocalNetPriority is not enabled. This feature forces the DNS server to return the best-fit host address to a client. If the client is located on the same network as at least one of the addresses in the round-robin list, that address is always returned to the client. You can disable this feature by adding the REG_DWORD value LocalNetPriority to this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
Set the value to 0, which will disable this feature. You'll have to stop and restart the DNS Server service for this change to take effect. On a Windows 2000 DNS server, this option is enabled by default.