What a weird section title, huh? Let's try to figure out what this means. In the early days of MetaFrame, people were happy with the fact that they could publish applications and that users could connect to "applications" instead of connecting to "servers."
However, the way that people use MetaFrame has evolved in the past few years, causing MetaFrame itself to evolve. A big piece of this evolution has to do with how users access files and content.
Now that MetaFrame has become a large part of many environments, there is a need to integrate it even more with users' everyday activities. In many organizations, users have grown accustomed to using NFuse or Program Neighborhood as their main "launching point" into their computing environment. Users use MetaFrame everyday to launch their applications. Wouldn't it be great if they could also use that same launching point to get access to network shares, important memos, or corporate training videos?
Additionally, there are situations in which you might want a user to be able to double-click a file on their local desktop computer and have that file open up via a remote MetaFrame session. Just imagine the possibility of allowing any user to be able to open any file of any type. Perhaps you could install applications like Microsoft Visio, MapPoint, and Project on MetaFrame servers. Then, a user receiving a Visio drawing via an email attachment (on their local computer) could just double-click that attachment and (without Visio being installed locally) have the drawing be opened by Visio via a remote Citrix ICA session. You would never have to worry about installing rarely-used applications for users ever again!
Maybe for you the opposite is also true. Perhaps you've chosen to deploy Microsoft Outlook via MetaFrame XP. What if a user receives an email that contains a hyperlink to a website? By default, when the user clicks on that hyperlink a copy of Internet Explorer will be launched on the MetaFrame server. Your user would then be using your expensive MetaFrame server to surf the web. Wouldn't it be great if there was a way to force the user to use their local web browser, even if the user clicks a hyperlink from within a MetaFrame session?
All of these "what if's?" are possible with MetaFrame XP today. As an administrator, you have the ability to decide what types of files are opened where by which users. How's that for flexibility? Let's look at what it takes to make this happen.
If you're using Feature Release 1 or 2, you can publish content in addition to publishing applications. Publishing content allows you to make computer files available to end users through the standard Citrix ICA client tools such as Program Neighborhood, NFuse, or the Program Neighborhood Agent. When users click on an application icon for published content, the content is opened with their local client device.
For example, in addition to several published applications, you could publish an FAQ document with information for your users about your Citrix server farm. That document would appear to users in the published application list along with any other published applications. If a user clicked on the published document, it would open on the user's computer just like a standard document.
In fact, if you publish content and your users access their applications via NFuse and a web server, the published content acts just like a hyperlink to any standard file, such as documents, videos, or MP3's. The advantage to providing the file via MetaFrame XP's "published content" function is that users can access the content through their standard ICA client methods of access, and you can set the permissions of the content just like you can on any published application. Users will never see the icon for content without the proper permissions.
You publish content just like you publish any other ICA application. To do this, select the "publish content" option in the application publishing wizard that is launched when you begin publishing anything via the Citrix Management Console. When you publish content you need to specify its location. You can specify a whole directory or a single file. Either way, you need to specify the content location in the HTTP address format, such as https://www.brianmadden.com, ftp://www.brianmadden.com/document.doc, or file://server1/share/document.doc.
Advantages of Publishing Content
- Access to files (content) can be controlled like any published application.
- Users can access non-Citrix content through familiar ICA client interfaces.
Disadvantages of Publishing Content
- The content viewers for each type of content must be installed locally on the client devices.
- If you are making published content available via a web server, then you must configure the MIME types for each type of content that you want users to be able to open automatically.
- Feature Release 1 or 2 is required.
- Published content only appears as part of an application set, either via Program Neighborhood or a web portal. This means that you cannot create a custom ICA connection to a published content item.
Client to Server Content Redirection
Traditionally, one of the biggest problems users face when their applications are loaded on MetaFrame servers instead of their local computers has to do with content (or file) redirection. To understand this problem, let's look at how it happens. Imagine an environment where Microsoft Word is available to end users via a published application on a MetaFrame server. Users with Windows desktops will undoubtedly find Word documents that they want to open while they are browsing the network or their local computers. In traditional environments, the user can simply double-click the document and Word is automatically launched with that document open.
In the MetaFrame XP world, it's not quite that simple. If Word is not installed on a user's workstation then the ".doc" file type extension is not associated with Word on that workstation. Even if the user uses Word on a MetaFrame server, double-clicking a ".doc" file on the workstation will probably just open a local copy of WordPad with an error that says that the document type is not registered.
In order to combat this, you could manually register the ".doc" file type association so that it launches the Word published application when a ".doc" file is double-clicked. While this would work for launching Word, it still wouldn't be a full solution because Word would not automatically open the file that the user clicked. This means that the user would have to manually browse back to the location where the file was located and open it from Word within their ICA session.
The solution to this is for the user's workstation to be configured so that when they click on a ".doc" file it opens a remote session of Word and passes the path of the file to the server so that Word can open that file.
There are actually a few different ways that this can be addressed. The exact method that you use will depend on which Feature Release you are using and how your ICA clients are configured.
Content Redirection Using Feature Release 1 or 2
If you're using Feature Release 1 or 2, then you'll be happy to know that the MetaFrame XP product has been extended to "officially" support a solution for this problem. To implement this content redirection, you need to configure both the MetaFrame XP published application and the Windows client device.
With Feature Release 1 or 2, MetaFrame XP supports client to server content redirection by adding the ability for an ICA client to pass the path of a file to a published application via a command line parameter. This is known as "parameter passing." The use of parameter passing to published applications is enabled by adding a ""%*"" to the command line of the published application. This is similar in concept to the way that Windows supports parameter passing by adding a "%1" to a command line. To enable parameter passing for a published application, all you have to do is add the ""%*"" to the end of the published application's command line via the Citrix Management Console. (Note that you need to add the quotes when you type this into the CMC, so you end up adding a space-quotes-percent-asterisk-quotes to the end of a published application's command line.)
For example, if you have a published application called "Microsoft Word" with the command line m:\program files\microsoft office\office10\winword.exe, you would enable the parameter passing by changing the command line to m:\program files\microsoft office\ office10\winword.exe "%*".
You can add the ""%*"" parameter to the end of any published application. Then, if the ICA client passes parameters, the MetaFrame XP server dynamically replaces the ""%*"" with the actual parameters. If the client does not offer any parameters, the server ignores the ""%*"".
Once you configure your MetaFrame XP servers to support the extended parameter passing, you need to configure your client devices. To do this, you need to change the file associations of the three-character file extensions for each type of file that you want to pass to a MetaFrame XP server. Usually, file type associations are configured so that they open an application that can read the file. For example, when a user double-clicks on a ".doc" file, their local computer knows to launch Microsoft Word and open the file that they double-clicked. However, when you're using extended parameter passing to open MetaFrame XP applications, double-clicking a ".doc" file needs to do three things:
- Launch the local ICA client software.
- Instruct the ICA client software to connect to a published application (Microsoft Word in this case).
- Tell the published application to automatically open the file that the user just double-clicked.
To do this, you need to add the file type association. (Windows Explorer | Tools Menu | Folder Options | File Types Tab | New) For example, you can configure the ".doc" file type to open a "Microsoft Word" published application by associating the ".doc" file extension with the command line c:\Program Files \Citrix\ICA Client\pn.exe /pn:YourAppSetName /app:Microsoft Word /param:"\\client\%1". The "app" command line switch instructs pn.exe to launch the specified published application. The "param" switch instructs it to attach the enclosed parameter to the tail end of the command to launch the application. In this case, the "%1" is the standard Windows command-line parameter passing variable. If you wanted to, you could add any parameters you wanted after the "param" switch.
This example assumes that the user is using the full Program Neighborhood client, which is launched with "pn.exe." If you use this client then your users must connect into the server farm via their local Program Neighborhood at least once so that the ICA client can build a list of published applications that are available. If the user does not connect first then the published application will not be found. Alternately, you may need to use "wfica32.exe" or "wfcrun32.exe" depending on your ICA client options. (See Chapter 10 for details.) No matter which client executable you need to use, you can get the command-line syntax by typing the client executable followed by a "/?" at a command prompt.
Content Redirection with Feature Release 2
In addition to the method of content redirection outlined in the previous section, there is one more option that you have if you're using Feature Release 2.
One of the problems with the type of content redirection mentioned previously is that you have to manually configure every ICA client device's file type association for each type of file that you want them to open via a MetaFrame application.
If you're using Feature Release 2, you can actually configure file type associations via the Citrix Management Console. These file type associations are then used by all ICA PN Agent clients.
Does this sound too good to be true? In a way, it is. The list of requirements you need to meet in order for Feature Release 2's "automatic" content redirection is pretty steep. These requirements include:
- You must use Feature Release 2.
- Users must use the "Program Neighborhood Agent" ICA client. (See Chapter 10 for details on the PN Agent.)
- Your users must access MetaFrame via NFuse Classic.
- You must enable client drive mapping.
There is really no way around these requirements. This is because the PN Agent client works by pulling all of its configuration information from a central location, so it's easy for a MetaFrame XP server to modify the properties of the ICA client to force them to pass the full path of the file that was clicked. Client drive mapping is how the published application finds the file.
You can enable this type of content redirection on an application-by-application basis. When FR-2 is used, you are presented with a "Content Redirection" screen during the initial application publishing process. (A "Content Redirection" tab has also been added to the published applications' properties page.) From here, you can select a checkbox next to each file extension that you would like redirected to this published application for your PN Agent users. Checking this box does two things:
- If it's not there already, it appends the ""%*"" to the end of the published application's command line setting.
- It modifies the PN Agent configuration file to have the ability to recognize that a type of file extension should now be used to open an application on a remote MetaFrame XP server.
For this to work, you need to import the file types from the registry (CMC | Right-click the server | Update File Types from Registry).
Advantages of FR-2's Content Redirection
- It's easily applied to all users.
- It's easy to turn on or off.
Disadvantages of FR-2's Content Redirection
- The requirements are pretty steep.
Content Redirection without Feature Release 1 or 2
All of that ""*%"" stuff we just talked about is only available if you're using one of the Feature Releases for MetaFrame XP. If you're not using a Feature Release then you'll have to configure content redirection the old-fashioned way.
There are several steps that you must take in order to configure file type association content redirection without using a Feature Release. What's interesting here is that the fundamental process used is conceptually identical to that of a Feature Release. The only difference is that you need to configure everything manually when you're not using a Feature Release.
In order to understand how this configuration must be done, let's step through an example. This example is for Microsoft Word, but you can use these techniques for any application.
1. Create a batch file that is in a publicly accessible network location, such as \\server\share\LaunchWord.bat.
The batch file should look like this:
(the next three lines are one line that is wrapped)
echo n:\Program Files\Microsoft Office\Office10\
winword.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 > p:\OpenFile.bat
pn.exe /app:"Microsoft Word"
As you can see, there are two drive letters used in this batch file, N: and P:. The N: drive and path is the application's installed directory on the MetaFrame XP server. The P: drive is the user's personal home drive. This P: drive can be a network share or part of the user's local profile. The exact location of the P: drive is unimportant. What is important is that the P: drive is accessible only by the current user.
2. Create a published application on your MetaFrame XP server to run p:\OpenFile.bat.
3. Create an association on your user's local workstation for .doc files that runs the batch file from the network location in step 1.
Then, when the user double-clicks a ".doc" file on their local computer, it will run the batch file from step one (since you configured the file type association in step 3). The batch file will dump the command to start Word and the document path into a new batch file on the user's home drive and it starts the ICA connection to the published application. That published application runs the new batch file on the MetaFrame XP server (as configured in step 2).
The %1 %2 .. %9 in the command line allows this to work if there are spaces in the document path. If you only had a %1, then the code would stop dumping the path if it encountered a <space> character. For instance, if a user's file is in the folder "c:\My Documents," this code would input "c:\My" into the OpenFile.bat. Extending to %9 allows for nine spaces in the path and file name.
The pn.exe /app:"Microsoft Word" command instructs the local ICA client software to connect to the "Micrsoft Word" published application. If you go to the command prompt and type, pn.exe /? you will see that there are many options. You can specify custom .INI files, and create a custom appsrv.ini file that pointed to the right server farm. You could put this .INI file in the same public location as the batch file.
Lastly, you might need to change the batch file to run pn.exe from the proper path, or add the path of it to your client's "PATH" statement. By default, pn.exe is in the \Program Files\Citrix\ICA Client\ directory.
Server to Client Content Redirection
Now that you understand how content redirection can help users to launch applications on remote MetaFrame servers, let's look at how users can click on content from within their MetaFrame XP sessions that is launched on their local client workstations.
If you're using Feature Release 2, you can configure your MetaFrame XP servers to allow users to click on certain kinds of links and have the content open on their local client workstations instead of on the MetaFrame server. In probably 99% of all cases this configuration has one purpose-to prevent users from surfing the web on MetaFrame servers.
In order to enable content redirection in FR-2, all you need to do is check a box in CMC. You can enable this on a farm-wide basis (CMC | Right-click on server farm | Properties | 'MetaFrame Settings' tab | check 'Enable Content Redirection from Server to Client') or on a server-by-server basis (CMC | Right-click on server | 'MetaFrame Settings' tab | 'Content Redirection from Server to Client' section | Uncheck 'Use farm settings' | Check 'Enable Content Redirection from Server to Client').
Once content redirection is enabled, whenever a user clicks an HTTP link the web page is opened on their client browser.
Server to client content redirection has several requirements:
- You must use Feature Release 2.
- Only Win32 and Linux clients are supported.
- Only HTTP, Real Media, QuickTime, and Windows Media types of content are supported.
- The application containing the hyperlink must "properly" use the Windows shell to launch a web browser. Interestingly, Microsoft Office does not properly use the Windows shell to launch a browser. Instead, it calls IE directly. (This is probably why Microsoft is experiencing a little legal problem with IE integration.) Server-to-client content redirection does not work from within Microsoft Office.