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.
- Add the following site(s) to the Local Intranet zone in Internet Options. (These will be specific to your organization.)
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.
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.
- Copy files from the Citrix Receiver client into the appropriate Windows folder to enable Citrix Group Policies.
- Copy CitrixBase.admx and receiver.admx from “C:\Program Files (x86)\Citrix\ICA Client\Configuration” to “C:\Windows\PolicyDefinitions”
- Copy CitrixBase.adml and receiver.adml from “C:\Program Files (x86)\Citrix\ICA Client\Configuration\en-US” to “C:\Windows\PolicyDefinitions\en-US”
- 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.
- Reboot the PC.
- 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.
I support an environment where users access the Primavera P6 thick client on Windows via Citrix.
If I connect to the Database Configuration app and add, modify, or delete the connection to a P6 database, the PrmBootStrap.xml file that is in my profile. For the version we are using (8.2), that location is C:\Users(username)\AppData\Local\Oracle\Primavera P6\P6 Professional. It appears that the file is also copied to the “%PROGRAMDATA%\Oracle\Primavera P6\P6 Professional” folder and the “All Users” profile (if it exists) as well, in “C:\Users\All Users\AppData\Local\Oracle\Primavera P6\P6 Professional”.
In the code below, I copy from the ProgramData folder instead of from my profile, but it would be easy to eliminate the outer for loop and uncomment two lines to make it copy from my profile.
Since I have multiple Citrix servers for P6, I normally would manually copy the file to the folders on the other Citrix servers so that the users will have the same list no matter where they log on. To simplify this, I wrote this Windows batch script to automate this copy process.
rem //Citrix servers hosting Primavera P6 should be in the serverlist variable, separated by spaces
set serverlist=citrixserver1 citrixserver2 citrixserver3
rem //Windows username of person who has standard file
set filepath=Oracle\Primavera P6\P6 Professional
rem set Sourceloc="C:\Users\%usersname%\AppData\Local\%filepath%\%filename%"
for %%s in (%serverlist%) do (
if not exist !Sourceloc! (
echo No file found: !Sourceloc!
) else (
for %%a in (!Sourceloc!) do set SourceFileDate=%%~ta
if "!SourceFileDate:~-2!" == "PM" set offset=12
set /a "SourceFileDateHour=!SourceFileDate:~11,2!+!offset!"
for %%x in (%serverlist%) do (
echo DestinationServer = %%x
echo SourceServer = %%s
if not %%x==%%s (
set secondloc="\\%%x\C$\Users\All Users\%filepath%\%filename%"
for %%y in (!firstloc! !secondloc!) do (
if exist %%y (
for %%a in (%%y) do set DestinationFileDate=%%~ta
if "!DestinationFileDate:~-2!" == "PM" set offset=12
set /a "DestinationFileDateHour=!DestinationFileDate:~11,2!+!offset!"
echo DestinationFileDateCompare = !DestinationFileDateCompare!
echo SourceFileDateCompare = !SourceFileDateCompare!
if "!SourceFileDateCompare!" gtr "!DestinationFileDateCompare!" (
ren %%y !NewDestinationFileName!
copy !Sourceloc! %%y
) else (
echo Destination file %%y is newer than or the same as !Sourceloc!.
) else (
echo INFO: %%y not found
) else (
echo Destination and Source servers are the same: no file copied.
If you uncomment the pause command at the end, you can look at the command window to make sure it’s working properly.
If you have tried to install an application on a Windows Server when logged in with Remote Desktop Connection and the result was a dialog box like the one above, this post is for you.
Understandably, many software companies want different kinds of licensing to be used when installing on a server running Terminal Services. The assumption is that you will likely be using it as a Citrix server, allowing many users to access the application at once. If this is what you are intending to do, then you must follow the licensing scheme required by the software vendor.
However, what if your intention is to install it only for yourself? In my case, I have a virtual development server that no one else uses, but I log onto it with Remote Desktop. When trying to install an application the other day, I got a message similar to the one above. How does it know that I’m logging on remotely?
Other users have had similar experiences, and some of the suggestions on this post on SuperUser gave me an idea.
What if I was logged onto the Console rather than an RDP session? This is a virtual server that is not physically located in the same place as me, so that seemed unlikely. Then I remembered VNC! After installing a free copy of UltraVNC Server on the server and Viewer on my PC, I was able to log in as an apparent session from the Console.
The application was satisfied and allowed me to install it without any further complications.
I was notified that a little-used application within my organization had begun displaying an error instead of allowing the users to log in via Citrix.
This ActiveX control, which was integral to the operation of the application I was servicing, had come from a very old version of Crystal Reports. Apparently, someone had recently installed a full version of Crystal Reports on this server and it had deleted the older OCX file.
I found a copy of the OCX file, copied it to the C:\Windows\SysWOW64 folder (as it was a 32-bit control) and attempted to run Regsvr32 on it to register the file.
This was the result:
Apparently the installation of Crystal Reports also deleted some files that the ActiveX control needed to be registered! Fortunately, I found a free program called Dependency Walker that can show missing dependencies on DLLs, OCXs, and some other file types.
Installation and running of the program is very straightforward. When running it on a copy of the OCX file on my desktop, this was the result:
As you can see from the circled area, two dependencies were missing: crpe32.dll and olepro32.dll. Olepro32.dll did exist in the SysWOW64 folder, so I copied it to the desktop, when running again, only crpe32.dll was missing. This file did not exist in SysWOW64, but I found it in the Crystal Reports installation folder. By copying crpe32.dll to SysWOW64, I was able to register the OCX file there, and my application began working again!