Microsoft "Metro" Applications and Queue-based Printing

When Microsoft introduced Windows 8, they also introduced the shiny "Metro" interface and associated applications. Notably, Microsoft Edge and Reader were some of the first Metro applications to make their splash in the user community. With Windows 10, Metro and the "classic" desktop melded very much into a singular interface platform, even though the two are much different.

So Why Do I Care?

Microsoft has always had a strange relationship with queue-based printing. In the Windows NT 4 Server days, through Windows 2003 Server (and Windows NT 4 Workstation through Windows XP), the general advice was to render print jobs to the PDL (Page Description Language) from EMF (Enhanced Meta File) on the print server. This was based on the (rightly or wrongly) premise that servers were made of better stuff (faster CPUs, more RAM) than were client machines. When Microsoft updated to Windows 2008 Server and Vista, that opinion shifted to making the clients do the rendering because they were either equal to, or greater than, the hardware capabilities of the servers to which they were connected. And Client-Side Rendering (CSR) was born.

Still Not Caring...?

For all of those non-Metro applications, the move either way has not really made much difference; they do what they do regardless of the place the PDL is generated. But not Metro.

And That Is the Problem!

If Client-Side Rendering is disabled on the print server's queue, printing from a Metro application will result in two print jobs on the print server, with one having a slightly older time stamp:

How Do I Fix It?

The resolution is as simple as enabling that checkbox to "Render print jobs on client computers." You'll still see the double job happening on the client:

but it won't show up on the print server, resulting in saved paper and user happiness.