At work we use Citrix XenApp extensively to publish applications. One of the minor issues I have encountered is that the Connection Center component of the Citrix Plugin client disables some of the visual effects at log on in Windows including the “Animate Window Minimizing and Maximizing” setting. I have also noticed that the “Show Windows Contents While Dragging” setting also sometimes gets deactivated. Having these disabled if you are using the Aero interface is particularly unattractive.
To stop these from turning off it is necessary to prevent the Connection Center process “concentr.exe” from running when the user logs on. Keep in mind that disabling the Connection Center will prevent you from accessing the features available in it. This fix will only affect programs and windows running locally on the computer, apps published from XenApp will still have the visual features disabled. On my computer the user I normally use is a standard user, so I will disable the execute privileges for the local Users group for the “concentr.exe” file.
I have found that this is the only way to disable the Connection Center from running without the Plugin (in particular the Web version) from detecting that something has been changed and rerunning the initialization. Renaming the “concentr.exe” file or disabling from running within “msconfig” didn’t work for me.
First navigate to “C:\Program Files (32-bit) or Program Files (x86) (64-bit)\Citrix\ICA Client”.
Right click “concentr.exe” and choose Properties.
Many organizations that process credit card payments must comply with the PCI (Payment Card Industry) security standard to help maintain the integrity of their systems. One of the technologies an organization can make use of to help in complying with this standard is to implement a multi-factor authentication scheme. WiKID offers a robust two factor authentication method based on one-time use passcodes. The WiKID server is based on the CentOS 5 Linux distribution. WiKID offers a free Community Edition, however several built in features are missing (such as RADIUS) that are needed to integrate with the Citrix Web Interface. WiKID Enterprise Server is offered with a 30 day trial and has all features necessary for integration with Citrix included out of the box. It has a reasonable price tag that is much cheaper than competing multi-factor authentication solutions. Facebook
In this example I will implement a WiKID server to provide an additional layer of authentication for Citrix Web Interface user logons. WiKID offers a prebuilt VMware appliance, however I had trouble getting this to work properly. At the moment my recommendation if you intend to set up WiKID in VMware is to set up a virtual machine manually using Red Hat Enterprise Linux 5 (32-bit) as the machine type with a basic setup (512MB RAM, 5GB Hard Drive, and 1 NIC). Once that is complete boot using the WiKID Enterprise Server ISO.
Select your time zone and press tab until the OK button is highlighted, press enter.
In this post I’ll discuss deploying Citrix XenDesktop 4. XenDesktop is part of Citrix’s virtual desktop infrastructure (VDI) technology that allows us to manage the publishing of Windows XP/Vista/7 desktops to clients. In many ways from the user’s perspective this is similar to publishing a full desktop with Citrix XenApp, but rather than users sharing desktops on a Windows server each user gets their own individual desktop host machine. One of the great things about XenDesktop is that we can publish virtual desktops regardless of whether the desktop host is a virtual machine hosted on Citrix XenServer or VMware vSphere, or a physical computer.
Generally you would use XenDesktop in situations where applications are not compatible with running on a terminal server or XenApp, or if each virtual desktop has unique requirements such as USB support. There is a one to one relationship and we’ll need one Windows desktop host for each user that connects. The hosts can be pooled so that we’ll only need one for each concurrent user.
The core application service that we’ll be deploying for XenDesktop is something called the Desktop Delivery Controller (DDC). The DDC is installed on a server and its job is to register desktop hosts and broker client connections to them. When we set up a DDC we create a farm and we can install multiple DDC’s for availability. If you have an existing XenApp farm it is recommended that you install the DDC in a new farm. Don’t worry, both XenApp and XenDesktop DDC farms can make use of a common Web Interface so that users have a single place to access their applications and desktops.
As for install requirements currently Windows 2003 SP2/R2 x86/x64 are the only supported operating systems for the XenDesktop DDC. In addition the server must be configured as a member of an Active Directory domain. The installation will need to write to an OU in Active Directory to store objects to support the DDC and the registration of desktop hosts. To allow this we will need to be logged on as a domain administrator during the installation. If you want the most control create this new OU in Active Directory before starting the install. You are also given the option to create a new OU within an existing OU during the installation routine.
In this example I will be installing XenDesktop Express, which is available as a zip archive on the Citrix website. I will configure a desktop host running Windows XP. Also I will make use of an existing SQL 2005 database server for the farm data store so the SQL Native Client will need to be installed on the DDC server. You can find links to download the SQL Native Client here. Be sure and download either the x86 or x64 version depending on the architecture of your Windows 2003 server. If you choose to use an existing SQL Server you will also need to create a new database for the XenDesktop farm before starting installation.
Install XenDesktop Desktop Delivery Controller
Now let’s start by inserting the DVD or ISO media for XenDesktop. The ISO is labeled “DDC_VDA.iso” and contains the installation files for both the Desktop Delivery Controller as well as the Virtual Desktop Agent (VDA) that we will install on each desktop host. The ISO comes bundled inside the XenDesktop Express zip file.
Select Install Server Components. The installer may prompt you to install .Net 3.5 SP1 if it is not installed on the server.
Accept the license agreement and click Next.
In my example I will install the Citrix License Server so make sure all of the component options are checked (the picture is incorrect). Click Next.
In this installment we’ll take a look at setting up Citrix Secure Gateway (CSG) 3.2 and Web Interface (WI) 5.3 together on a single server to provide secure connections to a Citrix XenApp farm. CSG allows clients to make secure connections to our XenApp servers from the Internet without the use of a VPN. I will be using the versions of CSG and WI that are provided with Citrix XenApp 6 and I’ll be installing them on Windows Server 2008 R2. The server will be set up in a DMZ and will not be a member of my Active Directory domain.
This tutorial assumes that you have already installed a XenApp 6 server farm and configured it with published applications. Click here for details on how to install XenApp 6. Also you’ll need to make sure and publish an application on your XenApp server, you can find details in this post. In addition, you’ll need to configure a DNS server or hosts file on your client to allow a domain name to be used when accessing the CSG/WI server from the client.
Update (5/22/2010): I have modified the instructions on my main article, Installing and Configuring Citrix XenApp 6, to include everything listed below.
Last time I discussed installing the Citrix XenApp 6 server. In this episode I’ll run through configuring a client computer for XenApp 6. One important thing to note is that you should be running the latest version of the Citrix XenApp Online Plugin client version 12. You can download it here. I had issues getting previous versions of the Plugin to connect to the XenApp 6 server, but with version 12 all is well. Also since Program Neighborhood is no longer included with the current Plugin client that functionality appears to no longer be supported. Instead we’ll use a XenApp Services Site (formerly Program Neighborhood Agent) to provide the settings for our client to connect through.
With the recent release of Citrix XenApp 6 I’ve begun testing this version as we prepare to upgrade our Windows terminal server environment. Probably the biggest reason for upgrading is that XenApp 6 offers support for Windows Server 2008 R2. There are also a number of changes in the tools used to administer your Citrix farm. In the recent past you had to use multiple tools for administration as Citrix migrated functionality into the MMC. This seems to now be mostly complete. The updates to the tools are welcome, but include a bit of relearning to find all the new methods and places to make configuration changes.
If you are evaluating and testing XenApp 6, Citrix has a developer license available that allows you to test with a single user for 1 year. Search the internet for “citrix developer license” for details. There is also a 99 user evaluation license available that is valid for 90 days.
Recently I was installing the Citrix Web Interface 5.2 that comes with XenApp 5 Feature Pack 2. I ran into difficulties when I attempted to login to the web page where the user enters their credentials. This is the message I would receive in the web browser:
The Web site is experiencing technical difficulties. We apologize for any inconvenience.
The internal error may only be temporary. Try reconnecting and, if the problem persists, contact your system administrator.
This is the warning event I would receive in the Application event log:
Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1309
Time: 1:53:01 PM
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 1/8/2010 1:53:01 PM
Event time (UTC): 1/8/2010 8:53:01 PM
Event ID: 247591ab13784ae7bc1ae48e69b20e79
Event sequence: 1
Event occurrence: 1
Event detail code: 0
Application domain: /LM/W3SVC/1/ROOT/Citrix/XenApp-3-129284527813100000
Application Virtual Path: /Citrix/XenApp
Application Path: c:\inetpub\wwwroot\Citrix\XenApp\
Machine name: CSG1
Process ID: 3744
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Exception type: HttpException
Exception message: The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write access to 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'.
Request URL: http://csg1.test.local/citrix/xenapp/auth/silentDetection.aspx
Request path: /citrix/xenapp/auth/silentDetection.aspx
User host address: 192.168.100.132
Is authenticated: False
Thread account name: NT AUTHORITY\NETWORK SERVICE
Thread ID: 1
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace: at System.Web.HttpRuntime.SetUpCodegenDirectory(CompilationSection compilationSection)
at System.Web.HttpRuntime.HostingInit(HostingEnvironmentFlags hostingFlags)
It turns out that the error is related to the Network Service account not having the proper file permissions to access the temporary ASP.net directory. This command can be run from the command prompt to correct the permissions:
CACLS "%windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files" /E /T /G "NT AUTHORITY\NETWORK SERVICE:C"
You should now be able to log in to the Web Interface without further errors.