Citrix Rebuilds Printing from Scratch for the next MetaFrame

Author's Note: The information in this article is based on information I’ve received from the various sessions and by talking with Citrix folks at the Tech Lab at Citrix iForum Global 2004. This information is not based on my own experience or testing, so it’s possible that I don’t have some of the details exactly right.

Author's Note: The information in this article is based on information I’ve received from the various sessions and by talking with Citrix folks at the Tech Lab at Citrix iForum Global 2004. This information is not based on my own experience or testing, so it’s possible that I don’t have some of the details exactly right.

I announced yesterday that Citrix would be releasing MetaFrame Presentation Server 4 (MPS4) in early 2005 instead of Feature Release 1 for MPS 3. (In fact, I'm hearing that the concept of Feature Releases is going away all together.)

One of the show's technical sessions by Citrix employees Jim West and Gary Barton focused entirely on the new printing architecture. For MetaFrame Presentation Server 4, they said, “We took a wrecking ball to the way we do printing and rebuilt it from the ground up!” This is huge news and will make a lot of people happy.

Some people have cautioned that we must wait and see whether this new printing subsystem is actually any good before rejoicing. Others point out that a re-architected printing environment can’t possibly be any worse than the current printing environment, so it’s okay to get excited about it now. In this article, I'll share my understanding of what the new printing environment will look like.

Current Printing Problems and Limitations

If you're not familiar with any of the current printing issues in Citrix environments, take a look at Stefan Vermeulen's site

Citrix started out by talking about some of the current printing limitations. (All of these current limitations apply to both MetaFrame XP and MPS 3, since printing didn’t change between them.)

Current limitations include the fact that you cannot assign default printers to users, printer objects are often orphaned and left behind after users log off, and printing policies are not based on location or connection type. They also talked about the current printing scalability issues, namely that CPU utilization spikes as printer objects are built-up and torn down with each logon and logoff. Citrix even told us they understand that current printer names are too long and that users usually can’t tell one printer from another from within an ICA session.

To address all these issue, Citrix realized that they had to start with a clean slate.

The Printing Architecture of MetaFrame Presentation Server 4

To begin with, printing in MPS 4 is accomplished with its own isolated subsystem. A new print manager service (cpsvc.exe) will take care of the collection of random DLLs and executables responsible for the printing voodoo in MetaFrame XP and MPS 3. (In MPS 4, client printer mapping will still be it’s own virtual channel. It’s just that now that virtual channel will be managed by the print manager service instead of cdm.sys which is responsible for managing all the other virtual channels.)

This new print manager service will act as the central clearing house for all things printing. It will communicate with the server's spooler service, ICA clients, remote printer services, and other MPS 4 print manager services. What this effectively means is that applications will no longer submit their print jobs directly to the spooler. This will allow Citrix to step in and do what they need to do with the printouts. (This is similar to what ThinPrint and triCerat's Simplify Printing do today.)

The big key here is that the MetaFrame printing architecture is moving away from the current “universal driver” format and towards an EMF-based format. (Read the "Third Party Products" section at the end of this article for more information about EMF-based printing.) EMF-based printing has several advantages over univesal driver-based printing, including:

  • Print jobs are not rendered on the server, decreasing CPU usage.
  • EMF files are smaller, decreasing server processing requirements
  • EMF files are the "native" format generated by Windows, which means they can be used on any printer.
  • EMF files are the "internal" printing format used by Windows, meaning that you don't need printer-specific drivers installed on your servers.

In MPS 4, the new print manager service will also compress the print data stream before it hits the ICA virtual channel. (This is a departure from MetaFrame XP and MPS 3 where print data was compressed just like any other ICA data.) This should provide more flexibility and better compression ratios.

From the user standpoint, the naming structure of printer objects is being changed to be more user friendly. When printer objects are created based on client printers, the printer name will show up with the same name as it is on the client (with the exception of a “session xx” identifier tacked on to the end). This should lower user confusion because the important part of the name (the first part) will be the name the user is used to.

Also, MPS 4 printer objects will pull device-specific printer settings from the ICA client. This will include tray settings, finishing options, paper type, etc. If there is a server and client printer driver match, all client printer settings can be inherited by the server. If the client does not have the ability to save printer settings locally, they can be saved as a user profile on the server.

Finally, Citrix has created a new little client side EMF viewer application. This allows users to preview printouts locally on their client devices in the exact format that they’ll print.

Administrative Changes

From the configuration and management standpoint, all MPS 4 printing options will be configured via Citrix policies instead of at the farm level. This means that you’ll be able to granularly control which types of users and connections use which type of printer options.

Printing will also be more tightly integrate into Citrix’s Smooth Roaming initiative. Administrators will be able to create policies that define customized printer workspaces based on the type of connection.

From a security standpoint, the new printing architecture will change the way that printer objects are created on the Presentation Server. Printer ports will be created with the context of a session, meaning that they’ll be “private” to each session.

What does this mean to the "other" printing vendors?

This announcement obvious has the ability to impact ThinPrint, triCerat, UniPrint, and EOL. I think it's too early to tell how this will shake out (since I haven't played with the Citrix stuff yet), but you can bet that these companies will be watching carefully.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

This message was originally posted by MTB on October 6, 2004
A new printing architecture? Now I am really P.O.'d that I didn't attend this year. It sounds as if this is shaping up to be a good iForum. Keep the info coming, Brian. Great job!
This message was originally posted by an excited visitor on October 6, 2004
Can't wait to see MPS4 when it is finally released. Something lke ThinPrint would be a real boon to our company which carries out a lot of printing using CAD like applications. ThinPrint is an EXCELLLENT product whic we have had zero problems with apart from trying to get it to work seamlessly with the CITRIX client.... Keep the good news a rollin!!!
This message was originally posted by David Teague on October 6, 2004
Of course I have given up on citrix printing all toghter and have been recommending Tricerat for the last year, but I would love to not have to tell a customer that they need to spend xxxx amount of dollars on top of thier citrix price.
This message was originally posted by xs4citrix on October 6, 2004
The magic word on iforum was also mfcom for about everything.
The current management console for the access suite is more of a read only thing, but the focus is there, so we can expect more development coming from that side, expanding the mmc snap ins into a real smooth tool.
Hopefully the TP on MPS4 will allready show improvements on that part.
This message was originally posted by CMan on October 8, 2004
I have evaluated all of the third party printing products out there and came to a single conclusion, whilst they are all very good, they all have their shortcomings. There is no way Citrix will blow away the competition here, and nor I suspect are they trying to, they are just trying to do what customers have been asking for years....make printing a little more robust in the standard product. As Mr Byrne says, Tricerat and others have a huge head start and will no doubt add more and more functionality to their products keeping way ahead in this particular market. Well done to Citrix for responding at last to customer needs, lets just see how robust the product is!!
This message was originally posted by ThinPrint Reseller on October 8, 2004
We resell ThinPrint, and they said the exact same thing. They've worked really hard on their product, and they had a lot of engineering issues to work out with v1. They don't seem to worried about Citrix EMF printing.
This message was originally posted by John Byrne on October 8, 2004
Citrix did not invent anything here, they simply *TRIED* to copy what's out there. I also spent time in the lab with this...and it is most definitely NOT simple. And since it is a 1.0 release of their EMF solution, there are going to be a ton of applications that won't print correctly.

Trust me on this one: triCerat has worked on this for years. It's taken an incredible amount of effort to get where we are today with Simplify Printing v3. While we commend Citrix for announcing they have fixed printing....well, this is at least the 4th time...?

Also, um, where is the RDP support for all this? Oh, that's right, they view the world as ICA only.


John Byrne
President, triCerat inc.
This message was originally posted by Just a dude on October 7, 2004
Yet another example of citrix following the lead of other companies with respect to how to enhance their own product. Some would call that listening to feedback. I call it lazy. Wouldn't it be nice if citrix turned over the proactive coin once in a while and decided to lead the industry in thin computing with advancing their own product first? Rather, they wait for others to capitalize on their shortcomings and then mooch off their technology.
This message was originally posted by an anonymous visitor on October 8, 2004
I can only hope that the message above from "John" is not actually John Byrne himself. I know John, and nothing shows worry or concern about how Citrix addressing their printing issues than a message like that.
This message was originally posted by Jeff Pitsch on October 8, 2004
I hope Mr. Byrne can explain why Citrix would want to extend the functionality of RDC? Does TriCerat extend the functionality of their competitors product in some way that no one is unaware of?
This message was originally posted by airizona on October 14, 2004
"Customers won't spend additional money for a bunch of 3rd Party tools"
....@ 300 Dollars per concurrent user, I guess you need to include Citrix as the most expensive 3rd party tool, or are you running Citrix without Terminal Services? ; )
This message was originally posted by Michael (MIRU) on October 14, 2004
Hi Brian
Just remembering the Munich PubForum, I'm excited about this new technology and I agree with David, that customers won't spend addidional money for a bunch of 3rd Party tools to get their SBC environment working well. This is a step in the fine direction.
This message was originally posted by Tech Analyst on October 15, 2004
Notice most of the people putting down Citrix for this are those who's jobs are closely tied to the competition, ie: Mr Byrne, the president of Tricerat and ThinPrint reseller. I can understand your concern folks, but until it's actually out and available, dont knock it, especially if it's free. There will always be a need for 3rd party products if it doesn't meet the needs the consumer. Citrix has developed solid products and continues to make improvements over time. Of all the software vendors that I deal with, Citrix is definitely the most responsive. I'm not singing Citrix's printing solution praises - yet, but I think it's a positive step and Citrix should be applauded for making the effort. This is definitely not a 'Yawn' announcement
This message was originally posted by Brian Madden on October 20, 2004
The article from Adobe that you refer to about "limitations" of EMF printing is only when printing to Postscript printers. The Terminal Server itself generates the EMF file, and the Citrix ICA client interprets it. It would be very easy to add this functionality to a non-Win32 client. (Although I'm not sure if Citrix is doing that or not.)
This message was originally posted by Henrik on October 21, 2004
Working with Citrix for 5 years now, and printing has always been the biggest issue / time consumer when implementing and when supporting. Citrix has in all years never listened to resellers and customers complaints and suggestions but I see a little opening there now. Just to bad there so late about it. So far they never succeded in solving this big issue with printing, so I'm gonna wait and see the tests and results that will come out of it.
This message was originally posted by on October 20, 2004
here is an article from Adobe that point out some of the limitation of EMF files
This message was originally posted by an anonymous visitor on October 20, 2004
I guess MPS4 printing solution will not work with thin client device or any non win32 windows based client (like mac and unix) becuase EMF file is "internal" windows protocol ??
This message was originally posted by Peter Ghostine @ Emergent OnLine on November 6, 2004
Brian, adding EMF support to non-Win32 clients is by no means a trivial matter. Contrary to previous comments that you had made, EMF is not a "printing" language (i.e., like PCL for example). An EMF file contains Windows GDI commands which can only be interpreted by Windows, not the printer engine. For an EMF file to be played back on an non-Win32 platform, these GDI commands must be translated to instructions specific to that platform. If that's "very easy to do", good luck!!! And even within the Win32 family, EMF is not standard enough to warrant its use as a universal printing solution... At least, not without a lot of serious work!!! For example, Windows 98/Me support EMF 1.0, NT 4.0 supports EMF 1.003, and Windows 2000/2003 support EMF 1.003/1.006/1.007/1.008. None of the EMF formats are 100 percent backward-compatible. I'm sure the EMF-based product vendors can confirm how problematic this is, especially when replaying the EMF on Windows 98/Me. Some of the GDI commands generated on Windows 2000/2003 can't even be interpreted on Windows 98/Me. I'm not saying that there are no workarounds to such problems, but to say that EMF is the end-all solution is a bit presumptuous. I'm not going to promote any vendor's solution here, (including Emergent OnLine's), but we'll soon be releasing a new version of our Universal Printing solution which supports both PDF and EMF. There are pros and cons to both, and I will be pointing them out in an upcoming technical paper. I will also discuss each vendor's solution (including Emergent OnLine, ThinPrint, TriCerat, and UniPrint)
in the most unbiased manner possible.

Regarding Citrix's upcoming EMF driver and support for client printer properties (i.e., trays, paper sizes, etc), all the aforementioned vendors have had this for years, and I can assure you Citrix will run into problems in that respect too (let alone EMF-related problems).
This message was originally posted by an anonymous visitor on November 19, 2004
Don;t know about you but this is going to be bad news for our company...

16.11.2004 - RDP only – ThinPrint announces a solution designed exclusively for Microsoft Terminal Services

Remote Desktop Printing Engine

The easily installed and administrated print solution especially for
Microsoft Terminal Services
Name a company that doesn't do this.... A little short-sighted on your part.
Hm, what's the use of adding rdp support when you want people to use your own product, namely ICA? Smart move on their part I think. Microsoft has been doing this for years :-)
Simply buy a real computer and be done with it. No I'm kidding. It is kind of strange to add a non-unified printing protocol to a unified connection protocol. But then, doesn't the mac use the ica-emf protocol to print when connected via ica? I'm going to get me a mac just to see how this all works ;-)
This is by far the best feedback on Terminal Server printing that I've read in a long time. Who's this guy?
On our Citrix servers this new printing service takes up 300MB of memory!!
holy sh*t


If you're going to be running around throwing blame, why don't you rephrase that question to be: "Why didn't Microsoft design a good printing system in the first place?"  And the answer would be because they didn't know way back then what the business requirements for multi-user, multi-device printing would be in 2006.

in PS4, they're longer than ever now:  printername (from clientname) in session xx