Resolving The Problem

Follow these instructions to install and configure WebSphere Integration Developer to run on Citrix Presentation Server:

1. When you install WebSphere Integration Developer on the server, ensure that you are logged on as a user with Administrator access.
   
   
2. After installing, ensure that the install directory is read-only. This is the product directory, not the shared install directory. This step will ensure that the configuration information is written in the home directory. If this measure is not taken, all users will end up using the same location for their configuration area, which is not supported.
   
   Note: Ensure that client users are granted write permission of the following directory otherwise the UTE server status cannot be detected:
   
   

<WID_install_root>\runtimes\base_v61_stub\

3. When launching WebSphere Integration Developer from a client, the workspace is created in a directory specified by the user.
   
   
4. In order to use the servers in the test environment, a profile is required for each non-root user. The product installer (who can be a root/Administrator or non-root user) can grant write permission to the appropriate WebSphere Process Server files and directories to other non-root users. The non-root users can then create profiles. Alternatively, the product installer can create a group for users who are authorized to create profiles or give individual users the authority to create profiles. The following example task shows how to create a group that is authorized to create profiles.

1. Log on to the WebSphere Integration Developer system as the product installer (the product installer can be a root/Administrator or non-root user).
   
   
2. Using operating system commands, do the following:
• Create a group named profilers, which will contain all users who can create profiles.
• Create a user named user1, who can create profiles.
• Add users product_installer and user1 to the profilers group.
  
  
3. Log off and log back on as the installer to pick up the new group.
   
   
4. As the product installer, use operating system tools to change directory and file permission's.
   
   The following example assumes that the variable $WASHOME is the WebSphere Process Server root installation directory /opt/IBM/WebSphere/ProcServer:
   
   

export WASHOME=/opt/IBM/WebSphere/ProcServer echo $WASHOME echo "Performing chggrp/chmod per WAS directions..." chgrp profilers $WASHOME/logs/manageprofiles chmod g+wr  $WASHOME/logs/manageprofiles chgrp profilers $WASHOME/properties chmod g+wr  $WASHOME/properties chgrp profilers $WASHOME/properties/fsdb chmod g+wr  $WASHOME/properties/fsdb chgrp profilers $WASHOME/properties/profileRegistry.xml chmod g+wr  $WASHOME/properties/profileRegistry.xml chgrp -R profilers $WASHOME/profileTemplates

Issue the following additional command where profile_template_name is default, dmgr, or managed, respectively:

chmod -R g+wr $WASHOME/profileTemplates/profile_template_name/documents

The ownership of files is preserved when the files are copied to the profile directory during profile creation. You granted write permission to the profile directory so that files copied to the profile directory can be modified as part of the profile creation process. Files that are already in the profileTemplate directory structure prior to the start of profile creation are not modified during profile creation.

Issue the following additional commands:

chgrp profilers $WASHOME/properties/Profiles.menu chmod  g+wr $WASHOME/properties/Profiles.menu

The following example assumes that the variable $WASHOME is the WebSphere Process Server root installation directory C:\Program Files\IBM\WebSphere\ProcServer. Follow instructions in the Windows documentation to give the profilers group read and write permission to the following directories and their files:

@WASHOME\logs\manageprofiles @WASHOME\properties @WASHOME\properties\fsdb @WASHOME\properties\profileRegistry.xml

You might have to change the permissions on additional files if the non-root user encounters permission errors. For example, if the product installer authorizes a non-root user to delete a profile, then product installer might have to delete the following file:

install_root/properties/profileRegistry.xml_LOCK

install_root\properties\profileRegistry.xml_LOCK

Give write access to the non-root user for the file to authorize the user to delete the file. If the non-root user still cannot delete the profile, then the product installer can delete the profile.