Follow / Friend Us
Welcome to the sixth and final part in the series about managing your Office assets in a world of tablet computing. In part one I mainly introduced the primary ways to consume Office with rich clients, remote rich clients, Office for Mac, Web Apps and Office on the phone. In part two I talked about consuming email on tablets using Exchange ActiveSync, compared the controls you get with other platforms to Group Policy and described options for configuring Office. In part three I wrote about the Office Web Applications as part of the SharePoint 2010 or Office 365 service. In part four I introduced a few ways to differentiate resource access based on device trust. And in part five I talked about tweaks to the Windows shell and Office ribbon to make things a little friendlier for touch on a small screen device. That all leads then to how to broadcast those remote Office application or complete Windows environments down to a connected device.
There are many ways to remotely access a computer. Native to Windows we have Remote Desktop Services so you can connect to a client or server from a remote Windows computer and related to that there are tools like Windows Remote Assistance which can be used standalone or the underlying Remote Desktop Protocol (RDP) connections can be hooked by programs like Remote Desktop Connection included with Office for Mac 2011 and Microsoft Lync or delivered via third party programs like GoToMyPC from Citrix, LogMeIn, or pcAnywhere from Symantec.
RemoteApp was introduced in Windows Server 2008 and uses similar connections and protocols as viewing an entire remote desktop, except the client can trim out the unused portions of the desktop to expose only the application window on the consuming client. RemoteApp windows behave similar to windows of applications on the local desktop, but the application is being executed remotely. Windows XP Mode works in a similar way when only application windows themselves are visible from the underlying Windows XP virtual machine.
This all becomes important with different devices, because we may not want to expose the entire Windows desktop and opt to only show the applications themselves. One of the best graphics I have found to visualize all of this comes from the Infrastructure Planning and Design guides for RDS.
On the right side you can see the view and options from consuming devices and the left are the options for hosting. The RD Session Host can have applications installed locally and and each connecting user gets a user profile and can view the application. For Office, this means that Office Volume License (VL) versions are used to install against that server. (Note: non-VL versions of Office will not install on a server with the RDS role applied and if you install Office prior to the RDS role, Office programs will not launch once the RDS role is active). In the Hyper-V case shown in the top left corner, the virtual machines act like physical computers and normal client installation rules and parameters apply. You can also see that domain credentials can be used to facilitate logins and wire up user profiles depending on the architecture you select.
Microsoft and Citrix have had a long history of partnering on remote desktop technologies. There are other options out there, but given the history, partnership and prevalence of Citrix, I opted to build my environment using their XenApp solution which follows the path of the RemoteApp scenario I described earlier. One of many advantages that Citrix bring to the table is the device coverage they have for Citrix Receivers – the applications used by iPads, Macs, Blackberry and Android slates among others to present remote Windows environments. XenApp is also well-integrated with Windows to make setup and configuration an easy process and XenApp’s policy management controls augment what can be done via Group Policy in Windows. For example, we can restrict printing rights to the printers on the corporate domain.
Another thing we’ll typically want to do along with setting up default save locations to either a managed SharePoint location or within the user profile is hide or lock out locations outside the user profile. After my many years of product managing the User State Migration Tool, I know there are a large subset of users who like to store things in custom folders on the root of C:\ instead of a user location we can easily roam from device to device, so I will configure Group Policy rules as well to prevent that behavior.
The great thing about using the XenApp solution and accessing a remote Windows environment is that I don’t need to give up Office features – the entire client plus any custom add-ins can be used.
There are quite a few advantages to remotely hosting applications and desktops and relegating the consumption device as a viewer or remote controller.
Those are just a handful of the advantages and they accumulate to the reasons why many organizations are looking at or implementing remote desktop and virtualization solutions.
Along with offering the full breadth of Office functions one of the great user benefits of using remote desktop solutions is that the sessions the users connect to can remain active. That means I can leave my desktop computer at work with my files open and everything else I am working on then when I move to my slate device, I can pick up where I left off in the same documents and then access the same environment from my home computer or phone. Since we are just remotely viewing a running environment it can remain running and for the most part stays – always on. Of course once in a while the remote environment needs servicing, but the sessions can often remain active for a few weeks at a time.
Along with these advantages are a few disadvantages. I still need a good connection to view the remote session without any interruptions and I don’t really have offline access if connections go down, or I am traveling or I happen to be the “man in the cave” or submarine or the oil drilling rig as we like to bring up in analogies. There are also multiple points of failure. The Infrastructure Planning and Design Guides I mentioned earlier will help plan for eventualities, but the fact remains that any link in the authentication host-web server-licensing server-connection broker-session host/virtual machine chain can cause service disruption.
I’ve covered a lot of ground in the last six blogs and started with the lowest common denominator for device support, Exchange ActiveSync, and progressed through options within the firewall using Office Web Apps and how to differentiate experiences based on device trust and what we can query from them using tools like IIS and UAG and finally talked about way to prepare for remote access with user interface tweaks and finally the tools and tech used to build it out.
While I couldn’t go super deep into how each component is built and configured, I hope I at least exposed a few additional options to you if you are considering integration of new devices into your hardware standards list or are backed into figuring out ways to improve Office file security and access for existing devices and the next wave to come.
My opinion on these devices is that they haven’t had the time to mature into manageable platforms and are slowly figuring out what we’ve been figuring out with the distributed computing model over a few decades. The ecosystem does continue to grow and follow the platforms achieving traction in the market, but in the meantime it’s about determining the best solution with the level of risk appropriate to your situation. On one end of that spectrum is letting the devices exist within the firewall and perhaps figuring out ways to provide measured access to resources and on the other end is relegating them as viewers into managed computers. It’s really up to you.
Thanks for reading,
Senior Product Manager
Office IT Pro Team
UPDATE: Now that all of the blogs are complete in the series, here are links to all six completed blogs: