Tuesday, September 27, 2011

How-To Configure Citrix Web Interface Zone Preference

This post will illustrate how to configure Citrix Web Interface to direct users to published resources in a particular zone when connecting through a specific Web Interface server.  It applies to web interface 5.2.


1 - Log in to the web interface server and open the Citrix Web Interface Management console.  Right click the site you are going to configure and click on Session Preferences.


2 - Select the Web Interface should override the ICA client name check box.

3 - Edit the SessionUtils.java file located in the C:\inetpub\wwwroot\Citrix\<sitename>\app_code\PagesJava\com\citrix\wi\pageutils folder.
In our case, we're looking to change the client name to "WM_<username>" or "WD_<username>" depending on which web interface server users are connecting to.  "WM_" is for the primary zone and "WD_" is for the backup.  This example will change it for the web interface server serving the primary zone. 

Comment out the following line:

deviceInfo.setClientName( clientName );

and copy the following just beneath it:

//The following two lines have been added in order to change the client name which enables us to set a zone //preference based on client to direct user's to a particular zone when connecting from a specific web interface //server
String userID = accessToken.getShortUserName();
deviceInfo.setClientName("WM_" + userID);

Note
: You cannot change hte length of the client name. For example, WDZO cannot be substituted for WD_

Here is a screenshot of the file when edited for the WI server in the primary zone:



4 - Open the Citrix XenApp Advanced Configuration Console and create a new policy for each zone that will specify zone preference and failover.

The settings are as follows for the primary zone policy:


Apply the policy filtered on the WM_ client name and select the Allow radio button.



5 - Repeat the steps taken on the web interface server on any other web interface servers where a zone preference is needed and edit the policy as necessary for zone preference and failover.

Notes:
You can check to verify your client naming convention is in force by logging into an application served by the web interface server you edited the SessionUtils.java file on. 

You can check the zone preference policy by publishing a test application or desktop and logging into each  web interface server and verify you land on a XenApp server in the zone that the web interface server is serving.

Friday, September 16, 2011

How-To: Create a Mandatory Profile in Windows 2008

This procedure was used to create a mandatory profile to be used in a XenApp deployment.  Using a mandatory profile will cause a user's environment to be "reset" each time they log on since a mandatory profile cannot be written to.  Because of this, you will need to employ some type of profile management solution if you want to allow users to customize their environment.  We use triCerat Simplify in my shop, but there are many other solutions available.  The advantage of using a mandatory profile is that you don't need to use roaming profiles which have traditionally been a nightmare as time passes and they become bloated and even corrupt.

1 – Create a folder on a file server to house the share.

2 – Share the folder with proper permissions.  Since this is going to house a mandatory profile, we only need to give authenticated users Read access, but leave Admins at Full Control:
  

3 – Create a folder within the share folder you just created to house the actual mandatory profile.
Add a .V2 extension to the folder’s name.
4 – Log on to a 2008 server that will only be loading up a local profile for an end user.  Run any programs, make any changes you want and then log back out.
5 – Log in as an admin on the same 2008 server and go to view the user profiles on the system.

6 – Select the user you logged on as before and click the “Copy To” button.  Then enter the path to your mandatory profile folder in the “Copy profile to” field.  Do NOT click OK yet.

7 – Click the Change button under “Permitted to use” and add Everyone.  Click OK.

8 – Click OK in the “Copy To” dialog.  Confirm the copy if prompted.




9 – Go back to the file server and verify the profile is copied into the folder you specified.
10 – Rename the ntuser.dat file inside the profile to ntuser.man.
11 - Go back to the 2008 server and remove the local profile for your template user.  Click OK all the way out of profiles and system settings.

12 – Set any policy or account attributes necessary to specify the use of the mandatory profile.

Wednesday, September 14, 2011

How-To: Create a Shortcut for Outlook 2007 Templates

Background/Purpose:  Outlook 2007 does not handle opening form templates the same way that its predecessors did.  You can no longer just double-click on an *.oft file and have it open on your desktop.  You must enter a series of button clicks/commands in Outlook to get it to open.  This procedure will show how to automate the process to make it easier on users.
This procedure uses a simple example and assumes you are using a home drive mapped to h:\ for end users. 
Here is the message a user would get if they try to double-click an *.oft file on a machine running Outlook 2007:

1 - Open OL2007 and click the Tools menu, then click Trust Center…

2 – Click on the Macro Security item and then choose either “Warnings for all macros” or “No security check for macros”.  Click OK.

Note:  “Warnings for all macros” is more convenient.  “No security check for macros” is more secure.
If you choose “Warnings for all macros”, then you will have to click through this warning when you run the macro:

3 –Click on the Tools menu and then click on Macro, Macros…

4 – In the Macros box that comes up, type the name of your macro (no spaces) and then click Create.


5 – In the VB editor that comes up, enter the following code making sure the path is correct for where the template form resides (*.oft file).


Click File, Save VbaProject.OTM

Close the VB editor.

6 – Click on Tools, Macro, Macros… and your new macro should be displayed in the box.  Select it and click the Run button to verify its operation.  Close the template that came up.

7 – Click on Tools, Customize…


8 – Click on the Commands tab and click on Macros under categories.  Your new macro should be displayed under Commands.

Click on the listed macro and drag it out to the menu location you want it in.  Give it a Friendly name.

Click Close.
Now you have shortcut that will open the form automatically instead of taking you through the steps listed here:
File > New > Choose Form > Look In: User Templates In File System > Your File.oft
The code should appear like this in the project:
---------------------------------------------------
Set newItem = Application.CreateItemFromTemplate("h:\your path\your form.oft")
newItem.Display
Set newItem = Nothing
---------------------------------------------------


Wednesday, August 31, 2011

Disable XSS filter in IE 8 using the registry

If you find yourself needing to the disable cross site scripting (XSS) filter in IE 8 using the registry for any reason, you can make the change for a user in this spot:

(This example is using the Trusted Sites Zone)

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2

1409  DWORD  0x00000003

If you need to enable it, set the value back to 0x00000000

Use a script, reg import or whatever to apply it at logon for the user...

Tuesday, August 30, 2011

How To Deploy Java Certs to All Users in Citrix or Terminal Server

Some Java app sites require users to accept certificates whenever they go to the site. 
Note:  This modification has to be done on a per site basis – every Java app site that users go to. 
1 – Go to the java app site.
2 – When prompted, put a check mark in “Always trust content from this publisher” and click the Yes button.

If you get a digital signature error after acceptance, then put a check mark in the “Always trust content from this publisher” checkbox again and click Run.
After clicking through these prompts, the trusted.certs file located in “%userprofile%\AppData\LocalLow\Sun\Java\Deployment\security” is modified.
3 - Copy the trusted.certs file to the C:\scripts\Java\security folder on the XenApp server.  You can rename any existing trusted.certs files that reside there in case of any need to fall back to the previous one.
Use a logon script that runs for each user to copy that file into each user’s profile as they log on to the server and all the sites\certs referenced in the trusted.certs file will work automatically for the users.

Thursday, August 11, 2011

Quick thoughts - Primavera p6 v7 on W2K8 Server x64/Citrix XenApp 5

Oracle's documentation on installing Primavera in a x64 terminal server environment doesn't quite get us all the way there...


Some items I have found that should be better documented for installing on a Citrix server:


1 - You must install a x86 Oracle client - Primavera does not have a x64 client in this version.  This also means you have to configure ODBC from c:\windows\sysWOW64\odbcad32.exe.
2 - On a Windows 2008 x64 server, I had to allow PM.exe and dbconfig.exe within DEP (data execution prevention).  I have not had to do this for any other of the many applications installed on the server.
3 - Since this is a x86 client, it does not seem to like being installed in "Program Files (x86)".  Install it in a folder without the (x86) designation.


Edit:  After figuring these items out, the Primavera installer would still fail when attempting to run dbconfig.exe.  I received the following message:


"Bad public user name or password. Database Server Error: OCI version 11.2.0.1.0 Production is not supported;"


A case was opened with Oracle and they provided 3 dll's that needed to be replaced.  The issue is due to a bug in the installer for V24733 (P6v7 w/SP3) in combination with the 11gR2 client (32-bit).  This has solved the issue.

Monday, July 25, 2011

Adobe Acrobat X toolbar in IE8 - Get rid of it on terminal server!

You have Acrobat X Pro installed in a TS environment and when anyone opens IE, they see the Acrobat toolbar.  That’s fine if everyone who accesses the server is supposed to get access to Acrobat and all of its plug-ins, add-ons, etc… 
I found a user registry setting that I <thought> would take of the issue for me:
[HKEY_CURRENT_USER\Software\Adobe\Adobe Acrobat\10.0\Settings]
"IEToolbarIsVisible"=dword:00000001
I thought setting this to 0 would take care of this, but unfortunately it did not work for me as the value kept resetting to 1 any time I reopened the web browser.
To get rid of this toolbar, this is the registry value to delete (export it if you think you may need to restore it for any reason in the future).
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Toolbar]
"{47833539-D0C5-4125-9FA8-0819E2EAAC93}"=hex:00           ß Delete!
How did I find this?  I took a look at the properties for the Adobe PDF Add-on.  Searched for its Class ID and figured I’d do a search and destroy.
So far, no negative impact…

Adobe Acrobat Pro and Reader on the same Terminal Server (Citrix XenApp)

The environment I currently work in needed to make Adobe Acrobat Pro available to users in our Citrix XenApp environment due to the big push we have for telework.  Here are steps that can be taken to make this happen so that users who are not licensed for Adobe Acrobat Pro are not able to use it and that Adobe Reader remains the default pdf reader on the server.
Notes:  Installed on a Windows 2008 x64 server running Citrix XenApp 5 
                Transforms file was created using Adobe Customization Wizard
-          Install Adobe Reader X Pro (in install mode, of course) using a manual or automated method and using a transforms file as an argument.  For instance:
msiexec /qn /norestart /i "d:\install\SOFTWARE\Adobe\Adobe Acrobat X\AcroPro.msi" TRANSFORMS="d:\install\SOFTWARE\Adobe\Adobe Acrobat X\AcrobatX10.mst"
-          Create a security group that will contain the user accounts of people you want to provide Acrobat Pro access to.  Set NTFS permissions on Acrobat.exe and Acrotray.exe so that it will not be executable except for this group.
-          Publish it as an application to the group you created via CAMC in the step above.  If you are publishing a desktop, add the icon for it via a script, group policy preferences or some desktop management software, assuming you have one (like triCerat Simplify, etc...).
-          Set the registry for users who log on to have Adobe Reader as their default pdf reader.  You can do this by importing a reg file via a script, group policy preferences or using profile management software.  Here are the keys/values to set:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\OpenWithList]
"a"="AcroRd32.exe"

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice]
"Progid"="Applications\\AcroRd32.exe"

In my case, I wrote a quick batch file that I use as a startup script in AD that installs the application using msiexec.exe and sets permissions using xcacls.vbs.  I am using desktop management software to “publish” the icon to user desktops and set their default pdf reader.