The Office Sustained Engineering team has released Service Pack 3 (SP3) for Office 2007 and SharePoint 2007. For complete details, including a list of all download and description links to the SP3 packages, see Office 2007 and SharePoint 2007 Service Pack 3 Availability. In addition, the links are available in this Knowledge Base article: List of all 2007 Office system SP3, 2007 Office servers SP3, and Windows SharePoint Services 3.0 SP3 packages.
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,
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:
First off maybe you might be asking, what is MODI?
MODI stands for Microsoft Office Document Imaging. MODI is a Microsoft Office application that supports editing documents scanned by Microsoft Office Document Scanning. It was first introduced in Microsoft Office XP and is included in Office versions up to Office 2007.
MODI is able to:
In our Office 2010 content on TechNet, we provided several articles supporting each application and explained the changes from Office 2007. These articles included information about the deprecation of MODI (Changes in Word). In order to get the functionality back, we offer two supported methods:
1) Non-Enterprise users: Review the following KB article for the alternative methods to regain the functionalities of some MODI features: http://support.microsoft.com/kb/982760.
2) Enterprise users: Install Microsoft SharePoint Designer 2007. It has MODI in it, and includes the OCT ability as well as config.xml, so you can customize and run it.
Enterprise Users
SharePoint Designer is a free download available from the Microsoft Download Center and can provide the MODI functionality by following these steps:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=BAA3AD86-BFC1-4BD4-9812-D9E710D44F42&displaylang=en
NOTE: This download does have the ability for the admin to create a customization file in the Office customization tool (OCT) to install MODI. You will need to download the main .exe; SharePointDesigner.exe, then extract the files with the command line. For example:
\\Servername\ShareName\SharePointDesigner2007_download\SharePointDesigner.exe /extract:\\servername\sharename\
This will extract the setup.exe, Admin folder, etc.
2. Run the following command to create the customizations in the OCT:
\\Servername\ShareName\SharePointDesigner2007\setup.exe /admin
3. Within the OCT, you would go to Set feature installations state, and make everything not available, except the MODI, as in the screenshot below. Changing the OCT settings to hidden and locked, if you do not want users to utilize SharePoint Designer, will hide it from within the Add/Remove Programs.
Since you are only installing MODI, the shared files of Owssupp.dll and MSO.dll, would not be affected when interacting with SharePoint 2007 and Office 2010 files (Word, Excel, PowerPoint). Also, the MSOCache footprint is much smaller with SharePoint Designer (~215MB) than with the Office 2007 suite (500 to 900 MB depending on SKU)
4. After the installation of SharePoint Designer, if you are using SharePoint document libraries, it is recommended to unregister the Name.dll for SharePoint Designer. Unregistering the Name.dll for SharePoint Designer will address the interaction of Office files stored on a SharePoint document library and having two different versions of Office products (Office 2010 and SharePoint Designer 2007) on the computer.
msiexec /I {90120000-0017-0000-0000-0000000FF1CE} REMOVE=IMNFiles /qn /L*V C:\temp\loggingremoval.txt
When you install Office 2010 SP1, SharePoint Workspace 2010 is automatically installed whether or not it was part of the original installation of Office 2010. This is due to a bug that triggers the installation of SharePoint Workspace 2010. For more details and to learn how to handle this, see When you install Service Pack 1 (SP1) of Office 2010, SharePoint Workspace 2010 is installed.
UPDATE 3/29/12
As stated by Jonathan in the comments:
Just released
support.microsoft.com/kb/2598245
Issue that this update fixes
When you install Office 2010 SP1, SharePoint Workspace 2010 is installed. However, SharePoint Workspace 2010 is not included in the original Office Professional Plus 2010 installation and should not be installed. In certain situations, Microsoft Office Groove 2007 is upgraded to SharePoint Workspace 2010 when you install Office 2010 SP1. For more information about this issue, see the following Microsoft Knowledge Base article:
http://support.microsoft.com/kb/2612800 Office 2010 SP1 installs SharePoint Workspace
Welcome to part five in the series about managing your Office assets in a world of tablet computing. In part one I 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 wrote about ways to differentiate resource access based on devices using IIS and UAG. The next major topic I'll discuss in this blog is how to tweak the user interfaces for remote access to Office environments running on Windows.
In part one of the blog series I referenced the phase “Post-PC Era” and discounted it a bit for those who still want to get real work done and for that need a pointing device and a keyboard. Applications developed for Windows over the years tend to assume that a keyboard and a pointing device exist and we will need to keep that in mind when I start to talk about optimizations we can make to Office and shell configurations for touch. I can say I know firsthand the challenges of using Office with touch navigation, as I use it that way about two hours per day in my car during my commute to and from Redmond.
While this is not an iPad, Android, or Windows slate, it presents the same challenges to be able to navigate a system with applications designed for keyboard and mouse. I’m going to relay some of my findings as I worked through configuring Office and Windows for primary touch use.
In this example, the remote desktop or server will be the target of our “touch-friendlier” configurations. Remote Desktop Services (RDS) can be used to access a full desktop or a remote application window of a Windows Server RDS role installed. In either case we can do a couple of things to make the experience better.
If you navigate to “Control Panel\Appearance and Personalization\Personalization\Window Color and Appearance” on a Windows machine and click on “Advanced appearance settings…” you will see this screen:
If you click on the “close” or “minimize” buttons it will toggle controls over to the Item called “Caption Buttons”. I will set the size at around 40, but it really depends on the resolution you run on the remote desktop or RDS server and the screen size and resolution of the consuming device, so you may need to experiment a bit to get the size right. Likewise, if you click on the scrollbar area, it will select the “Scrollbar” item and you can set that to a size matching the Caption Buttons. These minor tweaks are invaluable when you consider how small the standard buttons can be on a 7” Samsung Galaxy Tab for example:
These changes make scrolling and closing applications possible, even though they may look a bit unusual if you are not used to seeing these controls modified. One nice thing about these controls is that if you access the remote desktop or server session with these configurations, they will be respected by an iPad or Android device using Citrix XenApp for example. If you access this window from a Windows device, it will adjust the Caption Buttons and Scrollbars to the size of the connecting device.
In the picture above you can see a custom default Office tab I called “iPad” and in a previous blog in the series I showed a Word ribbon with a “Touch” tab. This isn’t some secret version of Office 2010 optimized for touch, but rather normal supported commands to customize the default Office ribbon. If you navigate in Word 2010 to “File\Options\Customize Ribbon” you will see a screen like this:
Here I have already produced a custom ribbon tab with larger controls. These will be more forgiving for touch use and the in this case Word will open with the “Touch” tab as the default tab. The result will look something like this:
Notice how each button is large enough for touch use and only a few core features are exposed. When we created the custom ribbon file, it saved an OFFICEUI file in the AppData folder for my user account:
The OFFICEUI file is comprised of basic XML and does not have an affinity to the user account where it was created, as seen below:
You can use this file as part of a default user profile and even copy these files into your Office installation media and use the Office Customization Tool (OCT) or config.xml as mentioned in part two of this blog series to copy this file into the correct location on your RDS server or standard remote desktop build.
Once all of these changes are in place and the iPad, Android or Windows device can access the remote desktop, the user experience should be better than the default configurations. There are still many areas in the application Window where a pointing device would outperform touch using a finger. Here is the resulting look from an iPad with our customizations highlighted in red:
While it doesn’t make every control and font optimal for the small screen touch experience, most common tasks are doable. These minor tweaks to the user interface will help save user frustration and help allow for the use of Win32 applications on non-Windows devices. Many organizations have thousands of customized line-of-business applications and rewriting the critical applications for a different platform may not be feasible.
I was honestly hoping to conclude the blog series with this fifth part, but soon realized that it would take another blog to describe how to configure the remote desktop environment. Part six will then be the final blog where I will discuss the common architectures to get a remote session on an iPad, Android or Windows device and show a few additional security configurations in the process.
An update to Service Pack 1 for Office 2010 now enables the service pack to update all language versions within multiple-language installations of Office 2010. Previously, only the English version was updated. For more information, see Office 2010 SP1 Microsoft Update Change for Language Installs.
Welcome to part four 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. That leads me to the present and maybe one of the thornier topics of the series – how to differentiate resource access based on devices.
When it comes to securing Office data, I think about three primary types of controls:
Local device storage protection tends to revolve around methods of encryption and how to lock someone out of local storage until they can provide as many factors of authentication as required to prove they are who they say they are.
Windows uses BitLocker™ Drive Encryption and there are scores of third party solutions available to encrypt entire hard drive volumes. iPads also use hard drive encryption to protect local data and Android Honeycomb and newer tablet operating systems add hard drive encryption also. Bitlocker’s design does not store user data in unencrypted partitions of the hard drive whereas other designs are not as proven and may store critical authentication data in unencrypted and accessible areas of the hard drive. Common Android versions 1.6, 2.1 and 2.2 platforms do not include native hard drive encryption and would be vulnerable if devices are compromised. To be clear, with Windows you do need to make sure that people are using encryption and enforce that as IT policy. If not, there are numerous ways of accessing information on the hard drives (removing them or booting into other operating system environments), changing local account passwords (using ERD Commander password reset), etc. Once you do require and enforce drive encryption, it is extremely difficult to access information on local storage without having computer-specific authentication factors (Trusted Platform Module, PIN, Smartcard, USB dongle, or password) at your disposal.
If you do choose to allow unmanaged devices to connect inside your firewall, then you have a few options aside from the usual certificate and proxy setting requirements. Some organizations for security reasons will erect a parallel network infrastructure specifically for unmanaged device access and limit information access to assets controllable via Exchange ActiveSync and related infrastructure. While that may have been a good enough option for many environments, IT is often under increased pressure to allow these devices to connect within corporate firewalls. If this sounds like you, there are a few things you can do to help to differentiate device access based on the device or browser connecting to your SharePoint data.
There have been common methods around for determining the health of a computer object hitting your network resources. We’ve had things like VPN quarantine and Network Access Protection (NAP) for a number of years now. In the NAP solution a device is basically interrogated when attempting to access a network and if it does not meet standards (patch state, up-to-date AV, etc.) it is given reduced-to-zero network access rights. Descriptions of how NAP works with IPsec, VPN, 802.11x and DHCP can be found on TechNet and this illustration represents the process flow of detecting and remediating and non-compliant device with IPsec.
The thing about NAP is that it requires a NAP capable computer like Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows Vista, and Windows XP with SP3. So if we want to enforce health using NAP, we would need to deploy devices with a Windows operating system on them.
Assuming I don’t have the ability to use NAP because my connecting device is a Mac, iPad or Android device, what can I do then? There are some options using Microsoft Forefront Unified Access Gateway (UAG) to enforce standards on non-Windows devices (Mac and Linux), such as requiring antivirus on these devices. The follow image shows the policy editor in Forefront UAG and the non-Windows platforms it supports.
The text above will be displayed to users when a device does not meet health requirements enforced by UAG. Information about UAG client requirements can be found on TechNet. Important for this blog is that Forefront UAG SP1 Update 1 adds support for browsers in iOS 4 and Android 2.3 and 3.0 platforms.
Another way you can help secure files from being downloaded to devices is to use Internet Information Services (IIS) to interrogate connecting devices with information passed up to an IIS server and based on that information, allow or disallow downloading files. Using IIS, I can define rules which will redirect devices attempting to download files. In that case, I can inspect an IIS log and determine the identifiers for the device.
In the log above I see the device type “iPad” and browser connecting to the document. Then I can go into IIS and configure a rule that redirects calls from devices with these attributes to a page telling them they are doing something unauthorized by the network admin.
As you can see from the IIS Manager above, I have created a rule that applies to all DOCX file extensions. When the device matches the pattern and has iPad in the descriptor, then I will redirect the user to the download%20denied.aspx Intranet site. I don’t need to do this for all files individually, but can define one rule that encompasses all files with the DOCX extension (or other extensions). The nice thing here is that we can allow the device to view the document using Office Web Apps, because it is rendered on the SharePoint server and only sending a PNG file back to the device.
When the user attempts to download a copy to a device we do not manage, the user will see a screen like this:
This basically would help prevent someone from downloading the file to the local hard drive and using another service to upload it or email it to an undesired location. In the case of an unencrypted hard drive or a device with removable storage, this could help prevent the file from being stored to an unprotected file system, SD card or similar. While this isn’t perfect, it can help reduce unintended activities by users while still providing viewing rights using Office Web Apps.
Data transmission was something else I listed in the very beginning of this blog, but the networking stacks of most current iOS and Android devices support the most common Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA) standards to help keep transmissions safe to and from devices. The key here is to use those methods as opposed to unsecured networks.
Mobile devices have come a long way and continue to improve, however they are not as manageable as more mature platforms instrumented for defense in depth – from data on the device or connecting to remote data. IT is understandable though given the current climate that certain concessions are made to grant access to devices which would otherwise not meet security criteria. Hopefully, some of the methods described in this blog will help you determine ways to provide limited, yet enough access to unmanaged devices to give you peace of mind and keep your users happy. Of course there are other mechanisms like Information Rights Management (IRM) to help provide access to unmanaged Windows devices to sensitive files via Exchange ActiveSync support in Windows Phone 7.5 and Windows Mobile and Outlook Web Access, but they don’t really help the iPad or Android conversation or provide a basis of comparison like NAP versus UAG and IIS policies, so I didn’t really go into detail with IRM here.
I wanted to start the conversation of enabling remote access using Citrix XenApp and Remote Desktop Services in Windows Server, how to customize the Office UI and Windows shell for access from an iPad or Android device, but I’ll save that for my next and most likely final blog in the series.
Welcome to part three 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 this blog, I’ll discuss the Office Web Applications as part of the SharePoint 2010 or Office 365 service.
A lot of people think Office 365 is just another name for Office Web Apps. Actually, the Office Web Apps are probably more frequently accessed via Windows Live or managed environments with SharePoint 2010 infrastructure. Office 365 really refers to the entire offering of email (via Exchange Online), collaboration (via SharePoint Online), instant messaging/meeting services/voice (via Lync Online) and Office client applications (via Office Professional Plus full clients with subscription- and user-pivoted activation or the Office Web Apps). Now that we know how to access Office Web Apps, let’s talk about them for a minute and for that I will reuse what my colleagues in the Office team wrote for TechNet documentation:
“Microsoft Office Web Apps is the online companion to Office Word, Excel, PowerPoint and OneNote applications that enables users regardless of their location to access documents and edit documents. Users can view, share, and work on documents with others online across personal computers, mobile phones, and the Web. Office Web Apps is available to users through Windows Live and to business customers with Microsoft Office 2010 volume licensing and document management solutions based on Microsoft SharePoint 2010 Products.”
The interesting things I notice there are A. Office 365 is not even mentioned (to my previous point) and B. we call them “companions” to full Office applications. The main rationale for calling them companions is found on the same site:
“There are some differences between the features of Office Web Apps, Office Mobile 2010 and the Office 2010 applications.”
The key word above is “some.” When you compare Office Web Apps feature set to Office Mobile 2010, I would say “some” is about right and suggests similar functionality. However, when you compare Office Web Apps to a full copy of Office Professional Plus 2010 or even equivalent apps in 2007 or 2003 versions, “some” makes it sound like the two are comparable – I like to think of the Office Web Apps as providing high fidelity viewing and a few core functions of the full clients, but I would never recommend anyone replacing full Office apps on a PC or Mac (including any currently supported Office version) with Office Web Apps. Hence, the rationale for calling them companions.
Since we are basically talking about companion devices in this blog, it is kind of a fitting analogy to draw. In the same way you probably do not generally want to replace a PC completely with touch-only slate device if you want to be able to perform any complex tasks (writing documents, statistical analysis in a spreadsheet, authoring a presentation, etc.) that same rule applies for not replacing Office full client applications with their Office Web Apps equivalents. That being said, there are some user roles where people do not perform complex authoring or editing tasks and may be able to get by with a touch-only device or the Office Web Apps. I would think this is more the exception than the norm, but I still remember the days in the late 1990s when former bosses of mine (before I joined Microsoft) would verbally dictate all emails to their secretaries, too.
Office Web Apps generally comprise of a viewer component (such as WordViewer.aspx), where the document is rendered on the server and an image file (PNG or XAML) is pushed to the browser to ensure full viewing fidelity.
Since the document is actually rendered on the server remotely and that server is running Windows, it can render the document as if it were opened on a Windows machine with Office locally installed. As long as the device can view the image file and process the information on the header, it can view the document as written on the Windows computer. Things start to diverge a bit when it comes to the “Edit in Browser” button you see in the above image. Once I click that, I get something like this:
Notice that in the edit mode, the SmartArt is not rendered and I lose some of the formatting, but I can edit the text with some limited controls. I’ll zoom in a little on the controls for a second to show the differences compared to a full Office client app:
And the full client Microsoft Word ribbon:
While the “Home” tab of Word looks pretty close, you’ll notice that a number of the other tabs are missing. You will also see a custom tab called “Touch” and we will cover that one in the next blog and how the client tabs can be customized for better touch use. The moral of the story is that if you value things like setting up your page and print layouts, inserting footnotes or tables of contents, mail merge track changes, comments and scores of other features, the Office Web Apps version of Word will not replace the full client and is thus relegated and positioned as a companion.
Because I am writing about how to deliver an Office experience to iPad and Android slates as well as Windows, here are a few screenshots of the Office Web Apps on those devices:
Edit Mode Excel Office Web App on an iPad in Safari
Viewer Mode Word Office Web App in an Android browser
While the Office Web Apps then do not replace the need for full Office applications for most users, they still enable multiple devices, form factors and browsers to view and edit documents. Office Web Apps are supported on multiple PC, Mac, Linux and mobile OS browsers like recent versions of Internet Explorer, Chrome, Firefox, Safari and Opera.
The biggest question for some is then how you let users access the Office Web Apps, because it usually means a connection is required to your internal SharePoint sites, which in turn means some form of authentication on premise or connectivity inside the network’s DMZ. If you are a security guy, this may sound scary and while I can’t replicate the security controls in Windows, I can do a little to help make malicious activity more difficult. In the next blog I will discuss the concept of differentiation of access based on device or browser trust and how that can be instrumented in a Windows environment. Be sure to read parts one and two of the series if you haven’t already – part three is coming soon.
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.
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.
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.
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.
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:
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.
Hello and welcome to my first blog as a member of the Office IT Pro team. I used to blog quite a bit for the Windows team about fun topics such as imaging, deployment automation, physical-to-virtual OS migration and application compatibility. If you’re wondering what I am doing in Office now… well, there are tons of cool deployment things we are doing for the next release and I definitely wanted to help with that – more to come on that in a few months.
A lot of people keep using the phrase “Post-PC World” as if the death of the keyboard and mouse are eminent. I love keyboard-less devices and anyone who knows me also knows I have a ton of ultra-mobile computers (UMPCs) both with and without keyboards. Right now, I am using a docked HP 8540W with a full-sized external keyboard and mouse to write this blog, because it would be a chore to do this on any of my keyboard-less Windows or non-Windows tablets in the same way it would be painful to use my tiny Umid mBook or Fujitsu U820 keyboards. Not all form factors are created equal for getting work done, and based on that, I think we are still in the “PC World.” All of this is especially important when it comes to Office and productivity applications and whether one is in content creating or consuming modes. And it happens to lead me to my first thought – Do users expect the same experiences across all these computing devices?
Hold that thought. This is part one in a series of blogs meant to explore how people can use multiple device types to access, view and edit work documents and files. I really want to cut through the hype and show some real ways to manage multiple device types with varying operating systems and browsers. I will break it down with the following key themes.
A lot of this is not just about Office and using the Office Suite of applications, but instead a general allegory on managing multiple devices and providing differentiated access privilege based on device trust. Yoni Kirsh and I presented this topic at TechEd in Atlanta last May. We covered many of these themes and showed a bunch of demos on Windows, iPad, Android devices and of course server-side. While my colleagues on the Windows team have built a lot of great content on the Consumerization of IT to explain what it means to have people want devices and the tensions associated with managing them, I thought I would get my hands dirty and actually build my own functional Exchange and SharePoint environment with a bunch of devices to see the real implications and decision points of building out a multi-device world. I have a little history doing this kind of stuff; when we used “Infrastructure Optimization” as a sales and marketing campaign back in 2006, I decided to write 500+ pages on how an IT pro would implement our Core Infrastructure Optimization recommendations, so how hard could this tablet topic be?
As with any investigation and reporting, there is a bit of discovery needed. If I put the lens on Office again for the moment, you will see there are quite a number of ways to view and edit Office files across a lot of platforms.
When you think about all of these options, there are two vectors that I find important as an IT guy, “Do they have enough functionality for the user and can I manage it?” When I say manage, I can’t just relegate management to the Office application itself. Management in this case means:
These are a few big questions, but still the tip of the iceberg. Of course, I need to weigh what the application can do. If my users are even running Windows XP with Office 2003, they have an expectation of what Office can do for them, so will replacing that with a set of Office Web Apps or Office for Mac 2011 really meet all of their expectations and give me enough management control? I have visualized the main scenarios for feature functionality and manageability into the following quadrant diagram.
Management-wise there is little I can set and enforce (enforce being the key word) on a Mac or a phone. Office for Mac 2011 offers some install-time configurability, but lacks any policy enforcement. That means everything is set as a preference and there is no Active Directory Group Policy-like enforcement of these settings. You will see recommendations like this from Microsoft:
Best practice
Consideration
Educate and train users about the security settings that are available to protect their documents.
There are no administrative settings that allow you to enforce security preferences that you specify. Even if you set and deploy security preferences, users can change these preferences at a later time. Therefore, if you are deploying security settings as part of your organization's policy, you must educate your users about the risks associated with changing default settings.
As a frequent conference speaker, I love quotes like this since they are a sure fire way to get fun reactions from your audience. “Yes, I will inform people like my mom to not change my default settings – that will work for sure.” If you are like me, pilgrimages home usually involve running ERD Commander at least once on every machine in the house. Are your users much better?
The net result here is that functionality and feature level parity against the Office Professional Plus 2010 Windows applications are close, but not quite the same. Manageability is largely limited to server-side access controls and install-time preferences. These limitations in my book put Office for Mac 2011 at about the same management level as Office for Windows Phone 7. While the phone doesn’t really have install-time or post-install preference setting per se, Exchange Active Sync-enforced settings fill in the install-time preference gaps and server-side document controls are roughly similar. Windows Phone 7.5 (Mango) and Office for Mac 2011 both respect Information Rights Management. The Office for Windows Phone 7 applications however do have a smaller set of features compared with the full clients for Windows or Mac. In fact, these features are roughly comparable with the Office Web Application feature set on an app-by-app basis, characterized by high fidelity viewing with limited editing or document creation capabilities. These limitations are generally indicative to most Web applications – Microsoft or not – versus their locally-installed counterparts. Office Web Applications if you have not yet used them are accessed via SharePoint 2010 environments, Windows Live or Office 365 portals.
Last but not least, I have Office installed on a remote Windows Server or client operating system and accessed via a remote Windows or Android device, iPad, thin PC or similar device. In theory, there should be parity with running the full client on a local and physical computer and with the current level of integration, we are getting close. My rationale for limiting the feature level is mainly due to lack of offline use or use over a slow connection. Depending on the architecture used and whether or not you allow user profile settings to persist, customizations may only be at the hkey_local_machine (HKLM) registry or default user profile level, which rules out per user customization. Since we are potentially painting a screen of a remote server or virtual client hosted in our datacenter, and the sessions are generally always active and connected to systems management tools for servicing, there is typically a management advantage. Even though remote hosting can provide benefits, you still need to pay attention to how endpoints are accessing these sessions and where data can be stored and accessed among other things. We will talk about data access and save-to location permissions in future blogs in the series.
With that, you have an idea of the delivery types for Office applications. I didn’t touch repackaging or Application Virtualization intentionally here as we can roughly put them with the full client; there are a few non-parity issues paired with a few provisioning and management benefits, but for the sake of this blog series I will combine that delivery type with where I put the local installation of Office Professional Plus 2010. In the next blog, we’ll cover Exchange Active Sync controls for email and calendar on slate devices along with how Office can be configured and customized for touch use.
Thanks for reading and more depth to come soon in part 2,
The Office Sustained Engineering team has announced the third Service Pack release for Office 2007 and SharePoint Server 2007. They are targeting a release date within calendar Q4 2011. As the release date approaches, we will share more about the exact timing.
For more information, see the announcement here: Announcing Service Pack 3 for Office 2007 and SharePoint 2007