Search This Blog

Wednesday, January 29, 2014

H2T shall henceforth be called... Ubiquity!

... because it's easier to say. And sounds cooler.

That is all.

Google Cloud Print - A Remote Desktop Solution For "Anywhere" Printing

It isn't often that I get giddy about a tech discovery (or re-discovery in this case), but when an elegant and effective solution to a significant technical challenge comes along, I experience Nerd Joy. This week's Nerd Joy brought to me by Google's updated Cloud Print service.

I came across Cloud Print quite awhile ago, back when Google first released it I think. My impression was that it was interesting, but not quite useful enough to really try and fit into my infrastructure. This week I happened to stumble across information about the updates Google made to the service back in July of 2013

Specifically, Google now provides a mechanism for enabling access to remote printing via a Windows service that runs in the background on a client, which administrators can then associate with a "master" print user in Google Apps. This user can then share those printer instances tied to that account with the rest of the users in the Google Apps domain, much like access to folders and files in Drive can be shared.

I installed and tested this service on a couple of machines at different sites, then shared the printers that were added to a test account. Printers can be shared per user, group, or publicly via a link that, when clicked, prompts the currently logged in Google Apps user to add the printer to their collection. While this mechanism works most effectively when someone is using Chrome, I also tested printing while logged into the Apps test account using Firefox.

The fairly minor catch in this process is that the printing is not handled by the local Windows printing service, but rather a document not already in Drive must be added to a print queue via upload.

A Windows Cloud Print "driver" is available that installs a virtual print driver (much like the "universal" print drivers from HP), but initial testing did not have the same success as the uploaded documents. When the virtual print driver was selected as the target in a Windows application print dialog, the print job got stuck in the queue with a status of "in progress". From what I can gather, this is a commonly encountered wrinkle. However, it is FAR from what I would call a "show stopper".

The reason this has me so giddy is because remote printing has been the one function people count on that's not reliably available using Remote Desktop. Yes, RD can "redirect" a printer connected to a local machine so that the printer instance is available for printing from the remote session, but unless the remote desktop session in question is logged into a client behind the same router as the local machine, printing response is glacial not even available.

I have toyed with the thought of making one or two printers at each site available via port forwarding and enabling IPP, but my impression is that this would be no less cumbersome to employ for remote desktop use because it still requires print driver installation on each potential RD host. Not manageable.

With Cloud Print, not only can I skip the driver installation requirement (or hair pulling experience of driver compatibility on servers) and messing with GPO to get Easy Print 'working", but I can also manage permissions and enable end user "self-install" of Cloud Printers with a single internal web page that provides a link to each printer that staff can add as needed.

Installing the service on one machine at each site that has multiple local networked printers installed is dead simple, and just WORKS. Staff who will be using remote desktop from multiple sites can be motivated to take that extra step to print if it means printing is now a more responsive function and they don't have to email themselves a document, then download it to the local machine (completely negating the security/privacy feature of having a remote desktop in the first place), then try and figure out which printer is available from the local machine, then remember to delete that downloaded document... et cetera, et cetera. 

Typically, in my experience, if a workaround procedure takes more than one extra step, it's going to cause frustration and ultimately be avoided. 

Providing all the functionality of a local desktop session within the privacy/security of RD is the ultimate goal for the H2T project. Google Cloud Print provides the means for staff using Remote Desktop to keep ALL their work functions encapsulated in the RD environment. Furthermore, GCP enables a critical enterprise function to be managed within Google Apps, removing yet another complicated piece from the Microsoft Server puzzle I am trying to simplify.

Finally, in the "icing on the cake" department, there are GCP apps for both Android and iOS, making the prospect of printing from mobile devices a very realistic option.

On we go!

Friday, January 17, 2014

New Year Check-In - H2T progress!

It's 2014 and the H2T project has moved past the POC phase: a Windows 7 VM hosted on a repurposed IT workstation running Server 2012. 

This shared remote desktop host is being used by 4 staff members. These staff members were previously using Windows XP, and not only made the transition to remote desktop without issue, but also did well with the move to Windows 7 (I did a lot of work to make the desktop navigation similar). Granted, 2 of the 4 staff had been using RD to work from home for the last year already, but this was still a significant change for them. A benefit to those who had been using it for awhile, their home RD experience was improved with direct connection to the RD host.

The POC was a 2 month initiate and monitor process. I encountered some issues (Firefox does not allow for concurrent use), but discovered new ways to refine the management of user profiles (use Portable FF, place in folder of Default profile and shortcut on desktop, multi-user FF!!!).

There were some refinements to the remote desktop client config needed prior to finalization of the Thinkiosk configuration for the converted machines used by the 4 staff. I found some discrepancies in RDP version, and variations between RDP on 7 and XP. Additionally, there were workarounds necessary in the setup of RDP for the Thinkiosk client configuration. These have not amounted to show stoppers, just more insight about the nuances that sometimes drive this effort. 

Getting to the point where calling up RD from the kiosk interface never remembers data from one use to another (use /public in RDP shortcut config of Thinkiosk) was the goal. I am now sufficiently comfortable with the Thinkiosk client installation and configuration that I am moving forward with the first H2T kiosk image.

For much of the project, my intention has been to avoid rebuilding machines. Having spent what I would call "too much tinker time" on the first 3 XP conversions to kiosk mode - removing old applications and data, updating and securing the OS - I have concluded that it will be faster to rebuild a machine with Windows Embedded (what I keep seeing Win 7 ThinPC called), pre-installed generic config for ccarcvpn (not auto-connected), and generic Thinkiosk config applied. I also installed the most current version of IE (11) - the browser called up when the kiosk interface loads - and installed OS updates to current. There is no other software on these machines; no Flash; no Java; no Adobe Reader. Nothing to monitor or undo later. Simple.

Yesterday I built a demo "kiosk" PC using a miniITX form factor motherboard (CPU included) and case, a 64GB SSD, optical drive, and 2GB of RAM. The optical drive is optional for most cases with a machine like this. External drives can be made available to departments that need them regularly. Because this was my first MiniITX build it took a little longer to put the parts together (GIANT HANDS) but box-to-boot time was still only about 30 minutes.

The bottom line for this machine without an optical drive is $207. I put WE and Thinkiosk on it. Smooth like butter. This will be the de facto kiosk client hardware configuration for new machines.

Next step is to image this new machine and apply that image to an old Dell machine (Dimension E3100s and E310s). It will be interesting to clock the rebuild process. I can't imagine it will take anywhere near as long as decommissioning software on XP machines by hand. The bugger will be with drivers, as the kiosk image is a pristine build with only the drivers for current hardware tucked into the OS data.

/goes off to do some braining/

Later The Same Day...

I just did a rebuild on an old Dell with the kiosk image and a current batch of drivers from I was entirely unprepared for the speed of this rebuild. The build image is about 6GB, easily 10GB smaller than the existing and bloated Windows 7 images. From the time I hit go in Acronis to start the rebuild, it was about 9 minutes til I was clicking through the kiosk interface and accessing the web and remote desktops as hoped. Didn't get nagged for drivers. No devices were left out. It just worked. It was what I imagine loading an OS with PXE to be.

Nine minutes. Twenty minutes less than the average time for the previous generation of builds.


Updated 01.29.2014 - The H2T project is now called Ubiquity.