|
| The design phase is where you utilize the information obtained during the analysis phase to design the layout of your MetaFrame network. In designing the network, you should stick to 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 q Hardware Requirements q Operating Systems Requirements MetaFrame Design q Farm Design q Zone Design q Data Collector Design q Data Store Design q Load Management Design q Applications q Applications Delivery q Printing Architecture Network Design q File Storage q Logon Scripts q Network Modifications Note: It is important to remember that the following examples are just examples and every design is going to very depending on the project vision on client environment.
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: q Server Requirements q MetaFrame Design q 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 than any value it may add. Therefore, it is important to carefully analyze and justify the structure required before beginning. 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 user 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 were not currently attainable. Below is a diagram of the planned native MetaFrame XP architecture: 
| 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 | The question that is asked for every project is What kind and/or how many Citrix servers do I need? This is a touchy subject and it 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 will probably 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. 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 as follows: 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 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 best 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 | | | | | | |
| Note: Citrix does not recommend any particular hardware vendor. This would be driving by the customers preference and or corporate standard.
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 the 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 | $4,085.00
| $4,085.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 | | $6,215.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: | | | | | | | | | | | | | | | | | | | | | | | | | |
| 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 should plan to conduct 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 thousands of users, new 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. |
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, several factors concerning hardware, database performance, and network congestion 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 q Pooled licenses All MetaFrame XP licenses are pooled together and can be used by all servers in the farm. q Simplified management and administration Citrix administrators only need to log in to one farm for all maintenance and administrative tasks. Multiple Farms q 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. q 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. q 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. q 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. q 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 q 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 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. q The data collector in each zone can support up to 70 resolutions per second. q 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, consider the cost of placing separate zones at each WAN point. 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. Therefore, 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. |
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 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. q The data collector in each zone can support up to 70 resolutions per second. q 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 to four additional servers for eight total 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. |
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. Microsoft 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 Microsoft 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, ensure 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 period 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, designed with 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. DABCC.COM should 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. Additionally, DABCC.COM should 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. |
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, DABCC.COM should implement a single MetaFrame XP farm. |
In this section, you will want to document the applications that will be deployed, how they will be installed (Image, Manual or Installation Manager (IM)), the server(s) to be installed on and who will have access to them. I recommend classifying applications in to the following three categories. Image I classify image applications as applications that are going to be installed on all servers for the lifespan of the farm. i.e., WinZip. Be very careful when deciding upon image applications you will need to remember that this application will be embedded in to the image, hence the possibility for future conflicts. Manual I classify manual application as applications that will be manually installed and uninstalled on the selected server(s). I recommend utilizing Installation Manager for a constant, scheduled, tested install but some applications just does not like to be packaged for whatever reason. This is when you install them manually. Installation Manager I classify IM applications as applications that will be packaged, installed and uninstalled on the selected server(s) using Installation Manager 2.0. Note: I will be adding an Installation Manager section in the next release of this document. So in the mean time to learn more about IM please visit the Installation Manager Administrators Guide You will also want to define which applications are installed on each server and who will have access to them. The following is an example table of published applications information: | 3. 6. Applications DABCC.COM would like to install and publish the following applications to the new MetaFrame XP Farm. The application data will be moved to Distributed 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: | Users: | | Adobe Acrobat | \\dabcc.com\dfsroot\apps\acrobat\setup.exe | IMAGE | All | | | Adobe Acrobat | C:\program files\adobe\reader.exe | Published Shortcut | All | CTX Users | | Exchange Admin | Loaded from Exchange 2000 CDROM | Manual | DB2KCX1 | | | Exchange Admin | \\dabcc.com\dfsroot\apps\tools\ exchadmin.cmd | Published Shortcut | DB2KCX1 | Exchange Admins | | Symantec Corporate Edition Antivirus 8.0 | \\dabcc.com\dfsroot\apps\smantecav\setup.exe | Manual | All | | | | | | | | |
| | | | | |
| | | | | | Microsoft Office XP | \\dabcc.com\dfsroot\apps\officexp\setup.exe TRANSFORMS=\\dabcc.com\dfsroot\apps\ officexp\trmsrvdabcc.mst | Manual | All | | | Excel 2002 | C:\Program Files\Microsoft Office\Office10\ Excel.exe | Published EXE | All | MS Office XP Users |
Word 2002 | C:\Program Files\Microsoft Office\Office10\ Winword.exe | Published EXE | All | MS Office XP Users | | Outlook 2002 | C:\Program Files\Microsoft Office\Office10\ outlook.exe | Published EXE | All | MS Outlook XP Users | | PowerPoint 2002 | C:\Program Files\Microsoft Office\Office10\ powerpnt.exe | Published EXE | All | MS Office XP Users | | Access 2002 | C:\Program Files\Microsoft Office\Office10\ msaccess.exe | Published EXE | All | MS Office XP Users | | WinZip 8.0 | \\dabcc.com\dfsroot\apps\winzip8\setup.exe | IMAGE | All | | | WinZip 8.0 | C:\Program Files\Winzip\winzip32.exe | Published EXE | All | CTX Users | | http://www.dabcc.com | DABCC.COM Web Site | Published Content | CTXUsers | N/A | | Note: The above example is in no may a reflection upon an endorsement of any particular application or combination of applications. You will always want to verify application compatibility and this is where the art of installation becomes a challenge in any MetaFrame deployment.
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 Classic / Citrix Secure Gateway (CSG), you can deliver application sets to users in three 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 Classic with Citrix Secure Gateway brings a powerful user interface to create a secure 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 Classic is both a developers tool and a Web masters application. NFuse Classic 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 Classic 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 Classic 1.71: q 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. q 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. Citrix Secure Gateway for Windows, Version 1.1, is a component of MetaFrame XP Feature Release 2. Secure Gateway is designed to work with NFuse Classic to provide a single, secure, encrypted point of access through the Internet to MetaFrame servers on internal corporate networks. Whether Secure Gateway is used for internal or remote access, the service transparently encrypts and authenticates all ICA connections to protect against data tampering and theft. A typical Secure Gateway deployment involves the interaction of five Citrix components: A client device with an ICA Client, Version 6.30 or later, installed A Citrix NFuse server A Secure Gateway server An STA server A Citrix MetaFrame server(s) with at least one of them running the XML service How NFuse Classic and Citrix Secure Gateway (CSG) Works 
The following details how communications take place between Citrix Secure Gateway components before a secure connection is established between a remote user and a MetaFrame server. 1. A remote user uses a Web browser to access a Web page on an NFuse server. The NFuse server requires the user to authenticate using valid user credentials. 2. NFuse uses the user credentials to contact the Citrix XML Service running on a MetaFrame server, and obtains a list of applications that this user is authorized to access. NFuse populates the Web page with the list of published applications that the user is authorized to access. The communications so far are the normal sequence of events that occur when an NFuse server is deployed to provide ICA Client users with access to published applications over the Web. 3. When the user clicks a published application link, NFuse sends the IP address for the requested MetaFrame server to the STA and requests a ticket for the user. The STA saves the IP address and issues the requested ticket to NFuse. 4. NFuse generates an ICA file containing the ticket issued by the STA, and sends it to the client browser. Note that the ICA file generated by NFuse contains only the FQDN or DNS name of the Secure Gateway server. The address of the MetaFrame server(s) that the ICA Client eventually connects to is never exposed to the client. 5. The Web browser uses the ICA file to launch the ICA Client. The ICA Client connects to the Secure Gateway using the FQDN or DNS name in the ICA file. Initial SSL/TLS handshaking is performed to establish the identity of the Secure Gateway server. 6. The Secure Gateway server examines the ticket from the ICA Client and uses information contained in the ticket to identify and contact the STA for ticket validation. If the STA can validate the ticket, it returns the IP address of the MetaFrame server on which the requested application resides. If the ticket is invalid, or has expired, the STA informs the Secure Gateway server and an error message appears on the client device. 7. On receipt of the IP address for the MetaFrame server, the Secure Gateway server establishes an ICA connection to the MetaFrame server. When the ICA connection is established, the Secure Gateway server encrypts and decrypts data flowing through the connection. Program Neighborhood Agent You can use the ICA Win32 Program Neighborhood Agent with NFuse Classic 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. You can also use Client to Server Content Redirection that will allow you to open local files with MetaFrame published 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 secure design possible while keeping with Citrix MetaFrame XP best practices. 3. 7. 3. Recommendations It is recommended for DABCC.COM to implement Citrix NFuse Classic 1.71 with Citrix Secure Gateway 1.1. 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. DABCC.COM should implement multiple Internet Information Servers (IIS) running NFuse Classic 1.71. This will allow DABCC.COM to achieve high availability for client application requests DABCC.COM should implement multiple Windows 2000 Servers running Citrix Secure Gateway services to achieve high availability for secure client to server requests. DABCC.COM should also implement multiple Windows 2000 Servers running Citrix Secure Ticket Authority service to achieve high availability for secure client to server requests. |
In this section, you will want to define the printing architecture that is required. In order to keep with the goals of high user perception you will want to define clear objectives for both the project and for the customer. These objectives with consist of the following: Gathering a list of printers that will be supported on go-live day this is probably the most important step in any MetaFrame deployment and one that is over looked. You will need to require a list of printers to be supported from the customer and a date for completion. You will not be able to complete the Printer Architecture section until you receive it. You will also need to set the expectation that the supplied printers will be the ones supported and any additional printers might require additional configuring. Define how auto-created printers will be utilized you will need to define if you will be auto creating printers or not and if so then how. You will also need to include what local printers will be autocreated, i.e., local connected printers only. Define how network print servers will be utilized you will need to define any network print servers that will be imported and their attached printers. You will also need to define what users / groups are assigned to what printers. Define how the Universal Print Driver will be utilized you will need to define how the Universal Print Driver will be configured in the MetaFrame farm. Define policies and procedures for adding additional supported printers you will define the end-user procedures for reporting additional servers. You will also need to define the administration procedures for adding additional printers. | 3. 8. Printing Architecture 3. 8. 1 Background Users can print documents easily when they run applications on MetaFrame XP servers. For most users, printing when they use applications in ICA sessions is no different from printing from applications that run on their own computers. When ICA Client users run applications that are published on MetaFrame XP servers, they can print to the following types of printers: q Printers that are connected to ports on the users client devices on Windows, WinCE, DOS, and Mac OS platforms. q Virtual printers created for tasks such as printing from a PostScript driver to a file on a Windows client device q Shared printers that are connected to print servers on a Windows network q Printers that are connected directly to MetaFrame XP servers The printers that ICA Clients use can be categorized by connection types. You can set up three general types of printer connections in a MetaFrame XP server farm: client printer, network printers, and local printers. Client Printers The definition of a client printer depends on the ICA Client platform. On DOS-based and WinCE client devices, a client printer is physically connected by a cable to a port on the client device. A PC or Postscript printer connected to a serial port on a Mac OS system is also considered a client printer. On 32-bit Windows platforms (Windows 9x, Windows NT, and Windows 2000), any printer that is set up in Windows (these printers appear in the Printers folder on the client device) is a client printer. Locally connected printers, printers that are connected on a network, and virtual printers are all client printers. Some virtual printers, such as a fax/modem device that is set up in the Printers folder, might not be available as a client printer in ICA sessions. MetaFrame communicates with local (LPT) printers through the ICA protocol. You can limit the amount of ICA protocol bandwidth it can use on a user and or group basis. Local Printers Printers that are connected directly to MetaFrame XP servers are local printers within a particular server farm. This definition includes a printer that is connected to the MetaFrame XP server that hosts a users ICA session, as well as printers that are connected to other MetaFrame XP servers in the same server farm. Network Printers Printers that are connected to print servers and shared on a Windows network are referred to as network printers. In a Windows network environments, you can configure MetaFrame to import network printers and assign the attached printers on a user and or group basis. MetaFrame communicates with network printers directly via a TCP/IP connection. Universal Print Driver The Citrix Universal Print Driver eliminates the need for many native printer drivers to be installed on every MetaFrame XP server in a server farm. The Universal Print Driver feature comprises the following two components: The Citrix PCL4 Universal Driver, a standard PCL4 printer driver that is used on all MetaFrame XP servers. A PCL4 interpreter and rendering agent that is integrated into the ICA Win32 Client. Version 6.20 or later of the ICA Win32 Client is required. When using this feature, the user prints from an application and the Citrix PCL4 Universal Driver on the server generates a print job in PCL4 format. The server sends the PCL4 print job to the ICA Client, where the PCL4 interpreter renders the print job. The client uses the local printer driver and print services to output the rasterized print job on the client printer. The PCL4 interpreter in the ICA Client rasterizes print pages in monochrome at 300 dots per inch (dpi) resolution. The universal driver feature works with any client printer, including PCL, PostScript, and Windows printers. Color images can be printed in grayscale (dithered black and white) on color printers. The PCL4 interpreter does not support special printer options or features such as duplex printing. 3. 8. 2 Requirements DABCC.COM has defined reliable printing from any application to both local and remote devices as a design goal. Keeping to that goal, DABCC.COM requires the ability to print from local print devices and network print servers. DABCC.COM required the following printers to be supported on go live day and understand that any additional printers might require additional configuration. DABCC.COM requires the creation of policies and procedures to add printers to the supported list. 3. 8. 3 Recommendations It is recommended for DABCC.COM to configure the MetaFrame XP printing architecture as following: Client Printers It is recommended for DABCC.COM to enable autocreation of client LPT printers only. All other printers will be assigned as network printers. It is recommended to assign autocreation of printers of a user-by-user basis. Local Printers DABCC.COM will not be utilizing local MetaFrame printers. Network Printers It is recommended for DABCC.COM to import print servers network print servers and assign then on a user-by-user basis. This gives DABCC.COM the ability the assign network printer to user and cut down at bandwidth. Universal Print Driver It is recommended for DABCC.COM to configure the Citrix Universal Print Driver to be used only when a native print driver is unavailable. Procedures for adding additional printers DABCC.COM administration staff will be required to be proactive maintaining printer compatibility. | The Server Design section consists of the following five sections: File Storage Logon Scripts Network Modifications 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 server and data 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 | | | |
| 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. In addition, 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. |
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. Define any user / group accounts that will need to be added and or edit 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 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 can configure client drive mapping farm wide or with the release of MetaFrame XP with Feature Release 2 you can configure on a user / group basis. The following networks drives will need to be created: | Drive Letter | Purpose | | X: | Root Drive (this drive will be hidden from the users view | | Y: | Terminal Server specific user home directory (this drive will be hidden from the users view) | | V: | Client C: drive (if available) | | U: | Client D: drive (if available) | 4. 3. 2. User/Group Modifications The following user / groups will need to be added to the DABCC.COM domain in order for proper functionality of the proposed MetaFrame XP farm. | User / Group Name | Purpose | | CTX Admin | MetaFrame Full task administrators | | CTX Admin (Read-Only) | MetaFrame view-only administrators | | CTX Users | All MetaFrame Users | | CTX Office XP Users | MetaFrame Office Users | | CTX Outlook Users | MetaFrame Outlook Users | | CTX Visio Users | MetaFrame Visio Users | | CTX Client Access Users | MetaFrame IBM Client Access Users | | CTX Notes Users | MetaFrame Notes Users | | CTX Users (High Bandwidth) | Used to tweak MetaFrame for high bandwidth | | CTX Users (Low Bandwidth) | Used to tweak MetaFrame for low bandwidth | | CTX Server to Client Redirection Users | Server to Client Content Redirection Users Group | | CTX IM | Installation Manager Service Account | The following will be added to the Terminal Services Profile tab of every domain account the will be logging in to the MetaFrame farm. | \\dabcc\dfsroot\tsprofiles\%username% | Added to the User Profile section | | \\dabcc\dfsroot\tsusers\%username% | Added to the Terminal Services Home Directory section | | | |
| 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 have gained. You will find the following Design Phase examples and templates located in Methodology in a Box 2.1. (MIAB2.1.ZIP) | Path \ Filename | Description | | \Examples\EXAMPLE Design Phase Deliverable.doc | Example of a Design Phase Deliverable. | | | | | Templates\TEMPLATE Design Phase Deliverable.dot | Microsoft Word template file for a Design Phase deliverable. |
This page left blank of purpose |