Articles
 Friday, 03 September 2010 11:32 |  Author: Eelco de Vries |   
The last couple of years I’ve been involved in some issues at several customers concerning performance. In almost every case the following took place:
Customer switches from client-server to SBC (mainly Citrix).
Existing WAN configuration is used or a new WAN is in place with limited bandwidth.
PoC and pilots went OK, but in production (with far more users) performance is (very) poor.
After first investigation Citrix environment performs well (at DataCenter or main location) but on branch locations performance is poor (latency, slow response, freezing sessions etc.).
Most of the time the WAN connections on branch offices is based on assumptions like:
Users sessions take about 50kbit/sec of bandwidth.
Mostly ICA traffic (= Citrix, Terminal Server only = RDP) is going over the WAN connections.
Both assumptions are always DEAD WRONG!
It’s possible to consume all available bandwidth on the WAN with just one ICA session. Just start Internet Explorer and go to a web page with a large amount of flash content and wait until all your colleagues complain… Or start Adobe Reader, open a PDF and use the slide bar on the side of the screen to scroll up and down… Just 2 examples which causes your ICA session to consume all the available bandwidth.
You can check the bandwidth consumption in the logs of your router. If you’re using devices like Packeteer, Juniper or WANScaler (Branch Repeater) you can easily check which sessions take a lot of bandwidth. If you do not have any monitoring tools available: just download SMCConsole; a very lightweight monitoring tool to check ICA bandwidth and latency. Just start the tool on a Citrix server, pick your own ICA session and try the two examples I mentioned earlier to increase your bandwidth consumption within ICA rapidly…
The last couple of years I’ve been involved in some issues at several customers concerning performance. In almost every case the following took place:
Most of the time the WAN connections on branch offices is based on assumptions like:
Both assumptions are always DEAD WRONG! It’s possible to consume all available bandwidth on the WAN with just one ICA session. Just start Internet Explorer and go to a web page with a large amount of flash content and wait until all your colleagues complain… Or start Adobe Reader, open a PDF and use the slide bar on the side of the screen to scroll up and down… Just 2 examples which causes your ICA session to consume all the available bandwidth. You can check the bandwidth consumption in the logs of your router. If you’re using devices like Packeteer, Juniper or WANScaler (Branch Repeater) you can easily check which sessions take a lot of bandwidth. If you do not have any monitoring tools available: just download SMCConsole; a very lightweight monitoring tool to check ICA bandwidth and latency. Just start the tool on a Citrix server, pick your own ICA session and try the two examples I mentioned earlier to increase your bandwidth consumption within ICA rapidly…
So item 1 is explained… Item 2 (only ICA traffic…): most of the customers use a single or clustered print server, located at the main office or Data Center, used for all branch offices. So when users print from their applications the print job is sent from the Data Center to the printer in the branch office. That means that SMB traffic is roaming on the network, using all available network it can get if the WAN is not managed. If someone prints a large PDF document the whole office will experience poor performance until the print job has finished. Or Administrators copying large amounts of data over the WAN… Or a user with a laptop who syncs Outlook with an Exchange server located in the Data Center… What has to be done to get an acceptable performance over WAN connections? We can divide the performance issues roughly into two pieces:
Why splitting it up? Simple: even with only ICA traffic on your WAN it’s possible to frustrate a complete WAN location by generating hugh ICA packets (using IE with flash or applications with rich media content). 1. Optimize ICA performance
2. Optimize WAN performance With more than just ICA traffic on the network the WAN has to be managed to avoid suppression of ICA traffic. There are many possibilities to increase the performance of the WAN, dependable of the kind of network traffic that roams the network: Prioritization. Quality of Service. Note: When the WAN connection is flooded with data even CoS or QoS can fail because the amount of data cannot be handled by the used equipment (network congestion). Packet shaping. Policy Based Routing. Increase bandwidth. So… check your WAN before you are going to use your SBC or VDI environment en masse. When you don’t have the expertise to monitor/investigate your network just hire an experienced network consultant to give you a good advise what to do. At the end it’ll save you a lot of money, time and frustration. Keep in mind that within SBC and VDI environments your Wide Area Network is a mayor key component of your infrastructure. When your network is not available your infrastructure is completely useless! Not only performance is an issue, but also redundancy. Make your WAN redundant if your business is dependent of your remote infrastructure. There are several ways to secure your WAN environment, but you don’t need a Citrix expert on that one, try a network geek :) Comments (0) Friday, 07 May 2010 14:42 | Author: Nico van Meurs |
This morning I took the Citrix 1y1-A15 Engineering a Citrix Virtualization Solution beta exam. This is the final exam to receive the new Citrix CCEE certification. And I’m happy to say that I passed with a score of 76%! According to the results I didn’t score very well on the monitoring part. So luckily I mainly implement Citrix environments and don’t manage them J I have to say I’m really enthusiastic about the quality of the exam. The simulations look very good! Big respect to the Citrix exam development team for this! I recognized a lot of questions from the exam development workshop I attended but I also noticed a few new questions. I like the fact that the exam is very real life oriented. And that you really need to have in depth knowledge about most of the Citrix products and the way they interact with each other, to pass the exam. This is something that we as item development team tried very hard and it’s good to see this worked out pretty well. Normally with beta exam’s you need to wait a few weeks before hearing your score. So it surprised me that I received the results directly after finishing the exam. I’m curious to know what Citrix will do with the feedback they receive from the beta testers. All in all I’m very happy with the new Citrix CCEE exam and I’m very proud I got the chance to be a part of this!
Comments (2) Friday, 16 April 2010 08:29 | Author: Nico van Meurs |
Using Streamed applications is a very flexible way of deploying applications to your end users. Sometimes you come across an application that you need to provide to your users more then once, with different configurations. You can do this by profiling the application multiple times, each time with a different configuration. But a big disadvantage of this method is that when your application needs an update, you must install this update to all created profiles. Luckily there’s a more effective way of solving this “problem” for many applications out there. For this method the application only needs to be profiled once but can still be published multiple times with a different configuration. To do this I use a bacthfile that writes the configuration to the application "on the fly". Most of the time the application configuration is held in the registry or in a configuration file, so this can easily be modified. In this batchfile I'm not using the actual configuration parameters, but instead I use variables. This variables can later on be specified in the properties of the published application.
Let’s take a look how this works by using an example application TOPdesk Settings Management. This application uses a configuration file stored in “C:\Program Files\TOPdesk\Settings Management”, the file looks like this:
Specified in the configuration file is the servername of the server to which the application must connect. As you can see in this example the file points to the TOPdesk test server. Next to that there’s also an acceptance server and a production server. So to use the same streaming profile for these different configurations I first create the batchfile.
ECHO OFF ECHO tas.hostname=%1> "C:\Program Files\TOPdesk\ Settings Management \host.properties" ECHO tas.tcpport=%2>> "C:\Program Files\TOPdesk\ Settings Management\host.properties" ECHO tas.username=ADMIN>> "C:\Program Files\TOPdesk\ Settings Management \host.properties" START dedicatedclient.exe
As you can see the batchfile creates the TOPdesk configuration file and uses the %1 and %2 parameters instead of the actual servername and portnumber of the TOPdesk server. After that it starts the application executable.
Next thing I need to do is adding the batchfile to the streamed application. I do this by using the Citrix Streaming Profiler. In the profiled application you choose Update / Install Application.
Choose Advanced Install.
Choose Select files and folder.
I created the batchfile on C:\. So from there I can upload the file to the applications program files folder in the streamed application.
After that choose Finish installations.
Now all I need to do is adding a shortcut to the batchfile by adding an application in the profile. Important here is that I add two asterisks in the command line parameters field.
After that I finish and save the profile. Next I need to publish the application.
In the following screen is the location where I can specify the value of the parameters used in the batchfile. Here I add the configuration parameters that I want my published application to use. When specifying more then one parameter don’t use a separator.
When I now start the application I can see that the parameters I specified in the published application are now passed through to my application!
Comments (0) Friday, 12 March 2010 11:38 | Author: Nico van Meurs |
At a customer I ran into the following situation. Separate NIC’s are used on the PVS clients for provisioning traffic. And the provisioned clients are in a different subnet as the Provisioning Servers and the DHCP servers. Of course in DHCP the router address is configured so that clients are able to connect to the other subnet. In between the two subnets the customer has two routers functioning as a HA pair. The default gateway address given to clients is a virtual IP configured on the HA pair. This looks something like this: Router1 physical IP: 192.168.1.251Router2 physical IP: 192.168.1.252 Default gateway virtual IP: 192.168.1.253
There’s a helper configured on the routers so the provisioned clients can get IP configuration from DHCP in the other subnet.
So what went wrong? Let’s take a look at the bootprocess. The PXE client on the provisioned machine sends a broadcast over the network looking for a DHCP server. One of the routers in the HA pair (lets say 192.168.1.251) picks up the request and passes this on to the DHCP server (according to the helper). The DHCP server accepts the request and sends an ip address back to the provisioned machine, including the default gateway VIP as router address. What happens next is something that I didn’t expect. Instead of using the default gateway VIP that was configured in DHCP, the PXE client uses the IP address of the router that answered to the DHCP request as the default gateway (192.168.1.251). And it hands this IP information over to the TFTP bootstrap program.
Next Windows boots without a problem. Within Windows a new DHCP request is being done resulting in the correct address (192.168.1.253) being configured as default gateway in Windows. This all looks ok.. right? BUT…. a very interesting fact here is that the communication between the provisioned client and the vDisk residing on the PVS server is NOT handled by Windows. Even when Windows is started the bootstrap program is still handling the communication from and to the vDisk. So because this bootstrap program uses the Router1 address as the route to the other subnet, there’s now no redundant situation for the routers. When Router1 fails the provisioned client just freezes, because it’s are unable to contact the vDisk that resides in the other subnet! We went even further in testing this by configuring no default gateway at all in DHCP. In this scenario Windows is able to boot because PXE just uses the router that first answers the DHCP request. But within Windows there is now no gateway to the Provisioning Server. Doing a ping to the Provisioning Server results in the message “Destination host unreachable”. So Windows is not even communicating with the vDisk when booted. Ok.. back to the problem.
The problem is that the PXE client uses the physical IP of Router1 as the gateway and passes this through to the bootstrap program. From this moment on the bootstrap program communicates over this IP, even when in Windows. So when Router1 fails, contact with the vDisk is lost.
Luckily this problem can be easily fixed by configuring a specific default gateway in the bootstrap program. You can do this by clicking Configure Bootstrap in the Provisioning Services console, and specifying the subnet and gateway address.
Now the bootstrap program uses this gateway as the route to communicate with the vDisk, in stead of using the gateway it get’s passed through from the PXE client. Resulting in fully working HA situation! 
Comments (0) Thursday, 18 February 2010 15:36 | Author: Nico van Meurs |
Citrix is doing a real good job providing technotes. Technotes contain solutions for specific problems, describe best practices or just provide information about Citrix products that's not directly availible in product documentation. Working with Provisioning Server a lot, some of this technotes really saved my life! A few of these are in my opinion a must read for everyone who's working or going to work with Citrix Provisioning Services in the future. I collected these technotes in this blog: Best Practices for Configuring Provisioning Server on a Network Registry Settings to Improve Failover Times for Citrix Provisioning Understanding Write-Cache in Provisioning Server Provisioning Server and Citrix License Server Interaction FAQ Reference of PXE Error Codes Hard Drive Local Cache and Boot Process for Provisioning Services Provisioning Target and Daylight Savings Time Comments (0) Friday, 05 February 2010 15:26 | Author: Nico van Meurs |
When you have worked with Provisioning Services you know the process to create a vDisk. First you install your gold build server or workstation (the master target device) with the OS and all the software and configuration you want to have in your vDisk. You also install the Provisioning Services client on this machine. Then you create an empty vDisk on the Provisioning Server, add the master target device to the Provisioning Services database and link the empty vDisk to the master target device. After that you make sure boot from hard drive is selected on the master target device and then boot the device. After the device is started and the vDisk is connected you can start the image building process. My opinion is that this is quite a time consuming procedure with lots of steps you have to take. Especially when you install your master target device fully automated, like I like to do, it sucks that you have to use this process afterwards to create the actual vDisk. So I was very happy to find another way to do this process of creating the vDisk. Now my goldbuild installation is literally 100% automated..! From installing the Operating System to creating the vDisk. To do this, there are just 3 simple things you need to do. First of all the Provisioning Services client software consists of two parts; 1: the target device drivers and optimization stuff and 2: XenConvert. The XenConvert contained in this package however is a customized version that only allows to convert to Provisioning Services vDisk. So the first thing I did is extract the two MSI’s from the Provisioning Services client setup. To do this just start the install and instead of finishing the installation, browse to the temp folder in your userprofile and locate the MSI’s. Actually the only MSI you really need from the installation package is the one that is called “Citrix Provisioning Services Target Device.msi”. The other MSI you need is the full XenConvert client (version 2.0.2 at the moment). The full XenConvert MSI can be downloaded from the Citrix website. So when you have both MSI’s separately you just install them (unattended if you want) on the master target device. Second thing you need to do is make sure you have a separate disk partition installed on the master target device. Make sure this partition is big enough to contain the complete vDisk. We're going to use this partition to save the vDisk on. Third and last action is building the disk via the full XenConvert client. You can do this by running the following command manually or via a script: "%PROGRAMFILES%\Citrix\XenConvert\XenConvertCLI" P2VHD [Diskname] [Sourcedrive] [Destinationdrive] Example:"%PROGRAMFILES%\Citrix\XenConvert\XenConvertCLI" P2VHD GoldBuild C:\ V:\ After the process is finished the destinationdrive contains the vDisk in VHD format. You can copy this VHD file directly to your Provisioning Server vDisk store and import in the database. Because the Target Device software is installed on the disk, the vDisk immediately works on your target devices! Another very handy thing to do; when you have to change your vDisk, just apply your changes on the master target device and build a completely new vDisk using the process above. A big advantage is that this way, you can easily update stuff like network drivers, XenTools, VMware tools, PVS Target Device software.. without having to reverse image your vDisk! Of course there are some limitations of using this procedure for creating your vDisks. As far as I found out one is that you only have the possibility to create a vDisk in dynamic format. Secondly you're only able to create a vDisk with one partition. But if these limitations don't matter to you I can assure you this is a very easy way to create your vDisks! Comments (3) |
- Making Citrix Provisioning Services 100% high available is a bitch….
- Dual boot Windows 2008 R2 (Native) and Windows 7 (from VHD)
- Citrix Exam 1Y0-A06: Implementing Citrix Provisioning Server 5.0: PASSED!!
- Citrix CCEE Item Development Workshop
- HOW TO GUIDE: Installing and Configuring Citrix Provisioning Server for Deploying XenApp - Part 2
) and is still busy designing and implementing SBC and VDI environments at customers, based on Citrix products. Besides consultancy Eelco is frequently asked for troubleshooting jobs and infrastructural challenges.