Archive

Author Archive

How to create a XenApp 6.5 Server 2008 R2 golden image for PVS 6.1

April 24th, 2013 No comments

I urge you to read my PVS 6.1 on XenDesktop/Windows 7 guide first. Read it and make sure you understand it. The same concepts and most all procedures apply to Server 2008 R2. So I am not going to get as detailed on PVS technology in this article. This is going to be more XenApp centric. If you don’t have a thorough understanding of PVS, it is easy to become lost so please make sure and read that article and go through those screenshots first.

Citrix has an excellent eDoc primer for understanding the intricacies of XenApp on PVS located here. I recommend skimming this before beginning:

http://support.citrix.com/proddocs/topic/xenapp65-install/ps-image-prep.html

Now on to the steps. This is just my way of doing it. It works well for me. There are a couple of different ways you can achieve the same thing so use what works for you:

1. I am assuming you already have a XenApp 6.5 farm created and at least one dedicated server for the role of the ZDC. All XenApp servers provisioned via XenApp will be member servers of this farm and you do not want them to become a ZDC. Just set the election preference in AppCenter under Zones. In this example, I have a Default Zone and have set one server as the ZDC but it is best practice to have at least a handful of servers that are not provisioned to be set as preferred. Just in case one goes down, you don’t want one your provisioned servers to become a ZDC:

1

2. Now go to your XenServer and create a new Server 2008 R2 VM

3. Install XenServer Tools

4. Make a copy of the VM and convert it to a template. This is your “clean” Server 2008 R2 image you can come back to later if you need to. You can spin up new VMs from it.

5. Now go back to the VM you were working on and install things that are needed on all servers like Symantec, Citrix Offline Plugin (if you intend to leverage app streaming), etc. but try to keep it as clean as possible. Remember, you are building just the base right now. Don’t install any applications you plan to publish yet.

6. Add the server to the domain. Make sure the name is the first server in your naming scheme, example: “ServerName-100″ where 1 denotes the image number and 00 is the VM number. The next VM that gets spun up using this image will be ServerName-101 and so on.

7. Begin installation of XenApp 6.5 like normal and follow Approach 3 detailed here:

http://support.citrix.com/proddocs/topic/xenapp65-install/ps-image-prep.html

8. If you have multiple NICs in your PVS environment for streaming vs. regular network traffic there’s an extra step you have to perform in the VM. Make sure you go into ICA Listener properties and set it to PVS Adapter #1, the network NIC. Not the PVS streaming NIC which is #0. They may be labeled differently in your environment depending on the NIC order of your VM. Just remember, you want the network NIC to handle ICA, not the streaming NIC.

9. Now install the apps you intend to publish. Just install, don’t try publishing anything yet. If you plan on streaming apps to your XenApp servers via Citrix Offline Plugin or App-V, skip this step.

10. Install the PVS Target and reboot. Do not run Imaging Wizard yet.

11. You can choose to install the EdgeSight agent at this point if you use EdgeSight in your environment. There is an excellent guide from Citrix on how to install EdgeSight in a PVS environment below. Don’t worry, when it detects the PVS Target software is on the system and the image is in private mode being updated, it won’t start the EdgeSight service and start sending your EdgeSight server junk data:

http://support.citrix.com/proddocs/topic/edgesight54/es-agent-install-streamed.html

12. Log back in to the VM and in the XenCenter console, set the PVS boot disk to boot first (BDM). Then go to the PVS Console on the PVS server and create a new Device with the MAC address of this VM’s provisioning/streaming NIC. Call the device ServerName-101 so it’s separate from the ServerName-100 original but call the vDisk 100 so you know where the image came from later (i.e. image 1). Set device to Boot from Hard Disk. Now reboot the VM. You can let Imaging Wizard do this but if you really want to be hands on, you can choose to create and attach an empty vDisk of the same size as the c: drive of the VM now.

13. It should have booted from the BDM boot disk and be connected to the empty vDisk you created. Run Imaging Wizard and push the image across to the PVS Server vDisk (don’t forget to optimize the image). If you did not create a vDisk in the above steps, just create a new disk and run through the Wizard prompts to create it real quick. It will assign the device to this new vDisk. Reboot when you are asked to.

14. Log back in and immediately XenConvert will launch and begin pushing your image over to the newly created vDisk.

15. Now go to the PVS console and set your device to boot from vDisk and reboot your VM. It should now be booting from your vDisk.

16. Log back in and re-run XenApp configuration and unjoin from farm using the prep option. This is done by going to Start > Programs > Administrative Tools > Citrix > XenApp Server Role Manager > and then clicking on the XenApp Server Role Manager app. Click Edit Configuration. Then click Prepare this server for imaging and provisioning. You want to just leave the defaults checked which is to remove it from the farm and join on the next boot. Once it removes it, it will ask you to reboot. Just close and power down the VM, don’t reboot.

2

3

4

17. Go to your PVS server and change the vdisk from private to standard mode. Now spin up a few VMs using the “Streamed VM Setup Wizard” in the PVS console. You’re going to need a template and you’re going to want to setup your write cache. I’ve covered this very well in my PVS 6.1 on XenDesktop/Windows 7 guide so I’m not going to get into the details here. Wait until the VMs are created and powered on.

18. Go to your ZDC and open up AppCenter and run a Discovery. You should see the new member servers. At this point you can begin publishing or streaming apps to them.

TO MAKE CHANGES AND RESEAL THE IMAGE
1. Boot a device into maintenance mode after creating a maintenance version on the vDisk. Or you can choose to power down all your running VMs and put the disk into private mode. Your choice.

2. Make your changes.

3. Re-run XenApp configuration and unjoin from farm using the prep option.

4. Shut it down and promote the image to production if using versioning. Or put the disk back into standard mode if you used the other method.

5. Reboot all your devices so it gets the new vdisk

I hope this guide helps. Please feel free to leave a comment below if you have any questions. I’ll try and help as best as I can. :)

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:\\sharepoint.domain.com. 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.

THE PROBLEMS
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:

2

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:

1

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

THE FIXES
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:

http://support.citrix.com/article/CTX130378

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\
Advanced\Modules\ClientDrive

NativeDriveMapping
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”.

3

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:
http://support.citrix.com/article/CTX127872

You can also read more about the NativeDriveMapping key here:
http://support.citrix.com/article/CTX124389

Additionally here is a really good CTX article from Citrix that covers Client Drive Mapping troubleshooting that might be helpful to you:
http://support.citrix.com/article/CTX238200

And some info describing differences in Client drive mapping between the different versions of XenApp and Presentation Server here:
http://support.citrix.com/article/CTX127614

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:

http://support.citrix.com/article/CTX116887

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:

4

You’ll notice the path bar says “http://sharepoint.domain.com” when you open it here:

5

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 “\\sharepoint.domain.com” instead of using WebDAV (or the DavWWWRoot keyword) which should be parsed like the HTTP protocol “http:\\sharepoint.domain.com”. 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:

6

You can see that it passed:

\\Client\\\sharepoint.domain.com\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:

7

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

http://sharepoint.domain.com/link/to/doc/repository/test%20jason.docx"

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:

http://community.obilogic.co.uk/blogs/teamblog/archive/2011/10/25/sharepoint-2010-edit-document-via-citrix-xenapp.aspx

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.

1

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 
"\\yourserver\rdsscript\rds.ps1"

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" 
pause

xenappserverlist.txt contents:


XenAppServer01
XenAppServer02
XenAppServer03
XenAppServer04
XenAppServer05

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

2

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:

2

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

1

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

8

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

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

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

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

6

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:

9

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.

7

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:

shell

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:

usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[614]: 
process_kernel_socket call to authenticate
user :User1, vsid :414
Tue Feb  5 09:53:53 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[138]: 
start_radius_auth attempting to auth User1 @ xxx.xxx.xxx.xxx
Tue Feb  5 09:53:53 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[741]:
 process_radius radius accepts : User1
Tue Feb  5 09:53:53 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[743]:
 process_radius extracted group string :(null)
Tue Feb  5 09:53:53 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[1466]: 
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
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[614]: 
process_kernel_socket call to authenticate
user :User2, vsid :414
Tue Feb  5 09:50:11 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[138]:
 start_radius_auth attempting to auth User2 @ xxx.xxx.xxx.xxx
Tue Feb  5 09:50:11 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[788]:
 process_radius radius rejects : User2
Tue Feb  5 09:50:11 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[138]:
 start_radius_auth attempting to auth User2 @ xxx.xxx.xxx.xxx
Tue Feb  5 09:50:14 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[731]:
 process_radius retransmit radius packet
Tue Feb  5 09:50:17 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[731]:
 process_radius retransmit radius packet
Tue Feb  5 09:50:20 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[778]: 
process_radius rad_continue_send_request:No valid RADIUS responses received
Tue Feb  5 09:50:20 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[785]:
 process_radius unknown return value from rad_continue_send_request :-1
Tue Feb  5 09:50:20 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/radius_drv.c[788]:
 process_radius radius rejects : User2
Tue Feb  5 09:50:20 2013
/usr/home/build/rs_93/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[1562]:
 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:

1

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:

2

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

3

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

4

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

5

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

6

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.