Back in 1993, the Citrix Engineering team used to get amusement from Dilbert. I remember posting clippings on the outside of my cubicle wall for others to read. Later I linked my personal website (1994) to the official Dilbert site. Many of us had come from IBM and fully understood Dilbert’s world.
This is certainly old news to most of you. Citrix purchased sepagoProfile back in May 2008 from sepago. sepagoProfile has been rebranded as Citrix User Profile Manager. sepago has produced a white paper about the User Profile Manager for the sake of Citrix.
The User Profile Manager is currently in tech preview and is being supported by a Citrix UPM forum. There is a UPM FAQ that covers the most common questions.
Posted in Acquisition, Citrix, XenApp, XenDesktop
Tagged Citrix, Citrix User Profile Manager, sepago, sepagoProfile, User Profiles
In June, Adam Jaques from the Advanced Products Group in Sydney demonstrated the Citrix ICA client on an iPhone. The video is on YouTube and can be seen from here:
Keep in mind that this is just a demonstration. If you see this as a valuable thing, please request it either through your normal channels of communication or fill in the poll below:
The real question is whether or not you want support with the iPhone and Citrix XenDesktop and XenApp.
Posted in Advanced Products, Citrix Video, XenDesktop
Tagged Advanced Products, Citrix, iPhone, Video, XenDesktop
Here’s another idea ahead of its time. This one also came from iForum 2003, but from a different customer.
At the time it seemed like a largely unsolvable problem with MetaFrame. This has since changed with the advancement of virtualization and the implementation of XenDesktop.
Here’s the text:
A customer was asking for the ability to recover sessions during iForum in Sydney.
Essentially there are looking for “rock solid” application connections.
Given the nature of networks, this seams like a pretty big request.
I think this request belies a bigger request for being able to have sessions that are fault-tolerant.
The faults could happen at many different places:
Network (down)
Hardware (faults)
Software (exceptions)
Based on the potential for error, it is fairly easy to see that it would be impossible to guarantee 100% up-time. However, we could greatly improve what we do today.
1. Change ACR to be at a transport layer level so that the user does not experience the session going away until the transport layer has died after a given retry duration and count. It is very important for the user to think it is still running even when it is in the process of reconnecting. This is definitely an image issue.
[ This did change not long after. Connections look alive even if the connection has errors.]
2. Use a RAID-like strategy for running applications. Have multiple sessions controlled by the same user input. I know this would be more difficult than it sounds but it would allow for instantly switching from a bad session to a good session in potentially a fraction of a second.
[Interesting but impractical. Divergent states would not be prevented.]
3. Potentially use record/playback to recreate session states. This does not seem as promising since states can change (files for example) and playing back the stream would not get you to where you want to be.
[This also sounds good but wouldn't work]
4. When you have multiple sessions running to support fault tolerance, have them talk to each other (master slave relationship) so that the sessions will always be in sync even if one goes down.
[Better, but certainly would not work universally]
5. Run the different copies of the same sessions on different machines in case the hardware fails.
[Hints of virtualization but not quite]
Another concept that come out of this is the idea of “Always on” applications.
This just means that for a given user, a certain application is always guaranteed to be running. This would be great for re-connect times and also would give the image of permanence to the user. For example, I would love to have a copy of Outlook “Always On” so that I could quickly check my email without having to fully start a new session. I know this can be done with disconnect times and other tricks but it would be a big coup to be able to say that a server will always be on with your app waiting and running.
[This would be an easy win if Citrix ever decided to push this angle. The technology for this is already there but it would require essentially getting rid of timeouts and making re-connections super smooth]
Back to 2008…
Session recovery is another one of those requirements that has been around for most of Citrix’s history. It is only recently with virtualization that it is possible to move VMs from one host to another. This concept overlaps well with how XenDesktop is built. Companies such as Marathon have focused on making Citrix fault tolerant.
However, the dream of moving around an individual session on XenApp seems almost impossible.
There was a brief glimmer of hope with the announcement of Luflogix from Brian Madden, but alas it was only an April Fools joke.
Given the age of the requirement and also the potential applications, there is a renewed possibility this could be addressed using modern technology.
The first step is to realize that there is a real need. The second step would be to setup a research project within Citrix Advanced Products. As a result, hopefully customers will finally get the ability to guarantee session permanence regardless of failures or location.
Once you get a session that can live forever, the next logical step is to find a way to move it to anywhere else in a self contained aspect. As usual, this kind of thinking is a bit ahead of the curve.
Posted in Citrix, Citrix Ideas, VDI, Virtualization, XenApp, XenDesktop
Tagged Citrix, Product Ideas, Session recovery
In recent developments Offline VDI has gained much interest. Offline support has been a common request of Citrix for many years. Until virtualization came around, it looked pretty hard to accomplish this goal in a believable way.
I was busy searching for interesting old ideas in the Citrix Product Ideas database and stumbled across Idea 420 entitled “Offline access”. This idea came straight from a customer and I just tried to capture it and form some guesses about how it would be done.
For amusement purposes only, I’m including what I wrote for that idea. Remember that this happened May 22, 2003 right after iForum in Sydney.
I was asked for this at iForum by a customer.
His assumption was that if he was working on something that he could continue to work on it even if he was not online. His then would later sync up whatever work he had done when he connected again.
This might work fine in a file-based world, but does not carry forward very well in Citrix’s area of expertise.
It brings forward the idea of what kind of work a user would be doing remotely AND offline.
Most common practices are to either work on documents or presentations.
It would be rare for them to expect that they would be able to talk to a server since they are indeed offline.
So, they are only confused about how the work is being done. If they knew that they were really working online all the time with the server and the software being on the server, they would not ask for offline access since that would mean they would know that they could not run the app on their client.
But, they do not seem to know this. There is nothing wrong with this since it really shows how transparent we have made things work for them.
So, there really only seems to be a few options.
1. Tell them to install the server app software on their client and then manually copy the files back and forward
2. Create a process for automatically installing apps that will be run offline on the client and have a sync method to go between server and client
3. Pretend that we are the software and treat everything like a generic case and later sync up any changes [??? don't know what this means in 2008]
4. Create a new model that makes it less obvious where things are running so that it can happen on the server or client with or without a connection
5. A miracle
I think I like number 2 the best. It is the most practical and I would think that Microsoft would probably chose that kind of model. Of course this means that you would probably have to install the likes of Office on clients that might not support it, but at least it would run as the customer would expect. The syncing feature would also be useful since it would mean that it would probably be better than what people do normally when they go on the road. There is even a good chance that these users would already have the native apps on their client and all they really want is the ability to work on these documents/presentations in a more transparent fashion. For example, if I am offline, use the copy I checked out. If I am online, use the copy from the server that I have just checked in again. I suppose that a library model (books) would work well in this case. This concept would not work well in a database type environment where the file is huge and many people might be working on it. The best you could do is check out a section of the database that you wanted to work on (if this was possible) and then take it on the road. I think that people are still going to get confused but we can do a lot to improve the situation when the user is offline.
Regards,
Jeff
Returning to 2008…
I got a good chuckle on option number 5. This all happened before the advent of the possibility of doing Offline VDI for such a trick. Things have become much more apparent since then. It’s still not completely clear but it is not as far off as 2003 was.
Even with the current visions, it is not obvious how this could be made transparent. The ultimate model would call for dual execution so that the local copy would take over when the network is lost. At the current pace this is still years away and could require a remodeling of how applications work. In the non-Windows world this is already happening for the sake of web applications. Newer applications are becoming more tolerant of offline access.
The current vision focuses on taking a VM, checking it out, and running it on a laptop. Once the offline mode is over, the user then needs to check the changes back in. The good news is that this concept is very easy to explain and understand. The bad news is that it is difficult to achieve and tends to ignore the limitations of moving and syncing VMs. Baby steps moves the technology forward regardless of the pace.
Sometimes (if not most) it is just as important to sell the pitch to the consumers in a simple way instead of how it ultimately might be deployed. In other words, engineers often make the mistake of being technically accurate and usually deluge non-technical consumers (including internal non-engineers). This tends to polarize internal opinions to match the simpler model since the more precise model cannot be understood.
Having Offline VDI support would benefit Citrix customers based on the assumption that offline access has been an outstanding requirement for many many years. Obviously if people are asking for it over and over, it must have a valid business model that would help both sides.
Posted in Citrix Ideas, Offline VDI
Tagged Citrix, Offline access, Offline VDI, Product Ideas
I was looking around YouTube for Citrix related video and found an interesting TV show segment from BestPlacesToWork from KPIX in the Silicon Valley. This video which is five minutes long, promotes Citrix as being an excellent place to work for within Silicon Valley. Top executives are interviewed along with some employees as well.
Best Places To Work is television show on KPIX channel 5 educating the public about what makes Bay Area companies some of the Best Places To Work.
Watch more videos at www.bestplacestowork.tv.
Watching the video instills a certain aspect of not matching reality. Of course, the video could be seen as a promotional video with the intent to recruit. The aspect I would disagree with is the startup mentality. We are simply too big for that.
For those of you living in Silicon Valley, you are certainly invited to apply. 
Advanced Products is a group within Citrix which is responsible for researching and developing Citrix’s future products. I’ve been working in AdProd since 1999 based out of the Sydney office. Recently, Brian Madden visited Australia and stopped by the Sydney office to discover what AdProd does.
He wrote an excellent summary at www.brianmadden.com about AdProd. This was a great time to spread the word and introduce others about the value of work done by AdProd. Our model of applied research has worked well and we have a great team of developers/researchers to tackle Citrix’s biggest opportunities.
Turning down the hype a bit, I am just glad to see an outside opinion about AdProd. As companies grow and more interactions occur, it is often difficult to see what different groups do to add value. I’m impressed with Brian’s perceptions and his knack for getting right to heart of the matter.
Posted in Advanced Products, Australia, Brian Madden
Tagged AdProd Sydney, Brian Madden, Citrix
Part of how Ardence works is based on PXE Boot. The PXE standard was created in 1999 by Intel and Systemsoft. The intent was to standardize the interfaces and mechanisms to allow for different environments to be remotely booted. The idea builds heavily on DHCP and TFTP with a focus on enabling boot code to come from a server instead of a local device.
As usual, there is a great writeup on PXE at Wikipedia.
I have past experiences with network booting based on my reseller stint during 1997-99. We actually had DOS clients that were booting off of a server to connect to MetaFrame. It was tricky to setup but the standardization always made things easier and consistent.
PXE takes it to a new level and enables developers to not only build network boot systems but also to implement streaming of operating systems as well. Obviously Ardence leverages this idea.
In the coming weeks I am going to learn more about Ardence and share the results with you. I have been tipped off that Ardence is probably Citrix’s greatest untapped resource. The source is usually correct.
To give you a place to start to learn a bit more about how Ardence technology works, please check out this podcast from Brian Madden with Pete Downing.
When a Citrix ICA client connects to a Citrix Presentation Server, it either uses TCP/IP port 2598 or port 1494. Port 2598 is used with session reliability and internally it uses SSL with the Citrix CGP protocol. The communication over port 2598 is like a private network link for a small selection of information related to Citrix.
The idea had its original invocation as part of the Secure Gateway project and the Nylon protocol. I briefly worked with Nylon around 2003 while working with the client piece of SG and learned of the bigger project to support Citrix Gateway Protocol (CGP) for standard client connections. Obviously port 2598 is more advanced since it allows for secure communication over SSL and it also has the ability to maintain sessions when the SSL link fails. This is
achieved by using a having a modified version of Apache on the Citrix Presentation Server (XenApp now) that accepts the connections for port 2598. This, in turn, is changed into a connection to port 1494 on the same system. To the user, it transparently works. Internally there is a change-over between 2598 and 1494. The Apache piece acts as a relay and also a point of allowing the session to continue.
Normally on terminal services sessions once the connection is dropped, the session is deemed as being disconnected. This causes a lot of churn and makes it hard to reconnect too quickly. However, since the Apache piece can hold up the connection to 1494 regardless of what the outside link is doing, the session does not need to be disconnected. This makes it much easier to re-establish a link from outside back to port 1494. From a user point of view, there is a good chance that a short term outage will not even be noticed except for the case of input feedback. There was a time in the past that any hiccup would trigger an instant drop of the client with the need for a full reconnect. Even with Auto Client Reconnect (ACR) this was not always a very pleasant experience.
This leads us to port 1494. If you select to drop session reliability it really means that you are bypassing the middleman. There is a good reason to have the middle management but sometimes it is nice just to go straight to the source. Port 1494 is the original design. The history of it I have already told before but let’s go down memory lane.
While working on the TCP/IP option for WinView, I realized that Citrix was going to need a server port number. Initially I would have picked just some semi-random number to test with. Eventually I determined that there was a central authority for giving out such numbers (IANA). This would have been 1994 and still fairly early on this list of supported ports. I asked John Richardson to get us a number from that group. John already had done this before or had some kind of connection with the group. I don’t remember which it is. Within a fairly short time, we had a port number reserved for us and we were told that we could use port 1494.
During the whole time I’ve known about port 1494, I usually remember it as Columbus+2. Of course I don’t have trouble remembering 1494 anymore since it is now ingrained in my memory from being referred to so many times.
Recently a co-worker, Jonathan, sent me a link for all the TCP and UDP ports in use. ICA is listed here at 1494 officially and 2598 unofficially.
There is an old trick to see if a Citrix Presentation Server is listening. Just issue a “telnet [servername] 1494″. Of course replace [servername] with either an IP address or the DNS name for the server. If you get a couple of “ICA” strings back, you know it is working (at least at the connection level). I’ve used this trick a number of times when debugging issues. Of course it works with PortICA as well but only if you are lucky enough to have an internal standalone version that is always listening. By default PortICA only listens when a user is coming in through XenDesktop.
In the history of ICA, it used to be much more important to support other protocols besides TCP/IP. In fact TCP/IP was a relative latecomer. The other protocols such as IPX/SPX, NetBeui, and even Async have essentially faded away. It would not have been easy to predict how strong TCP/IP would be circa 1990. It would be interesting to see if any other protocol (besides derivatives of TCP/IP) will become stronger. Remember how the 7-layer OSI was supposed to replace TCP/IP? I still remember my instructors at school professing that TCP/IP was a dead end and that OSI was the way to go. I guess the real world is not always as practical.
One last interesting point about how the server receives the connection. Ever since 1997 when Citrix sold Multi-Win to Microsoft, the actual socket is accepted by a Microsoft device driver. The driver is configured to listen on different ports based on how the server has RDP and/or ICA. 2008 will see the first Citrix device driver in PortICA to accept connections. This was necessary since PortICA does not use Terminal Services and needs to implement the entire kernel stack to drive ICA.
