Tag: Citrix

Posted on

Maintaining Consistent Primavera P6 Client Configuration Files Across Multiple Users Using PowerShell

PowerShell 5.0 icon

In setting up Oracle’s Primavera P6 EPPM version 18.8, I discovered that users who connected to the client via Citrix were not picking up changes that were made to the default configuration file.

Normally, if that file is changed and is newer than the user’s own file, it will be overwritten with the default. In this case, users were not seeing the newer file, and when I looked, they often had no local profile on the Citrix server.

As it turned out, the user profiles were set up as roaming profiles that were deleted upon logoff. This wouldn’t necessarily be a problem, except that the their copy of the config file was always listed as newer than the default.

A workaround was to be logged into the server via RDP, and to have the user log in via Citrix. At that time, the config file could be manually copied, overwriting the user’s old file, and then (most importantly!) manually opening and saving the user’s file, so that it would remain in place in their roaming profile even after logoff.

This is clearly not a feasible practice in a production environment. However, an automated script that does this could solve this problem! Save the following as a .cmd file and make sure it is run prior to running the P6 client executable.

copy "C:\Program Files\Oracle\Primavera P6\P6 Professional\18.8.0\Data\PrmBootStrapV2.xml" "C:\Users\%username%\AppData\Roaming\Oracle\Primavera P6\P6 Professional\18.8.0" /y

powershell (Get-ChildItem 'C:\Users\%username%\AppData\Roaming\Oracle\Primavera P6\P6 Professional\18.8.0\PrmBootStrapV2.xml').CreationTime = $(Get-Date)
powershell (Get-ChildItem 'C:\Users\%username%\AppData\Roaming\Oracle\Primavera P6\P6 Professional\18.8.0\PrmBootStrapV2.xml').LastAccessTime = $(Get-Date)
powershell (Get-ChildItem 'C:\Users\%username%\AppData\Roaming\Oracle\Primavera P6\P6 Professional\18.8.0\PrmBootStrapV2.xml').LastWritetime = $(Get-Date)

As long as the Citrix server has PowerShell installed, this should work.

Update: Part 2 has a script that will allow for both Local and Roaming profiles.

Posted on

Enabling Single Sign-On in Citrix Receiver

Citrix logo

After downloading a new version of Citrix Receiver and installing it, I discovered that the single sign-on (SSO) functionality that used to “just work”, had stopped working.

After hunting through the Local Group Policy Editor, the registry, and the folder in which Citrix was installed, I was able to put together the following instructions. Completing these steps fixed my problem, however, the fole locations may vary somewhat depending on how your Windows and Citrix installations are configured.

Note: The person executing these steps will need local admin rights on the PC.

  1. Add the following site(s) to the Local Intranet zone in Internet Options. (These will be specific to your organization.)
    1. http://yourcitrixwebportal.com
    2. https://yourcitrixwebportal.com
    Internet Options dialog box
    Local intranet zone box
    Local intranet zone - add sites

    In Internet Explorer, go to Tools –> Internet options.
    On the Security tab, click “Local intranet” in the “Select a zone…” area.

    Click the Sites button, and on the next dialog box, click the Advanced button.

    Add each site above by pasting or typing the URL into the “Add this website…” field and click the Add button for each one. The checkbox requiring HTTPS should be unchecked.

    Click Close, OK.

    Internet Options box - Advanced tab

    Click the Advanced tab on the Internet Options box. Make sure the “Enable Integrated Windows Authentication” checkbox is checked. If not, check it. (You will also need to reboot the PC if this setting is changed after closing Internet Options.)

    Click OK to close Internet Options.

  2. Copy files from the Citrix Receiver client into the appropriate Windows folder to enable Citrix Group Policies.
    1. Copy CitrixBase.admx and receiver.admx from “C:\Program Files (x86)\Citrix\ICA Client\Configuration” to “C:\Windows\PolicyDefinitions”
    2. Copy CitrixBase.adml and receiver.adml from “C:\Program Files (x86)\Citrix\ICA Client\Configuration\en-US” to “C:\Windows\PolicyDefinitions\en-US”
  3. Click Start –> Run –> type gpedit.msc in the search field and hit Enter to open the Local Group Policy Editor. Find the “User authentication” folder in the left pane under Local Computer Policy –> Computer Configuration –> Administrative Templates –> Citrix Components –> Citrix Receiver. Click “User authentication” to display its settings in the right pane. In the right pane, double click “Local user name and password”. Click the Enabled radio button, and make sure that the “Enable pass-through authentication” and “Allow pass-through authentication for all ICA connections” checkboxes are checked. Click OK to close the “Local user name and password” settings box. Close the Local Group Policy Editor.
    Local Group Policy Editor
  4. Reboot the PC.
  5. When opening the Citrix app you may see a box asking to Permit or Block access to local resources. Check the checkbox and select Permit.
Posted on

Moving a Legacy Citrix-Based Application to a Current Version of Windows

Citrix logo

In my last post, the problem I experienced was with an old application (which I’ll call “App #1”) written in PowerBuilder 6.5, and accessed via Citrix.

Today, a similar type of application (“App #2”) is the source of the problem, and the fact that it’s being moved to the same new server made the cause of the problem even more difficult to discern.

Both applications connect to the same Microsoft SQL Server instance. After moving App #1, the problem was connecting to an Oracle Database via ODBC. Connecting to SQL Server worked fine.

However, App #2, while ostensibly identical in its method of connecting to the database, threw an error when trying to connect via the new Citrix server.

error dialog box

This is the same error given if one enters an incorrect username and password, so it’s not the most helpful notification to receive. Also, this application has no error log, and does not send errors to the Windows Event Viewer. App #2 is basically a black box.

I decided to check whether or not XP Compatibility mode would affect how App #2 ran on the new server. Though App #1 was unaffected by this, something had to be different and this should be easy enough to check.

Because the application ran from a network drive rather than locally on the Citrix server, checking the Properties on the executable was not fruitful. The entire Compatibility tab was grayed out.

Compatibility tab on Properties dialog box for app on network drive

By copying the application executable to the server, I was then able to set the Compatibility Mode selector for Windows XP SP 3. The application ran perfectly! This did not completely solve my problem though – this app was run by Citrix via batch file rather than an app shortcut.

I figured there must be a way to set the Compatibility Mode within the batch before executing via start.exe.

After digging a bit, I did find several options for doing this. Though the method preferred by many involved adding registry keys, I chose the simplest route.

Adding this line to the batch file just before the call to the application executable solved my problem!

set __COMPAT_LAYER=WinXP