|
| Design 1. Design Overview The design phase is where you utilize the information that was obtained during the analysis phase to design the layout of your MetaFrame network. In designing the network you should stick the basic principals of Simplicity and Future Growth. A good project is a simple and straightforward one that anticipates future changes in the environment. A shortcoming I have found in analyzing networks is that, networks are designed for today and not tomorrow. Even if you consider todays deployment as a small one, you will still want to design for tomorrow. This gives you the ability to anticipate future growth. The Design Phase document will document the architecture that will be implemented during the Implementation phase. The key sections of these documents are outlined below: Design Overview Server Design Hardware Requirements Operating Systems Requirements MetaFrame Design Farm Design Zone Design Data Collector Design Data Store Design Load Management Design Applications Applications Delivery Network Design File Storage Logon Scripts Network Modifications
The following is an example of a Design Overview: | 1. Design Overview D&D Consulting has been engaged to design and assist in deploying Citrix MetaFrame XP Application Servers for DABCC.COM. The main technology areas covered in this document includes: Server Requirements MetaFrame Design Network Design D & D Consulting will utilize a Project Management approach in order to achieve an optimum network design. Simplicity is the best investment. Simple structures are easier to explain, maintain and debug than complex ones. Every network created will require some maintenance over its lifetime. When you create a structure without well-defined reasons, it will end up costing more in the long run than any value that it adds. Therefore its important to carefully analyze and justify the structure before you create it. Your business and your organization will always change. There are normal changes that occur within any organization such as changing applications requirements or enterprise-wide reorganizations that will affect DABCC.COMs MetaFrame XP architecture. When designing the architecture, consider how these potential changes will affect end-users and administrators interaction with the farm. Make sure your design is general and flexible enough to accommodate constant and significant change. Aim for the ideal design. In your design and planning you should aim for the ideal structure even if it does not reflect the current architecture plan. It is useful and practical to understand what would be ideal, even if it is not currently attainable. Below is a diagram of the planned native MetaFrame XP architecture: 
| 2. Server Design The Server Design section consists of the following sections: Hardware Recommendations Operating System Requirements The following is an example of a Server Design Overview: | 2. Server Requirements The Server Design section consists of the following sections: Hardware Recommendations Operating System Requirements | 2. 1. Hardware Recommendations The question that gets asked for each and every project is What kind and/or how many Citrix servers do I need? This is a touchy subject and it really all depends on a number of factors. It is not the purpose of this document to examine cost analysis and scalability testing, For the most part, a customer for this sized project probably will not want to incur the associated expense. However, it is important to make a determination from the information we have gathered and our experience in past installations. All MetaFrame environments are different and based on the data you collected from the Proof of Concept, you should be able to give your recommendations on server hardware. (Application memory and CPU usage). The following are my recommendations, anything more would be like shooting arrows in the dark. What type of and how many processors do I need? There are numerous processors to choose from in deciding what server hardware to purchase. A minimum of a single Pentium is required, but I recommend dual Pentium III or IV processor boxes for maximum performance in a cost effective manner. How much memory per server? From my experiences I recommend 1GB RAM per CPU. This gives you the best bang for your buck and is ultimately more cost effective in the long run. How many servers do I need? This all depends on how many users you will be supporting, the amount of RAM each application requires, the type of applications you are running and how heavy the end users utilize the applications and numerous other factors. What I have always recommended is this. A MetaFrame server is an application server and the only data that needs to reside on it should be the applications executables. With this in mind, I dont believe in scaling out vs. scaling up and having N+1 instead of RAID controllers and redundant fans and power supplies. The money you save is better spent on an additional server for load balancing purposes. In other words if you have 40 concurrent users on two boxes and one drops off, you would want to make sure that the other server would be able to handle the additional 20 users load. If the remaining server(s) cannot hold the load then you will need to add another server to the farm. This guarantees your customer high availability. N+1 solves this perception issue. The following is an example of Hardware Requirements: | 2. 1 Hardware Recommendations Keeping to the vision of achieving high availability while achieving a very high user perception of performance, D&D Consulting specked the following hardware price quotation. | Hardware Price Quotation | | | | Quantity | Part Number | Product | Unit Cost | Total Cost | | | | HARDWARE | | | | | | | | | | 4 | 218789981 | Proliant DL360 PIII933/256k | $4,650.00 | $18,600.00 | | | | Pentium III 933MHz processor, a 256KB L2 ECC cache, an integrated Smart Array controller and 128MB PC133 Registered ECC SDRAM, expandable to 4GB. In addition to the 133MHz front bus speed, this server contains a 3.5" 1.44MB floppy disk drive, a 24X (max. speed) Slimline CD-ROM drive and two open PCI slots (one 64-bit/33MHz and one 32-bit/33MHz). Because there is no pre-installed hard drive, you are free to configure storage to fit your needs. The standard Wide Ultra2/Ultra3 SCSI drive cage supports up to two 1" Wide Ultra2/Ultra3 hot-plug hard drives, for a maximum Internal hot-plug capacity up to 72.8GB (2 x 36.4GB). | | | | | | | | | | 4 | 265447-B21 | P3-933 SECOND PROCESSOR KIT FOR DL360 | $1,298.00 | $5,192.00 | | 4 | 155646-001 | REMOTE INSIGHT LIGHTS-OUT EDITION | $486.00 | $1,944.00 | | | | | | | | 8 | 125669-B21 | 512MB REG SDRAM DIMM 133MHZ | $1,357.00 | $10,856.00 | | | | (STD MEMORY IS 128MB AND THERE ARE (3) EMPTY SLOTS) | | | | | | | | | | 8 | 142654652 | 9.1 PLUGGABLE WIDE ULTRA SCSI 3INT UNIVERSAL 10K | $453.00 | $3,624.00 | | | | | | | | | | Sub Total minus tax / Freight | | $40,216.00 | | | | | | |
|
2. 2. Operating System Requirements In this section you will want to document the Operating System and MetaFrame version recommended with a preliminary price quote for the proposed operating system(s) and MetaFrame version and any additional client access licenses. The following is an example of a Operating System Requirements: | 2. 2 Operating System Requirements In keeping with the vision of achieving high availability while achieving a very high user perception of performance and stability, D&D Consulting, recommends Microsoft Windows 2000 Server and Citrix MetaFrame XPe. The following is a software quote for Microsoft Windows 2000, the appropriate client access licenses and Citrix MetaFrame XPe with the required amount of additional connection licenses. | | Citrix MetaFrame v1.0 XPe | | | | | | | | | | | | | 1 | EW22XPE0020 | XPe Starter Kit, includes 20 users w/ 1 yr subscription | $5,285.00 | $5,285.00 | | | | | | | | | | | | | Microsoft Windows 2000 Server | | | | | | | | | | | | | | | | | 1 | C11-00821 | Windows 2000 Server | | | | $710.00 | $710.00 | | | | | | | | | | | | 20 | C78-00480 | Windows 2000 CAL | | | | $29.00 | $580.00 | | | | | | | | | | | | 20 | C79-00539 | Windows 2000 Terminal Services CAL | | $78.00 | $1,560.00 | | | | | | | | | | | | | | | | Pretax/PreFreight Sub Total | | $8,135.00 | | | | | | | | | | | | | | | In order to process this order with the above products and/or services specified, | | | | | Please sign, date and fax the complete quote back at your convenience. | | | | | If your company uses purchase orders, please include a copy with the fax. | | | | | | | | | | | | | | | | Authorized Signature: | | | | | | | | | | | | | | | | | | | | | | | | | | |
| 3. MetaFrame Design The MetaFrame Design section consists of the following sections: Farm Design Data Collector Design Zone Design Data Store Design Load Management Design Applications Application Delivery In the MetaFrame Design section you will want to format each of the above bullet points into the following three sections. This will give your customer a background on your recommendations based on the project vision / requirements. Background Give a brief background on the technologies you will be using and or ones where a decision is required. Following this, itemize all of the risks and processes needed to accomplish the task. If your customer needs to make a decision, make sure that you document all of the possible options equally. Requirements - Define each of the requirements for achieving a successful implementation. These requirements are derived from the project vision, organizational units, geography and as always, corporate politics. You will probably want to organize a meeting to define the requirements for each section. Recommendations Document your recommendations based on the above requirements and your professional experience. The following is an example of a MetaFrame Design Overview: | 3. MetaFrame Design The MetaFrame Design section consists of the following sections: Farm Design Data Collector Design Zone Design Data Store Design Load Management Design Applications Application Delivery Printer Environment The following is background on the foundation that will control the proposed MetaFrame environment. MetaFrame XP incorporates the advanced Citrix server communications and management foundation and the Independent Management Architecture (IMA). The integration of the MetaFrame XP application server software with the IMA is central to the enhanced functionality of MetaFrame XP and the scalability of Citrixs server-based computing solutions. IMA is a unified enterprise-wide platform for the installation, management, maintenance, support, and security of your organizations server-based computing and application hosting services. It is both an architectural model and a protocol for server-to-server communications. IMA is constructed on a collection of core subsystems that define and control execution of Citrix products. IMA enables MetaFrame XP servers to be arbitrarily grouped into server farms that do not depend on the physical locations of the servers. IMA allows MetaFrame XP servers to be in a single server farm even if the servers are on different network subnets. With MetaFrame XP for Windows servers and the extensible Citrix IMA foundation, organizations gain a wide range of enterprise management and scalability features and options: Central administration of MetaFrame XP and other Citrix servers Centralized data store for all Citrix configuration data Centralized license management and pooling without license gateways ICA Client discovery of published applications without UDP broadcasts Logging of shadowed sessions Simple Network Management Protocol (SNMP) support Auditing of administration activity While IMA and MetaFrame XP provide significant enhancements that facilitate enterprise application hosting, both MetaFrame XP and IMA support the current functionality of all existing ICA Client software from Citrix and will operate with an installed base of ICA Clients. In addition to the Citrix Management Console, several Windows-based management utilities are included with MetaFrame XP. These utilities provide management and configuration features that are independent of the IMA system. As the size of an organization increases from dozens to hundreds to thousands of users, additional MetaFrame XP servers can be added to the server farm. With IMA, MetaFrame XP installations can scale to multi-site, enterprise-level server-based computing scenarios, while administrators maintain complete control from any location. |
3. 1. Farm Design In the Farm Design section you define the number and location of the server farms. The following is any example of a farm design: | 3. 1 Farm Design 3. 1. 1. Background Citrix server farms provide you with a flexible and robust way of deploying applications to ICA Client users. A Citrix server farm is a group of Citrix servers managed as a single entity and share some form of physical connection. In addition, the servers in the server farm share a single IMA-based data store. A single farm can be used for the enterprise. However, there are several factors concerning hardware, database performance, and network congestion that can decrease performance of the farm. A way to increase performance is to create separate, multiple farms for the enterprise. The following are advantages of both single and multiple farms. Single Farm Pooled licenses All MetaFrame XP licenses are pooled together and can be used by all servers in the farm. Simplified management and administration Citrix administrators only need to log in to one farm for all maintenance and administrative tasks. Multiple Farms Reduced IMA Traffic A single farm with remote zone data collectors must communicate frequently to keep published application and user connection information synchronized across the farm. No firewall changes - When the farm spans through a firewall, TCP ports 2512 and 2513 must be opened on the firewall for IMA communication. The implementation of a separate farm per site eliminates the need to open ports 2512 and 2513 on the firewall and any ODBC ports used for data store communication. No Internet traffic - When the farm spans an Internet WAN connection, IMA traffic and ODBC connection information can potentially be intercepted. This data does not travel across a WAN connection when a farm is isolated to one site. No data store replication As discussed in the section titled Estimated Bandwidth Usage and Requirements on page 21, Citrix recommends that the data store be replicated to remote sites when using a single farm in a WAN environment. The use of multiple farms eliminates the need for data store replication, because each remote site maintains its own data store. 3. 1. 2. Requirements DABCC.COM would like centralized license pooling across all sites in the organization with a single point of management throughout the company while keeping with the requirement of reduced bandwidth consumption. 3. 1. 3. Recommendations Because of the bandwidth limitations and the cost of server-to-server communications, it is recommended for DABCC.COM to implement a single MetaFrame XP farm. | 3. 2. Zone Design In the Data Collector Design section you will need to document the configuration and location of the MetaFrame XP data collectors. Zone layout is crucial to the end-user perception of performance. The following is an example of a zone design: | 3. 2. Zone Design 3. 2. 1. Background The layout and distribution of zones in MetaFrame XP is crucial to the end-user perception of performance. In an IMA-based Citrix server farm, a zone is a grouping of Citrix servers that you configure. By default, all servers in a farm that are on the same network subnet belong to the same zone. You can use the Zones tab in the Properties dialog box to create and configure additional zones. Zones are designed to enhance the performance of a Citrix server farm by allowing geographically related servers to be grouped together, whether they are connected to the same network subnet or not. If all the servers in a farm are in one location, you can configure the farm with a single zone without causing slower performance or making the farm more difficult to manage If you manage an enterprise server farm with servers in different geographic regions, you can place servers into zones based on the location of the servers. This can improve performance and make management of the farm more efficient Data Collectors Each zone in a server farm contains one Citrix server that is designated as the data collector for the zone. A zones data collector receives information from each MetaFrame XP server in the zone. Data collectors store information about the servers and published applications in the server farm. The data collector knows the addresses of each server and the applications that are available on each server in the zone. Data collectors in IMA-based server farms are similar in function to the Windows Master Browsers in Microsoft Windows networks. However, data collectors use TCP/IP for server-to-server communication. Windows use RPC for server-to-server communication. The data collector in each zone can support up to 70 resolutions per second. Member servers in each zone frequently update their session and load information to their zones data collector. The data collector is then responsible for relaying new information to all of the other data collectors in the farm. This operation consumes N times the amount of bandwidth, where N represents the number of zones. In a WAN environment, the cost of placing separate zones at each WAN point must be considered. For example, if DABCC.COM implements three separate zones, each time a dynamic event such as a user logon occurs, one initiating zones data collector sends that event to the other two data collectors. So the same event goes across the WAN link two times. If, the environment is configured as a single zone with a central zone data collector, each time a dynamic event occurs, the event traverses the WAN link only once to the central zone data collector. 3. 2. 2. Requirements The requirement is to provide a robust, highly optimized zone structure capable of supporting the IMA traffic with the lowest cost in server-to-server traffic achieving optimal end-user performance. The zone design must be capable of supporting the current and future needs of DABCC.COM. 3. 2. 3. Recommendation It is recommended for DABCC.COM to implement a single zone. If a remote site grows to more than two MetaFrame XP servers, the cost for server-to-server replication is less expensive than having every Citrix server in the remote site communicate with a single data collector located in the Des Moines data center. | 3. 3. Data Collector Design In the Data Collector Design section you will need to document the configuration and location of the MetaFrame XP data collectors. The following is an example of a Data Collector Design: |
3. 3. Data Collector Design 3. 3. 1 Background Each zone in a server farm contains one Citrix server that is designated as the data collector for the zone. A zones data collector receives information from each MetaFrame XP server in the zone. Data collectors store information about the servers and published applications in the server farm. The data collector knows the address of each server and the applications that are available on each server in the zone. Data collectors in IMA-based server farms are similar in function to the Windows Master Browsers in Microsoft Windows networks. However, data collectors use TCP/IP for server-to-server communication. Windows use RPC for server-to-server communication. The data collector in each zone can support up to 70 resolutions per second. Member servers in each zone frequently update their session and load information to their zones data collector. The data collector is then responsible for relaying new information to all of the other data collectors in the farm. This operation consumes N times the amount of bandwidth, where N represents the number of zones. DABCC.COM is planning to implement up two four additional servers totaling for a total of eight servers in the farm. This is important in designing the data collector architecture. A dedicated data collector (control server) will be used. It will consist of Windows 2000 running in Remote Administration mode, leaving the Server Service for the proper thread scheduling. The following roles will be housed on the control server: Data Collector, Citrix Management Console (CMC) publisher, Resource Manager Primary Metric Server, central Auto-Client Update database and print driver replication source server. 3. 3. 2. Requirements DABCC.COM would like centralized license pooling across all sites in their organization and single point of management throughout the company while keeping with the requirement of reduced bandwidth consumption. 3. 3. 3. Recommendations Because of the bandwidth limitations and the cost of server-to-server communications, it is recommended that DABCC.COM implement a single MetaFrame XP farm. | 3. 4. Data Store Design The Data Store Design section not only documents what data store your customer will use but how they will account for any failures through replication, backup, etc As always, you will give background information on the data store types (SQL, Oracle or Access), location, and the access methods (direct or indirect). The following is an example of a Data Store Design: | 3. 4. Data Store Design 3. 4. 1. Background Before installing MetaFrame XP, you must decide which database to use for the data store for your server farm. Microsoft Access The Microsoft Access is a lightweight database that is included with Windows server operating systems. It is most appropriate for smaller server farms of up to 50 servers. However, mid-sized server farms of more than 50 servers often perform just as well with a Microsoft Access database as with a SQL Server. When using Microsoft Access, the database is stored on the first MetaFrame XP server in the farm, and is created as part of the MetaFrame XP installation process. Access is best used for centralized farms and supports only indirect mode for all servers other than the host. It therefore has slower performance than a direct mode data store on large farms. Database replication is not supported with Access. Microsoft SQL Server Microsoft SQL Server is a true client/server database that offers robust and scalable support for multiple-server data access. It is suited for use in farms of any size. When using Microsoft SQL Server, the database is on a dedicated server running Microsoft SQL that must be set up prior to creating the server farm Microsoft SQL servers require significant expertise to install and maintain. If you do not have expertise with these products, using them in a production environment is not recommended. See the documentation included with your database product for important details such as performance tuning and database backup procedures. Do not install MetaFrame XP on the Microsoft SQL database server. Refer to the Microsoft SQL Server documentation for specific hardware requirements on the database server. It is important to note that other factors in addition to the number of servers affect the data store and overall server farm performance. Other factors that affect performance are the number and type of published applications, the maximum number and the average number of concurrent client connections and the hardware configuration of MetaFrame XP servers. After you decide which database to use for the data store, you need to decide whether the MetaFrame XP servers will access it by direct connection or indirectly through another MetaFrame XP server. Direct Access To make a direct connection to the data store, a MetaFrame XP server must have the appropriate ODBC drivers installed and configured properly. The server then connects directly to the server on which the database is running. Indirect Access For indirect access, a MetaFrame XP server connects to an intermediary MetaFrame XP server. The intermediary server connects to the data store directly. Using indirect connectivity with an SQL database eliminates the need to install and configure the ODBC drivers on every MetaFrame XP server. If you are using an SQL database for the data store, you can use a combination of direct and indirect access methods for the servers in the farm. Indirect access is not recommended for mission-critical server farms because the intermediary server is a single point of failure. By default, indirect access uses TCP port 2512 for communication between the MetaFrame XP servers. If the MetaFrame XP servers are in different subnets, be sure this port is not blocked by any firewalls. If this port number is not convenient, it can be changed. Replicated Database Having a single data store is recommended where appropriate but in some situations, a replicated data store can improve farm performance. Below are some of the concerns and situations that arise from using replicated database technology. High latency links without the use of replicated databases can create situations where the data store is locked for extended periods of time when performing maintenance from remote sites. This means that the IMA service can time out (but starts after an extended period of time) and some normal operations can fail when performed from the remote site. In a high-latency situation, data store writes take longer to complete and for a period of time, block all additional writes from local or remote sites. In a high-latency situation, data store reads will probably not adversely affect local connections, but the remote site will experience slower performance. Use of replicated databases to speed performance can be justified in some scenarios. The farm servers perform many more reads from the data store than writes to the data store. Most reads occur during startup, when each server populates its local host cache. In a LAN environment, using replicated databases can speed the startup time of the IMA service and improve the responsiveness of the servers in large farms. In a WAN environment, the configuration of the data store is important. Because MetaFrame XP is read-intensive, place replicas of the data store at sites where a considerable number of servers reside. This practice minimizes reads across the WAN link. Limit the use of replicated databases to situations where the remote site has enough MetaFrame XP servers to justify the cost of placing a replicated copy of the database at the site. Database replication consumes bandwidth. The database server software configuration - not MetaFrame XP - controls the frequency of database updates. Distributed Databases MetaFrame XP supports distributed databases. Distributed databases are useful when the data store begins to bottleneck due to too many read requests. To distribute the load of reads, a distributed database can be used. Microsoft SQL Server uses replication to create the distributed database environment. MetaFrame XP needs to be assured of data coherency across multiple databases. Because of this requirement, a two-phase commit algorithm must be used for writes to the database. When configuring Microsoft SQL Server for a two-phase commit, Citrix recommends using the Immediate Updating Subscriber model. See the Microsoft SQL Server documentation for information on setting up replication with the Immediate Updating Subscriber model. 3. 4. 2. Requirements DABCC.COM would like to keep with the goal of achieving a highly available data store, which is designed for growth in mind. 3. 4. 3. Recommendation It is recommended for DABCC.COM to implement Microsoft SQL 7 Service Pack 2 database server as the Independent Management Architecture (IMA) data store. This will allow DABCC.COM to achieve the vision of the project while providing an enterprise class database server to accommodate for growth, replication, and high availability. It is recommended for DABCC.COM to implement Microsoft SQL 7 server in a distributed database model. This will allow DABCC.COM the ability to prevent a single point of failure along with distributing the load of reads and writes on the data store. It is recommended for DABCC.COM to implement a replicated database to a zone if the number of Citrix MetaFrame XP servers grows to greater than five in a given zone and or end-user performance perception drops. This will allow DABCC.COM to deliver the best performance to end-users along with reducing IMA traffic over WAN links. |
3. 5. Load Management Design In the Load Management Design section you will need to document how Load Management will be configured. Define the Load Evaluators you will be using, any rules, their settings and the benefits they bring. You will want to document all. This area defines how load balancing and Load Management evaluators will be configured. The following is an example of a Load Management Design: | 3. 5. Load Management Design 3. 5. 1. Background Load Manager is installed automatically with MetaFrame XPe. Load Manager uses a system of load evaluators to calculate server loads. Data collectors compare server loads to determine the server to which the ICA Client will connect. DABCC.COM will implement default Load Balancing load evaluator for all applications in the MetaFrame XP farm. This rule allows your load evaluator to calculate a load based on the number of users on an attached server. When the number of users is less than or equal to the high threshold, Load Manager Reports a load percentage based on the threshold value. When the number of users exceeds the high threshold, Load Manager Reports full load. The valid range for the high threshold is 1 to 10000. When Load Manager is functioning, applications that are published on a single server are also considered load managed. If the server load becomes full, the server stops accepting connections to the published application. 3. 5. 2. Requirements DABCC.COM would like centralized license pooling across all sites in their organization and single point of management throughout the company while keeping with the requirement of reduced bandwidth consumption. 3. 5. 3. Recommendations Because of the bandwidth limitations and the cost of server-to-server communications it is recommended for DABCC.COM to implement a single MetaFrame XP farm. |
3. 6. Applications In this section you will want to document the applications that will be deployed and the processes and procedures required in order to perform the installation of each application. OS settings (registry) are determined and changes to the installation processes are defined. These procedures might need to be fine tuned during the Implementation phase. You will also want to define which applications are installed on each server and who has access to them. The following is an example table of published applications information: | 3. 6. Applications DABCC.COM would like to implement the following applications in the new MetaFrame XP Farm. The application data will be moved to Distrusted File System shares, as shown below, to supply high availability and the ability to move the data without disrupting the farm. Proposed Application List: | Name: | Executable: | Type: | Servers | | Adobe Acrobat | \\dabcc.com\dfsroot\xpimsapps\acrobat\acrobat.wfs | IMS | All | | Adobe Acrobat | C:\program files\adobe\reader.exe | Published Shortcut | All | | Exchange Admin | Loaded from Exchange 2000 CDROM | Manual | CXPMSTR | | Exchange Admin | \\dabcc.com\dfsroot\xpapps\tools\ exchadmin.cmd | Published Shortcut | CXPMSTR | | One World Production | C:\b7\system\bin32\oexplorer.exe | Manual | CXP1 CXP2 | | Office 2000 | \\dabcc.com\dfsroot\xpimsapps\ office2k\install.cmd Launch install.cmd from server console. (installed with a custom .MST file) | Manual | All | | Office 2000 Resource Kit | \\dabcc.com\dfsroot\xpimsapps\ o2ktools\orkdata.msi | IMS | All | | Excel 2000 | C:\Program Files\Microsoft Office\Office\ Excel.exe | Published EXE | All |
Word 2000 | C:\Program Files\Microsoft Office\Office\ Winword.exe | Published EXE | All | | Outlook 2000 | \\dabcc.com\dfsroot\xpimsapps\ol2k\ install.cmd Launch install.cmd from server console. (installed with a custom .MST file) | Manual | All | | 3. 7. Application Delivery This section defines the application delivery architecture within the MetaFrame environment. You should also document the different types of clients (OS version, location and available bandwidth and ICA Client compatibility) that you will need to support. To choose which ICA Win32 Client or Clients to deploy in your enterprise, decide how your end users will access published applications. If you are using MetaFrame XP in conjunction with Citrix NFuse, you can deliver application sets to users in two ways. (ICA Web client or ICA Program Neighborhood Client) The following is an example of an Application Delivery Design: | 3. 7. Application Delivery 3. 7. 1. Background NFuse brings a powerful user interface to the application deployment process. This interface uses Java object technology executed on a Web server to dynamically create an HTML-based presentation of the Citrix server farm for each user. Included in each users presentation are all of the applications published in the Citrix server farm for that user. NFuse is both a developers tool and a Web masters application. NFuse includes an API and an easy-to-use wizard. The API lets you create customized Web server scripts from scratch to meet the requirements of your environment, while the wizard creates scripts that you can use as is or modify according to the NFuse API. With NFuse, you are able to deliver a seamless interface between the user and their applications with little or no configuration on the client side. The following are just two of the advanced features leveraged by using NFuse 1.6: Ticketing secures user authentication by eliminating user credentials from the ICA files sent from the Web server to client devices. Tickets have a configurable expiration period and are valid for a single ICA session. After use, or after expiration, the ticket is invalid and cannot be used to access applications. You can use ICA files with tickets as an alternative to standard NFuse ICA files, which contain encrypted user credentials, using Basic encryption. ICA Client Detection and Installation. When a client device user visits an NFuse Web site, the Web-based ICA Client installation code detects the device and Web browser types and prompts the user to install an appropriate ICA Client. In the case of 16- and 32-bit Windows devices, Web-based ICA Client installation can also detect the presence or absence of an installed ICA Client and prompt the user if necessary. How NFuse Works The following diagram describes the interaction between the Citrix server farm, Web server, and ICA Client device: 
1. An ICA Client device user visits a login page and enters user credentials. The Web browser sends an HTTP request containing the credentials to the Web server. 2. The Web server reads the users information and uses the NFuse Java objects to forward that information to the Citrix XML Service on a designated Citrix server in the server farm. This designated server acts as a broker between the Web server and the Citrix server farm. 3. The XML Service on the designated server then retrieves from the farm, a list of applications that the user can access. These applications comprise the users application set. In MetaFrame XP server farms, the XML Service retrieves the application set from the Independent Management Architecture (IMA) system and Program Neighborhood Service, respectively. 4. The Citrix XML Service then forwards the users application set information to the NFuse Java objects running on the Web server. 5. The Web server uses the NFuse Java HTML containing links to the applications in the users application set. Each hyperlink in the HTML page points to a template file stored on the Web server. 6. This file serves as a template from which NFuse can dynamically generate ICA files. ICA files are text files containing parameters that configure ICA session properties such as the application, to run in the session, the address of the server that will execute the application and the properties of the window to display the application in. ICA files are written in .INI file format and have an .ICA extension. 7. The user initiates the next step by clicking one of the hyperlinks in the HTML page. The Web browser sends a request to the Web server to retrieve an ICA file for the selected application. 8. The Web server passes this request to the NFuse Java objects, which retrieve the template ICA file. The template file contains substitution tags. The Java objects replaces the substitution tags in the template ICA file with information specific to the user and desired application. The Java objects then send the customized ICA file to the Web browser. 9. The Web browser receives the ICA file and passes it to the client devices ICA Client. 10. The ICA Client receives the ICA file and initiates an ICA session with a Citrix server according to the ICA files connection information. Project Columbia (NFuse Portal) I dont know where to begin to tell you how great Project Columbia is. It makes your life deploying applications through the web as simple as one, two, and three. Project Columbia 6.0 is a sample NFuse 1.6 website that has been customized by Citrix technical support to address common configuration issues. The web pages included in project Columbia 6.0 are based on the default example site included with NFuse 1.6 but have been customized to implement additional features. 
The above picture shows the single sign-on to the portal, which interacts with multiple farms of varying version levels and operating systems. This initial page is load balanced for high availability. Once the user logs in, only the applications they have rights to run are shown. Program Neighborhood folders appear along with published applications. Project Columbia adds support for the following: Overriding the web servers default MetaFrame server farm address. Identifying multiple XML services per server farm for fault tolerance and load-balancing. Merging application sets from multiple server farms. Serving internal users and external users connecting through network address translation from the same web site. Altering the size and layout of application icons. Hiding applications or folders by name. Offering the user a menu of domains during logon. Routing ICA sessions through client-side SOCKS proxy servers. Routing users to multiple internal MetaFrame servers through a single external IP address using port address translation. Allowing users to change expired NT4 or Windows 2000 Active Directory domain passwords. Forcing the installation or upgrade of ICA clients to windows users who do not already have an ICA client installed or have an old ICA client installed. Support for Citrix Secure Gateway (CSG) The following requirements apply to the web server hosting the Project Columbia files: Windows 2000 with IIS 5.0 NFuse 1.6 Active Directory Services Interface (ADSI) 2.5 or later VBScript Scripting Engine 5.0 or later Active Server Pages 3.0 or later Project Columbia includes a file named config.txt, this is the file where you indicate your preferences regarding how the features of Columbia should be implemented. After making changes to the config.txt file, you must either restart the World Wide Web Publishing service or unload the ASP application in Internet Services Manager, then revisit the web site. You can use the ICA Win32 Web Client with NFuse to publish links to applications into a Web page on your corporate Intranet or the Internet. Users run a standard Web browser to access the Web page that contains the links to their applications. The Web Client includes the engine needed to launch published applications. Program Neighborhood Agent You can also use the ICA Win32 Program Neighborhood Agent with NFuse to push links to applications directly to users Windows desktops. Because users do not run a Web browser to view a Web page, accessing remote applications is just like accessing local applications.
Program Neighborhood If you do not want to deliver applications using NFuse, publish the applications for direct access. To directly access applications published on MetaFrame XP servers, users launch the ICA Win32 Program Neighborhood Client to browse for application sets or create custom ICA connections to Citrix servers or published applications. Remember this could add client configuration requirements. 3. 7. 4. Requirements DABCC.COM would like to simplify and streamline the process of deploying applications to the end-users. The deployment design is required to be the most cost effective design possible while keeping with Citrix MetaFrame XP best practices. 3. 7. 3. Recommendations It is recommended for DABCC.COM to implement Citrix NFuse 1.61. This will allow DABCC.COM the ability to integrate and publish interactive applications into any standard Web browser. This will also allow for rapid ICA Client deployment no matter the client operating system. It is recommended for DABCC.COM to deploy Project Columbias sample NFuse site. This will allow DABCC.COM to take advantage of twenty plus advanced features with very little development needed. It is recommended for DABCC.COM to implement multiple Internet Information Servers (IIS) running Project Columbia sample NFuse site. This will allow DABCC.COM to achieve high availability for client application requests. | 4. Network Design The Server Design section consists of the following five sections: File Storage Logon Scripts Network Modifications 4. 1. File Storage In this section you will want to define the file storage architecture required. In order to properly deploy MetaFrame, a number of network file shares are required for both application and user specific information. I highly recommend storing this data utilizing Microsofts Distributed File System (DFS). DFS gives you the ability to create a virtual file structure that always stays the same no matter the changes made to the servers and datas locations. Note: For more information on DFS please refer to: Distributed File System (DFS): Best Practices and Troubleshooting Guide. (http://www.dabcc.com\win2k\docs\Distributed File System - Best Practices and Troubleshooting Guide.doc) The following are the required shares needed for a MetaFrame installation: Terminal Services specific home directory (required) Terminal Services specific profile directory (required) ICA Client Update Configuration database (highly recommended) Installation Manager application packages (required for IM) System Policies (required for MetaFrame server that are not part of a Windows 2000 Active Directory domain. The following is an example of a File Storage Design: | 4. 1. File Storage In keeping with the vision of achieving a constant perception of a virtual workplace a number of file shares will be needed for the proposed MetaFrame XP environment. The following file shares will be utilized. | UNC Path: | Purpose: | | \\dabcc\dfsroot\imapps | Installation Manager Application Share | | \\dabcc\dfsroot\tsusers | Citrix users Home Directory | | \\dabcc\dfsroot\tsprofiles | Citrix users Profiles Directory | | \\dabcc\dfsroot\icadatabase | Citrix Client Update database | | \\dabcc\dfsroot\tspolicies | Citrix specific policy share for MetaFrame server who are members of Windows NT 4.0, workgroup and or Novell Netware environments | | | |
| 4. 2. Logon Scripts The section defines any changes needed to the logon scripts and the reasons why. During the Infrastructure Assessment section you would have analyzed any existing login scripts and if you think any changes are needed you will want to document here. Also if you will be implementing any drive mappings, environmental variables and or any other changes, you will want to document them here. The following is an example of a Logon Scripts Design: | 4. 2. Logon Scripts No modification will be made to DABCC.COM current logon scripts. | 4. 3. Network Modifications This section defines the changes needed within the existing environment in order to successfully scale and support the proposed MetaFrame solution and beyond. This would include the following: Define any physical environment changes needed such as use of servers, hubs, switches in the proposed environment Define any network drives letters that will be utilized and their purpose. The following is an example of a Network Modifications Design: | 4. 3. Network Modifications Keeping with the key points of the project vision, DABCC.COM will be implementing the following network modifications. 4. 3. 1. Existing Infrastructure Modifications The following ports on the Cisco Catalyst 2948G-L3 switch will be utilized for the four proposed MetaFrame servers. | Ports | Device | | 9 | DB2KCX1 | | 10 | DB2KCX2 | | 11 | DB2KCX3 | | 12 | DB2KCX4 | 4. 3. 2. Client Drive Mapping Client drive mapping is just one of the features of MetaFrame XP that you will need discuss with you customer and decide how you will be working with the client drives. Client drive mapping is built into the standard Citrix device redirection facilities and the client drives appear as a network type (Client Network) in Network Neighborhood. The clients disk drives are displayed as shared folders with mapped drive letters. These drives can be used by Windows Explorer and other applications like any other network drive. By default, the drives on the client system are all automatically mapped. If the MetaFrame servers drives were not remapped during installation of MetaFrame then the client drives will, by default, start with V$ and continue mapping all available client disk drives and CDROMS in ascending order. If they were remapped then the client drives will start with C$. The client drive letter is a configurable setting via the servers registry. (this is a per server setting, so if you choose to change the default drive letter then you will need to make the change on all your MetaFrame servers) Remember if you configure MetaFrame to automatically auto-create drive then you will need to make sure enough drive letters are available. You are able to disable client drive mapping and map client drives manually through the Client Settings dialog box of a selected ICA connection in the Citrix Connection Configuration Utility. The Connection options control whether drives are mapped to client drives. If this option is cleared, the devices are still available but must be mapped to drive letters manually. 
The following networks drives will need to be created: | Drive Letter | Purpose | | X: | Root Drive | | Y: | Terminal Server specific user home directory | | V: | Client C: drive (if available) | | U: | Client D: drive (if available) | | 5. Design - Checkpoint Now that you have completed the Design phase you are ready to present your recommendations to your customer in the form of a design document. At this point your customer can choose to continue with the project or bow out gracefully. In this case he still has gained a considerable understanding of his environment as well an architectural design for his future MetaFrame deployment. In both cases you walk away with a considerable amount of service revenue as well as the experience you gained. You will find the following Design Phase examples and templates located in Methodology in a Box 1.0. (MIAB1.0.ZIP) | Path \ Filename | Description | | \Examples\EXAMPLE Design Phase Deliverable.doc | Example of a Design Phase Deliverable. | | | | | Templates\TEMPLATE Design Phase Deliverable.doc | Microsoft Word template file for a Design Phase deliverable. | |