September, 2010

This blog looks suspiciously different, doesn't it?  What changed?  Well we changed the name to better reflect the scope of what we post and to continue our alignment with the Office and Windows Springboard Series program.   This is in line with the changes we've made on the Office TechCenter on TechNet (www.OfficeITPro.com). 
 
What will you see on this blog?  You'll continue to see Office related announcements of new tools, releases,  articles, resource centers, tips, tricks and anything else we think you, as an IT Professional, should know about when planning, deploying and/or managing Office in your environment.  
 
As always, let us know what you think and if there are any specific topics you'd like us to cover.

Cheers!

Cat

To set up an Office 2010 KMS host on Windows Server 2003, you must install Key Management Service (KMS). Although the minimum required version is KMS 1.1, we highly recommend that you install KMS 1.2, which recognizes virtual computers as part of the activation count.

To install KMS 1.2, follow the instructions in Microsoft Knowledge Base article 968915: An update is available that installs Key Management Service (KMS) 1.2 for Windows Server 2003 Service Pack 2 (SP2) and for later versions of Windows Server 2003.

Note that for KMS 1.2, Windows Server 2003 must have at least SP2 installed.

We recently created a new Office 2010 Security resource center. Please take it for a test drive and let us know what you think. Is there anything that you would like to see added? Do you find this resource useful? We would love to hear back from you. Thank-you!

We've had some questions about the Windows Installer version required by the Office 2010 Office Customization Tool (OCT) and would like to clarify the requirements.

In Office 2010, there are two architecture-specific versions of the OCT, one for 32-bit Office 2010 and one for 64-bit Office 2010. The 64-bit version of the OCT supports 64-bit client editions of Office 2010, and provides the same user interface, capabilities, and configurable settings as the 32-bit version. The OCT files are located in the Admin folder under the x86 (32-bit) and x64 (64-bit) folders, respectively.

The Office 2010 release requires Windows Installer 4.0 on computers that are running the 64-bit version of the OCT or importing 64-bit Setup customization .msp files. Windows Installer 3.1 does not recognize properties such as “ProgramFiles64Folder,” which are used by the 64-bit version of the OCT and the OCT Import feature. Windows Installer 4.0 was released with Windows Vista, Windows Vista  with SP1, and Windows Server 2008.

For information about Windows Installer, see Windows Installer (http://go.microsoft.com/fwlink/?LinkID=111108), and Released versions of Windows Installer (http://go.microsoft.com/fwlink/?LinkID=201918).

 For information about the OCT, see Office Customization Tool in Office 2010 (http://technet.microsoft.com/en-us/library/cc179097.aspx). For information about the Import feature, see Import an Office 2010 Setup customization file (http://technet.microsoft.com/en-us/library/ee681791.aspx).

Many thanks to Curtis Sawin, a Senior Consultant with Microsoft Consulting Services, for providing this content for the Office Resource Kit Blog.

Recently, while performing deployment testing of Microsoft Office 2010 for a customer, we ran into a specific issue while upgrading Office 2003 to Office 2010.  Specifically, Office 2010 setup may fail when upgrading from Office 2003 if the Office 2003 Local Installation Source (LIS) is corrupt.  Further, it’s possible to install Office 2003 in such a manner that Office 2010 will detect a corrupt LIS, when, in fact, the source has been deleted.  We discovered that Office 2010 responds differently to an Office 2003 installation when a LIS is not created, compared with a LIS that is created and then deleted.

This blog post describes the issue and provides a workaround.

Office 2003 and the Local Installation Source (LIS)

Beginning with Office 2003, Setup.exe creates a LIS as an optional component during installation.  Typically, the LIS is installed into the “C:\MSOCache” folder.  The goal of the LIS is to ensure that any requirements for the original installation source do not result in a prompt to the user.  The original installation source may be required if an end-user repairs Office 2003, adds a new feature, or applies a hotfix (i.e., a patch).  If the original installation source is not available, the end-user will be prompted to find a source location where the Office 2003 setup files can be found.  If the end-user does not know the location of the source, the desired action (e.g., repair, feature addition or hotfix installation) will fail. 

At the end of the Office 2003 installation, you are prompted to Delete installation files (see image below).  If this check box is selected, when you select the Finish button, the setup files are removed from the LIS.  (Side note:  This check-box is not selected by default).

It’s also important to note that to install Office 2003, you can also run the MSI directly (e.g., std11.msi or pro11.msi) instead of running Setup.exe.  Using the MSI to install Office 2003 is fully supported and allows customers to use Group Policy to deploy Office 2003.

If the MSI is used rather than Setup.exe, then a LIS is not created when installing Office 2003. 

Office 2010 Setup and the Office 2003 LIS

Office 2010 setup detects for previous versions.  Specifically, Office 2010 checks for Office XP, Office 2003, and Office 2007.  When checking for Office 2003, setup checks for an Office 2003 LIS and validates that it’s intact.  If the Office 2003 LIS has been altered, Office 2010 will display the following message and the installation will stop.

 Additionally, the following will be written to the installation log file:

Catalyst Office 2003 Cache Integrity check.  Corrupt cache found.
Return Code: 30066.  Exception Caught: PreReqCheckFailure

In short: If the Office 2003 LIS has been altered or corrupted, Office 2010 setup will fail.

Additionally, it should be noted that if you select Delete Installation Files at the end of Office 2003 setup, Office 2010 setup will detect this as a corrupt cache.  This is very important to note, so I’ll say it louder: 

It is possible to install Office 2003 in a (supported) manner which will cause Office 2010 setup to fail.

This situation is exacerbated in that Office 2003 may have been installed years ago.  Thus, IT admins may not be aware of how Office 2003 was installed when they are preparing to install Office 2010.   Thus, detecting and handling this situation becomes critical to ensuring a smooth upgrade to Office 2010.

That’s the bad news.  The good news is the following:

- Only specific, limited subset of Office 2003 installations are subject to this issue.
- You can use an Office 2003 Resource Kit tool to prevent this issue from causing problems.

Office 2003 Installations Affected

As stated earlier, there are two ways to install Office 2003: Using setup.exe or using the MSI directly.  If you install Office 2003 using the MSI directly, the LIS is not created.  Thus, Office 2010 setup will not perform this “cache integrity check.  Meaning, Office 2003 installations installed via the MSI directly are not subject to this issue.

Further, the Delete Installation Files check box is not selected by default. Thus, if you were to install Office 2003 silently, or with a basic (progress-bar only) interface, the LIS would not be deleted at the end of the installation.  This is a configurable setting, however.  If you set the property PURGE=1 during Office 2003 setup then the cache will be deleted upon the completion of setup.  Thus, you must either take specific action during installation (i.e., clicking the check-box), or purposefully configure the Office 2003 installation to purge its LIS in order to get into this situation.

Thus, it would be extremely rare to find that Office 2003 has been installed in this manner, so that Office 2010 cannot be installed.  In short, this problem only exists if the following are true:

- Office 2003 has been installed using setup.exe, and

- The Delete Installation Files check-box was selected during Office 2003 setup, or
- The PURGE property was set to “1” during Office 2003 setup.

Workaround: Correcting The Issue using LISTOOL.exe

We found that when Office 2003 is installed without a LIS via the MSI installation method, Office 2010 setup upgrades successfully.   Further, even though there is no Office 2003 LIS, because it wasn’t created in the first place, the original Office 2003 source is not needed when Office 2010 is installing.  Office 2010 will successfully uninstall Office 2003 using the cached MSI file (in “c:\windows\installer)”.

We also found that removing the “C:\MSOCache” folder does not correct this issue.  Meaning, if you install Office 2003 with a LIS, Office 2010 setup will detect this, even if the LIS no longer exists, and the Office 2010 installation fails.  In short, Office 2010 setup makes a distinction between an Office 2003 installation with a removed LIS and an Office 2003 installation without a LIS ever created.

However, you can use LISTOOL.exe, from the Office 2003 Resource Kit to either regenerate the LIS, or delete the LIS safely.  To delete the LIS, you can run:

LISTOOL.exe remove=all

This will delete the LIS, and allow Office 2010 setup to succeed.  The above command typically takes less than 5 seconds to complete, and can be run silently, using the “/q” command-line switch.

The command-line switches for LISTOOL.exe can be found in the screen shot below.  These can also be found by running

LISTOOL.exe /?

Running LISTOOL.exe before Office 2010 Setup

Now that we know we can mitigate this issue using LISTOOL.exe, it would be more helpful to perform this step immediately before Office 2010 setup is run…but only on computers where Office 2003 is currently installed.

This can be facilitated by creating a script/program that:
- Checks for any Office 2003 product,
- removes the Office 2003 LIS,
- then installs Office 2010. 

Such a script must be run prior to calling Office 2010 setup.  It cannot be called by leveraging Add Installations and Run Programs in the Office Customization Tool (OCT) to run a program before Office is installed.  Nor can you use the Command element in the Config.xml to run a program before Office 2010 is installed.  Such programs are run after the cache integrity check is performed.

In order to check for any Office 2003 product, you can use the Windows Installer automation interface to enumerate through all MSI products on a machine to find any Office 2003 product.   When you enumerates through all MSI products, the ProductCode for each product is returned.  Thus, in order to detect Office 2003, you must know the ProductCode for the Office 2003 SKU (i.e., Standard, Professional, etc.).

Fortunately, the ProductCode algorithm for all Office products is publicly available.  Support article 823672: Description of numbering scheme for product code GUIDs in Office 2003 can be used as a guide.  For instance, the last 28 characters of the ProductCode for any Office 2003 product is “6000-11D3-8CFE-0150048383C9}.”  You can then detect for this string when enumerating all products, and run LISTOOL.exe if a matching product is found.

Below is a sample VBScript that demonstrates this:

'     Sample script to check for Office 2003.
'     The script will launch LISTOOL.EXE to remove the Office 2003 LIS for any Office 2003 product
'     Requirements: LISTOOL.EXE and Install.cmd must exist in the same path
'     Notes:  This sample contains no error handling.  It is for demo purposes only.

Option Explicit

Dim oMSI, oProds, oProd
Dim oFSO, oShell, strCommandLine, strofficeCommandline
Dim str2003Guid, intLen2003, intReturn

set oFSO = CreateObject("Scripting.FileSystemObject")
set oShell = CreateObject("WScript.Shell")
set oMSI = CreateObject("WindowsInstaller.Installer")
set oProds = oMSI.Products

str2003Guid = "6000-11D3-8CFE-0150048383C9}"
intLen2003 = len(str2003Guid)

strOfficeCommandline = "install.cmd"
strCommandline = "listool.exe /q remove=all"

'     Check for any office 2000 or 2003 product
for each oProd in oProds
      ' Remove Office 2003 LIS if found
      if right(oProd,intLen2003) = str2003Guid then
            intReturn = oShell.run(strcommandLine,,1)
            exit for
      end if
next

'     Call the Office 2010 installation
IntReturn = oShell.run (strOfficeCommandline,,0)

Summary

Office 2003 presents a unique challenge when upgrading to Office 2010.  Fortunately, the projected scope of affected computers is small, and a targeted mitigation can be used to work around this issue. 

When customers are migrating from earlier versions of Office, one of the many questions they ask is how to get the end-users ready for Office 2010?

The ORK team put together the User Readiness and Training Resource Center (http://technet.microsoft.com/en-us/office/ff381682.aspx ) which highlights: 

User Resources               How to Train Users              Other Training Resources

The User Readiness and Training Resource Center is your portal into resources like posters, flyers, at-work guides, and weekly e-mail templates to get people excited about Office 2010.  Not only do we provide assistance in those formats, but you also have access to product guides that further assist users in learning about Office 2010. The guides include printable getting-started guides, feature guides, and product overviews.

One of the highlights of our resource center earlier this month was the availability of the downloadable and online Interactive guides (http://go.microsoft.com/fwlink/?LinkId=201999) that use Silverlight technology to show you where your favorite menu and toolbar commands are located in Office 2010 applications.

Today I want to highlight another great resource for training users on the new Office 2010 applications.  The Office 2010 migration guides cover Microsoft Access, Excel, OneNote, Outlook, PowerPoint, and Word, and they focus on assisting customers who are transitioning from Office 2003 to Office 2010 (or Office 2007 specifically for OneNote). 

If you haven’t already heard about the migration guides, each guide provides helpful information that was gathered from customers like you.  Helpful information like “How to keep your favourite commands nearby, “or “How to create ribbon tabs or groups of your own,“ or “Do keyboard shortcuts still work? “ and “How to work with people who don’t yet have PowerPoint 2010 . “ 

All six guides are available as separate downloads, so you can grab just the ones you need.

1. Be sure to install the free Adobe Reader (if you don't already have it on your computer).
2. Then browse and download our free Office 2010 migration guides.
3. Go back to the User Readiness and Training Resource Center and discover more resources that will help you train your users to work in Office 2010.

Enjoy!

This is the newly released version of MDT 2010, a Solution Accelerator for operating system and application deployment. MDT 2010 Update 1 supports Office 2010, Windows 7, and Windows Server 2008 R2 in addition to Windows Vista, Windows Server 2008, Windows Server 2003, and Windows XP. MDT 2010 Update 1 supports the x86 platform and the x64 platform.

Some of the key changes contained in MDT 2010 Update 1:

• Comprehensive tools and guidance to efficiently manage large-scale deployments of Office 2010.
• A new User-Driven Installation (UDI) deployment method that uses System Center Configuration Manager. UDI lets you initiate and customize an operating system deployment on your PC through an easy-to-use wizard.
• Automatic detection of the true supported platforms for drivers, thereby reducing deployment issues.

You can find more information and download MDT 2010 Update 1 here.

Update: This issue has been fixed as of August 2011 in Update 1 of OMPM. See our recent blog post for more information.

One of our field consultants, Curtis Sawin, discovered a discrepancy in the macro counts displayed by Office 2010 Migration Planning Manager (OMPM) and Office 2010 Code Compatibility Inspector (OCCI). For example, when run against the same Excel spreadsheet that contains macros, OMPM reports 889 issues, and OCCI reports 85 issues, as shown in the following examples:
 
OMPM (889 issues reported):

OCCI (85 issues reported):

The discrepancy is caused by a difference in how the two programs detect macros. If a file contains a macro, OMPM scans it against *all* Office programs to determine which programs may have compatibility issues with the file. In contrast, OCCI scans the macro only against the program that is associated with the file (you can manually force it to scan more, though). For example, if an .xls file contains a macro, OMPM scans its compatibility against all Office 2010 products. OCCI only scans it against Excel.

The result is that the OMPM report reports more macro issues for a given file than OCCI reports—sometimes as many as 10x more. The number and types of issues identified by OCCI are the ones you’ll want to investigate. However, the OMPM report is internally consistent, so that if a file reports 100 issues, that file has more macro issues than a file that reports 50 issues. In this way, you can still use OMPM to prioritize investigation with OCCI.

We are working to fix the issue by making OMPM perform the same scan as OCCI, so that OMPM only counts issues a macro would have in the program associated with its containing file. We will post an announcement here when a fix is available.

Jill

UPDATE (NEW) - 11/11/2010:

The Security Solution Accelerators team recently announced the release of the new Office 2010 Security Baseline that can be used with the Security Compliance Manager tool!

New users can access the Office 2010 Security Baseline by visiting the Microsoft Download Center to download the Security Compliance Manager tool.

Existing users can access the Office 2010 Security Baseline in the tool by clicking the Tools menu, and then clicking Check for Baselines.

---------------------------------------------------------------------------------------------------------------------------------------

OLD:

The Solution Accelerators team recently announced the beta release of the Microsoft Office 2010 Security Baseline, the latest addition to the Security Compliance Manager Baseline Beta Review Program.

Join the Microsoft Office 2010 Security Baseline Beta Review Program. This baseline is available for beta review.

Note: You need to have a Windows Live ID and register with Microsoft Connect before being able to join the Microsoft Office 2010 Security Baseline Review Program, which is listed in the Microsoft Connect Product directory as Security Solution Accelerators for the product name. After you click "(apply)", the Microsoft Connect page, "Participate in the Security Compliance Manager Baseline Beta Review Program!", will appear. From this page you can then download the beta baseline for Office 2010.

The best-practice guidance and security settings provided by this new beta release allow you to plan and deploy your baselines from Microsoft with ease and confidence. The security baseline for Microsoft^® Office 2010 provides you with free Microsoft-recommended solutions to meet today's security challenges. In combination with best-practice guidance and the Security Compliance Manager, the baseline is designed to help you plan, deploy, and monitor the security of Office 2010 applications. This beta release also includes a setting pack for Office 2010, enabling you to define baselines that include settings outside the scope of the security baselines from Microsoft.

The Microsoft Office 2010 Security Baseline is formatted to be imported for use in the Security Compliance Manager tool, which released in early 2010. This powerful tool provides guidance to work with other tools and features of Microsoft products to help you plan, deploy, and monitor your security baselines. The tool enables you to access and automate all of your organization’s baselines in one centralized location, balancing your needs for security and functionality.

To learn more about the Security Compliance Manager tool, visit the TechNet Library.

To download the tool, click here.

Office 2010 Language Packs are add-ins that enable desktops to support multiple languages, including Menus/Display, Help, Dictionary, Thesaurus, and Spell Checker. Language packs enhance the user experience. For example, users can choose to use individual aspects of the language pack, such as the spell checker feature, which they can use to proof a document in a language other than the default language that is configured on their computer.

Language Packs enable localized Menus/Display, Help, and document proofing tools for most Microsoft Office 2010 applications, including Access , Excel, InfoPath, OneNote, Outlook, PowerPoint, Project, Publisher, SharePoint Workspace, Visio, Word, and the Microsoft Office 2010 suites that contain these products. Language Packs are not supported on Word Starter 2010 and Excel Starter 2010. Access 2010 and Project 2010 are not supported in Hindi.

Language packs are available for the following languages:
Arabic, Brazilian Portuguese, Bulgarian, Croatian, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, Estonian, Finnish, French, German, Greek, Hebrew, Hindi, Hungarian, Italian, Japanese, Kazakh, Korean, Latvian, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian, Serbian Latin, Slovak, Slovenian, Spanish, Swedish, Thai, Turkish, and Ukrainian.

For information about deploying multiple languages, see our earlier blog, Deploying Office 2010 with multiple languages (http://blogs.technet.com/b/office_resource_kit/archive/2010/01/19/deploying-office-2010-with-multiple-languages.aspx) for a list of resources.

For information about how to purchase Office 2010 language packs, see the Office 2010 language options page (http://office.microsoft.com/en-us/language/?CTT=5&origin=HA101828857).

Microsoft is working with local language authorities around the world to provide free Office Language Interface Packs for languages that are not covered by Office Language Packs 2010. For more information about acquiring Language Interface Packs, visit the Microsoft Local Language Program website (http://office.microsoft.com/en-us/language/redir/XT101829222.aspx?CTT=5&origin=HA101828857).

When customers are migrating from earlier versions of Office, one of the many questions they ask ask is how to get the end-users ready for Office 2010 and once they are on the new version how can we make it easier for them to transition their knowledge of one version to another?

First let's take one step back.  Remember opening Office and seeing a menu bar, or perhaps you are still using a version of Office that looks like this:

With the release of Office 2007, a lot of the applications received a new UI.  When you opened Word it looked a little different, that difference is called the ribbon.

So now that we have determined there is a visual change between Office 2003 and the most recent Office 2010, let me introduce you to some of those tools that you can find on the User Readiness and Training Resource Center - the interactive guides. 

The interactive guides are like having a techie standing beside your user ready to answer, as the users ask: “How do I do this in Office 2010 when I knew how to do it in the previous version?”  And as the users click the known menu or command – the Silverlight based guide shows the users how to do it by using the ribbon in Office 2010.

The guides are available individually for the following applications:

You can either run them directly from the Internet, or you can download and install them to your local desktop.   Your users will start quickly recognizing how each tab is organized in the new ribbon – and transitioning to the feature rich environment of Office 2010.

For further details and information about downloading and installing the guides, see the latest article “Interactive Guides to UI Changes”: http://technet.microsoft.com/en-us/library/ff959696.aspx

If you're new to the ribbon check out some of our content at: http://go.microsoft.com/fwlink/?LinkId=200824 and my prior post http://go.microsoft.com/fwlink/?LinkId=200825.

Enjoy!