You can now get the April 2012 Cumulative Updates (CUs) packages for Office 2010 and the 2007 Office system. The CUs also include Office servers and SharePoint products. In these overall knowledge base articles, you’ll find links for the individual update packages and their descriptions.
For links to all the Office CUs, Public Updates (PUs), and Service Packs, see the Update Center for Microsoft Office, Office Servers, and Related Products.
You can now get the February 2012 Cumulative Updates (CUs) packages for Office 2010 and the 2007 Office system. The CUs also include Office servers and SharePoint products. In these overall knowledge base articles, you’ll find links for the individual update packages and their descriptions.
Brought to you by our compatibility guru Curtis Sawin.
The primary use for OMPM is to provide details about document conversion issues, and it helps answer the question, “What’s my risk of converting my binary Office file(s) to the Open XML file format?” However, we find that many people use OMPM to help answer the question “What’s my risk of opening my binary Office file(s) in an Office 2010 application?” The result is that we see some people use OMPM for the wrong question, spending significant time, effort, and money using a good tool to provide the wrong information.
For any compatibility project, regardless of platform, you should separate your compatibility tasks into pre-deployment and post-deployment tasks. Meaning, prior to migrating to your new platform (such as Office 2010, Windows 7, or Internet Explorer 9), you should focus your efforts only on tasks that enable you to deploy the new platform. Such tasks should have a clear and direct impact on the ability to deploy your platform. This is why pre-deployment tasks are considered deployment enabling tasks.
Post-deployment tasks are ones that allow you to realize the benefits of your new platform, which could include increased productivity (did I mention Paste Preview?), and lowered costs. Further, post-deployment tasks can position you for future platform migrations. Such tasks are considered environment optimization tasks.
For example, updating deprecated macro code is a post-deployment task, because object model items that have been identified as deprecated from previous versions of Office will still compile, but might not be available in future versions of Office. In other words, the deprecated macro code doesn’t actually block Office deployments. So after you’ve deployed Office 2010, updating your deprecated code will position you to migrate to future version of Office.
Converting documents is also a post-deployment task, because doing so allows you reduce your network storage needs and helps optimize your environment.
As we mentioned earlier, OMPM identifies document conversion issues, not document issues. Meaning, for a specific document, OMPM can help tell you “will it convert” to the latest file format, but it does not tell you “will it work” in Office 2010.
Using OMPM in a pre-deployment manner to help figure out “will my documents work when I open them in Office 2010?” is a common misuse of OMPM. There are a couple reasons for this:
The last bullet is the killer. OMPM provides data for IT Pros to grasp. Often, what we are seeing is customers using OMPM to find document conversion issues, and then focus their testing only on documents with “red” issues. This is an easy way to rationalize an enormous volume of data into something more manageable. “Red” documents are often 5-20% of the total inventory. Rationalizing my inventory to only 5% of what was discovered sounds like an excellent use of my discovery process!
However, this approach has several flaws. As we’ve noted, the most important flaw is that OMPM provides conversion issues, and does not provide information that will help you determine if a red document will work in Office 2010. Additionally, focusing on “red” documents ignores the importance of the document, and treats all red documents as equally important (i.e., docs that must be tested). Thus, while you think you’re saving time, you’re actually wasting time, potentially focusing on documents that have conversion issues, but don’t add value to the business. Lastly, using OMPM in this manner provides a false sense of security. While you can say you’ve focused your testing efforts on documents that have been reported to have only red issues, you can’t say that you’ve gotten closer to determining “will my stuff work” in Office 2010.
We are finding that companies spend 12-18 months in getting ready to deploy Office 2010. Meaning, once the decision is made to deploy, it could be up to a year and a half until your end-users are using the new version of Office. Most of this time is eaten up by lengthy (and costly) document assessment using OMPM. In fact, we’re finding that people who do NOT use OMPM prior to an Office 2010 upgrade are deploying faster, cheaper, and without any additional risk.
A new feature of the 2010 version of OMPM is that the tool identifies “macro issues.” In short, it will provide two data points: a count of all potential object model issues, and a count of all potential 64-bit compatibility issues.
The object model issues, listed as Functionality Issue Count in the OMPM reporting tool, summarizes the total number of items in macro code that have been removed, changed, or deprecated from previous versions of Office. The 64-Bit issues, listed as x64 Compatibility Issue Count, lists the sum of all macro code declarations that are not explicitly listed as “safe for 64 bit Office.”
With this improved functionality, many feel that this insight is invaluable and must be uncovered prior to deployment. For instance, you wouldn’t want to use a document in Office 2010 that had 88 functionality issues and 3 x64 Compatibility issues, would you? That depends on:
If you’re not deploying 64-bit Office 2010, you can ignore all the data in the x64 Compatibility Issue Count column in the OMPM reporting tool. It doesn’t provide value in this situation, and is just noise.
The Functionality Issue Count data is a summary of removed, changed, or deprecated object model items. Most of these items are not impactful, but some of them may be impactful. How can you tell? Unfortunately, OMPM doesn’t make this distinction. So looking at the data doesn’t give you much to go on. Check out the article Understanding potentially impactful changes in the Office 2010 object model for more details about how object model changes may affect macros.
Lastly, while OMPM can tell you which documents have the most functionality or x64 macro issues, OMPM cannot tell you if the document/macro is important to the business. It would be a waste of time to spend testing and remediation cycles on documents that don’t provide business value. So using the volume of macro issues to help rationalize which documents should be tested often leads to inefficiencies.
Much of this article has described what not to do…which by itself is not so helpful. So if using OMPM for discovery documents and macros is bad…what is good? Start with the end-users. Canvas your customers. A major benefit (and challenge) of Office is that end-users can build their own solutions using Office, and that Office solutions are not managed by the IT organization. Further, many companies do not have the IT organization manage their Office documents, so the IT department has little insight into what Office documents are important to run the business.
You’ll find it is MUCH faster to partner with project managers, relationship managers, or designated business leads to identify what documents are critical to the business than it is to use OMPM to scan your entire environment and focus on the (gulp) wrong data. This partnering can also be leveraged for other IT initiatives and projects and help make enacting change in your environment more agile.
Most compatibility projects, regardless of platform, use the flow of “Inventory, Rationalize, Test, and Remediate” and with Office, it seems logical to use OMPM for the discovery, rationalize by filtering the “yellows” or “reds,” and testing and remediating your smaller subset. What this is inadvertently doing is rationalizing your list based on the wrong criteria. It’s kinda like car shopping based on color first. “Honey, here is a list of all the blue cars that you can pick from.” When you’re focusing your testing/remediation on the wrong set of data, you’re not reducing your risk. If fact, you’re increasing your risk by not focusing on the correct data.
Working with the business areas first to identify critical documents/solutions will provide an efficient means to perform the discovery and rationalization at the same time, as the business is validating the data as its being generated. The result is increased efficiency (which reduces time/cost) and lowered risk (by focusing on the right data).
OMPM is an excellent tool to perform a specific task. Using OMPM to find document conversion issues, and using that data to determine if there’s a business justification for converting your documents after your Office 2010 deployment is completed is a great way to obtain value out of your investment, and realize potential savings. Using OMPM to answer the wrong question will lead to a costly and inefficient upgrade project that will hinder your business’s agility and delay the productivity benefits that Office 2010 brings to your customers.
The concepts in this article are explained in more detail in this 1-hour video Solving Office Compatibility to Accelerate Office Deployments, recorded from the Microsoft SharePoint Conference in Anaheim, CA. Below is an intro to the video:
Office file and solution compatibility causes concern for organizations when they begin planning for an Office upgrade. This typically leads to extended deployment projects delaying the realization of the new version value. The key to keeping your deployment project on track is utilizing the right process and leveraging tools appropriately to understand the potential risks. This session will demonstrate how the right approach will address the expensive/long assessments, fear of the unknown, and increased costs. Meet the Office Compat team and learn how to leverage the programs and resources to expedite Office 2010 or Office 365 client deployments.
Using OMPM Part 1 - Identifying Document Conversion Candidates and Estimating Storage SavingsUsing OMPM Part 2 – Performing Bulk Conversion
In Part 1 of this series, we discussed how to use OMPM to identify “conversion candidates,” which are documents that pose virtually no compatibility risks when you convert them from the binary format (e.g., xls, doc, and ppt files) to the Open XML format (e.g., xlsx, docx, pptx).
Let’s take a look at the process of actually converting the documents. This involves using the Office File Converter Tool (OFC.EXE), and using an exported list from the OMPM Reporting Tool (OMPM.accdr).
To recap, you can use the OMPM reporting tool to create a “low risk” filter to identify documents that:
The following WHERE clause can be used to meet this criteria:
WHERE MaxIssueLevelID > 2 AND DATEADD(d,-30,GETDATE()) > ModifiedDate AND FileID not in (SELECT FileID from Uv_FilterMacroIssue)
To convert files that meet these criteria, you can use the OMPM reporting tool to export the filtered list. After you’ve selected Apply Filter to add your criteria, select the Export… button to export the list of files.
The output will be one or more XML files that contain the full path to all the files in your result set. The folder in which the files have been exported will be referenced by the file conversion tool, OFC.exe
Next, open the OFC.ini file (found in the “TOOLS” folder when you download and extract the OMPM Toolset), and modify the FileListFolder item to point to the same folder where you exported the files. For example, if you exported the file list to the D:\DataExport folder, the FileListFolder item would look like this:
FileListFolder=D:\DataExport
Using the FileListFolder item will result in OFC.exe converting all the files that have been exported by the OMPM reporting tool. Further, using FileListFolder rather than the [FoldersToConvert] section of the OFC.ini allows you to ensure that you’re only converting files that you’ve specifically tagged as low-risk “conversion candidates.” Using [FoldersToConvert] section simply points OFC.exe at one or more folders and says “convert everything.” In some cases this can be helpful, but if your goal is to selectively convert files while retaining the ability to automate the conversion, using FileListFolder provides much more control.
To facilitate moving the converted files to the original location(s), the ofc.ini file has a [ConversionInfo] section that allows you specify the destination folder structure. For example, you could reproduce the folder structure by specifying the following:
[ConversionInfo]
SourcePathTemplate=*\*\*\*\*\*\*\*\*\
DestinationPathTemplate=X:\*1\*2\*3\*4\*5\*6\*7\*8\*9
This would result in the converted files being placed in a folder structure similar to the source folder in on the “X:\” drive. OFC.exe also adds the computer name to the destination path. If you can reproduce the folder structure, you’re in position to implement a repeatable process to move the new files and delete the old ones. Even better, you could create a script to automate such a process.
Also, OFC can convert to a maximum depth of 10 folders. For example, DestinationPathTemplate=I:\Converted\*1\*2\*3\*4\*5\*6\*7\*8\*9\ works correctly. However, DestinationPathTemplate=I:\Converted\*1\*2\*3\*4\*5\*6\*7\*8\*9\*10\ does not work.
One mitigation for this is to map a drive letter to a folder structure (ie, connect the “x:\” drive to \\myserver\myshare\folder1\folder2\folder3\folder4) and perform a find-and-replace in the exported XML file(s) to replace the folder structure with the drive letter.
The impact of this limitation should be minimal, but it’s a pain to troubleshoot, so we wanted to make sure you’re aware of this limitation.
Below are some screen shots that show examples of the various components.
Here is an exported XML file from the OMPM Reporting tool:
Notes:
Here is an OFC.INI file (with all the comments removed):
You can find more information about the items in the OFC.ini file in the TechNet article Convert binary Office files by using the Office File Converter (OFC) and Version Extraction Tool (VET)
Here is my source location of my legacy files:
The next step is to run OFC.exe from a command-prompt. No command-line parameters are needed if you have the ofc.ini in the same folder. Here is a screen shot of OFC.exe running:
Below is a screen shot of the resulting folder:
Check out the folder structure D:\Converted\Ninja99\f$\Converted. The Destination Path includes the computer name and drive letter (or UNC name) in the folder structure. This facilitates moving the files back to the original location.
Also, note the Date Modified and Size columns. The conversion process retains the original modified, accessed, and created time stamps (which is good if you have archive/storage solutions that are triggered using these time stamps), and the sizes are significantly smaller than the previous versions.
So keep in mind that using OFC.exe to “convert” files will require you to clean up the legacy files and replace them with the converted ones. Thus, when determining the ROI of a bulk conversion project, the time investment of this clean up activity must be considered.
Performing bulk conversion is an environment optimization task that will help you realize the value of your investment in Office 2010 by reducing your storage needs, which will save you money. Bulk conversion should be considered an optional task, and it should not be performed when preparing to deploy Office 2010, it should be used only post-deployment...and on low-risk files.
Using Office Migration Planning Manager (OMPM) to identify “high-risk” binary format documents—that is, xls, doc, and ppt files that will have conversion issues--is a great way to determine which documents should not be converted after an Office 2010 deployment. Conversely, you also use OMPM to identify “low-risk” binary documents that are good candidates for conversion to Open XML, and then use another OMPM tool, ofc.exe, to bulk convert all the identified documents. Bulk conversions, you ask? Although many companies tell us they aren’t interested in bulk converting documents, and we actually recommend against converting documents as part of an Office 2010 deployment project, there are still good reasons to bulk convert: namely, reducing your network storage needs by 50% or more. This can translate into significant (and measurable) financial savings.
The overview seemed to provide a bit of a contradiction. First, we say “don’t convert as part of an Office deployment project,” and then we immediately get excited about some benefits of conversion. What gives?
First of all, converting documents as part of an Office deployment project can lead to problems, especially broken links. Office 2010 uses Compatibility Mode when opening binary files and disables certain features that are not backwards compatible, ensuring that the binary files remain compatible with previous versions of Office. Using Compatibility Mode requires no effort or configuration on your part, and users can continue working in their files as they did with previous versions of Office. So, if the new features are not desired in existing files, why do the extra work? Part of the Office 2010 migration project should be to identify faster, simpler ways to migrate to the new platform. Not taking on work that doesn’t add business value is a great way to save money. So, when preparing to deploy Office 2010, make sure you’re focusing only on tasks that are “deployment enablers.”
Spoiler alert: Using OMPM (or other tools) to scan your environment for document conversion issues is NOT a “deployment enabling” task. More on this later.
Once you’ve migrated to Office 2010, you’re in a position to take advantage of the new features in all new documents you create. This is also a great time to determine if performing bulk document conversion is worth the effort. Leveraging features that enhance productivity (helloooo Paste Preview and SmartArt!) and reducing your network storage needs are great “environment optimization” tasks that allow you to realize the value of your investment in Office 2010.
Using OMPM to identify low risk files – aka, conversion candidates – is a post-Office deployment task that helps you determine if bulk conversion is worth the effort. The data gathered by OMPM can be used to help determine the return on investment (ROI) of bulk conversion. Meaning, by using OMPM, you can help answer the question “What will my storage savings be if I convert a bunch of documents?” In an environment where the IT organization implements a charge-back model for network storage, using OMPM could also help answer the question “How much money will I save if I convert my docs?” Often, IT organizations are viewed as “costing the business money.” Using OMPM can help change that perception to demonstrate how IT is “saving the business money.”
Documents that are good candidates for conversion are ones where the projected impact to the business is minimal. When defining “low risk” for your organization, you could apply specific business rules, such as “exclude recently modified documents,” and combine that with specific data returned from OMPM, such as “exclude documents with yellow or red document conversion issues” and “exclude documents with macro issues.” What remains are documents that meet the following criteria:
OMPM categorizes potential document conversion issues into categories that indicate the severity of the issues. “Green” issues are mostly benign and will most likely have no impact. Examples of such green issues are Excel files that use labels in formulas (which are automatically converted in Excel 2010) or have charts in them. “Yellow” or “Red” issues are potentially more severe, and conversion of such documents may result in data or functionality loss.
Files with macro issues fall into two categories: (1) files that contain macros that use object model items that are either changed, removed, or deprecated since previous versions of Office, and (2) macros that call functions that are not specifically marked as compatible with 64-bit versions of Office. While OMPM doesn’t provide detailed information about the impact of these macro issues, we are excluding them from our potential conversion list…to reduce our risk.
Macro issues are listed separately from Red, Yellow, and Green issues. Meaning, a file could have 3,245 macro issues identified and listed as a “green” document for conversion issues. Or it could be listed as file with no conversion issues. This is an important distinction to note when we build our “low risk” filter.
We are also excluding recently modified files. For instance, we won’t convert any file that has been modified in the past 30 days. This will further ensure that we are only converting documents that will most likely never be used. Even if some of them will be used, we’re only converting ones with virtually no conversion risk. If 30 days isn’t sufficient for your environment, increase that number.
Note: the OMPM reporting tool only exposes the “last modified” date of files. It does not provide information about the “last accessed” date of files. Boo!
The basic process to convert your documents is below:
Step 1 – Gather your data:
To learn more about how to do these steps above (except for identifying your storage), check out our TechNet documentation for OMPM.
Step 2 – Analyze your data:
To determine which files are conversion candidates:
To estimate the storage savings of conversion:
Step 3 – Do the work:
To convert the conversion candidates:
This article will cover step 2. A separate article will discuss step 3. Why two separate articles? Step 2 is all about determining “Is it worth it to convert my documents?” If you determine that it’s worth it (from a financial perspective), go on to step 3, which is about performing the work. If you determine it’s not worth it, stop reading, and provide the data to you management that justifies your decision. You’ve now just saved yourself and your company some effort, which you’ve determined is not worth potential savings.
Open up the OMPM Reporting tool (OMPM.accdr) and select the OMPM Compatibility Link. In the Select a File Filter section, navigate to the bottom of the section and select the Customize SQL button. The following WHERE clause can be used to meet or criteria:
After adding the query, selecting the Apply Filter button will return all the files that meet the criteria.
Here’s what it looks like in the OMPM reporting tool
In the above example, about 74% of my documents are conversion candidates, as they meet my low-risk criteria.
If you’re not familiar with SQL, the above may look a bit confusing. The table below breaks down the query.
Now that I know how many documents (and what percentage of my documents) are conversion candidates, it would be valuable to know my estimated storage savings if I decided to convert them. While our documentation on TechNet indicates the Open XML files are “up to 75% smaller” than binary files, in the field we’re seeing 50-60% reduction in size when converting documents. For planning purposes, we recommend you estimate a 50% reduction in storage needs when converting document to the Open XML format.
The OMPM reporting tool doesn’t provide the cumulative size of all files listed. So you could copy and paste (blecch!) all the data from the OMPM reporting tool (using the Scanned Files tab) into Excel (for example) and then sum up the File Size column. Not too elegant and quite cumbersome.
An easier method is to connect to the OMPM database using SQL Server Management Studio (SSMS) and execute a query against the database directly. Here are some simple steps you can perform to do this:
1. Open SQL Server Management Studio.2. Connect to the server that contains the OMPM database.3. Select the New Query button.4. In the query editor window, copy and paste the below text:
SELECT
SUM(Cast(Size as BigInt))/1024/1024/1024
FROM
Uv_File
WHERE
(MaxIssueLevel = 'No Issues' or MaxIssueLevel = 'Green')
AND
DATEADD(d,-30,GETDATE()) > ModifiedDate AND
FileID not in (SELECT FileID from Uv_FilterMacroIssue)
This is very similar to the filter used in the OMPM Reporting tool, except we have access to more tables and views. As a result, we are able to use the MaxIssueLevel fields to specify “Green” and “No Issues” rather than the MaxIssueLevelID values. This makes the query a bit easier to understand.
The result is a single value that represents the total number of gigabytes used by all of the files that are conversion candidates. The amount of data were evaluating could be huge, and the file size is represented in bytes. This is why we’re using the CAST function to convert the File Size data into a data type that can handle very large numbers. We’re then dividing by 1024 three times to convert the bytes to kilobytes, then megabytes, then gigabytes.
Here’s an example of this query and the resulting sum.
In the above screen shot, we see that 44 GB are being used by all of our low-risk documents. To estimate the storage savings, we’ll use a very simple formula:
This gives you the ability to determine, “Is it worth it?” Meaning, we can take the estimated storage savings and determine if the ROI of performing a bulk file conversion is worth the investment. Again, if you’re in an environment where the IT department implements a chargeback model for network storage, you can now estimate the amount of money you will be saving your customers. Typically, chargebacks are recurring, so you would provide the amount of money you would save…per year! (Side note: Some people LOVE to see 3-, 4-, or 5-year forecasts. Being able to provide “Here is my 5-year savings forecast for this project” could really make people notice the value of document conversion!)
The recommended use for OMPM is to identify documents which are good candidates for conversion and then convert those documents. This is an activity that is best undertaken after Office 2010 has been deployed. In short, use OMPM as an analysis tool to help determine if there is an adequate return on investment for a document conversion effort.
We've had some questions about how to deploy a custom dictionary in an organization. To deploy a custom dictionary, administrators can use the following approach:
The following section lists the registry keys to update to use the new custom dictionary, NewCustom.dic, for example. To do this, use Registry Editor, regedit.exe. For information about using regedit, see Configure the Registry.
This approach sets the Custom dictionary file as the default, and configures it as enabled. It specifies the NewCustom.dic file as the second dictionary, and sets it to enabled. It also removes the culture tag to apply to all languages.
The following registry keys and values must be added or updated:
The following registry key must be deleted, if it exists:
To deploy the logon script to users, administrators can use Group Policy to assign a User Logon Script. For information about using Group Policy Management Console and User Logon Scripts, see the following resources:
As an alternative, administrators who have deployed Office 2010 can use the Office Customization Tool (OCT) to add the custom dictionary file and add registry values. The OCT can be used for maintaining an Office 2010 installation. Note that there are two versions of the OCT in Office 2010, one for 32-bit Office 2010 and one for 64-bit Office 2010. The OCT is available only with volume licensed versions of Office 2010 and the 2007 Office system. To determine whether an Office 2010 installation is a volume licensed version, check the Office 2010 installation disk to see whether it contains a folder named Admin. If the Admin folder exists, the disk is a volume license edition.
To use this method, administrators perform the following tasks:
For more information about using the OCT, see the following resources:
The Office Sustained Engineering team has released the list of updates that are included in Office 2007 Service Pack 3 (SP3). Office 2007 SP3, which was released in October 2011, includes a roll-up of all Public Update (PU) and Cumulative Update (CU) releases since Office 2007 SP2, as well as stability and performance improvements. Note that Office 2007 SP3 does not contain the October 2011 PU or the October 2011 CU.
For the updates list, see the Microsoft Office Updates blog (http://blogs.technet.com/b/office_sustained_engineering/archive/2011/12/09/office-2007-service-pack-3-roll-up-list.aspx).
Our compatibility guru Curtis Sawin shared his expertise on Office compatibility planning at the recent SharePoint Conference in Anaheim, CA. Here's his introduction to the video, along with the link.
http://go.microsoft.com/?linkid=9788373
One of our colleagues on the Get to the Point SharePoint blog recently wrote about working with a small business customer who, in the process of migrating to Office 365, experimented with using Office exclusively in the cloud (using OWA and Web Apps) and later using a combination of Office web-based and rich clients. Their observations were very interesting--check it out:
My experience with Software + Services in Office 365
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
If you’ve installed Office 2010 Service Pack 1 (SP1) and are experiencing either of the following issues with Outlook 2010 SP1:
You should install the Outlook 2010 hotfix package. It’s part of the Office 2010 Cumulative Update (CU) for August 2011.
For more information about the latest Office products updates, see the Update Center for Microsoft Office, Office Servers, and Related Products.
Brought to you by our compatibility expert Curtis Sawin
Helping users get used to the ribbon is a challenge for IT organizations that are migrating their Office 2000, Office XP, or Office 2003 environments to Office 2010. Although customer feedback strongly demonstrates that the ribbon is a much better (i.e., more productive) experience in the long term, the “ohmygoodnessit’sdifferent!” reaction from users can be a short-term hurdle when first using Office 2010.
One strategy to help users ease into this transition is to hide, or collapse, the ribbon. Check out the screen shots below. Here is an image of Excel 2010 in its default state.
Below is an image of Excel 2010 with the ribbon collapsed.
Finally, here is an image of Excel 2003.
Interesting, right? Collapsing the ribbon makes the Excel 2010 tabs look similar to Excel 2003 menus. Okay, so it’s not identical, but the reduction in change may help your users ease their transition into the fluent user interface.
Note the red circles in the upper right hand corner of the Excel 2010 images. This toggle arrow can be used to manually expand or collapse the ribbon, providing your users the ability to customize the interface to their preference. Additionally, CTRL+F1 can be used to expand/collapse the ribbon.
When deploying Office 2010 to your users, it’s possible to create a customized installation to have the ribbon collapsed by default when your users first open an Office application. You can accomplish this by adding specific registry keys into your setup package.
For most Office applications, there is a single registry value that controls the ribbon appearance. Outlook is an exception and will be discussed later in this post.
Here is the registry value:
HKCU\Software\Microsoft\Office\14.0\Common\Toolbars\<AppName>\QuickAccessToolbarStyle
In the above value, <AppName> is any of the following values:
• Access• Excel• OneNote• PowerPoint• Project• Publisher• Visio• Word
The following table defines the available values for the “QuickAccessToolbarStyle” registry value.
A REG_DWORD value of 4 (shown below) will collapse the ribbon and has the same effect as pressing CTRL+F1 or selecting the toggle arrow.
Outlook provides a bit more customization. There are 24 different registry keys that control the ribbon and quick access toolbar. This is because there are so many different types of items and modules in Outlook that the product team had to create multiple ribbons. While this implementation is generally transparent to end-users, this complexity surfaces here. Thus, if you want to collapse the ribbon for Outlook, you’ll need to determine the specific Outlook window that you want collapsed.
The below table outlines the different registry values that manipulate the visibility of the ribbon. All of these values are under HKCU\Software\Microsoft\Office\14.0\Common\Toolbars\Outlook
The Office Customization Tool (OCT) can be used to add these registry keys just like any other registry key. Adding registry entries via the OCT is a pretty straightforward process. Check out the TechNet article Office Customization Tool in Office 2010 for details.
Deploying Office 2010 with a collapsed ribbon may help your users transition to using the ribbon instead of the legacy menus. Making sure your users are comfortable with change will help you accelerate deployments while reducing costs (by eliminating Help Desk calls). Adding some registry keys to your setup using the OCT provides an easy way to accomplish this.
Check out the Windows 8 blog post, Improvements in Windows Explorer, which provides screen shots of Windows Explorer with a ribbon interface.
One of the challenges of migrating to Office 2010 is assessing the impact of object model changes in Office applications. IT Pros and developers fear that macros built using a previous version of Excel (for example) may not work in Excel 2010 because the object model has changed too much. Broken macros seem almost inevitable when you review the exhaustive list of differences in the object models between the latest version of Office 2010 applications and their Office 2007, 2003, XP, and 2000 counterparts on MSDN (see the links at the end of this article). However, most changes are non-impactful changes and will not have any effect on your macros. What does “most” mean? Below is a summary:
49 potentially impactful changes. Across 5 applications. Spanning 4 previous versions. That’s it. Here’s a chart that sums up our findings:
This article describes what we mean by non-impactful changes and potentially impactful changes. BONUS: For your future reference, we have a table that lists all potentially impactful changes. The table is also attached as a .pdf file at the end of this post.
The MSDN documentation provides all changes in the object model for each Office 2010 application. The changes are organized so that each previous Office version lists all methods or properties that have either changed, been removed, or have been deprecated.
For example, for Excel 2010, there are nearly 900 items that in the object model that are different from previous versions. At first glance, this seems like a large, scary number. The MSDN article Excel 2010 Object Model Changes Since Earlier Versions lists every one of those items that have been changed. When printed, the article is about 90 pages long.
The majority of these changes are deprecated (also listed as hidden) items. So what is a “deprecated item” and how will it affect your macros? If an item is listed as deprecated, that means you should not count on it being available in future versions of Office and that you should plan to update the code in the future. However, a deprecated item will still work! Thus, if you have macro code that was built for a previous version of Office and it contains deprecated methods, properties, or constants, there is no action necessary to make those items work in Office 2010. None. For the nearly 900 changed items (882 to be exact), 794 are deprecated items. This means nearly 800 of the 900 changes in the Excel object model will not cause any impact if you have those items in your macros.
So you can postpone addressing deprecated items, but you shouldn’t ignore them entirely. Code containing such items should be reviewed and updated to make sure that today’s deprecated code doesn’t become tomorrow’s broken code.
“Removed” items are the big ones. An item that is listed as removed is no longer in the Office 2010 object model. If you have an existing macro that contains items that have been removed in Office 2010, that macro won’t work. For Excel 2010, there are 9 object model items that have been removed since previous versions. These are the items that need your focus. Replace ‘em.
“Changed” items are methods and properties that are…well…changed since an earlier version. For instance, a changed method might return a different data type, or a property may have changed from “read only” to “read/write.” Doing a little analysis, we found that most changed items involve a method or property accepting additional, optional parameters. For example, in Excel 2003, the ListRows.Add method provides one optional parameter. In Excel 2010, it provides two optional parameters. The addition of the optional parameter doesn’t have any impact on its use. If you used this method in Excel 2003 and only provided one parameter, the same code will work in Excel 2010 without modification.
In Excel 2010, there are 97 changed items. None of these items is potentially impactful. All of the changes in the items will not affect existing code that contains the “changed” items.
So, out of 882 methods and properties that are different from 4 previous versions of Excel, only 9 of these will be impactful.
Not all changed items are non-impactful. For example, in PowerPoint, the Presentation.SaveAs method uses a different default value for the optional parameter FileFormat. The default value changed from “1” (ppSaveAsPresentation) in PowerPoint 2003 to “11” (ppSaveAsDefault) in PowerPoint 2010. Thus, if you’re using this method and are not explicitly providing a value for the FileFormat parameter, you may experience different results running a macro built in PowerPoint 2003 than in PowerPoint 2010. Thus, depending on how you’re using this method, the change is potentially impactful.
Tools like the Office Code Compatibility Inspector (OCCI) can be used to scan your macros to see if they contain code that has been changed from previous versions. OCCI will provide you with a report that lists the number of items that have been changed, deprecated, or removed. It’ll also tell you if you’re using any external references (especially important if you’re migrating Office 2010 as part of an operating system upgrade), and if you are making any declarations that are not explicitly marked to work in a 64-bit Office environment. Below is a screen shot of a summary of OCCI findings on an Excel workbook with a macro.
Note that OCCI uses the term “redesigned” which corresponds to “removed.” (No, I don’t know why this is different).
Since OCCI picks up all changes, you must sort through the output to figure out what information is “actionable.” Meaning, OCCI will tell you “things are different.” But what things need to be fixed immediately? What things need to be fixed eventually? OCCI doesn’t provide this deep level of information. The table below aims to address that gap. It lists all potentially impactful changes; things that should be evaluated immediately. Depending on how they are used, code that contains these items may not need any modification. So treat this as a ‘quick start’ guide to addressing any macros. But don’t over rely on any tool or even the below table. At the risk of sounding redundant, executing the macros to determine if they work is the only sure way to determine if they work.
The table below lists every such potentially impactful change, which includes all removed items, and all potentially impactful changed items. Use this table to quickly identify what code in this table you may be using. While you can use tools such as OCCI to detect all changes, this table provides more actionable (and consumable) data by eliminating object model changes that won’t have any impact when migrating your macros to Office 2010.
One of the challenges of relying on tools is that they typically provide data that helps answer technical questions (e.g., “what has changed?”) not business questions (e.g., “How will this impact my solution?”). Tools certainly have their place to help automate and expedite troubleshooting efforts, but over-reliance on tools can lead to leveraging the data that tools provide to answer the wrong questions. As always, the best method to ensure if your solution works when upgrading to Office 2010 is to perform end-user testing that involves actually using the solution (in a test environment, if possible).
(You can download the above table in a .pdf file by clicking the link for the .pdf at the end of this post.)
The below links provide the differences in the various object models.
My name is Anthony Cafarelli and I’m a Consultant with Microsoft Consulting Services who recently compiled a list of useful advice that I gained while performing OMPM scans at client sites. In this blog post I would like to share some of that knowledge and I hope that anyone reading it finds it useful!
The issue I am going to focus on in this blog post is an import error. This error is caused when the scanned files have very long file names, in excess of 250 characters. Thus it isn’t an extremely common error but these steps will help you address the import if you do find this situation. When importing data into the OMPM database you may receive the following error:
Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data
What this error indicates is that the file name and path in an XML file you are trying to import is too long for the “Warninginfo” field in osWarning table. Because of this length issue, the information is not imported into the database and the XML file is skipped. Typically this shows up with a Last Accessed or Last Modified date warning, so the files usually wouldn’t be a concern to not have in the database. However, if it was part of a .cab file containing multiple XML files (and most likely it is, and most likely that CAB contains 10,000 files unless you modified the offscan.ini file to change those settings). And, this is important to note, if any XML file contained in a CAB file cannot import, then none of those files make it into the database. At this point, you have a few options:
1) Ignore that the CAB file did not import and base your results on the other CAB/XML files that did import correctly.
2) Extract the CAB file and import each XML.
3) Modify the database.
If option 1 is acceptable, there is nothing more for me to say here. That is the easiest option, but you do lose a significant amount of data that may be useful.
Option 2 is an interesting one. Out of the 2 options I listed that address the issue, this is one that has a lot of work required for the technician, but significantly increases the import time into the database.
Just to give a little background in a simplified way: The reason why the entire CAB doesn’t import when a single XML file has an error is because of the way OMPM does the import. The CAB is extracted by the import process and every XML file is parsed all at once. This significantly (VERY significantly) speeds up the import of a CAB file but also reduces the ability to address errors.
When you extract the XML files you will be able to get the (on average) 9,999 other XML files imported into your database. I haven’t actually timed it and compared it, but I would say the import of the individual XML files is at least 10x slower, if not more. There is another way to increase the import speed, but it involves more work from the technician (and this is my preferred method because I hate modifying the database due to the supportability concerns, and I will get into that a little more below). Here is the modified option 2:
1) Extract the CAB file.
2) Use the findstr command to locate the extracted XML file that is the one with the error.
3) Delete that XML file.
4) Re-package the CAB file with the remaining files.
With this method, you maintain the high import speed and address the file with the long name. Using findstr and deleting the XML file are pretty straight-forward, so I’m not going to get into them. But, finding a good way to re-package the CAB can be tricky. My best advice is to go to this page (yep, another TechNet page) and implement the PowerShell scripts listed:
http://technet.microsoft.com/en-us/magazine/2009.04.heyscriptingguy.aspx?pr=blog
Once you’ve re-compressed into another CAB file, you can import it and still maintain your high speed import! Pretty good trick, right?
Now let’s talk about Option 3. I have very mixed emotions about this one. It’s easy and it’s effective but it definitely pushes supportability. The simple explanation of this approach is this: The oswarning field in the database isn’t big enough to hold the data we are trying to put into it, so let’s just make the bucket larger. I found 2 methods for doing this. And apparently, based on what I have written so far, I love numbered lists, so here’s another one:
1) Use SQL Management Studio to modify the field size.
2) Modify the files that OMPM uses to create the database so that every database you create has the larger field size to start.
Using SQL Management Studio is fairly straight-forward, but depending on your version of SQL it can be slightly different. I’m not going to get in depth into that solution, so if you are unsure of it, either find your favorite SQL resource (friend, colleague, book, blog, etc.) and research it or use the second method.
The second method requires you fire up a text editor. Notepad.exe is my favorite, so that’s what I’m going to use as an example. Start notepad and open ProvisionDB.sql in the OMPM/Database/Include folder.
Once you have the file opened search for “oswarning” and click Find Next.
You will see the following:
Here you will see the WarningInfo field (at 255 characters). Simply change the number to something higher (let’s say 285) and save the file. Now every time you run the createdb command, the new database will have a larger field. NOTE: This will not modify your existing databases, so make sure you create a new database and run your imports there. You’ll want to pull any files out of the OMPMimported folder that you imported into the old database so you can re-import then into the new one.
The Office Compatibility team is aware of this limitation and is reviewing this challenge for future updates.
Hope this was helpful for anyone reading it! I plan on writing a few more blog posts about other issues and “creative” resolutions I found in the field.
Anthony
In our previous post, for those of you running Office Web Apps hosted on-premises, we covered which service pack and cumulative updates to install and in what order for SharePoint. However, we didn't include a scenario with the language packs updates. We've had some questions as to where those fit in. So without further ado - here is our recommendation depending on your environment:
If your environment includes:
Apply these updates:
SharePoint Server 2010 + Office Web App Farm + Language Packs
Step 1: SharePoint Server 2010 SP1: http://support.microsoft.com/kb/2460045
Step 2: Office Web Apps SP1: http://support.microsoft.com/kb/2460073
Step 3: SharePoint Server Language Pack SP1: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26621 (Download and apply the SPs for the language packs you have installed)
Step 4: SharePoint Server 2010 June CU: http://support.microsoft.com/kb/2536599
Step 5: Office Web Apps June CU: http://support.microsoft.com/kb/2553919/
(NOTE: The Office Web Apps updates for Excel Web App are included in the SharePoint Server 2010 June Cumulative update.)
Step 6 - Optional patch:
2553935 Description of the Office Web Apps hotfix package(wacproof-sv-se.msp): June 28, 2011 *NOTE: Only needed if you have Swedish language pack installed.
Step 7: Once you have finished applying all the updates, run the SharePoint 2010 Products Configuration Wizard or "psconfig –cmd upgrade –inplace b2b -wait” one time on every server in the farm.
SharePoint Foundation 2010 + Office Web Apps + Language Packs
Step 1: SharePoint Foundation 2010 SP1: http://support.microsoft.com/kb/2460058
Step 3: SharePoint Foundation 2010 Language Packs SP1: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26629(Download and apply the SPs for the language packs you have installed)
Step 4: SharePoint Foundation 2010 cumulative update http://support.microsoft.com/kb/2536601
Step 5: Apply the following 3 patches for Office Web Apps: 2553924 Description of the Excel Web App hotfix package (xlwacwfe-x-none.msp): June 28, 2011 - http://support.microsoft.com/kb/2553924
2544029 Description of the Excel Web App hotfix package(wacmui-xx-xx.msp, xlwacmui-xx-xx.msp): June 28, 2011 - http://support.microsoft.com/kb/2544029
2553919 Description of the Office Web Apps hotfix package(wacwfe-x-none.msp): June 28, 2011 - http://support.microsoft.com/kb/2553919
2553935 Description of the Office Web Apps hotfix package(wacproof-sv-se.msp): June 28, 2011 *NOTE: Only needed if you have Swedish language pack installed
Step 7: Run the SharePoint 2010 Products configuration wizard.
For more information, see the Microsoft SharePoint Team Blog post “Service Pack 1 for SharePoint 2010 Products is Now Available for Download”. Note that SharePoint Server 2010 SP1 includes the SharePoint Foundation SP1 and that SharePoint Server 2010 Language Pack SP1 includes the SharePoint Foundation 2010 Language Pack SP1. So if you are running SharePoint Server 2010, installing the SharePoint Foundation 2010 service packs are optional.