Author Archive

Opening Sharepoint documents in a Windows 7 XenDesktop session using XenApp published Office products with content redirection

March 26th, 2013 2 comments

Wow, long title there! Just like it says, I’m going to cover opening Sharepoint documents in a Windows 7 XenDesktop VDI session using XenApp published Office products with content redirection enabled. Here’s an example scenario:

  • Your company uses Sharepoint and the URL is http:\\ It is part of the Local Intranet zone in IE.
  • Your users are using Windows 7 VDI/XenDesktop VMs with Citrix Receiver Enterprise pulling published apps into the Start menu.
  • You have Office 2010 products (Word 2010, Excel 2010, Visio 2010, etc) published via XenApp with content redirection enabled so .docx, .xlsx, .vsd files launched in the VDI session will open using the published Office app.
  • Your users want to click on a Word, Excel, Visio, etc. document in a Sharepoint document library and click the Edit button to edit the document instead of just Read Only. They expect the published Office app to launch and allow them to edit the document.

In this scenario, when the user clicks on let’s say a Visio document in Sharepoint, the published app will launch but the document will not be sucked in. You’ll get a “File not found” error and if you look closely, the URL begins with “\\” as if it’s a UNC path instead of an HTTP path:


If you click OK, Visio will open but no diagram will open.

If you right click, Save As the Visio diagram to your C: drive and attempt to open it locally, it will launch the published Visio instance but will give you the following “File not found” error:


Again, look closely. It says “\\Client\” instead of your VM’s name.

Well, really it’s 1 fix and 1 workaround for now. Let’s start with the fix first. We’re going to get local files and files residing on network shares launching right using the published app. I’m going to use Visio and a .vsd file again as the example:

1. On the Windows 7 VM, you must enabled Native Drive Mapping to be able to launch the .vsd file via published Visio. You can follow the CTX article here to make the registry change:

or you can enforce it via group policy. One thing though, on Windows 7 x64 the path is:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\

Reg Type: REG_SZ
Add the Value: True

Once the value is set to TRUE, try launching the .vsd file you saved to your hard drive or on a network share. It will launch immediately. Then go to File – Save As in Visio and checkout the path bar. It will say “\\Client\C$\Users\xxxx\”. So now your system recognizes the word “Client”.


This is because you’re going through 2 virtualization layers. Citrix has an excellent article detailing how Client drives are passed through multiple sessions here:

You can also read more about the NativeDriveMapping key here:

Additionally here is a really good CTX article from Citrix that covers Client Drive Mapping troubleshooting that might be helpful to you:

And some info describing differences in Client drive mapping between the different versions of XenApp and Presentation Server here:

2. Now back to Visio diagrams in Sharepoint. First you need to verify content redirection is behaving correctly. In my case, I needed to make sure to change the published app location to include the “%**” switch. By default when you enable content direction, it will be:

"D:\Program Files (x86)\Microsoft Office\Office14\VISIO.EXE" "%*"

with just one asterisk. You need to add two so it looks like this:

"D:\Program Files (x86)\Microsoft Office\Office14\VISIO.EXE" "%**"

The reason for this is documented in this CTX article:

This was written for Presentation Server 4.5 but it still applies to XenApp 6.5 just fine.

Once you get content redirection squared away on your XenApp server, things will still not work correctly unfortunately when opening docs in Sharepoint in your XenDesktop session. You can try right clicking and editing but you will still get the File not found error. This error has nothing to do with Client Drive Mapping. Being a Sharepoint Architect in a previous role long ago, my gut feeling was this is a WebDAV issue. Remember, Sharepoint uses WebDAV with document libraries though to the casual observer it might appear to be a UNC file share path. My gut was telling me Receiver was not handling WebDav paths correctly and was treating them like regular SMB file share paths. No proof this is the culprit just yet, only a hunch.

Let’s run an experiment. In your Sharepoint document library, click Actions > Open with Windows Explorer:


You’ll notice the path bar says “” when you open it here:


Go ahead and launch the Visio diagram in this document library. When you try and launch it, it will launch published Visio and give you the same File not Found error as before. In some scenarios even an Access Denied error though it never actually was able to find the file. Again, it is looking for “\\” instead of using WebDAV (or the DavWWWRoot keyword) which should be parsed like the HTTP protocol “http:\\”. Sharepoint Content Redirection is never going to work because Citrix Receiver doesn’t know how to get there. One work around is to tell your users to save locally, edit, then upload. But this is annoying and most users will complain.

I started thinking Mini Redirector (which is Microsoft’s WebDav client and part of the Windows 7 OS) was trying to hand-off the DavWWWRoot keyword in the URL to Receiver and Receiver didn’t know what to do with it. Looking at the URL though it didn’t even seem to be passing it through. It was as if it was passing a straight UNC path. Or maybe is was not talking to owssupp.dll which is required to interact with and edit docs in Sharepoint. Maybe somehow it wasn’t handing off through Receiver properly. Now I was really starting to go down the rabbit hole and before I dug further, I figured I’d give Citrix Support a call and see if they had any input.

I was able to talk to a XenApp support technician and a XenApp Developer who were both very knowledgeable. I explained my WebDav theory and we ran a little experiment. We ran Process Monitor from my Windows 7 workstation and attempted to edit a simple Word document in Sharepoint. The published version of Word launched as expected and failed to find the file. Here is the URL that was passed to the PNAgent when we used the Process Tree display:


You can see that it passed:

\\Client\\\\link\to\doc\repository\test jason.docx"

Looks a bit odd, doesn’t it? No wonder it can’t find the file.

Then we went to the XenApp server with Word 2010 installed locally, opened Internet Explorer, and navigated to the Sharepoint document library. When I clicked Edit on the Word document this time, this is what was passed to the locally installed Word:


And of course the Word document successfully launched. You can see it passed a nicely formatted HTTP URL:"

The XenApp Developer verified this was actually a bug and needed to be fixed. It may or may not be WebDav related, but he confirmed there is definitely a disconnect at the Content Redirection level via Sharepoint as I had suspected. It has been added to their bug queue to get taken care of.

In the mean time, his suggestion is to publish Sharepoint itself on the same server Office 2010 products are installed on (publish IE passing the Sharepoint URL during launch). This is a good workaround but may annoy a few users. I always hate publishing IE because of the stuff you have to do to lock down/harden the browser. People can get confused and start browsing to Youtube or other process intensive websites using this published instance of IE if you don’t completely lock down the allowed URLs. This can cause a severe impact on XenApp performance for all users on the box. If I limit tabs, then people start complaining they can’t open additional tabs and the helpdesk gets flooded with phone calls. So just keep that in mind if you use this workaround.

Another work around I found online is by Anthony Obi:

He has an issue where owssupp.dll was not being detected on the client system (because it wasn’t there) and added an extra menu item in his Sharepoint deployment to edit documents as a work around. He modified the new Edit action to launch some Javascript that talks to PNAgent.exe that then talks to the published Office instance and passes the correct URL. This might work as well for you but of course it requires a modification of your Sharepoint environment and end user training.

I will post here as I get updates from Citrix Support on this issue. It’s a fairly unique scenario but definitely not uncommon in the real world as application delivery and desktop virtualization continue to be separated through multiple layers.

How to use PowerShell and PsExec to change the RDS license server name on all your XenApp servers

March 7th, 2013 No comments

Let’s say you decide to decommission your Remote Desktop Services (RDS)/Terminal Services Licensing Server or you moved your TS/RDS CALs to a different server. That means you need to change the name to the new server under Remote Desktop Session Host Configuration on all your XenApp servers.


This is a pain to do manually when you have several hundred XenApp servers. You can do it through group policy but you may only want to change it on a subset of servers in an OU and not all of them. So I used PowerShell and PsExec to precisely target all my XenApp servers I wanted to change. It’s a very quick option when you are pressed for time.

You’ll need to create rds.bat and rds.ps1 and put them in "d:\rdsscript" on the server you plan to run the Powershell script from. You’ll want to share out your "d:\rdsscript" folder on the server you plan on running the script from, otherwise you might get Access Denied errors because the script references a UNC path. The contents of these two files is below.

rds.bat contents:

powershell.exe -executionPolicy unrestricted -command 

rds.ps1 contents:

Import-Module RemoteDesktopServices
cd RDS:\
cd .\RDSConfiguration\LicensingSettings\SpecifiedLicenseServers
new-item –name newlicenseserver.yourdomain.fqdn
remove-item oldlicenseserver.yourdomain.fqdn -confirm:$false -recurse:$true

Modify the rds.ps1 script with the name(s) of the servers you want to add a the name(s) of the servers you want to remove. You can run rds.bat locally on a XenApp server as a test to see if it worked.

Now it’s time to run it on all your XenApp servers remotely. You can use any number of delivery methods. Again I chose to use PsExec because it’s quick and gets the job done. I highly recommend doing your dev, staging, etc. servers first before doing it in production.

Now copy PsExec.exe into the "d:\rdsscript" folder. You’ll also want to create psexec.bat and xenappserverlist.txt now. Here are the contents of the two files:

psexec.bat contents:

psexec -s @xenappserverlist.txt "\\yourserver\rdsscript\rds.bat" 

xenappserverlist.txt contents:


So your shared directory on the server you plan on running the script from will look something like this:


Now just double click on psexec.bat and it will run the script on each of your XenApp servers in the list. The “-s” tells psexec to execute as the local system account so you don’t have to put your username and password in the script. I don’t like to put usernames and passwords in the script because doing that would send it across the network in plain text so it may be a security concern.

Hope this helps. Let me know if you have any other methods to accomplish an RDS license server migration quickly. I’m always looking for more options. :)

AppSense Management Console crashes when trying to add Client Access Credentials

February 12th, 2013 3 comments

Sometimes after restoring an AppSense database and/or rebuilding an AppSense server, you might notice you can’t push agents (Client Communications Agent/CCA, Environment Manager Agent, etc.) to clients and it will give you an error in the Management Console. The Status field will say:

No client access credentials have been specified.  Please enter credentials before retrying to to Poll the client.

and under the Client Access Log, you can see more details on the error:

Could not use credential: "DOMAIN\UserID", error:  Password decryption failed, error: [Unable to access the Master Key on the server, error was Keyset does not exist.]

In a pinch, you can manually install the agents on the client and they will start checking in but you are still going to get these error messages in the Management Console:


When you go to “Client Access Credentials”, you will get prompted with the following error message:

DataAccessServices.CryptoManager+MasterKeyAccessException: Unable to access the Master Key on the server, error was Keyset does not exist


If you hit OK and attempt to enter the missing credentials, the AppSense Management Console will crash on you. As in the entire MMC will crash and disappear. Don’t worry, this is an easy fix.

1. Go to Start > All Programs > AppSense > Management Center > AppSense Management Server Configuration


2. The Encryption field will likely be red. Just click it and you will see the Encryption Key Status is “Not Valid”. The Transfer Key may also say “Not Present”:


3. Go ahead and click the “Regenerate” button. It will warn you asking “Are you sure that you want to replace the current master key hash? A new master key hash will be regenerated”. Go ahead and click OK:


4. Now click “Store” for the Transfer Key. It will ask you to enter a new Transfer Key Password. Go ahead and type it in and press OK. One thing to note, if you are load balancing the Management Server and it says the Transfer Key is “Present”, do not click Store and enter a new one. Instead just click Retrieve and type the password when prompted. If you are load balancing and it doesn’t have the Transfer Key present, use Store on the first server and when performing these steps on the second server, use Retrieve:


5. Now your Encryption settings should look something like this. Encryption key is “Valid” and Transfer Key is “Present”:


6. Now open up the Management Console again and you should should be able to add credentials under Client Access Credentials. You might even see the old user name and password in there. You will have to re-enter the password on it though:


7. Now go back to your Deployment Group and find your client machine. Click “Poll Now” and it should successfully poll impersonating using the credential you entered.


How to troubleshoot RADIUS or TACACS authentication issues on a Netscaler/Access Gateway

February 5th, 2013 2 comments

A lot of companies use RADIUS or TACACS authentication on a Netscaler for use with Access Gateway (AGEE) which is pretty secure. Sometimes you might have users that complain they can’t login via the Access Gateway. There are a few things you can do to troubleshoot authentication issues. I’m going to run through some screenshots from a NS 9.3 device because that’s what I have in front of me at the moment but the same troubleshooting methods can apply to NS 10.x.

Capturing AAA authentication traffic in real-time
1. SSH into the Netscaler, login with your admin credentials, then enter shell by typing:


2. Now you want to capture the authentication in real time and see exactly what the error looks like. This is handled by the AAA (Authentication, Authorization, and Auditing) on the Netscaler. So type the following:

cat /tmp/aaad.debug

A successful authentication against the Access Gateway would look like this. The user is named User1:

process_kernel_socket call to authenticate
user :User1, vsid :414
Tue Feb  5 09:53:53 2013
start_radius_auth attempting to auth User1 @
Tue Feb  5 09:53:53 2013
 process_radius radius accepts : User1
Tue Feb  5 09:53:53 2013
 process_radius extracted group string :(null)
Tue Feb  5 09:53:53 2013
send_accept sending accept to kernel for : User1

and an unsuccessful authentication would look like this. The user is named User2:

Tue Feb  5 09:50:11 2013
process_kernel_socket call to authenticate
user :User2, vsid :414
Tue Feb  5 09:50:11 2013
 start_radius_auth attempting to auth User2 @
Tue Feb  5 09:50:11 2013
 process_radius radius rejects : User2
Tue Feb  5 09:50:11 2013
 start_radius_auth attempting to auth User2 @
Tue Feb  5 09:50:14 2013
 process_radius retransmit radius packet
Tue Feb  5 09:50:17 2013
 process_radius retransmit radius packet
Tue Feb  5 09:50:20 2013
process_radius rad_continue_send_request:No valid RADIUS responses received
Tue Feb  5 09:50:20 2013
 process_radius unknown return value from rad_continue_send_request :-1
Tue Feb  5 09:50:20 2013
 process_radius radius rejects : User2
Tue Feb  5 09:50:20 2013
 send_reject sending reject to kernel for : User2
Tue Feb  5 09:50:23 2013
lwagent.c[1107]: main EV_DEBUG: handle time out

you can see very clearly that the authentication server has denied access. This points to an issue on the authentication server. To stop the capture, just hit Ctrl + Z.

Viewing the ns.log using Syslog Viewer
1. You can look at all the failed logins in the ns.log. In the Netscaler admin console/GUI, go to System > Auditing and click the “Syslog messages” button:


2. Select the AAA module and then double click each ns.log file. You will immediately see all the “LOGIN_FAILED” event types as you go through each ns.log (these are the logs stored at /var/log on the Netscaler). Pay attention to the message, it will tell you why the authentication attempt failed. As you can see in this example, the authentication server is the problem and is denying access:


Running a Trace
1. Lastly you can run a network capture/trace when users are experiencing the issue. You can do this via the console/GUI easily by going to System > Diagnostics and clicking on “Start new trace”:


2. Set the packet size to 0 and hit Start:


3. Stop the trace once you feel you have enough traffic captured:


4. Download the nstrace .cap file and you can open it in Wireshark for further analysis:


Hope this helps some of you. Let me know if you have any other methods of troubleshooting authentication issues you would like to share. LDAP troubleshooting is easier since the Netscaler can give you a lot more detail as to what is failing. RADIUS and TACACS is a little trickier since you have something in the middle to troubleshoot but the steps above should give you enough to tell you if the problem resides on the Netscaler or on the authentication server.

How to launch multiple sessions of a XenApp 6.5 application without stealing the original session

February 5th, 2013 2 comments

If you have an application that requires more that one session per user, as in they want 2 sessions open to the same application concurrently, there are a few things you need to do. You have run through all these steps. Otherwise you’ll be left scratching your head trying to figure out why the 2nd session keeps stealing the 1st session and you only get 1 application window open. :)

1. Verify the app is set to allow multiple sessions. By default “Allow only one instance of application for each user” is unchecked. Leave it like that.


2. Log into your Web Interfaces and right click on your XenApp Web Site. Then click Workspace Control. Make sure the Reconnect Button is set to “Allow users to customize”. This allows the select users who need concurrent application sessions to modify their settings without having to impact the rest of your users.


3. Verify Remote Desktop Session Host on your XenApp servers is set to allow more than 1 session. Most people forget this one since it’s not really a Citrix setting. Go to Start > All Programs > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration. Double click on “Restrict each user to a single session”:


and under the “General” tab, uncheck “Restrict each user to a single session”:


4. Have the user login to the Web Interface. Have them click Settings in the top right and uncheck the “Reconnect” option. Then hit Save:


5. Now have the user try to launch 2 sessions of the same app one right after another. You should have 2 sessions launch now. Here is an example with Notepad: