Out of the box, NFuse Classic 1.7 only has the ability to provide applications to users from a single server farm (because it only communicates with the Citrix XML service from a single server). This is unfortunate since (as we learned in Chapter 3) there are plenty of real world situations in which your MetaFrame XP environment might need to consist of multiple server farms.
Luckily, there is a solution that allows you to use a single NFuse web site to seamlessly and securely access published applications from multiple server farms. This is possible with a Citrix product called "Enterprise Services for NFuse 1.7" (abbreviated as ESN).
ESN is a standalone product from Citrix that sits between an NFuse web server and multiple server farms, as shown in Figure 11.6. When ESN is used, the NFuse web server communicates with ESN, and ESN communicates with the Citrix XML service running on multiple MetaFrame XP servers in multiple server farms. ESN stores all of its configuration in a SQL database. That database can be shared between multiple ESN servers for scalability and redundancy.
Figure 11.6: How ESN fits into the NFuse architecture
Advantages of using Enterprise Services for NFuse
- Easy way to provide a single interface into multiple server farms.
- Can be used to "load-balance" multiple server farms.
- Leverages existing NFuse 1.7 technology and components.
- Fully supported by Citrix.
Disadvantages of using Enterprise Services for NFuse
- Must be run on a Windows 2000 IIS web server.
- A SQL database is required.
- Requires MetaFrame XPe with Subscription Advantage.
- Other requirements are pretty steep.
Even though ESN is a separate product, it cannot be purchased. It is only available (via download) if you own MetaFrame XPe with a current Subscription Advantage license. See Chapter 14 for detailed information about licensing and Subscription Advantage.
The remainder of this section will focus on how ESN works and the design considerations that you need to think about for your environment. In Chapter 17 we'll describe how ESN can be used to load-balance multiple server farms for the ultimate in redundancy and high availability.
How Enterprise Services for NFuse Works
In the beginning of this chapter, we outlined the step-by-step process of how NFuse Classic works. Figure 11.7 (next page) details that same process when ESN is also used.
Figure 11.7: How ESN works
- A user with a web browser and an ICA client requests the NFuse portal web page by typing in a URL.
- The web server sends down the HTML login page via the HTTP protocol.
- The web user enters credentials and sends them back to the web server.
- The web server forwards the user's information to an ESN server.
- The ESN server validates the credentials.
- The ESN server retrieves the user's list of applications from its database. (ESN caches this information from the server farm, updating it every 24 hours.)
- The ESN server sends the application list to the NFuse web server.
- The NFuse web server builds a web page containing all of the user's application icons.
- Each icon is hyperlinked with its application properties.
- The user selects an application to run by clicking on an icon in thie web browser.
- The web browser sends a request to the web server for the link that the user selected.
- The web server sends the request to the ESN server.
- The ESN server sends the request to the appropriate server farm via the Citrix XML service.
- The MetaFrame XP server sends a response back to the ESN server.
- The ESN server sends the information to the NFuse web server.
- The NFuse Java Objects on the web server retrieve an ICA file template. That template is modified with the application's and user's specific information. This creates a custom ICA file for the user.
- The custom-built ICA file is sent to web browser on the client device.
- The web browser receives the ICA file and passes it to ICA client software that is also loaded on the ICA client device.
- The user's local ICA client starts the MetaFrame XP session with the information contained in the custom ICA file.
Understanding the ESN Components
There are five components that make up Enterprise Services for NFuse environments:
- NFuse Classic Web Server
- ESN Server
- ESN Database
- MetaFrame XP Servers
- ICA Clients
Component 1. NFuse Classic Web Server
As you saw in Figure 11.7, the NFuse web server performs essentially the same role whether ESN is used or not. The main difference is that when ESN is used, the NFuse web server contacts the Citrix XML service on the ESN server rather than on a MetaFrame XP server. NFuse 1.61 or newer is required for ESN. Also, the default NFuse web pages are replaced with ESN web pages.
In order for this to happen, you need to put your NFuse web server into "Enterprise Mode." This will tell NFuse that it is communicating with an ESN server. You can put an NFuse web server into enterprise mode by viewing the NFuse administrative web pages (NFuse Admin Web Site | Mode Link | Mode Setting) or by adding the following two lines to the NFuse.conf file:
Since NFuse Classic is still in place when ESN is used, you can still access and modify NFuse Classic settings. However, several NFuse Classic settings are also specified at the ESN level. For these particular settings, the system ignores the NFuse Classic settings when ESN is used. NFuse Classic pulls the configurations from the ESN server. These settings include:
Load balancing of Citrix XML servers.
- Password change settings.
- Firewall configuration. (See Chapter 15)
- Alternate addressing. (See in Chapter 15)
- Citrix Secure Gateway. (See in Chapter 15)
- Authentication options, including pass-through authentication and smart card support. (See in Chapter 15)
Component 2. ESN Server
The Enterprise Services for NFuse server is the main ESN component. It uses the Citrix XML service to poll all of the configured server farms (every 24 hours by default) and creates and maintains its own aggregated list of applications that are available across the farm.
Additionally, the ESN server maintains a list of user account mappings for NFuse user accounts that can be used to access MetaFrame XP servers in multiple farms.
The ESN server itself must be running Windows 2000 with Service Pack 2 and Internet Information Services. When you install ESN, a new web server component called "Tomcat Jakarta" is installed. (This is essentially an interpreter for the ESN web code, since that code is written as Java Server Pages which are not natively supported by IIS. More information is available at http://jakarta.apache.org/tomcat/.)
When you install ESN, you must choose whether it validates users against a Windows domain, an Active Directory, or an NDS tree. This is known as the "account authority." If you plan to use Windows NT 4.0 domain or NDS authentication, your ESN server must belong to a Windows domain. If you plan to use Active Directory authentication, your ESN server can operate in workgroup or domain mode.
All of these requirements apply to the ESN server only. Your NFuse Classic web server can be on a non-Microsoft platform.
Component 3. ESN Database
ESN stores all of its information in a database. In addition to the cached lists of server farm applications and the user account mappings mentioned previously, the ESN database also stores all of the ESN configuration settings and any log files that you enable. (Unlike NFuse Classic, ESN does not store any information is text-based configuration files.)
The ESN database must be a Microsoft SQL 7.0 or SQL 2000 server. In large environments, a single ESN database can be used with multiple ESN servers. In a sense, the ESN database is kind of like the "data store" for ESN servers.
The exact size of the database will vary depending on the number of farms, applications, user mappings, and log files that you have. However, even the largest ESN databases are not especially large.
Component 4. MetaFrame XP Servers
The last ESN server component is the MetaFrame XP servers. In ESN environments, MetaFrame XP servers perform the exact same role that they do in NFuse classic environments. The only difference is that they provide information about farm applications via the Citrix XML service to ESN servers instead of NFuse Classic servers.
In order for a MetaFrame XP server to work with ESN, it must have Feature Release 1 or 2 installed.
Component 5. ICA Clients
ICA clients access the ESN environment in the same way that they access NFuse Classic environments. Similar to when NFuse Classic is used, once a MetaFrame XP ICA session is launched, both the ESN and the NFuse servers are no longer involved. At that point the user has a direct connection to the MetaFrame XP server.
At minimum, end users must have Internet Explorer 5.01 with Service Pack 2, 5.5 with Service Pack 2, or Netscape 4.7 to access ESN web portals. All ICA client platforms are supported except for the Java client version 6.30. (You can use the Java client version 6.20.)
Designing your ESN Solution
Now that you know how ESN works, you can start to think about the design of your ESN environment. There are several issues to consider:
- What will be your strategy for aggregating published applications from multiple server farms?
- How will you configure user account mappings to ensure that all users can access MetaFrame XP servers from all farms?
- Where will you put your ESN servers?
Published Applications from Multiple Farms
As long as published applications from multiple server farms have the same display names and application names, and as long as they are in the same Program Neighborhood folder, ESN will aggregate them into a single icon for on the ESN web site. This can be used to load-balance server farms.
You can use the ESN administrative web pages to specify default server farms for groups of users. Then, when users click on icons for applications published in multiple farms, they are sent to their preferred farm unless that farm is not available, in which case they are sent to the next least-busy farm.
User Account Mapping Methods
The whole point of using ESN is to provide your users with access to multiple server farms. Unfortunately, there are many situations in which your users will not have rights to the MetaFrame XP servers in all the farms, since different servers from different farms are usually in different domains.
To address this, configure a user account mapping policy for each server farm to which ESN connects. This mapping correlates user accounts that are valid on the ESN web site with user accounts that are valid in each target server farm. The exact policy that you use for a farm depends on two items:
- Are your users' accounts valid in the target server farm?
- Is the target server farm in the same domain as the ESN server? (This does not have anything to do with the users' account domains.)
Based on your answers to these two questions, there are three possbile mapping modes:
- Manual account mapping.
- Automatic account mapping.
- No account mapping.
You must make this account mapping decision for every server farm that is part of your ESN environment. Let's take a look at each of the three options.
Option 1. Manual Account Mapping
If your users already have valid accounts on the MetaFrame XP servers in the target farm, you can configure "manual account mapping." This setting causes the ESN web pages to ask the user to enter his account information for each farm the first time that he logs in to ESN. However, this information is then stored in the ESN database and users are not asked for their information again.
Advantages of Manual Account Mapping
Disadvantages of Manual Account Mapping
- It only works when users have accounts that are valid on the target MetaFrame XP servers.
- The users must perform their own mappings. Even though this is explained in detail the first time the users login to the ESN web site, there is still a chance that the user could do something wrong.
Option 2. Automatic Account Mapping
If your users do not have valid accounts on the MetaFrame XP servers in the target farm, and if you do not want to manually configure accounts for them, you can configure the farm for "automatic account mapping." To use this, you need to manually create a pool of user accounts in the target farm. (These accounts all need to be configured with the same password.) Then, when a user logs into the ESN web site, ESN automatically picks an unused account from the pool and creates a permanent mapping in the ESN database that locks the two accounts together. This allows users to log into the ESN website with their official account and be able to sign into the target server farm without re-entering their credentials.
Advantages of Automatic Account Mapping
- The mapping process is transparent to the user.
- The auto-mapped accounts can be configured so that they never expire.
Disadvantages of Automatic Account Mapping
- The account that the user is mapped to for use with the target MetaFrame servers is picked randomly, and therefore it doesn't correspond to the user other than via the ESN mapping.
- You must manually set up a pool of user accounts for use with the target MetaFrame servers.
Option 3. No Mapping
Lastly, if the MetaFrame XP servers in the target farm are in the same domain as (or a domain that trusts) the ESN server, you do not need to configure any account mapping (since you users will have authenticated to the ESN server already).
Advantages of No Mapping
- No work for you.
- No work for the user.
Disadvantages of No Mapping
- Only works when the account by which the user accesses the ESN web server also works on the target MetaFrame servers.
Placing ESN servers in your environment
Now that you've designed all the other aspects of ESN, you need to think about where you're going to put your ESN servers. As you decide this, keep the following points in mind:
- The ESN server requires regular and consistent access to the ESN database since it queries it whenever a user logs into the ESN website.
- By default, ESN servers only contact MetaFrame XP farm servers once every 24 hours. The ESN servers do not necessarily have to be close to every server farm.
- You can have multiple ESN servers that share the same SQL database. You can even configure SQL replication to ensure that ESN servers in different parts of your environment have local SQL access.
- You can configure multiple ESN servers and multiple ESN databases to access the same MetaFrame XP servers.
- A MetaFrame XP server can communicate to NFuse Classic servers as well as ESN servers.
- As with NFuse Classic, a user's session on an ESN web server ends once he launches his ICA application.
Configuring Enterprise Services for NFuse
Configuring ESN is relatively simple. While there are dozens of potential options (all outlined in the "Enterprise Services for NFuse Guide" that comes with the product), you can configure your ESN environment by following a few basic steps:
- Configure your current NFuse server for ESN support.
- Install ESN and SQL Server.
- Configure the "one time only" settings of ESN by accessing ESN's administrative web pages at http://yourESNserver/ NFuseEnterprise/admin/login. (All ESN options are configured via web pages. The first time you access the web pages you are presented with the special "one time only" options.
- Configure the SQL Server database connection.
- Configure your user mapping and authentication method.
- Configure the Windows group that you want to have administrative rights over ESN.
At this point, you have completed the "first time only" options.
- Access the ESN administrative web pages again. You will be sent directly to the administration home page.
- Add a MetaFrame XP server farm or farms (ESN Admin Web Pages | Farms | Add Farm). You add a farm by specifying the URL of a server running the Citrix XML service. (This URL is in the servername:port format.) You can add primary and backup servers for redundancy.
- Configure account mapping for each farm
- Once you do this, you will be able to begin using ESN.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.