Preventing Active Directory user and computer policies being applied to a server object with block inheritance and loopback policies in replace mode

One of the most frequent issues I’ve had with Microsoft terminal and Citrix XenApp servers is preventing Active Directory user and computer policies from being applied to these servers.  The computer policies are easy enough to block with the Block Inheritance feature within the Group Policy Management Console but blocking user policies isn’t as straight forward and since I’ve been asked enough times on how to do it and how it works, this post will serve as something I can point other colleagues to reference. 

**Note that I don’t have any screenshots with servers as examples so I’m going to use workstation computer objects instead.

The following screenshot shows the OU named Bunch of User Policies followed with a sub OU named Prevent User Policies.  There is also an account named CCS Admin in the Bunch of User Policies OU:

The idea here is that the OU named Bunch of User Policies has various user and computer policies applied to it as shown in the following:

• Office 2010 <— User policy
• Office 2010 Customizations <— User policy
• View Client Customizations <— User and Computer policy

Executing gpresult on the Windows 7 desktop in the OU named Prevent User Policies will show that following user policies are applied to the CCS Admin account:

• Office 2010 <— User policy
• Office 2010 Customizations <— User policy
• View Client Customizations <— User and Computer policy

• Default Domain Policy
• Local Group Policy

Blocking Computer Policies

The computer policy View Client Customizations is easy enough to block by using the Block Inheritance feature on the OU named Prevent User Policies (sorry about the name, this should have been named Prevent User and Computer Policies) and moving the computer object CCSAdmin into the OU:

Note how a gpresult now shows that only the:

• Local Group Policy

… is applied:

Blocking User Policies

With the computer policies blocked, the next step is to block out the user specific policies as shown from the gpresult:

• Office 2010 <— User policy
• Office 2010 Customizations <— User policy
• View Client Customizations <— User and Computer policy

• Default Domain Policy
• Local Group Policy

What we need to do is to create a new GPO loopback policy and configure it in replace mode then apply it to the OU containing the computer object that you do not want user policies applied to:

Navigate to Computer Configuration –> Administrative Templates –> System –> Group Policy –> User Group Policy loopback processing mode:

Enable the policy and set the Mode to Replace:

With the loopback policy applied, a gpresult will show the following:

Computer Settings

• Loopback Replace Mode
• Local Group Policy

User Settings

• Local Group Policy

Notice how we have successfully removed both the computer and user policies from this computer object for any user that logs in.  One of the other questions that come up quite often is how we can block user logon scripts configured in the Active Directory account’s Profile tab and unfortunately, there is no easy way to do this with policies.  The only alternative I know of is to actually modify the logon script to check what computer object the user is logging onto and then filter it.

Install Citrix XenApp 6.5 hotfixes fails with the message: “Installation ended prematurely because of an error.”

Problem

I ran into an interesting problem the other day when I was trying to install a bunch of hotfixes for a few Citrix XenApp 6.5 servers:

What I noticed was that no matter which hotfix I ran, the installation would fail with the following error:

Installation ended prematurely because of an error.

Note that I ran all of the hotfixes in a command prompt ran as an administrator so I proceeded to turn on verbose logging during the install with the following command:

msiexec /p XA650W2K8R2X644001.msp /L*v install.log

Product: Citrix XenApp 6.5 - Update 'XA650W2K8R2X64001' could not be installed. Error code 1603. Additional information is available in the log file D:\XenApp Hotfixes\install.log.

Unfortunately, the logs weren’t all that useful as there was a lot of content but not really anything that stuck out to tell me what was wrong:

MSI (s) (EC:5C) [16:53:02:783]: Restoring environment variables

MSI (s) (EC:5C) [16:53:02:783]: Destroying RemoteAPI object.

MSI (s) (EC:C4) [16:53:02:783]: Custom Action Manager thread ending.

MSI (c) (E4:7C) [16:53:02:799]: Back from server. Return value: 1603

MSI (c) (E4:7C) [16:53:02:799]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied.  Counter after decrement: -1

MSI (c) (E4:7C) [16:53:02:799]: PROPERTY CHANGE: Deleting SECONDSEQUENCE property. Its current value is '1'.

Action ended 16:53:02: ExecuteAction. Return value 3.

MSI (c) (E4:7C) [16:53:02:799]: Doing action: Fatal_Error

Action 16:53:02: Fatal_Error.

Action start 16:53:02: Fatal_Error.

MSI (c) (E4:7C) [16:53:02:799]: Note: 1: 2235 2:  3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = 'Fatal_Error'

Action 16:53:02: Fatal_Error. Dialog created

Solution

After doing a bit of research, I found the following forum post: http://forums.citrix.com/thread.jspa?threadID=297715&start=30&tstart=0 where a user indicated that this had to do with an expired Citrix certificate on the server.

After going ahead and delete the certificate Citrix Systems, Inc. from the local computer store, the hotfixes began to install properly.

Changing a Citrix XenApp farm to use port 8080 for the XML service port

If you ever do any research on what port to use for the XML service in a Citrix XenApp environment, you’ll notice that there are options to share port 80 with IIS, use port 443 with SSL on IIS and finally port 8080.  I haven’t really found any official documentation on what is best practice but I was able to find forum posts where Citrix engineers recommend the use of port 8080 and not to rely on IIS.

The process of changing the XML service port to 8080 is quite easy but since I know I’m bound to forget after not having to perform the configuration on a regular basis, I thought it would be good to write a blog post so I can reference it in the future.

Begin by logging onto your XenApp server and stop the Citrix XML Service:

Once the service has been stopped, proceed with opening up the command prompt as an administrator an executing the following command to unregister the Citrix XML Service port:

ctxxmlss /u

Once the command completes successfully, proceed with executing the following command to register the port to 8080:

ctxxmlss /r8080

Once the command successfully completes, proceed with starting the Citrix XML Service:

… then open up the registry to confirm that the changes have been applied via the following registry key:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CtxHttp

Name: TcpPort
Type: REG_DWORD
Data: 0x00001f90 (8080)

Once the port change has been confirmed, log onto your Web Interface server and reconfigure the farm settings for your websites:

Using the “Test Connection” feature to test the database connection when adding a new Citrix XenApp 6.5 server to an existing farm throws the error: “Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.”

Problem

You’ve completed the installation of a new Citrix XenApp 6.5 server and attempt to add it to an existing farm using a remote SQL server as the database server but after entering the credentials and using the Test Connection feature, you receive the following error:

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Solution

I found this error message extremely misleading as the first thought I had was that I pointed to a SQL server in a different domain or used an incorrect service account that belonged to a different domain than the SQL server.  Both were not the case and the reason that this error message was thrown was because the service account was locked out.  The Test Connection feature completed successfully once I unlocked the account:

Publishing Citrix XenDesktop 5.6 VM Hosted Apps does not launch the application

I ran into an interesting problem last night while trying to publish a few web applications that required Internet Explorer 7 and because the environment I was working with was XenApp 6.5, which required Windows Server 2008 R2 as the base operating system, there was no other choice than to use Citrix’s VM Hosted App feature that allows you to publish an application installed onto a virtual desktop.  I went ahead and configured the application to launch internet explorer while adding a website’s URL into the command line argument but immediately noticed that whenever I attempted to launch the application through the Citrix web interface, the receiver would start but the application never launches.  Additionally, the virtual desktop reboots shortly after the Citrix receiver disappears.  As some administrators may know, the reason why the virtual desktop reboots is because that is the default behavior when a user logs off and the way to prevent that from happening is execute the following command:

Set-BrokerDesktopGroup -Name "Desktop Group Name" -ShutdownDesktopsAfterUse $False

More information can be found in the following Citrix KB:

How to Configure the Logoff Behavior of a Desktop Group in XenDesktop 5
http://support.citrix.com/article/CTX127842

With the reboot issue out of the way, let’s look at what configuration changes were required to get the applications to launch:

Step #1 - Registry Additions to the XenDesktop DDC

The first change the Citrix engineer had me make was the following registry key we had to add on both of our XenDesktop DDCs:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\DesktopServer
XenAppLicenseEdition
REG_SZ
Value: PLT

***Note that we’re using the Platinum version of XenDesktop so the value was set to PLT.

Step #2 - PowerShell cmdlets on XenDesktop DDC

The second change we needed to make was to execute the following cmdlets on one of our DDCs:

Set-BrokerSite -DesktopLicenseEdition PLT

To set up VM hosted apps to use Platinum edition:

Set-BrokerSite -AppLicenseEdition PLT

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Once we completed steps 1 and 2 as well as the PowerShell cmdlet:

Set-BrokerDesktopGroup -Name "Desktop Group Name" -ShutdownDesktopsAfterUse $False

… the published applications were now able to launch and the virtual desktop hosting the application no longer rebooted when we closed the applications.

Citrix XenApp 6.5 server in AppCenter missing installed hotfixes

Problem

You would like to check to see what hotfixes have been installed for each of the XenApp servers in your farm but noticed that one of the servers is listed as not having any hotfixes installed in the AppCenter:

You open the Programs and Features of that server (appwiz.cpl) and notice that there are 2 hotfixes installed but they are not listed:

You browse over to another server in the farm in AppCenter and can see the hotfixes installed listed:

Solution

One of the reasons why the hotfixes would be missing is if there is a problem with local host cache so one of the first items to try is to execute the command dsmaint recreatelhc so that the local host cache is populated with fresh data from the data store but prior to executing the dsmaint recreatelhc command, you’ll need to stop the IMA service.  The following demonstrates this:

C:\Windows\system32>net stop imaservice

The Citrix Independent Management Architecture service is stopping.

The Citrix Independent Management Architecture service was stopped successfully.

C:\Windows\system32>dsmaint recreatelhc

Recreating LHC database finished successfully.

C:\Windows\system32>net start imaservice

The Citrix Independent Management Architecture service is starting....

The Citrix Independent Management Architecture service was started successfully.

C:\Windows\system32> 

Once the local store has been populated with fresh data from the data store, navigate back into the AppCenter and you should now see the patches installed:

Publishing an Internet Explorer 7 or 6 web application with Citrix XenDesktop VM Hosted Apps

One of the challenges I find I frequently face with XenApp deployments is the ability to publish legacy applications that is either incompatible with 64-bit operating systems or require a version of Internet Explorer that is older than the version that is natively installed on the XenApp base operating system.  One of the recently deployments I was involved in had Citrix XenApp 6.5 on Windows Server 2008 R2 but had 2 applications that required Internet Explorer 6 or 7.  As most would know, XenApp 6.5 will only install on Windows Server 2008 R2 and the base operating system is shipped with Internet Explorer 8.  Since there is no way of profiling and streaming Internet Explorer 6 or 7, the only option that crosses the mind is Citrix XenDesktop’s VM Hosted Apps.  For those who are not familiar with what VM Hosted Apps are, the following is a snippet from Citrix’s eDoc:

VM hosted apps allows you to deliver applications from virtual machines or physical computers, including blade servers, running Windows single-user desktop operating systems. Users access these applications through a Web browser, the Citrix online plug-in, or Citrix Receiver, just as they would applications hosted from XenApp servers running Remote Desktop Services. VM hosted apps allows you to deliver applications that otherwise must be installed locally or require extensive compatibility testing on XenApp servers.

http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-vmha-wrapper.html

The obvious drawbacks of using VM Hosted Apps is that you essentially have 1 to 1 mappings for application as each application you launch will use 1 virtual or physical machine.  So in the event that you want to allow 100 users to launch the same web application that uses a VM Hosted App, you’ll need to have a pool of 100 virtual or physical machines.  You can probably get by with 512MB to 1GB of memory for Windows XP but if you multiple, say 512MB by 100, you’ll essentially be using 50GBs of memory.  A typical 8GB XenApp server can serve many instances of Internet Explorer.  With that being said, if you absolutely need a way to publish legacy applications that your XenApp server cannot host then this would be a viable workaround.

**Note that Citrix blogs also has a post that demonstrates the process of publishing a VM Hosted App here: http://blogs.citrix.com/2011/09/07/xendesktop-5-configuring-vm-hosted-apps/

Now without further delay, the following is an example of publishing a web application with Internet Explorer 7:

Creating a Desktop Catalog

The first step is to create a desktop catalog from a master template that you have prepared with the applications you intend on publishing and then create a desktop catalog.  VM Hosted Apps supports different catalogs and depending on which type you deploy, the characteristics will vary.  For more information about the characteristics, see the following:

Working With Machine Catalogs and Desktop Groups
http://support.citrix.com/proddocs/topic/xenapp65-publishing/ps-vmha-manage-catalogs-groups.html

Notice how I created a random pool named WinXP VM Hosted Apps in the following screenshot:

Creating a Desktop Group

Once your desktop catalog has been created, proceed with creating a desktop group and add the desktop catalog machines to it:

Create an VM Hosted Application

Once the desktop group has been created, proceed with creating your VM Hosted App by right clicking on the Applications node and selecting Create Application:

Since we already have the desktop group created proceed with clicking on the Add existing button:

Select the desktop group you just created and click on the OK button:

Proceed by clicking on the Next button:

The next screen allows us to choose the program that we would like to run so either type in the path and executable of the application or click on the Browse button to locate it:

Clicking on the browse button will present us with the following Browse For File window:

Notice how the Share drop down menu allows you to select either the Start menu or C$:

If your application is located in the start menu, simply use the Start menu and if your application isn’t, use the C$ option.  For the purpose of this example, we’re going to launch internet explorer and because we would like to launch a webpage in the browser, we’re going to put in the URL of the webpage in the Command line arguments field as such:

The next step is to add the users allowed to access the application so click on the Add button and choose a user or group:

Clicking on the next button will allow you to specify a folder to put the application in and/or add shortcuts to the client’s start menu or desktop:

Clicking on the next button will then bring you to the advanced options.  Change them accordingly to your requirements:

The next menu allows you to give the application a name:

The next menu provides you with a summary of your VM Hosted App configuration:

Clicking next will create the application and provide you with the result:

Clicking on the finish button will show the newly created application in the list list of applications configured:

Proceed with logging onto your Citrix web interface webpage:

Notice how the newly published application is now available:

Launching the application will present you with multiple prompts that mimic the log on process for a Windows XP desktop:

**Note that I’ve spoken to a Citrix engineer about having this seamless and he said he has never seen these login prompts not presented but when I read responses of forums, I’ve seen people say it could be seamless.  In any case, I’ve always seen this prompt but it could be just the applications I’ve dealt with and I will update this post if I ever come across not seeing it. 

Once the log off completes, you should see the application launch:

Closing the application will essentially log you off of the desktop so don’t be surprised if you see the log off windows when you close the application.

Hope this helps anyone out there not aware of this feature that provides a workaround for publishing legacy applications.