Compartilhar via

Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 2)

  • Artigo

Welcome to part two 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. Now I want to spend some time talking about the technologies to ensure that email, calendars and other Office content can be consumed across multiple device types. I think of “Office” as the communication, email and collaboration workloads in addition to the apps themselves, so these workloads are very much a part of this story. Before I get into topics like customizing the Office UI for touch devices or remotely accessing desktops, let’s start with the build environment I am using and then I will go into the basics of mobile device connectivity to Office workloads.

My Build Environment

I’m always a stickler for making sure that everything is actually running and working before I try to describe it, that way I know the pain of building and wiring up everything. While I don’t have something like the entire Windows Server System Reference Architecture (WSSRA) environment – which we affectionately used to refer to internally as “Minicore” – running to test this stuff out, I do have a relatively robust (and portable) environment. Minicore in WSSRA ran 32 virtual machines, but I am running six VMs and using the host, iPad, and Samsung Galaxy Tab as clients.

  • HP8540W laptop with Quad Core i7, 16GB RAM and 1 TB RAID 0 SSD storage. Onboard NIC and PCIE NIC
  • Windows Server 2008 R2 Enterprise with Hyper-V Role installed
  • Six virtual machines all running Windows Server 2008 R2 Standard
    • Domain Controller
    • SharePoint 2010
    • Exchange Server 2010
    • RDS RemoteApp
    • Citrix XenApp
    • Forefront Unified Access Gateway 2010 (UAG)
  • iPad 2 (with iOS 4)
  • Samsung Galaxy Tab (with Android 2.2)
  • MacBook Air with Office for Mac 2011
  • Cisco wireless router connected to the PCIE NIC

This is what I carried with me to TechEd and the SharePoint Conference this year, so you don’t want to get stuck behind me in a TSA queue at the airport. That is the environment I will also be grabbing screenshots of for the rest of the series. Now, we’ll start with the basics.

Exchange ActiveSync

Back in 2002 we built something called AirSync as part of Microsoft Information Server (MIS) 2002 and about a year later the feature was expanded and moved into Exchange Server 2003 and renamed Exchange ActiveSync. I still remember the initial ability to get email and calendar on my phone in my early days at Microsoft and it was a lifesaver. Over the years Exchange ActiveSync (EAS) has evolved and with its availability to non-Windows platforms, it has become a key value and security pillar across many device types, including Windows Mobile and Windows Phone, Apple’s iPad and iPhone as well as Android-based devices. For me regarding this blog series, it is also the lowest common denominator to get Office access on a variety of devices.

Exchange ActiveSync provides a variety of important IT administrative features, such as the ability to require and enforce a PIN to unlock a device. This forces an additional factor of authentication so that if a device is lost, one would need to know the PIN for access to either the entire device – in cases of devices with native Exchange ActiveSync support – or to the software environment connecting to EAS, such as TouchDown from NitroDesk or RoadSync from DataViz.

Above is the properties view from Exchange Server 2010 and in addition to password policies, we can set policies for sync settings and other device attributes, such as the ability to disable device cameras and browsers. In high security environments, these controls provide additional protection for data leakage and protection from malicious code entering via Web browsers. Apple also provides the iPhone Configuration Utility to be used with third party mobile device management (MDM) infrastructure to push policies out to iPhone and iPad devices.

A substantial piece of the enterprise security story for these devices comes via the Exchange ActiveSync capabilities and the work needed for these devices to support them. This is also true for Android 2.0 and newer devices with native EAS support.

The configurability of devices using the controls in Exchange ActiveSync is a step in the right direction for most devices and by limiting the number of days of email stored on a device helps reduce the risks associated with data security, but the implementation of EAS across devices, including iOS, Android, Symbian and Windows Phone varies dramatically from platform-to-platform. This is especially the case with Information Rights Management (IRM) using Exchange ActiveSync and at the time I am writing this, IRM using EAS is limited to Windows Phone and Windows Mobile platforms. For organizations requiring increased security for specific email traffic, IRM provides persistent protection to messaging content. Because EAS clients are increasingly being used to access e-mail, it's important that your mobile device users be able to create and consume IRM-protected content in a secure way. When I say EAS support on these devices is a step in the right direction, I really mean it cannot and does not compare with Active Directory Group Policy controls most IT departments are used to. This is something to think about when entertaining the idea of shifting users to lesser-developed platforms.

Group Policy Configuration Management with Office

Office has a rich history of granular configuration management on the Windows platform. Starting with policy management capabilities in the Office 97 release, capabilities have grown dramatically in the last 15 or so years. Back in those days, there were just slightly more than 50 enforceable settings and with Office 2010, there are more than 2000 enforceable settings. I know that some are wondering so I will mention that Office for Mac 2011 (as with previous Mac versions) contains no enforceable settings and uses optional install-time preferences only, which as I mentioned in part 1 can be changed by users at will. Speaking of install-time preferences… that leads me to ways Office can be configured at install-time on Windows. These are extremely important to the security and manageability story of Office, because you can determine not only how Office is configured, but also configure things like confidentiality settings (encryption and IRM rules), integrity settings (trusted publisher and location + digital signature rules) and availability settings (VBA Macro, add-in, ActiveX, Internet Explorer and file blocking rules). These controls are unique to a Windows environment running Office.

There are three primary control mechanisms to lay Office down in a customized way on a Windows machine:

  1. Group Policy Predefined Settings
  2. Config.xml
  3. Custom MSP file generated using the Office Customization Tool (OCT)

These are also listed in the order of who wins if there are conflicts. As you would expect, Group Policy settings have the most control and supersede whatever you define in the config.xml which supersedes what is in a custom OCT-generated MSP file. There are thousands of possible Group Policy settings available to you when configuring Office 2010. The problem effectively becomes “Where do I start?” and we have the Security Compliance Manager to help you establish baselines because it is easier to start with a known usable configuration and tweak that versus starting with a blank canvas.

Next in line of priority is the config.xml file used in tandem with Office. Because it is XML and there isn’t a ton of stuff predefined, you probably don’t want to use it for a long list of settings, but for configuring things like simple calls to an activation service or customization of language proofing tools, the config.xml file is your best and sometimes only option. Here is what a relatively standard config.xml file looks like:

The last option is to use the Office Customization Tool. This tool essentially drives how Office gets installed and configured. These settings – like with config.xml – are set at install time only and not enforced. If your do not then use Group Policy enforcement, the manageability and security of what you need policy-enforced in the environment is severely compromised similar to Office for Mac. OCT exposes the same settings as Group Policy and allows you to perform registry writes and run custom commands during the Office setup process. The most common control used in a managed deployment of Office 2010 might be the setting to Suppress recommended settings dialog – as this pops-up a message to users essentially asking them to opt-in to Windows Update, which is something that most managed environments’ IT admins would perform on behalf of the user with tools like Windows Server Update Services (WSUS) or System Center Configuration Manager.

Those are the primary ways to customize an Office install on Windows and I wanted to make sure I covered this content, because even if you are reading this blog for clues on how to deliver Office to an iPad, these will come into play when we start discussing ways to host Office on a remote desktop or server and access that via the iPad, Android or Windows device. Whether I am provisioning to a Windows Server 2008 R2 box with the Remote Desktop Services role installed or a remote Windows 7 virtual machine, I’ll still want the ability to customize that installation on the fly – especially if I am providing this service for thousands of users.

And on that bombshell, I will conclude part 2 of the series. Be sure to read part one if you haven’t already and I hope to post part three in the next couple of days.

Thanks for reading,

Jeremy Chapman

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:

  1. Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 1) – Introduction and Methods to Deliver and Consume Office
  2. Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 2) – Exchange ActiveSync Considerations and Customizing Office Client Installations
  3. Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 3) – Office Web Apps on Non-Windows Devices
  4. Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 4) – Device-Based Access Management
  5. Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 5) – User Interface Configurations to Prepare for Remote Desktop Environments
  6. Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 6) – Building Solutions for Remote Access to Windows Environments

Comments

  • Anonymous
    December 07, 2011
    "If your do not then use Group Policy enforcement, the manageability and security of what you need policy-enforced in the environment is severely compromised similar to Office for Mac." I believe you menat "you" in the quoted section above. Great blog btw, very informative.