Pages

Wednesday, June 27, 2012

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:

image

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

image

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

image

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:

image

image

image

image

Note how a gpresult now shows that only the:

  • Local Group Policy

… is applied:

image

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

image

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:

image

image

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

image

Enable the policy and set the Mode to Replace:

image

image

image

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

Computer Settings

  • Loopback Replace Mode
  • Local Group Policy

image

User Settings

  • Local Group Policy

image

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:

clip_image002[8]

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.

clip_image002

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

image

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.

image

clip_image002[6]

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.

clip_image002[4]

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

Tuesday, June 26, 2012

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:

clip_image002

image

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

image

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

ctxxmlss /r8080

image

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

clip_image002[6]

… 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)

clip_image002[4]

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

image

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.

image

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:

image

Thursday, June 14, 2012

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

image

***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:

image

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

image

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

image

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> 

image

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:

image

Wednesday, June 13, 2012

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:

image

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:

image

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:

image

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

image

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

imageimage

Proceed by clicking on the Next button:

image

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:

image

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

image

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

image

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:

image

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:

imageimage

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:

image

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

image

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

image

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

image

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

image

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

image

Proceed with logging onto your Citrix web interface webpage:

image

Notice how the newly published application is now available:

image

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

image

**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:

imageimage

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.