JasonSamuel.com

I’ve covered Access Gateway quite a bit in the past and these two articles on my blog are a good primer for what I’m about to cover:

1. How to setup your Citrix Netscaler (Access Gateway) and Web Interface for iPads and mobile devices that use Citrix Receiver

2. Quick way to brand Access Gateway and Web Interface 5.4 with company logo and colors

Now let’s throw a new scenario into the mix. You want to allow users from another domain access to resources through your Access Gateway and Web Interface. Here is what you need to do to accomplish this.

SETTING UP A DROPDOWN BOX TO PASS THE DOMAIN
On your Access Gateway, if you followed my “branding guide” article above you will have noticed on the themes available from the Citrix blogs there are 2 versions, one normal and one with a dropdown. If you chose Horizon to customize like I did, make sure to download Horizon2.gz which has the code for the dropdown already in it. You just need to add your domains in the code. This is found in these two files:

\Horizon2\ns_gui\vpn\index.html

\Horizon2\ns_gui\vpn\tmindex.html

If you have your own theme and just want to add the code, Citrix has an excellent CTX article here covering it:

How to Add a Drop-down Menu with Domain Names on the Logon Page for Access Gateway Enterprise Edition:
http://support.citrix.com/article/CTX118657

What’s happening here is that a dropdown box is created with pre-populated domain names that you specify in your code. The user selects the proper domain when logging in and then this domain name is inserted into the header and passed to the Netscaler Access Gateway vserver where the authentication policy examines it. Based on the name the Netscaler sees in the header, it forwards the request on to the correct authentication server. This works great with LDAP authentication servers. I have not tested it with TACACS or RADIUS yet.

SETTING UP ACTIVE DIRECTORY LDAP AUTHENTICATION
Now it’s time to setup your Active Directory authentication for each of your domains.

1. Download LDAP Browser 4.5 for free here: http://www.ldapbrowser.com/download.htm

2. Go to your Netscaler under System > Authentication > Servers tab and create a new LDAP server. Use port 636 for secure LDAP instead of 389. Use LDAP Browser to get the Base DN and Administrator Bind DN. I prefer to use the app so I don’t fat finger the distinguished name and spend an hour trying to figure out that I missed a comma. Using LDAP Browser is much quicker and less error prone. The Base DN can be your entire AD domain or you can lock it down to an OU. The Administrator Bind DN is the actual account name that is used to enumerate AD. So CN = the user name, OU= the OU it’s in, etc. Add the password for this service account.

Make sure to select “SSL” for security type near the bottom. Click the blue “Retrieve attributes” link and it should talk to AD. Then the drop down boxes in Other Settings will not be greyed out anymore. Set the following:

Server Logon Name Attribute = samAccountName
Group Attribute = memberOf
Sub Attribute Name = CN
SSO Name Attribute = UserPrincipalName

So everything should look like this so far:

3. Now expand the Netsted Group Extraction arrow near the bottom. You need to enable it and set the same Group Name Identifier as you did for Server Logon Name Atrribute. In this case samAccountName. Then press OK to create the server:

4. Now it’s time to create the policy and bind it to the server. Hit the tab for Policies and create a new policy. Choose the server you just created. For the Expression, you will want:

REQ.HTTP.HEADER Cookie CONTAINS domain1

where domain1 is the name of your first domain.

5. Now do steps 2 through 4 again but for your second domain, domain2.

6. Almost done. What we’ve done so far is create two authentication servers and two authentication policies. These two policies are good for web browser users (IE, Firefox, Chrome, Safari, etc.) but mobile devices using the Citrix Receiver native app like iPhones, iPads, Android phones, Android tablets, etc. will not work just yet. This is because they cannot pass cookie values. Nor do they pass the domain during authentication against the Access Gateway (a traffic capture can confirm it only passes user ID and password). You need to create a different set of authentication policies for these. So you will create one for each domain. You will bind to the same authentication server as the other policies but you’ll want to add the word “mobile” or something descriptive to the end of the policy name so you know what it is for. The expression should be:

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver

7. Now do the same for your other domain, domain2.

8. Now go to your Access Gateway vserver and add all 4 policies you created. Take a look at my example screenshot closely and the priority order.

Here is the logic behind this policy order:

100 – Domain1 user logs in via web browser and uses drop down/passes cookie for domain1 so authenticates against domain 1 DC.

110 – Domain2 logins via web browser and uses drop down/passes cookie for domain2 so authenticates against domain 2 DC

120 – Domain1 user logins via iPad so first two policies are automatically false since the native Citrix Receiver app can’t pass a cookie. Authentication policy is looking for CitrixReceiver in the header so it will try to authenticate against domain 1 DC. It will be successful and the user will see his apps.

130 – Domain2 user logins via iPad. The first two are false for the same reason as 120. The expression from policy 120 is true so the user will actually authenticate and fail against domain 1 DC. Then it moves on to the 130 policy and authenticates against the domain 2 DC. It will be successful and the user will see his apps. Note, if a user has the same account name on both domains, it will cause a rejected login attempt on domain 1 which depending on your Active Directory account lockout policy can eventually lead to an account lockout. Just be mindful of this and adjust your policy accordingly if you need to.

MODIFYING YOUR SESSION POLICIES
9. Now on to the session policies. If you followed my guide on How to setup your Citrix Netscaler (Access Gateway) and Web Interface for iPads and mobile devices that use Citrix Receiver you should have 2 policies. One for regular traffic and one for mobile/Citrix Receiver traffic. Should look something like this:

Go ahead and click on the blue profile link for the CitrixReceiver policy first.

10. Under the Published Applications tab, clear the Single Sign-on Domain, you don’t need it anymore. SSO is being handled by the authentication server now. Specifically the SSO Name Attribute setting for each server which you set as UserPrincipalName. So it is automatically passing the UPN formatted user credentials to the Web Interface as the same time the user is successfully authenticating against the Access Gateway using the SAM account name. Pretty cool right? Now do the same for your other policy that controls regular web traffic.

11. An extra step for your mobile traffic policy. Under the Client Experience tab, you can set the Clientless Access to Allow and the Plug-in Type to Java but it’s not necessary. It will still work but since it’s mobile traffic only, this won’t hurt.

SETTING UP ACTIVE DIRECTORY AUTHENTICATION GROUPS
12. Now let’s move on to setting up your authentication groups. Let’s say each domain has a security group that gives users access via the Access Gateway. Again, there are 2 well documented methods for group extraction:

How to Configure a NetScaler Appliance for Active Directory Group Extraction for LDAP:
http://support.citrix.com/article/CTX111079

How to Configure a NetScaler Appliance for Active Directory Group Extraction for LDAP Using the Groups Allowed To Login Feature:
http://support.citrix.com/article/CTX125797

I prefer the first method. It’s basically just one step in one place (the authentication server object) and goes into effect at the authentication level. No fooling around trying to control it via a session policy. So go back to your 2 authentication servers you created before and take a look at the Search Filter field. It should be blank at the moment.

13. Go to LDAP Browser and get the DN for for the security group you want to give access to for your first domain.

14. Go back to the Search Filter field and type memberOf= followed by the DN (distinguished name) for the security group. So it should look something like this:

That easy. Make sure to do it for the authentication server for domain 2 as well. Go ahead and test your login scenarios and everything should work perfectly.

ADDING REDUNDANCY FOR YOUR AUTHENTICATION SERVERS
I only covered how to add a single authentication profile (domain controller) for each of the 4 policies on the vserver. Most companies are going to have multiple DCs. There is no way to add multiple DCs per authentication policy. The solution is to create a Load Balanced vserver with all your DCs behind it per domain and then add the IP of the vserver to an authentication server that is bound to the authentication policy. So in the example I’ve been showing you, I would have to create 2 load balanced vservers since I am working with 2 domains.

15. Go to Load Balancing > Servers > and add all your servers here:

16. You guys know I prefer to create service groups vs. services and the reasons why if you’ve read my previous Netscaler articles so go to the Service Groups section and add a new services group. Select SSL_TCP for the protocol.

Specify the server based members and make sure to set the port to 636. You can weight the servers here if you want to. Under the Monitors tab, go ahead and add a ping monitor or whichever monitor you prefer. Do this for each group of your authentication servers. You might want to group them by city, datacenters, production vs. DR, or whatever makes sense in your environment.

17. Now create a load balanced virtual server for your first domain. Select SSL_TCP for the protocol, port 636, and give it an IP address. Under the Service Groups tabs, add the groups you need. Keep in mind you won’t be able to see the SSL_TCP service group you created until you set the vserver protocol to SSL_TCP. Under the Methods and Persistence tab, you can get creative if you like or just leave it the default Least Connection. It really depends on your environment and where you prefer traffic to go. Under the SSL Settings tab, bind the cert you use for your Access Gateway vserver. Do all of this for your other domain as well. Both load balanced vservers should be in the UP state at this point.

18. Now go to System > Authentication > Server tab and left click on one of the DCs. Then at the bottom click Add, this will copy all of the settings on the DC you had highlighted and allow you to create a new one based off of it. So you don’t have to put all your DNs and stuff in again. Just give it a unique name and for the IP, type in the IP of LB vserver you just created for that domain:

Now do the same for the other domain.

19. Now go to the Policies tab and edit each of your 4 policies. You can simply change the server in the drop down to the new one you created for each of your 4 policies and you’re done. All authentication traffic is now going through your load balanced vservers. Keep in mind that before, LDAP traffic was going from your NSIP to each DC. When you use LB vservers, traffic is going from the SNIP to each DC. So make sure you have your firewall ports open from the correct source IPs or you won’t be able to authenticate. Retest all your scenarios and everything should continue to work just as before.

TROUBLESHOOTING LOGINS
Once you’ve set everything up you might encounter issues and need to troubleshoot. There are a few ways to troubleshoot logins. I’ve covered this before here:

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

20. First you can troubleshoot the authentication layer but capturing of all authentication happening on the device. Open Putty and connect via SSH to your Netscaler. Enter the shell by typing

shell

and pressing enter. Then type:

cat /tmp/aaad.debug

and the cursor will go to the next screen and wait. Open up your web browser and attempt to login to the Access Gateway. Immediately you will see the request happen in your SSH window. You’ll see exactly what is happening line by line like this. You’ll even see the nested group extraction taking place:

The last line will show the accept or reject:

When you’re done, press Ctrl+Z to exit.

21. The next layer to troubleshoot is all the polices. All of them, authentication, session, etc. You want to see everything a user hits when he logs in. So type the following:

nsconmsg -s disptime=1 -d current -g pol_hits

and login to the Access Gateway again using a web browser. Immediately in your Putty window you’ll see what all policies were hit:

This will help troubleshoot your policy flow. We’ve built a lot of intelligence into the cascading authentication and session policies and based on the user’s device and domain, it will vary what all they hit. This is an excellent way to test each of those scenarios.

22. The last step is getting down to the packet layer and analyzing the traffic using Wireshark. I’ve covered this in my previous post but go to System > Diagnostics > Start New Trace and set the packet size to 0. Then press Start.

Login to your Access Gateway via web browser, stop the capture, and download it to your desktop. You will also want to WinSCP into the Netscaler and grab the SSL RSA key for the SSL cert you are using on your Access Gateway site so you can decode the SSL traffic. Then double click on the .cap packet capture file and it will open in Wireshark. Go to Edit > Preferences > Protocols > SSL > and click Edit in the RSA Keys field:

In the SSL Decrypt Window, hit New in the bottom right side and this window will popup. Type in the IP address of the Access Gateway vserver, port 443, protocol http, the exact path on your hard drive to the SSL RSA key file, and leave the password blank. Then press OK to add it:

Press okay and get back to your capture. Now in the Filter field, just type the following:

frame contains youruserID

because we want to find all the instances of your user ID being passed. You should be able to find your user ID and password in plain text. Follow the TCP stream if you need to to find out exactly what is happening.

Hope this helps. Please leave a comment if this post helped you or if you have any questions and I’ll try my best to help.

If you’re running a Citrix VDI implementation using Provisioning Services (PVS) and XenDesktop, you need a way for your help desk and even the end user to easily identify the VM and pertinent system info easily. BGInfo is the tried and true way of doing this in a corporate environment. A simple overlay for the wallpaper. In a PVS environment, a lot of the info you would need to grab from a physical desktop are useless since it all goes away after the VM reboots and you’re back to a clean image. A lot of companies use BGInfo to quickly see troubleshooting data without having to use a management tool or agent. With PVS VMs, troubleshooting itself is rarely necessary. You just tell the user to reboot and they’re back to a clean slate. So BGInfo can be leveraged as more of an identification tool for when the user calls in than a troubleshooting tool. Download BGInfo from Microsoft here:

http://technet.microsoft.com/en-us/sysinternals/bb897557.aspx

I did a little custom BGInfo configuration to capture just the important pieces of info for my Windows 7 PVS XenDesktop environment. Of course this might differ for your environment and you might need more fields but this is a good starting point:

1. A Title – let’s the user know they are on a Windows 7 VM and not a workstation. Users can get confused when switching back and forth.

2. Host name – for when the help desk asks the user the name of their VM

3. IP addresses – both the streaming NIC and LAN NIC IPs. Not really necessary in a PVS environment obviously, but nice to have it displayed.

4. User Name – good to know what account the user is logging in with

5. Boot Time – very important to know in a PVS environment. You know those calls you get saying a person’s desktop looks completely different from everyone else and after you investigate a bit you figure out they’re on an old version of the image because they haven’t rebooted in forever. Yeah, this will help with that.

6. Write Cache free disk space left – another very important piece of info in a PVS environment. Once the write cache gets filled up, the VM is done and users start calling in. Good to know how much the user has left. Also a good way to gauge if your allocated write cache is truly enough for your environment or if you need to think about growing it.

So here’s how my desktop looks, very simple and clean:

I like to bake BGInfo into my images. I just create a folder called c:\BGInfo and copy Bginfo.exe in there. I’ll get to the other 2 files in a second.

Run Bginfo.exe and you get all the default stuff, delete it all and start clean adding just the stuff you need. Here’s how mine looks:

Don’t forget to set your settings under Position > Multiple Monitor Configuration for people with more than 1 monitor. I like mine to just be on the primary screen:

And under Desktops, you’ll want to change it for pretty much anyone that hits the VM using any method. I set mine to “Update this wallpaper” for all scenarios and prompt if it has an issue setting it (so I can investigate if anyone reports an issue):

Then go to File > Save As and save your configuration file. It will be saved with the .bgi extension.

That’s it for the implementation side. For PVS though, you’re going to have a lot of different NICs and you don’t want a bunch of “0.0.0.0″ IPs being displayed. I just wanted my streaming IP and LAN IP displayed. So under Fields click Custom:

and then click New. You will need to create a new field called “IP Addresses” and do a WMI query to pull the IPs of only the active NICs. I used the following query:

SELECT IPAddress FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled=TRUE

Which will look like this when you are entering and Evaluating it:

Make sure to name the Identifier when you are saving it:

Then just add the field and hit apply and you should see both IPs appear.

Now the last part is the Write Cache free disk space percentage. I could not find a way to do it from just a simple WMI Query. So I wrote this little .vbs script and stuck it in c:\BGInfo. As you can see, my write cache drive is the Z: so you will need to change the code to whatever drive letter you are using:

' Display Write Cache percentage free (z:)
' Written by Jason Samuel (www.jasonsamuel.com) for use with BGInfo 

Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")

Set colDisks = objWMIService.ExecQuery _
    ("Select * From Win32_LogicalDisk Where DeviceID = 'z:'")

For Each objDisk in colDisks
    intFreeSpace = objDisk.FreeSpace
    intTotalSpace = objDisk.Size
    pctFreeSpace = intFreeSpace / intTotalSpace
    Echo FormatPercent(pctFreeSpace)
Next

Then just create a new Field and set the VB Script for it:

Add the field to your config and hit Apply and it should show the percentage free on your desktop. Now just create a group policy to run it every 5 min. Or you can schedule a task to run it every 5 minutes in the VM itself. I like to use these switches:

/accepteula /timer:0 /log:"C:\BGInfo\BGInfo.log"

If you want BGInfo to run just once, it is very easy to do via scheduled task, GPO, login script, registry, or even adding it as a shortcut under Startup. Just Google it, tons of ways out there. But if you want it to run every 5 minutes and refresh the info, the only way to do it is via GPO. If you bake in into a local scheduled task in the image like I mentioned above, it will not work in a provisioned environment. It will attempt to run under the Administrator account of the maintenance image. So if you baked it in as “VM0001\Administrator”, a provisioned VM named VM0054 will not have this account. This will cause the scheduled task to fail. It won’t run under the System account either. The System account won’t run interactively. The task will start but stay running indefinitely and you will get an error like this in the BGInfo log:

An error occured while attempting to set the new desktop settings.
Please ensure the current user has rights to change desktop settings:
This operation requires an interactive window station.

To get around all this, use group policy. By default group policy will run the scheduled task under “%LogonDomain%\%LogonUser%” which is exactly what you want. Here is how my group policy looks:

Notice I have 2 triggers. The first trigger is to run BGInfo at login and update the wallpaper. But when opening a VDI session from a Win 7 host, it may open in Desktop Viewer but not in full screen. When the user goes full screen, the desktop wallpaper will not resize automatically and instead appear as tiled. So to get around this, I have a second trigger that runs BGInfo again 30 seconds into the session and runs every 5 min from then on. Hopefully within that 30 seconds, the user will have gone full screen and BGInfo will get a chance to run at the resolution the user will use throughout their session. One thing to note, I suggest adding a 3rd trigger that runs BGInfo on workstation unlock like this:

This is very useful in VDI when you go from a Desktop to an iPad for example. Upon login, it will immediately update the wallpaper resolution and run indefinitely every 5 minutes. This is a lot of triggers but it covers all your bases. I really wish BGInfo had a “Fit” setting for the wallpaper like Windows 7 has by default. It would avoid this whole resize mess. Right now BGInfo 4.16 only supports Center, Tile, and Stretch for the wallpaper.

Also if you decide to store the Bitmap BGInfo creates in a central place like c:\BGInfo, make sure Users and/or Authenticated Users have Full Control to c:\BGInfo and all child objects and change the location the .bmp is stored to under this folder. Othwerwise the background may not change for users that are not admins on the VMs:

Lastly, you might get an error like below, but the wallpaper does in fact update.

An error occured opening the Default Desktop registry key.
Please ensure the current user has rights to change Logon Desktop settings:
Access is denied.

This is because the user is not an admin and does not have rights to change the Logon Desktop settings. Either give permissions to do this or go back into your .bgi and uncheck the “Display an error when user permissions prevent a Logon Desktop from being modified” option that you had set before for troubleshooting purposes under the Desktops settings in BGInfo. Then the popup will stop.

One thing I’ve been trying to do is brand BGInfo with my company logo. But I don’t want a big white box around it like when you use a jpg. I want to use a transparent gif. BGInfo does not support this from all the things I’ve tried so far. For example, here is the Amazon logo as a transparent gif:

Looks great on a white background but I want to use it with the standard Windows 7 wallpaper which has a gradient. It looks pretty awful because BGInfo flattens it somehow when creating the bmp causing there to be a black background around the logo:

But if your company chooses to use a standard wallpaper with no gradient, like a solid white background for example, just edit the background of your logo to match the color of the background and save it as a jpg. Add it to BGInfo and it will look perfect. Here is the Amazon logo (jpg with white background) with BGInfo set to white for the background wallpaper:

Hope this helps. Let me know if you have any questions or suggestions for custom fields to add that might be handy in a PVS XenDesktop environment.

Had an interesting morning. Our network team discovered my workstation was making around 6000 requests an hour on RDP port 3389 through our internal firewall to an unroutable network reserved in our server subnet. Basically a SYN flood (DOS/Denial of Service attack) was being executed internally from my workstation. I know my machine is clean and the only thing I had open was XenCenter. It had been running for about a week now, that was the last time I rebooted my workstation. So time to put on the detective hat and figure this one out.

While using TCPView to do a live netstat, I discovered that XenCenter by default will always establish a connection via RDP when you click the Console tab. It tests to see if RDP is available on the VM and then ungreys that “Switch to Remote Desktop” option. Even if you are using a console session, XenCenter wants to see if RDP is an available option to you. You know that little flash of the console you usually see after hitting the Console tab? That’s the XenCenter console checking for RDP and “connecting” to the VM transparently to verify RDP is available. Not so transparent and actually annoying but I never thought too much about it.

SYN_SENT on 3389:

Established connection:

Terminating connection:

The problem is in a PVS environment, you usually have your network split between a streaming traffic NIC and a regular traffic NIC. The streaming traffic NIC is supposed to be the first NIC/device. So Device 0. It will look something like this on all your VMs:

Where the first streaming NIC is only routable within the Blade enclosure or server subnet and the secondary NIC routable and used for regular network traffic.

Well the problem is that when you click the Console tab on one of these VMs, XenCenter will send a SYN request to what IP is at Device 0. So in our case, an unroutable IP in the server subnet.

Not a problem right? Well it never stops. It continuously sends the SYN requests attempting to connect. Even if you click off the Console tab or go to another VM, it continues to try RDP on that IP. Our firewall separating workstation and server subnets was getting hammered. You can verify because your Console will have the “Switch to Remote Desktop” option greyed out during this whole process.

and TCPView will show all those little red SYN_Sent attempts. After a few days of leaving XenCenter up and clicking from console to console, the amount of traffic hitting your firewall will be tremendous. It will look like a SYN flood attack. If you have an IPS or IDPS (Intrusion Prevention or Intrusion Detection & Prevention System), it might even shut down your port.

I called Citrix and submitted a ticket with their development team. I got a call back later and there is a work around. In XenCenter, go to Tools > Options > and click the Console option. Then uncheck “Enable Remote Desktop console scanning”:

When you uncheck this, it will also uncheck “Automatically switch to the Remote Desktop console when it becomes available”. This is fine:

After this you will notice the SYN flood will immediately stop and all your VMs will now have the “Switch to Remote Desktop” option ungreyed from the get go. If you click it, then it will attempt the RDP connection and you will see the SYN_Sent again:

In my opinion, Citrix should fix this but stopping the SYN requests after you click away from the Console tab. This is not an issue that will impact many people but if you are running a PVS environment and you have it setup using Citrix best practices with 2 NICs and the streaming NIC is not accessible from your workstation subnet, you will eventually run into this issue. The longer you keep XenCenter open, the worse it will get.

If I get any updates from Citrix on a fix, I will post here. For now the work around will work fine. You just won’t have the Remote Desktop automatic console scanning available for your regular environments anymore. Not really a big loss for me but it might be for you depending on your environment.

Wow it’s been busy as we approach the end of the year. I am going through my Inbox as I can and I really appreciate all the comments and emails from you all. Really makes it worth while hearing how these posts are helping out there in the real world.

Here’s a quick fix for today. PVS 6.1 environment with latest updates started showing the following error anytime a VM attempted to boot:

Vdisk is locked. 0xffff8017

The fix is not that painful but you will need to kick off everyone that is still connected and running using that vDisk. So there is an outage involved in this procedure for people that use that image.

1. Tell all your users that are still connected to save their work and log off. This is going to be a complete outage for anyone that uses that particular image.

2. Go to your DDC and put the Desktop Group in maintenance mode. This will prevent the DDC from attempting to start up VMs and potentially lock up the vDisk while you are working on it. Then Force Shutdown on all the VMs. Verify in XenCenter they are all shutdown.

3. RDP to a single PVS server and in the PVS Console, go to the Store and right click on your vDisk. Verify there is no gold lock next to the vDisk. If there is clear all the locks. Then click “Unassign from Selected Devices(s)…”

4. Make sure all your VMs are checked and click Unassign

5. If you have maintenance versions, I suggest you merge them at this point. You’ll want to use the “Merged Base – Last base + all updates from that base” option so you get an nice single .vhd file to play with.

6. Once you have verified you have a nice little .vhd file you can rename it if you wish. Now copy that .vhd file and the associated .pvp file to all your other PVS stores. Get all your PVS servers in sync and check the replication status. They should all have blue dots:

7. Now go back to your Store view and right click on your vDisk. You should now see an option to Delete. Click it.

8. MAKE SURE you DO NOT check the Delete the associated VHD files check box. Just hit Yes only. All it does is delete it from the PVS database. It will not touch anything in your Store this way. Better safe than sorry. Do this on all your PVS servers.

9. Now right click on “Store” and click “Add or Import Existing vDisk…”

10. Click Search to search your Store for vDisks. Only check that new .vhd you had created in step 5 and 6 above. Then click Add once it stops being greyed out.

11. It will be imported in Private mode every time. Go ahead and switch it to Standard mode. You might also want to check Cache type, Enable Active Directory machine account password management, and KMS on the Microsoft Volume Licensing tab because all that stuff will likely not carry over for you.

12. Now go to your Device Collection. In this example I have 20+ Devices that need this particular vDisk golden image. I’m not going to sit here and click and modify each one. So I will set the vDisk on the first VM only.

13. Now right click that VM you just set and click “Copy Device Properties…”

14. Hit “Clear All”, then check “vDisk Assignment” only, then hit Copy.

15. Now just highlight all your other VMs, right click in the highlighted area, and click Paste. Instantly all your VMs will be assigned that vDisk.

16. Now just boot up a couple of VMs and verify the “Vdisk is locked. 0xffff8017″ error is gone. Then disable Maintenance mode on your DDC and you’re back in business. Don’t forget to tell your users to log back in. You can delete all those old .vhd, .avhd, and .pvp files from old versions of your image if you like or archive them somewhere. It will help keep your Store nice and clean.

When you launch Internet Explorer and open your Citrix web interface page, you want it to pass through the user’s credentials and see all the available apps. When the user clicks on an app, it should launch immediately with no further prompts. Plain and simple.

But this is not always the case unfortunately. Sometimes pass-through authentication breaks. Symptoms I have seen are:

1. You get prompted for credentials at the Web Interface logon (an authentication error occurred error message) like this:

2. Passthrough at the web interface works fine but when launching an app, you get a Windows 2008 R2 logon screen from the XenApp server like this:

3. You get a combination of both issues above.

Don’t worry, there are a number of things you need to check that can resolve these issues for you. One or more of these factors may be the cause of errors in your environment. Just run through the bullet points below and verify everything:

1. You need to be using Citrix Receiver Enterprise if possible and not just the plain Citrix Receiver. The latest Citrix Receiver is 3.1 but 3.0 behaves the same way. It comes with Online Plugin 13.1.0.89 enabled out of the box. You can go to the “Receiver for Windows 3.1 – Admins” download page here:

https://www.citrix.com/English/ss/downloads/details.asp?downloadId=2319945&productId=1689163

You will need to download the 55.1 MB zip file. Inside you will see both “CitrixReceiver.exe” and “CitrixReceiverEnterprise.exe”. The one you want to install is the Enterprise version. This version will install with pass-through authentication support automatically for you as well as Single Sign On (SSO). You can always install and enable SSO with the standard Receiver using the “/includeSSON” and “ENABLE_SSON=Yes” command line switches and this actually will give you pass-through authentication features (more on this in bullet point 7 below). Receiver Enteprise will require administrator access to install on PCs unlike the standard/regular Citrix Receiver. The difference between the two versions is described here:

http://support.citrix.com/proddocs/topic/receiver-31-windows/ica-clients-deciding-v2.html

Note how Enterprise has “Single sign-on/pass-through authentication” but standard only has “Single sign-on”?

Now here’s a big problem. When an end user tries to download the Receiver off the Citrix website, it will not show Enterprise:

http://www.citrix.com/receiver

Go ahead and choose Windows in the drop down. The next page will show the download for Receiver. It does not specify if it is Standard or Enterprise. If you download the executable, it is just CitrixReceiver.exe which is the Standard version you had downloaded above.

So if you are troubleshooting pass-through authentication, the first thing you want to make sure of is go to Add/Remove programs on the user’s PC and verify it says “Citrix Receiver (Enterprise)” like below and not just “Citrix Receiver”:

I’m guessing Citrix only offers the standard version to end users so they are not confused on which one to download. The problem is if you are in an environment where Receiver Enterprise is not deployed centrally or if users take it upon themselves to install the latest Receiver from Citrix’s website (which does not require admin rights btw), they can cause a big mess and you are stuck troubleshooting it.

Another tip, you need to restart your PC for the pass-through authentication to work after you finish installing Receiver Enterprise 3.1. It will sometimes not start the Single Sign On process until you restart your PC. Or it will start it but it still not correctly passthrough credentials for whatever reason. So your best bet is to restart your PC to make sure everything is working correctly. Once you restart your PC, open Task Manager and verify “ssonsvr.exe” is running like below:

Here is another screenshot from Process Explorer which shows the dependency a bit better:

You can also go to the registry and under “HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\SSON” it should have a string value called “Enable” with a value data of “True” like this. This means SSO was installed. This key will be there if you installed Enterprise or forced the SSO install using Standard. Here is a Windows XP example:

Another thing you can do, and I’m on an XP 32 bit box right now, is navigate to “C:\Program Files\Citrix\ICA Client” and open up appsrv.ini in Notepad. You should see “SSOnUserSetting=On” at the very bottom which means that single signon is enabled.

Another check to verify for Enterprise installation, go to “HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PNAgent” in the registry and look for the DWORD value “EnablePassThrough”. It should have a value of “1″ meaning it is enabled. Standard Receiver doesn’t include the PNA plugin so you won’t even have this key if you were using it.

2. You need to verify the Citrix Receiver group policy allowing pass-through authentication has been applied to the PC you are working on. If you are just working on a test machine, you can apply this policy to just that PC for testing purposes instead of through AD. Just open up gpedit.msc on the PC, right click on “Administrative Templates” and then click “Add/Remove Templates…”. Click Add and choose the following file:

C:\Program Files\Citrix\ICA Client\Configuration\icaclient.adm

Once you have added it, navigate down to Computer Configuration > Administrative Templates > Citrix Components > Citrix Receiver > Authentication and you will see an option called “Local user name and password”. Double click on it and set it to Enabled. You need to have “Enable pass-through authentication” and “Allow pass-through authentication for all ICA connections” enabled. So it will look like this:

If you expand the User Configuration section, you will see the same settings under there as well. I usually have it set there as well but it is not necessary. In my testing, you can leave it enabled at the computer level and it will work. The changes should be instant from my testing but if they don’t take, try doing a “gpupdate /force”, restarting your browser, and/or rebooting your machine.

3. There is a known issue with XenApp 6.5 where pass-through authentication will not work. You need to apply Hotfix XA650W2K8R2X64001 to all your XenApp servers. You can get it here:

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

This will update your ccticket.dlls among other files that will fix the issue.

4. Verify on your XenApp servers that the RDP connection is set to not prompt for passwords. Under the Remote Desktop Session Host Configuration console, doubleclick on RDP-Tcp, then click the Log on Settings tab. Verify “Use client-provided log on information” is selected and “Always prompt for password” is NOT checked:

5. Verify in the Web Interface console that you have specified pass-through authentication for the XenApp site. Just open the Web Interface Management console, right click on your site, and click Authentication Methods. Pass-through should be checked here:

It should also be done on the XenApp Services site if you need it.

6. Pass-through authentication will not work in Firefox. I’ve added my web interface to the Trusted URIs config in FireFox but it won’t work. NTLM Passthrough authentication works fine on the web interface, but it won’t carry to the XenApp server when launching an app. You can add your WI to the list by typing this in the address bar in FireFox:

about:config

Then just type “NTLM” in the filter box. Add the URL (without the http:\\) in the “network.automatic-ntlm-auth.trusted-uris” box. If you do manage to somehow getting pass-through authentication to work in Firefox, please leave a comment below. I’m not a huge IE fan.

Quick note in IE, you do not need to add your WI URL to the Trusted Sites security zone for passthrough to work. Local Intranet is all you need from my experience. Sometimes you may get prompted at the web interface for credentials. Just make sure the site appears in Local Intranet and not Internet. I’ve seen issues where NTLM passthrough may not work in this scenario.

7. One final note, I did some additional testing using the Standard Receiver and command line installation. If you install Standard Receiver using command line with the following:

CitrixReceiver.exe /includeSSON ENABLE_SSON=Yes

You will see in Process Explorer or Task Manager that “ssonsvr.exe” is indeed running after the install. In my testing I was able to get it to actually pass-through but on certain XenApp 6.5 servers only. They had the pass-through hotfix I talk about below in bullet point 3 above applied. This was the only exception. And it only worked immediately after the Citrix Receiver install without rebooting the system. After rebooting the PC, it behaved like all other regular unpatched XenApp 6.5 and below farms. I would get the Server 2008 logon.

I then added the .adm template and configured it as described in bullet point 2 above and pass-through authentication worked fine with both patched and unpatched XenApp 6.5 servers. It even worked on XenApp 5 Feature Pack 3 farms with Web Interface 5.3 just fine.

If you check Process Explorer as you launch an app, the whole chain is there from the single sign on service to the connection manager down to the ICA client/Online Plugin:

So bottom line, you can get standard Receiver to work with passthrough but only if using these command line switches during install. I would just deploy Receiver Enterprise to begin with to avoid having issues down the road. It just seems to make more sense to me.

EdgeSight Agents for XenApp can be deployed and configured to all of your XenApp servers easily via command line scripts/batch files. Here are the 3 .bat scripts I have written for the 3 different agent flavors, 5.3 for 32 bit and 64 bit 2003 OSes and 5.4 for 2008 XenApp 6.0, 6.5, etc. OSes. It also writes a very verbose log file to the C: drive so you can troubleshoot if the agent fails to install. Keep in mind I have the “XENAPP_AGENT” folder shared out on the EdgeSight server in these examples but you can stick it on a network share and modify the path accordingly:

2003 32 bit agent install:
start /wait Msiexec /i "\\edgesightservername\XENAPP_AGENT\EDGESIGHTXAAGENT.MSI" /l*v "c:\edgesightinstall.log" /qn SERVER_NAME=edgesightservername COMPANY=yourcompanyname ALLOWSERVEROS=1 INSTALLROOT="D:\Program Files\Citrix\System Monitoring\" DATA_DIR="D:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data\" REMOTE_SECURITY=0 FUNCTIONALITY_MODE=1 SHOW_SERVICES_TAB=1

2003 64 bit agent install:
start /wait Msiexec /i "\\edgesightservername\XENAPP_AGENT\EDGESIGHTXAAGENTX64.MSI" /l*v "c:\edgesightinstall.log" /qn SERVER_NAME=edgesightservername COMPANY=yourcompanyname ALLOWSERVEROS=1 INSTALLROOT="D:\Program Files (x86)\Citrix\System Monitoring\" DATA_DIR="D:\Documents and Settings\All Users\Application Data\Citrix\System Monitoring\Data\" REMOTE_SECURITY=0 FUNCTIONALITY_MODE=1 SHOW_SERVICES_TAB=1

2008 64 bit XA6+ agent install:
start /wait Msiexec /i "\\edgesightservername\XENAPP_AGENT\EDGESIGHTXA6AGENTX64.MSI" /l*v "c:\edgesightinstall.log" /qn SERVER_NAME=edgesightservername COMPANY=yourcompanyname ALLOWSERVEROS=1 INSTALLROOT="D:\Program Files (x86)\Citrix\System Monitoring\" DATA_DIR="D:\ProgramData\Citrix\System Monitoring\Data\" REMOTE_SECURITY=0 FUNCTIONALITY_MODE=1 SHOW_SERVICES_TAB=1

Now let me go over what each of these switches does. Keep in mind some of these values are ideal for my current environment, but you may need to edit these scripts for yours:

-SERVER_NAME = the EdgeSight server name

-COMPANY = the company you created in EdgeSight. You can also use “DEPARTMENT” to further breakdown but that is for Endpoint agents. XenApp agents will use the Citrix farm name to break down so you don’t need to worry about this value.

-ALLOWSERVEROS = I set it to 1 which means go ahead and install on Server OSes but this is really an EdgeSight for Endpoints setting and not for EdgeSight for Xenapp. I just leave it to maintain consistency with my VDI install script. Doesn’t hurt anything.

-INSTALLROOT = is where the Edgesight agent will be installed. I am installing on the D: drive instead of the default C: drive as you can see. The directory will vary depending on your OS so please pay close attention to this. Inside this directory are the various agent related files like rscorsvc.exe, Firebird files (including Fbserver.exe), etc. are located.

-DATA_DIR = is the EdgeSight working directory and will contain important logs like SYS_EVENT_TXT.txt and all the Worker logs. Again, I tell it to install on D: drive because I don’t want my C: drive to ever fill up with logs. Slim chance with EdgeSight but I try to follow best practice whenever I can. Also note the Firebird database (RSDATR.FDB) is also located in this directory. If anything, that is the file that will be growing the fastest.

-REMOTE_SECURITY = So if you ever use the Monitor or Troubleshoot tabs in the EdgeSight web console and click on a server, your desktop is actually connecting to the EdgeSight agent on that server over port 9035 using the credentials you are logged into your desktop with, not the EdgeSight web console.

So let’s say you are using your domain user account to login to your desktop, but use a server administrator account to login to the EdgeSight web console. When you click on a server under Monitor, your desktop immediately opens a connection on 9035 to that server. If your domain user account is not a local administrator on that server, EdgeSight will display a message like this:

Real time information is unavailable.
There was an error connecting to the remote Citrix System Monitoring Agent database. The Citrix System Monitoring Agent may not be running on the specified machine. Please try again.

OR

Real time information is unavailable.
Access denied: You do not have permission to access this resource.

Naturally if you are using a regular domain user account and another administrative account for server administration, you are probably not going to have the domain user account as a local admin on the server. So the EdgeSight agent allows you a couple of options to work around this. Namely, allowing anyone to connect over the EdgeSight web console or limiting it to a certain AD security group. Unfortunately, both these options have to be set in the registry, it’s not something you can set in the EdgeSight agent GUI. The location of these keys are:

32 bit OS:
HKEY_LOCAL_MACHINE\Software\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurity

64 bit OS:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurity

By default, RemoteSecurity is set to “1″ meaning you have to be a local admin on the server. Setting it to “0″ allows you to specify the AD security group that should have access to the EdgeSight agent. This security group should contain all the domain user accounts that will be using the EdgeSight web console. To actually specify the group, you need to drop the security group name into one of the following keys:

32 bit OS:
HKEY_LOCAL_MACHINE\Software\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurityGroup

64 bit OS:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\System Monitoring\Agent\Core\4.00\RemoteSecurityGroup

The last option and the one I have used in my scripts above is setting RemoteSecurity to “0″. This lets anyone using the EdgeSight web console to connect to a server to view realtime info. The reason is if you have several network segments with Citrix farms and they are all on different domains with no trust, you can’t specify all those different AD security groups in the registry unless you create a custom EdgeSight install script for each domain specifying the RemoteSecurityGroup value. This gets a little cumbersome to manage if you have a lot of domains. Even then, getting it to pass these credentials from your desktop to the XenApp server in question gets a little hairy. So just keep in mind, “0″ is a workaround but really the best practice is to use “1″ and specify a RemoteSecurityGroup if you can. My reasoning is “0″ is okay since I already control who has access to the EdgeSight web console and I want all my console users (which are all server admins) to have access to realtime reports.

BTW, just add “REMOTE_SECURITY_GROUP=yourADsecuritygroupname” to the install scripts above if you want to specify this value for your EdgeSight agents.

-FUNCTIONALITY_MODE = I set this to “1″ to set the agent to Advanced mode. If you set it to “2″ it will install in Basic mode. So if your environment consists of a bunch of Enterprise Citrix servers and you don’t have any Platinum servers or an actual EdgeSight for XenApp monitoring license, then you may want to use the value of “2″ to just pull basic EdgeSight data. Otherwise you will begin getting errors on your EdgeSight server like:

EdgeSight – Grace Period license violations detected on YourServerName
The device YourServerName at xxx.xxx.xxx.xxx has reported Grace Period violations
EdgeSight has detected license violations in the payload for the device YourServerName at xxx.xxx.xxx.xxx. This device is still within the 14-day licensing grace period.
Please take corrective action to prevent future violations.

I don’t really recommend the Basic mode. It will likely defeat the purpose of you deploying EdgeSight in your environment in the first place. Here is a good comparison of the EdgeSight Advanced vs. Basic agents:

http://support.citrix.com/proddocs/topic/edgesight54/es-feature-by-agent-type.html

As you can see, you lose some key monitoring metrics like:

-Network Performance
-XenApp User Summary
-Launch Summary for a Farm
-Summary for a Farm
-Users Summary for a Farm
-Application Errors
-Session Performance
-Active Application Monitoring (if you use application monitoring scripts)

In my opinion, you aren’t really getting key performance metrics on your Citrix farms unless you are running in Advanced mode. I heavily depend on the above reports to monitor farm health.

-SHOW_SERVICES_TAB = This is actualling meant for the EdgeSight for Endpoint agents but I do it for XenApp agents too to maintain consistency with my VDI install scripts. Setting the value to 0 will prevent users from being to to disable Citrix System Monitoring Services because it hides the Services tab under Control Panel > Citrix System Monitoring Agent. Setting it to 1 allows the tab to be displayed. It doesn’t really apply to server OSes since they display but default but it doesn’t hurt leaving the value as 1.

Here’s how XenApp agent vs. XenDesktop/Endpoint agent will look if you specify the value as 1:

A few other points. DO NOT run one of these install scripts against your License servers. License servers do not use EdgeSight agents, they are polled directly. You specify that in the EdgeSight web console under Configure > License Monitor Configuration > License Servers. They are polled every 15 min by default.

If you are trying to monitor a published application that launches using a script, like a .cmd extension for example, it may not register in EdgeSight as a launch. You need to install Citrix hotfix EUEM100W001 on your XenApp server to fix this:

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

By default, EdgeSight agents for XenApp upload performance data twice a day to the EdgeSight server. This means app launches, users, errors, etc. This can be configured to upload more frequently if you like. The default times are 5 AM and 7 PM. You can adjust it under Configure > Agents > XenApp Default > then expand the Performance Upload section.

I guess the only other thing I really want to stress is to make sure to double check your antivirus settings and also to verify ports 80, 443, and 9035 are open to every XenApp server you want to monitor. AV settings can be tricky with the various OSes in your environment, I may type up a quick guide on what to white list/set exceptions on if anyone needs it.

By default, Firefox stores it’s profile cache in "C:\Documents and Settings\yourusername\Application Data\Mozilla\Firefox\Profiles". This can be problematic when using roaming profiles with a limited amount of profile storage space due to quotas. As you add extensions, it grows even bigger. This is a big problem in XenApp/XenDesktop/View and other VDI environments using roaming profiles. You’ll soon start getting errors saying you are almost out of profile storage space or that you have exceeded your profile storage space. Something like this (note I just grabbed this screenshot from a Google Image Search, you would normally see a bunch of Mozilla Firefox related files in there eating up the space):

The solution is to move the profile out of the user folder and into another local folder or onto a network drive/home folder, thus reclaiming the profile storage space. For example, I created "c:\FireFoxProfile" to house the profile. Here is what you need to do to begin using this folder:

1. Edit "C:\Documents and Settings\yourusername\Application Data\Mozilla\Firefox\profiles.ini" in Notepad and change:

IsRelative=1

to

IsRelative=0

What this does is allow you to use an explicit path that you specify for the profile.

2. Change the next line from:

Path=Profiles/xxxxxxx.default

to

Path=c:\FireFoxProfile\xxxxxxx.default

3. Save profile.ini and restart Firefox. You will notice that immediately, the new profile folder is populated. Keep in mind when you open Firefox for the first time, it will be like a brand new install and you will lose all of your bookmarks, extensions, customizations, etc. unless you restore them from the old path.

4. You can delete everything in your old profile path once you have Firefox working in the new profile path. This will immediately reclaim your roaming profile storage space.

NOTE: If deploying to the entire corporation, there are other methods to centrally manage Firefox and control the deployment. This solution is good for the one off users though.