- Targets Overview
- Isolating Services
- Managing Isolation Environment Rules
- Preparing a Workstation for Profiling Applications
- Profile Contents on the Server
After you create and store an application profile on a file server, the profile consists of directories and subdirectories of files. For your reference, this topic describes the structure of profile directories and the files in them. Citrix recommends that you do not modify these files directly.
Use the profiler to modify the contents of the profile folder:
For example, if you create a profile called PDF Viewer with a single target, the profile, a folder called PDF Viewer, has contents similar to the following on the file share:
The manifest (.profile) is the top file in the data structure that defines a profile. The manifest file is an XML-formatted text file that describes a profile. Manifest files have the file extension .profile.
The information in a manifest file includes:
The manifest file of a profile created for inter-isolation communication includes references to the subprofiles and may or may not have targets listed in the manifest file.
Each target consists of a set of files representing a compressed subdirectory structure within the profile structure.
Target file names are based on the target GUID and version. The association to a user level concept, such as “MS Office,” comes from the profile manifest.
Each time a target is created, it is assigned a GUID so it can be uniquely identified and independently cached on the user device. The GUID is used to set the name of the isolation environment so that no two different installations of the same named target occupy the same location in the execution system cache. The directory used to store the isolation environment on the user device also includes the version number of the target. In this way, when you update a target, user devices are assured that the execution InstallRoot accurately reflects the install root of the target you defined. For speed, the user device locally updates the internal file cache when a target version is updated rather than reloading from the server.
If a profile is copied (including its targets), the GUID is unchanged. If a profile is new (when you use save as), the new profile has new targets, and new GUIDs are assigned for the targets in that profile. Use them to maintain each profile separately without conflicts if you update either one.
You have the option of digitally signing the contents of a profile. The manifest file indicates if the profile is signed, and when signed, the manifest file is digitally signed to sign the entire profile. The hashes for all files in a target are stored in a single file, Hashes.txt.
The SHA-256 of the Hashes.txt file in the profile is stored in the manifest, and the SHA-256 hash of each target in the profile is stored in the manifest. Because the manifest file is digitally signed, the SHA 256 of each file listed in each Hashes.txt file can be authenticated.
To keep the manifest file size small, the binary data that represents the application icons is stored in a separate file called icondata.bin. The profiler stores all icons for the installed application. When you publish the streamed application, you have the option to change the icon by choosing among the set of icons that the application installed or other icons that you prefer.
Specify when the Citrix Offline Plug-in should execute scripts associated with a profile or target:
Intermediate applications executed from a profile do not invoke pre-launch or post-exit scripts.
Scripts are commonly .CMD files, but can be any file that Windows can execute. Create pre-launch and post-exit scripts independent of the profiler, and after creating a script, use the profiler to add the script to a target, including these settings:
When you add a script to a target, the profiler copies the script file to the profile. The profiler also retains the original file name of the script.
If an .EXE script requires a .DLL file, add a script for the .DLL file and disable it. The .DLL file is available for the script to load, but the user device does not run the disabled .DLL. For example, use this technique to add a signed .DLL to the profile even though it is not executed.