Active Directory-Based activation uses your existing Active Directory infrastructure to host activation for Microsoft Office 2013 Volume-Licensed (VL) clients, through their connection to the domain.
Both on the host as well as client side, the Active Directory-Based activation requires either a Windows 8 VL computer or a WindowsServer 2012 computer. It uses the same GVLK/KMS host key (CSVLK) pair that KMS activation uses. It also requires the installation of Microsoft Office 2013 Volume License Pack.
STEP 1: Download the Microsoft Office 2013 Volume License Pack from the Microsoft Download Center (MSDL) site.
STEP 2: Double-click the downloaded EXE to run it:
STEP 3: Once the EXE finishes running, you will see theVolume Activation Tools wizard pop-up:
STEP 4: On the next screen, choose Active Directory-Based Activation:
STEP 5: Next enter the KMS host (CSVLK) key and optionally give it a name:
STEP 6:Choose activation method, online or phone:
STEP 7: Activation Succeeded:
The current version of the Office 2010 KMS Host License Pack cannot be installed on machines running Windows 8 or Windows Server 2012. Attempts to do so will result the error, "Unsupported operating system".
1/7/2013 UPDATE: The "Product activation failed" error that can occur when attempting to perform a phone activation of an Office 2010 KMS host installed on Windows 8 or Windows Server 2012 machines has been addressed in the latest release of the KeyManagementServiceHost*.exe file, which can be found in the link below.
12/4/2012 UPDATE: This issue has been addressed in the latest version of the Office 2010 KMS Host License Pack, which can be found at the link below.
Microsoft is working on an update for the Office 2010 KMS Host License Pack which will allow it to be successfully installed on Windows 8 or Windows Server 2012 machines.
All of the steps below are no longer required as of 1/7/2013. See related note above in red, bold text.
In the meantime, the following steps can be used to work around the issue:
1) Download the Office 2010 KMS Host License Pack (http://go.microsoft.com/fwlink/p/?LinkID=169244)2) Run the downloaded KeyManagementServiceHost.exe file to extract files that it contains. Ignore the "Unsupported operating system" error that occurs and click OK.3) Press the Enter key to close the command window that is related to cscript.exe.3) Browse to the %programfiles% or %programfiles(x86)% folder and navigate to the MSECache\OfficeKMS subfolder. If you installed the Office 2010 KMS Host License Pack on a 64-bit operating system, %programfiles% is the Program Files (x86) folder.4) Rename the existing kms_host.vbs file to kms_host.old5) Download the kms_host.zip file from the Office Deployment Support Team's SkyDrive share at http://sdrv.ms/RiZ8Q9. 6) Extract the kms_host.vbs file from the zip file and place a copy of it in the %programfiles(x86)%\MSECache\OfficeKMS or %programfiles%\MSECache\OfficeKMS folder.
7) From an elevated command-prompt navigate to the %programfiles(x86)%\MSECache\OfficeKMS or %programfiles%\MSECache\OfficeKMS folder and run the following command:
cscript kms_host.vbs
7) If the KMS host machine has Internet connectivity, click Yes to enter the Office KMS host product key and activate online. Otherwise, click No, and press Enter to close the command window.
Open an elevated command prompt and run the following command line to check the installation, licensing state, and current status of the Office KMS host:
cscript slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864
See the following articles for additional information related to Office KMS host installation, activation, and troubleshooting:
Deploy volume activation of Office 2010http://technet.microsoft.com/en-us/library/ee624357.aspx Troubleshoot volume activation for Office 2010http://technet.microsoft.com/en-us/library/ee624355.aspx
Office Deployment Support Team Blog, "Office 2010 KMS installation and troubleshooting"http://blogs.technet.com/b/odsupport/archive/2010/06/01/office-2010-kms-installation-and-troubleshooting.aspx
Support for Windows XP, Office 2003, and Internet Explorer 6 running on Windows XP ends on April 8, 2014.
After April 8, 2014, Microsoft will not provide any public support for Windows XP, Office 2003, and Internet Explorer 6 running on Windows XP. This includes security patches, non-security hotfixes, and incident/assisted support.
To continue receiving assisted support and security updates:
By moving to these versions, customers will receive the latest security technology from Microsoft.
Self-Help Online Support for Windows XP, Office 2003, and Internet Explorer 6 will be available for a minimum of 12 months after their end of support date. Microsoft online Knowledge Base articles, FAQs, troubleshooting tools, and other resources, are provided to help customers resolve common issues.
For additional information related to why support is ending for Windows XP SP3 and Office 2003, what end of support means to customers, and how Microsoft will help customers see http://www.microsoft.com/en-us/windows/endofsupport.aspx
Installing Service Pack 1 for Office 2010 may cause the SharePoint Workspace (SPW) feature to be added to the installation, when it was previously set to "Not Available". This issue is the subject of Microsoft Knowledge Base article 2612800.
The screenshots below illustrate the SPW feature state as displayed in the Control Panel and the Office Customization Tool (OCT) when set to "Not Available":
(click to view larger images)
A related update was recently published to the Microsoft Download Center:
x86/32-bit (Office2010-kb2598245-fullfile-x86-glb.exe)http://www.microsoft.com/download/en/details.aspx?id=29250
x64/64-bit (Office2010-kb2598245-fullfile-x64-glb.exe)http://www.microsoft.com/download/en/details.aspx?id=29249
This update must be applied prior to the installation of SP1 to prevent the SPW feature from being added by SP1 or a later update.
Enterprise customers who are using the Updates folder for new installations of Office 2010 and including SP1 MSP files can use these steps to prevent the installation of SharePoint Workspace 2010:
1) Extract the contents of the update executable to a temporary location using the “/extract:<path>” switch (see KB912203 for addt'l switches).
(click to view larger image)
2) Note the contents and subfolder in the location of the extracted update:
3) Copy the pre_rmaddlocal-x-none.msp and osetup.dll files, SP1 MSP files, and any other update or OCT generated MSP files into the Updates folder. The osetup.dll file can be found in the Admin subfolder, and the presence of this file will cause the pre_*.msp file to be applied before SP1, and after any OCT files.
There are currently no plans to add this update to the Microsoft Update Catalog, as doing so would cause it to be offered to all Microsoft Update users. In this case, only users who have set the SharePoint Workspace feature to Not Available will be affected by the issue.
See the following articles for additional information:
KB2612800 Office 2010 SP1 installs SharePoint Workspacehttp://support.microsoft.com/kb/2612800
KB2598245 Description of the Office 2010 update: March 29, 2012http://support.microsoft.com/kb/2598245
Office Sustained Engineering and Release Team Blog post, "Update to Office 2010 SP1 to prevent unintentional installation of SharePoint Workspace"http://blogs.technet.com/b/office_sustained_engineering/archive/2012/03/30/update-to-office-2010-sp1-to-prevent-unintentional-installation-of-sharepoint-workspace.aspx
When troubleshooting KMS configuration and activation issues, our customers are often surprised to find unexpected Windows or Office KMS hosts in their environment.
By default, Windows and Office clients discover KMS hosts via DNS and a related _vlmcs SRV record. To determine whether a KMS client can locate a KMS host and/or whether undesired KMS hosts exist on the network, run a command line similar to the following:
nslookup -type=srv _vlmcs._tcp >%temp%\kms.txt
Review the kms.txt file. It should contain one or more entries similar to the following:
Running this nslookup command frequently reveals _vlmcs SRV entries which are tied to unauthorized Windows or Office KMS hosts.
In many cases, Windows KMS hosts may have been unintentionally set up by users who mistakenly entered a KMS host product key, rather than a Windows client product key. To remedy this issue, perform the following steps on the machine(s) in question, to replace the KMS product group key and "convert" it to a KMS or MAK client:
1) Open an elevated command prompt.2) Run a command similar to the following:
cscript slmgr.vbs /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx (where xxxxx-xxxxx-xxxxx-xxxxx-xxxxx is a 25 digit, Windows product key)
3) To prevent instability in the license service, the system should be restarted or the Software Protection Service should be restarted. The following command lines can be used to restart the Software Protection Service:
net stop sppsvcnet start sppsvc
4) Run a command line similar to the following to display the license information for the installed, active Windows edition:
cscript slmgr.vbs /dli
5) Using DNS Manager, in the appropriate forward lookup zone, delete the _vlmcs SRV records that exist for each machine which is not to serve as a Windows KMS host.6) See the following articles for additional information:
Slmgr.vbs Options http://technet.microsoft.com/en-us/library/ff793433.aspx
Windows 7 and Windows Server 2008 R2 Customer Hosted Volume Activation Guide / Deploying KMS Activationhttp://technet.microsoft.com/en-us/library/ff793409.aspx
Unintentional creation of an Office KMS host is less common, because setting up an Office KMS requires a specific product key and the installation of the Microsoft Office 2010 KMS Host License Pack.
To determine whether a machine has the Office 2010 KMS Host License Pack installed and is an active Office KMS host, run a command line similar to the following:
The output of a machine which has the Office 2010 KMS Host License Pack installed will resemble the following. Key items are "Partial Product Key: GB7AH" and "License Status: Licensed", which indicate that the Office 2010 KMS host key is successfully installed and activated.
Name: Microsoft Office 2010, KMSHost editionDescription: Microsoft Office 2010 KMS, VOLUME_KMS channelActivation ID: bfe7a195-4f8f-4f0b-a622-cf13c7d16864Application ID: 59a52881-a989-479d-af46-f275c6370663Extended PID: 55041-00096-199-000004-03-1033-7600.0000-3632009Installation ID: 008523674214771124199799184000850026888810090415321136Processor Certificate URL: http://go.microsoft.com/fwlink/p/?LinkID=88342Machine Certificate URL: http://go.microsoft.com/fwlink/p/?LinkID=88343Use License URL: http://go.microsoft.com/fwlink/p/?LinkID=88345Product Key Certificate URL: http://go.microsoft.com/fwlink/p/?LinkID=88344Partial Product Key: GB7AHLicense Status: LicensedRemaining Windows rearm count: 1Trusted time: 10/16/2011 2:07:42 PM
Key Management Service is enabled on this computer Current count: 0 Listening on Port: 1688 DNS publishing enabled KMS priority: Normal
Perform the following steps to remove an Office KMS host in your environment:
cscript slmgr.vbs /upk bfe7a195-4f8f-4f0b-a622-cf13c7d16864
CAUTION: If the above command line is run without the Office activation ID ("bfe7a195-4f8f-4f0b-a622-cf13c7d16864"), all installed product keys are uninstalled, including those for Windows.
3) Run following command line again, to check the status of the Office KMS host:
4) If the Office KMS host product key has been removed, the output will be similar to that below. Key items are "This license is not in use" and "License Status: Unlicensed".
5) Using DNS Manager, in the appropriate forward lookup zone, delete the _vlmcs SRV records that exist for each machine which is not to serve as an Office KMS host.6) See the following articles for additional information:
Deploy volume activation of Office 2010http://technet.microsoft.com/en-us/library/ee624357.aspx
Troubleshoot volume activation for Office 2010http://technet.microsoft.com/en-us/library/ee624355.aspx
In a previous Office Deployment Support Team Blog post, we explained how to automatically activate Office 2010 by using a customized config.xml file and setting element/property, AUTO_ACTIVATE.
This blog post will expand on that a bit and explain how to perform the same actions using an MSP file created with the Office Customization Tool (OCT).
NOTE: Adding the AUTO_ACTIVATE property to an install will trigger an attempt to activate only once. If that fails for whatever reason (i.e., proxy issues, user rights, Internet connectivity issues, etc.), another attempt will not be made and Office users will later be prompted to activate Office 2010.
The following is a simplified example of a custom config.xml file, which can be used with volume license source files for Office 2010 Professional Plus to automate the process of inputting an Office MAK product key and activating the product at install time. In addition, the installation operation will be silent, with a related verbose log file created in the %temp% directory.
These options are typical for many customers who deploy Office in an enterprise environment. For more information, see the Config.xml file in Office 2010 article at http://technet.microsoft.com/en-us/library/cc179195.aspx
<Configuration Product="ProPlus">
<PIDKEY Value="ABC12xxxxxxxxxxxxxxx34XYZ" />
<Setting Id="AUTO_ACTIVATE" Value="1" />
<Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />
<Logging Type="verbose" Path="%temp%" Template="Microsoft Office Pro Plus Setup(*).txt" />
</Configuration>
1) In the above, "ABC12xxxxxxxxxxxxxxx34XYZ" is a placeholder for what should be your organization specific MAK product key for Office 2010.2) Install Office 2010 as a user with local administrator rights by using a command line similar to the following:
<path to Office 2010 source files>\setup.exe /config <path>\config.xml
3) Alternatively, this file can be added to the root of source files for Office 2010 (i.e., the same location of Setup.exe on a CD/DVD or network share), and running the setup executable will cause the config file to be automatically parsed at install time.
The following steps can be used to accomplish the same thing using the Office Customization Tool (OCT). In addition to providing for more advanced customization of an Office installation, adding a MAK product key to and OCT generated MSP file instead of a config.xml causes the key to be obfuscated, rather than appearing in plain text as it is in a config.xml file.
1) Run the OCT by typing setup.exe /admin at the command line from the root of the network installation point that contains the Office 2010 source files. For example, use \\server\share\Office14\setup.exe /admin.2) In the OCT, select Licensing and user interface in the left pane, and in the right pane select Enter another product key, add your organization specific MAK Office product key in the Product key field, and other options as desired.
3) In the OCT, select Modify Setup properties in the left pane and then click the Add... button in the right pane.4) In the Add/Modify Property Value dialog and type AUTO_ACTIVATE in the Name field. Note that property names are case sensitive.5) In Value field, type 1, and then click OK.
6) Note that the AUTO_ACTIVATE property has been added to the MSP file and has a value of 1.
7) Click the File menu and then click Save as to save the Setup customization file. If the file is saved in the Updates folder that is part of the Office source file location/installation point, running the Office Setup.exe file will automatically detect the customization file in the Updates folder and apply the customizations.8) As an alternative to placing the customization .msp file in the Updates folder, you can use the Setup command-line option /adminfile to specify the fully qualified path of the location of the MSP file. For example, type setup.exe /adminfile \\server\share\mychanges\custom.msp.
The 32 and 64-bit versions of Service Pack 1 (SP1) for Office 2010 are now available!
Service Pack 1 for Microsoft Office 2010 (KB2460049) 32-bit Editionhttp://www.microsoft.com/download/en/details.aspx?id=26622
Service Pack 1 for Microsoft Office 2010 (KB2460049) 64-bit Editionhttp://www.microsoft.com/download/en/details.aspx?id=26617
See the following Knowledge Base articles for an overview of Service Pack 1 improvements and technical details:
KB2460049 Description of Office 2010 SP1http://support.microsoft.com/kb/2460049
KB2532118 Technical details about the Microsoft Office 2010 Service Pack 1 (SP1) releaseshttp://support.microsoft.com/kb/2532118
To obtain an Excel workbook that lists the issues which are addressed by this service pack, click here.
Version 2 of the Group Policy template files and OCT files for the SP1 release of Office 2010 are also now available for download!
Office 2010 Administrative Template files (ADM, ADMX/ADML) and Office Customization Toolhttp://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18968
NOTE: If you are using the Office Customization Tool to create MSP files for custom installations of Office 2010, we recommend that you use the most recent version of the OCT files.
Updating OCT files is simple – just replace the /Admin folder in your Office 2010 installation files or installation image with the new /Admin folder after extracting it from the download package.
If your Office 2010 installation files include 32 and 64-bit versions, you will need to replace the contents of the /Admin folder in the x64 and x86 directories with those from the appropriate download package.
See the following article for additional information:
Office 2010 Administrative Template files (ADM, ADMX, ADML) and Office Customization Toolhttp://technet.microsoft.com/en-us/library/cc178992.aspx
Need Service Pack 1 for SharePoint 2010 and/or Office 2010 Web Apps? We've got you covered!
Download Service Pack 1 for Microsoft SharePoint Server 2010http://www.microsoft.com/download/en/details.aspx?id=26623
KB2460045 Description of SharePoint Server 2010 SP1http://support.microsoft.com/kb/2460045
Download Microsoft Office Web Apps Service Pack 1http://www.microsoft.com/download/en/details.aspx?id=26639
KB2460073 Description of Office Web Apps SP1http://support.microsoft.com/kb/2460073
KB2532120 Technical details about the Microsoft SharePoint 2010 and Office server Service Pack 1 (SP1) releases http://support.microsoft.com/kb/2532120
Windows Installer 4.x and later includes the “MSI Restart Manager” which is designed to reduce required operating system reboots during Installer maintenance mode operations, by restarting applications rather than rebooting the operating system.
A typical Office update scenario where the MSI Restart Manager is used may be similar to the following:
1) Windows 7 machines have Office 2010 installed.2) Using a sample update named KBxxxxxx.exe, extract the MSP files from the executable using a command line similar to the following (run the executable with the /? switch to see all available switches):
<path>\KBxxxxxx.exe /extract:<path>
3) A customer deploys an Office update during the business day or during off hours, prior to rebooting machines/ensuring that no Office applications are in use, using a command line similar to the one below:
%windir%\System32\msiexec.exe /P <path>\POWERPNT.msp REBOOT=ReallySuppress /L*V <path>\POWERPNT.log /QN
4) If a user has PowerPoint and a related document open at this point, an expected reboot will not be called for or suppressed. 5) Instead, the MSI Restart Manager is invoked, closes PowerPoint, allows files in use to be updated without a reboot, and reopens PowerPoint.6) The resulting behavior is that, upon restart, PowerPoint’s auto recovery functionality has saved the file that was previously open, and the user is prompted how they want to proceed with the auto-recovered file.
In order to prevent the application restart from occurring and disable the MSI Restart Manager, a command line similar to the following can be used:
%windir%\System32\msiexec.exe /P <path>\POWERPNT.msp REBOOT=ReallySuppress MSIRESTARTMANAGERCONTROL=Disable /L*V <path>\POWERPNT.log /QN
It is important to note that if the MSI Restart Manager is disabled, a reboot is suppressed, and Office files to be updated are in use, changes to files will not occur until after the machine is rebooted (this would be a scenario where the log file ends with a return code of 3010).
The screenshots below illustrate the behavior which occurs when installing updates while Office apps are open, with and without the MSIRESTARTMANAGERCONTROL=Disable property being set.
1) If the MSI Restart Manager is not disabled, and the update process is run in quiet mode versus silent mode (“/QB” vs. “/QN”), the user will be prompted to close open applications:
2) If the MSI Restart Manager is not disabled, and the update process is run in quiet mode, with only reboots suppressed, open Office applications will automatically be restarted. Upon restart, open documents will be auto saved and auto recovered.
3) Clicking the “Recovered” button will result in the Document Recovery pane being displayed, and the user will be prompted as to which copy of the document that they wish to save.
4) If the MSI Restart Manager is disabled, the update process is run in silent mode, and reboots are suppressed, Office applications will not be restarted, but the resulting log file will contain a 3010 exit/return code (see attached LogFile.zip and the KB2464594.log file that it contains).
See the following articles for additional information on the MSI Restart Manager and the MSIRESTARTMANAGERCONTROL property:
Using Windows Installer with Restart Managerhttp://msdn.microsoft.com/en-us/library/aa372466.aspx
MSIRESTARTMANAGERCONTROL Propertyhttp://msdn.microsoft.com/en-us/library/aa370377.aspx
If you have installed the KB2464588 update for Microsoft PowerPoint 2003, which is related to Microsoft Security Bulletin MS11-022, you may be aware of/experiencing the following known issues:
When you open presentations that contain layouts with background images in PowerPoint 2003, an error may occur. When the error occurs, you receive a message that states that some contents (text, images, or objects) have corrupted. You can determine what content has been lost by viewing the layout, but not by viewing the slide content. Items that were removed will display a blank box or a box that contains "cleansed."
The KB2543241 hotfix was created to alleviate these issues. The following steps can be used to install the KB2543241 hotfix in a manner that is conducive to an enterprise environment (i.e., via command line, silently, and requiring no user interaction):
1) Extract the MSP file from the KB2543241 executable, by using a command line similar to the following ("C:\KB2543241" is an example of a path where files could be extracted to):
<path>\office2003-KB2543241-ENU.exe /C /T:C:\KB2543241 /Q
2) Attempt to silently install the KB2543241 MSP file, generate a verbose installation log, and suppress reboots using a command line similar to the following (change "/QN" to "/QB" to display only a basic progress indicator):
%windir%\System32\msiexec.exe /P C:\KB2543241\POWERPNT.msp REBOOT=ReallySuppress /L*V C:\KB2543241\KB2543241.log /QN
3) Check the end of the verbose log file (i.e., KB2543241.log) for a return code. A value of zero indicates success with no further action required. A return code of 3010 also indicates a successful installation of the MSP file, but a reboot is required to complete the update process.
4) See http://msdn.microsoft.com/en-us/library/aa368542(v=vs.85).aspx for additional info on Windows Installer return/error codes.
5) Machines with Windows Installer 4.x and later (Windows 7 ships with Installer 5.x) contain functionality provided by the MSI Restart Manager. The design of the MSI Restart Manager is to reduce required system restarts caused by required files being in use during a maintenance mode or update process.
6) With the MSI Restart Manager, if a file that is to be updated is held in use by another process or application (i.e., PowerPnt.exe), that application is restarted in order to allow for an "on the fly" update.
7) This has the potential to cause issues with open Office applications, which may be unexpectedly restarted. To prevent applications from being restarted, a command line similar to the following can be used:
%windir%\System32\msiexec.exe /P C:\KB2543241\POWERPNT.msp REBOOT=ReallySuppress MSIRESTARTMANAGERCONTROL=Disable /L*V C:\KB2543241\KB2543241.log /QN
8) It is important to note that if the MSI Restart Manager is disabled, a reboot is suppressed, and Office files to be updated are in use, changes to files will not occur until after the machine is rebooted (this would be a scenario where the log file ends with a return code of 3010).
9) See the following articles for additional info on the MSI Restart Manager:
MSI Restart Manager - How it relates to Office updates and application restartshttp://blogs.technet.com/b/odsupport/archive/2011/04/29/msi-restart-manager-how-it-relates-to-office-updates-and-application-restarts.aspx
10) For further information on the KB2543241 and KB2464588 updates & hotfixes, see the following blog posts, articles, and bulletin:
Office Sustained Engineering and Release Team Blog post, "Issues after installing PowerPoint 2003 update KB2464588"http://blogs.technet.com/b/office_sustained_engineering/archive/2011/04/23/issues-after-installing-powerpoint-2003-update-kb2464588.aspx
KB2543241 Description of the PowerPoint 2003 hotfix packagehttp://support.microsoft.com/kb/2543241
Office Sustained Engineering and Release Team Blog post, "April 2011 Office Security Update Release"http://blogs.technet.com/b/office_sustained_engineering/archive/2011/04/12/april-2011-office-security-update-release.aspx
Microsoft Security Bulletin MS11-022 - ImportantVulnerabilities in Microsoft PowerPoint Could Allow Remote Code Execution (2489283)http://www.microsoft.com/technet/security/bulletin/MS11-022.mspx
KB2464588 MS11-022: Description of the security update for PowerPoint 2003: April 12, 2011http://support.microsoft.com/kb/2464588
After installing the April 2011 Public Update for Outlook 2007 (KB2509470), some users have reported difficulty with print previewing messages. The KB2512788 hotfix was created to address these issues.
The following steps can be used to install the KB2512788 hotfix in a manner that is conducive to an enterprise environment (i.e., via command line, silently, and requiring no user interaction):
1) Extract the MSP file from the KB2512788 executable, by using a command line similar to the following ("C:\KB2512788" is an example of a path where files could be extracted to):
<path>\office-kb2512788-fullfile-x86-glb.exe /extract:C:\KB2512788 /Q
2) Attempt to silently install the KB2512788 MSP file, generate a verbose installation log, and suppress reboots using a command line similar to the following (change "/QN" to "/QB" to display only a basic progress indicator):
%windir%\System32\msiexec.exe /P C:\KB2512788\outlook-x-none.msp REBOOT=ReallySuppress /L*V C:\KB2512788\KB2512788.log /QN
3) Check the end of the verbose log file (i.e., KB2512788.log) for a return code. A value of zero indicates success with no further action required. A return code of 3010 also indicates a successful installation of the MSP file, but a reboot is required to complete the update process.
6) With the MSI Restart Manager, if a file that is to be updated is held in use by another process or application (i.e., Outlook.exe), that application is restarted in order to allow for an "on the fly" update.
%windir%\System32\msiexec.exe /P C:\KB2512788\outlook-x-none.msp REBOOT=ReallySuppress MSIRESTARTMANAGERCONTROL=Disable /L*V C:\KB2512788\KB2512788.log /QN
10) For further information on the KB2509470 and KB2512788 updates & hotfixes, see the following blog posts and articles:
Office Sustained Engineering and Release Team Blog post, “Issues after installing Outlook KB KB2509470"http://blogs.technet.com/b/office_sustained_engineering/archive/2011/04/28/issues-after-installing-outlook-kb-kb2509470.aspx
KB2512788 Description of the Office Outlook 2007 hotfix package (Outlook-x-none.msp): April 26, 2011http://support.microsoft.com/kb/2512788
KB2509470 Description of the Extended Protection for Authentication update for Outlook 2007http://support.microsoft.com/kb/2509470
We can automate the silent uninstallation of Office patches via a command line like so:
%windir%\System32\msiexec.exe /package {Office GUID} /uninstall {Patch GUID} /QN
First we will need to determine what the GUID is for Office, and next what the GUID is for the patch that we are trying to uninstall. To determine what the GUID is for the installed version of Office, look in the uninstall hive in the registry.
x86 OS HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID} x64 OS HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}
On my two example machines I have Office 2003, and Office 2007 installed.
The GUID for Office 2003 will be similar or equal to {90110409-6000-11D3-8CFE-0150048383C9} The GUID may be slightly different then what I have listed here. Verify you found the correct GUID by verifying the product under the “Displayname” key listed in the GUID.
See also - Description of numbering scheme for product code GUIDs in Office 2003 Here is a screenshot of this registry key on my machine that has Office 2003.
The GUID for Office 2007 will be similar or equal to {90120000-0011-0000-0000-0000000FF1CE} The GUID may be slightly different then what I have listed here. Verify you found the correct GUID by verifying the product under the “Displayname” key listed in the GUID.
See also - Description of the numbering scheme for product code GUIDs in 2007 Office suites and programs Here is a screenshot of this registry key on my machine that has Office 2007.
Notice that there are many GUIDS that end in 0FF1CE in my screenshot above. The reason for this is because Office 2007/2010 is a multi-msi based product, and because of that there is a GUID for each component in Office 2007/2010. So for example if I clicked on {90120000-0015-0000-0000-0000000FF1CE} in my example above the “Displayname” would show “Microsoft Office Access MUI (English) 2007”. This is not the GUID for the Office suite. This is only the GUID for the Access MUI component. For Office 2007/2010 make sure that you find the GUID that has a display name that correlates with the name of the suite. ie.. Microsoft Office Professional Plus 2007, or Microsoft Office Standard 2007 etc..
Next we need to discover the GUID of the patch we are trying to uninstall. To do this we will want to look at the properties of the MSP file that is contained within the patch .exe.
First we will need to extract the MSP(s) from the patch executable.
The method to extract the contents from Office patches has changed since Office 2003.
To extract the contents from 2003 patches- I will download the Office 2003 patch from KB2464588 as an example. (office2003-KB2464588-FullFile-ENU.exe) For Office 2003 patches we will need to extract the MSPs from the executable using an extraction command like so to extract the MSPs from this patch executable to the c:\temp directory: office2003-KB2464588-FullFile-ENU.exe /c /t:c:\temp
To extract the contents from 2007 patches- I will download the Office 2007 patch from KB2464594 as an example. (PowerPoint2007-KB2464594-fullfile-x86-glb.exe) For Office 2007 patches we will need to extract the MSPs from the executable using an extraction command like so to extract the MSPs from this patch executable to the c:\temp directory: PowerPoint2007-KB2464594-fullfile-x86-glb.exe /extract:c:\temp
Now that we have the MSP from the patch executable we need to find the GUID of the patch.
We can find this by right clicking on the msp and going to properties. We will be looking for the revision number. Sometimes there will be a lot of numbers in the revision number section. Copy/paste the list of revision numbers into notepad, and delete all but the first one. The first number in the list of revision numbers is the GUID. *note* - In Vista you will not be able to find the GUID this way.
So using the POWERPNT.MSP file from KB2464588 as an example we discover that the GUID for this patch is {AB0D3DA9-FC93-4F57-ADE2-B6669749B25E} because that is the first number in the revision number properties.
From Windows XP:
From Windows 7:
So now we know that the Office 2003 suite GUID in my example is {90110409-6000-11D3-8CFE-0150048383C9}, and we know that the GUID for the Office 2003 patch from KB2464588 is {AB0D3DA9-FC93-4F57-ADE2-B6669749B25E}. So the command that could be used to programmatically remove this patch would be:
%windir%\System32\msiexec.exe /package {90110409-6000-11D3-8CFE-0150048383C9} /uninstall {AB0D3DA9-FC93-4F57-ADE2-B6669749B25E} /qn
*note* You could use /qb for an automated uninstall with a progress bar, or use /qn for a totally silent uninstall.
We found that the GUID for Office 2007 in my example above was {90120000-0011-0000-0000-0000000FF1CE}, and the GUID for the Office 2007 patch KB2464594 is {E6B7C11E-21E9-4BA0-9677-29AD603B953C}.
So the command that could be used to programmatically remove this Office 2007 patch would be:
%windir%\System32\msiexec.exe /package {90120000-0011-0000-0000-0000000FF1CE} /uninstall {E6B7C11E-21E9-4BA0-9677-29AD603B953C} /qn
FAQ-
How can we determine if the patch is installed programmatically if we know the GUID of the patch? A- This can be done once we convert the patch GUID to a compressed GUID. (How to convert an Office GUID, or Office patch GUID to a compressed GUID) Then query for the compressed GUID at this registry location:
HKEY_CLASSES_ROOT\Installer\Patches\
So for example the patch GUID for KB2464588 is {AB0D3DA9-FC93-4F57-ADE2-B6669749B25E}. Once converted we find that the compressed GUID is 9AD3D0BA39CF75F4DA2E6B6679942BE5.
So if KB2464588 is installed the following registry key would exist:
HKEY_CLASSES_ROOT\Installer\Patches\9AD3D0BA39CF75F4DA2E6B6679942BE5
Is it possible to uninstall a patch that is not natively uninstallable? A- While it is not recommended, nor supported by Microsoft it is possible to uninstall patches that are marked as not uninstallable. Once again we will need to convert the patch GUID to a compressed GUID. (How to convert an Office GUID, or Office patch GUID to a compressed GUID) Using the same example above we know that KB2464588 has a compressed GUID of 9AD3D0BA39CF75F4DA2E6B6679942BE5. The registry key that determines whether or not this patch is uninstallable will be located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\[Office guid]\Patches\9AD3D0BA39CF75F4DA2E6B6679942BE5
"Uninstallable"=dword:00000001
If the patch is not uninstallable natively, it would be possible to change the "Uninstallable" value at this registry location to “1” and then the patch would be available to uninstall.
We have a patch that has multiple MSP files inside of it. Is this normal? Would we need to uninstall them all? A- It is not uncommon for Office patches to contain multiple MSP files. If you wanted to completely remove the patch you would need to uninstall each of the MSPs. It is also not uncommon for Office patches to apply to multiple products and as such show up multiple times in Add/Remove. In these cases to completely remove the patch you would need to run the uninstall command targeting the GUID for each Office product that has the patch installed.
When Office products are downloaded from the Volume License Service Center they come down as .ISO files. .ISO is not a file format that Windows can open natively.
An ISO file is an image of a CD/DVD. Typically you would be able to use a burning program like Nero, or ImgBurn, to then burn that ISO file directly to a disk.
How do I use .ISO files?
Once you have downloaded an .ISO file, there are several possible options you can use to install the software:
The purpose of this blog will be to demonstrate the usage of my favorite third party freeware program that can be used to “mount” the ISO file and allow the extraction of the contents.
As you can see there are many programs that we could use to extract the contents from ISO files, but there are few reasons that I prefer Pismo File mount.
- Free - Easy to use - Non invasive
Let me demonstrate how I use Pismo File Mount to extract the contents from an Office ProPlus 2010 ISO I downloaded from the VLSC.
1. Downloaded and ran the installer for Pismo File Mount Audit Package. 2. After the installation, I right click on the ISO file that I had downloaded and choose “Mount Image”
3. After mounting the image you will notice that the icon for the ISO has changed and how looks like this:
We can now double click on this and it will open like so:
Now we will want to select all and copy the contents to another local folder on the machine.
4. After I have copied the contents to another folder on the machine, I will “unmount” the ISO so that it is no longer in use by Pismo File Mount.
Now that I have the contents extracted I can delete the ISO and copy the contents to a network share, burn to a disc, or copy to a thumbdrive for installation on other machines. At this point I uninstalled Pismo File Mount. Note: While this blog article is written with ISO files in mind, it also pertains to .IMG files.
There are a couple common scenarios that occur that can cause an invalid product key error with Office 2010 volume license edition when attempting to install the VL MAK key.
1. After purchasing a Volume License edition of Office 2010, when entering the key that came with the discs that were sent in the mail, you get invalid product key.
2. After installing the Volume License edition of Office 2010 and entering the MAK product key that you obtained from the Volume License Service Center you get invalid product key error
First it is important to understand that 32 bit versions of Office 2010 that are volume license will not ask you for a product key during the installation. Both of the scenarios above assume that you have already installed Office 2010 VL, and are now trying to enter the product key post installation by clicking on “change key”.
Issue #1 When you purchase Office 2010 from a Volume License retailer and you opt for physical media to be sent to you, you will find that it comes with 3 discs and a product key.
After you install Office 2010 successfully and try to input the product key that comes with the media you will get an invalid key error. The reason for this is because the product key that ships with the media is for “Office Web Apps” and not in fact for Office 2010 ProPlus.
To obtain the VL MAK key for Office 2010 you will need to logon to the Volume License Service Center. After you purchased your Volume License version of Office 2010, you should have received an email from the Volume Licensing Service Center (msvlop@microsoft.com) welcoming you to register at the VLSC. You will need to find this email, and login to the VLSC and obtain your VL MAK key from there. If you didn’t receive this email and you expect that you should have, or need assistance logging on to the VLSC you can call the following number for VLSC support (866-230-0560 Option 3) They should be able to pull up your VL agreement using the email address or company name of the purchaser.
Issue #2
After installing the Volume License edition of Office 2010 and entering the MAK product key that you obtained from the Volume License Service Center you get invalid product key error.
It is not uncommon for folks to install the volume license version of Office 2010 on a machine without first uninstalling the preinstalled OEM version of Office 2010 from the machine. Then when running Microsoft Office 2010 from the start menu they are actually launching the OEM version of Office 2010 rather than the VL Standard/Proplus version. The Office 2010 OEM version has an icon that looks like this:
If you are clicking on this icon, it is expected that your VL MAK key would give you an invalid key error message, because the OEM version is being run and that version will not accept a VL key.
Solution- Check programs and features in the control panel, and ensure that you only have one entry for the Office 2010 suite. Uninstall the OEM version of the Office 2010 suite.
Here is an example of what Programs and Features will look like when the OEM version is installed along side the Office 2010 ProPlus VL version.
The entry above that says “Microsoft Office 2010” is the OEM version of Office 2010 and will not accept a VL product key. Since you installed the Volume License version of Office 2010 Standard/ProPlus feel free to uninstall the version that is labeled “Microsoft Office 2010”.
After you uninstall the OEM version of Office 2010 now you can click on start, programs, Microsoft Office, and click on an Office application. (IE Word, Excel). Then you can input the MAK key by going to file, and help inside the application and choosing Change Product Key.
Sometimes you cannot uninstall the existing 2003, 2007 or 2010 Microsoft Office suite on your computer by using the Add or Remove Programs feature in Control Panel of Windows XP or the Programs and Features feature in Control Panel of Windows Vista/Win7. To help with this Microsoft has created Fix it utilities at http://support.microsoft.com/kb/971179. Office uninstallation can fail if any of these are true:
These fix it utilities can remove Office 2003-2010 products regardless of the current health of Office. These fix it utilities are provided as MSI files and run automatically without user invention. This is a good solution for folks that have a single machine that cannot uninstall the Office Suite under normal conditions. There are some limitations to the fix it solutions however. Because it is automatic, the end user cannot specify which products to remove, and the MSIs will only remove Office Suites. It will not help with the removal of standalone products. Also, the fix its lack the ability to be automated. So if you needed to run these on multiple machines, you would need to do so manually.
Fortunately, the VBS engine that the fix it uses can be obtained from the fix it and can then be automated.
Instructions to obtain Offscrub.vbs from the fix it utilities:
1. Download the fix it for the appropriate version of office, and run it. 2. Agree to the EULA and click next. 3. When you get to this screen stop and browse to the %temp% directory.
4. Find the Fixit directory in the %temp% directory and copy it to the desktop
5. You can now cancel the Fixit utility. Browse to the Fixit folder you copied to the desktop, and inside you will find offscrub.vbs. (OffScrub07.vbs in my example since I ran the Fixit for Office 2007)
Now that we have obtained the Offscrub07.vbs script from the Office 2007 Fixit, we can run it manually outside of the Fixit. We can also automate it’s usage from a command line with a variety of variables.
If you run the Offscrub2007.vbs script manually, by double-clicking or by calling it with cscript without any switches you will be presented a screen like the following:
In my example screenshot we can see that Offscrub found Access 2007 Standalone, Office 2007 Standard, and Visio Standard 2007 are installed. If I click ok on this screen the way it is, Offscrub will remove all three products from the machine. If I only wanted to remove Visio, I would remove everything in this box except VISSTD and click ok.
Using this manual method you can use Offscrub to remove Office 2007 standalone products, which you would not be able to do if you were running the Fixit alone.
If you want to automate Offscrub you can do so via command line.
Usage: OffScrub07.vbs [List of config ProductIDs] [Options]
/? ' Displays the help /Force ' Enforces file removal. May cause data loss! /S ' Does not search the local hard drives for shortcuts (*NOTE* The help file lists /SkipShortcutDetection as a valid switch to skip shortcut detection but this is incorrect. Use /S instead.) /Log [LogfolderPath] ' Custom folder for log files /NoCancel ' Setup.exe and Msiexec.exe have no Cancel button /OSE ' Forces removal of the Office Source Engine service /Q ' Setup.exe and Msiexec.exe run quiet with no UI /Preview ' Run this script to preview what would get removed
Examples: OffScrub07.vbs CLIENTALL ' Remove all Office 2007 Client products OffScrub07.vbs SERVER ' Remove all Office 2007 Server products OffScrub07.vbs ALL ' Remove all Office 2007 Server & Client products OffScrub07.vbs ProPlus,PrjPro ' Remove ProPlus and Project Stages of the script =============== - Basics : Non customizable tasks - Stage 1: Component detection. Builds a list of files which are installed/registered to a product that's going to be removed. Depending on the amount of applications that are removed - this can be a very time consuming task. "/Bypass 1" allows to bypass this detection. - Stage 2: Remove products with Setup.exe - Stage 3: Remove products with direct calls to Windows Installer - Stage 4: CleanUp - scrub files and registry settings that remained from the previous stages. In combination with 'Stage 1' this is the core of the removal concept.
Usage Examples ============== - "Safe" (Similar to calling setup.exe) OffScrub07.vbs ALL /Bypass 1,3,4 OffScrub07.vbs ALL /Bypass 1,3,4 /Quiet OffScrub07.vbs ProPlus /Bypass 1,3,4 /Quiet - "Preview" OffScrub07.vbs ALL /Preview OffScrub07.vbs ALL /Bypass 2 /Preview
Note: The preview option will not give the same results as the true removal. Still useful to get a good picture of what will be removed on the client
- "Quiet" OffScrub07.vbs ALL /Quiet
Note: The CMD output window will still receive all messages but the UI for Setup and Msiexec tasks will be suppressed.
- "NoCancel" OffScrub07.vbs ALL /NoCancel
Note: Setup and Msiexec tasks have no "Cancel" option
So if we were going to script the automation of Office 2007 ProPlus so that the uninstallation was silent, and couldn’t be cancelled, we would run a command like so:
cscript offscrub2007.vbs ProPlus /Q /NoCancel /BYPASS 1
I would advise that when automating Offscrub you skip the component detection (Stage 1) . You do this by using “/Bypass 1”. The reason is because I have seen instances where component detection causes third party products to attempt repair. Usually this is not big deal, but if the third party product is in an unhealthy state (for example it’s missing it’s cached MSI) than it will prompt the user to locate the MSI and thus stall Offscrub. Obviously not desired if we are looking to automate the removal with no user intervention.
FAQ- How can we remove the black window that populates when Offscrub is run? A- If the command prompt screen is closed while offscrub is running it will fail to continue. We can prevent that by hiding the command prompt window. Edit the the Offscrub.vbs file and find for the following code at the bottom of the script:
We have elected to use the Offscrub method and hide the CMD prompt window that Offscrub populates, but now find that there is no message to the user that the Office installation is taking place. Can we generate a notice to the users so they know that Office is being installed, and don’t try to shut down or disconnect the PC in the middle of the install? A- It is not uncommon for folks to want to disable the command prompt window that Offscrub generates, because if that command prompt window is closed by the end user, then Offscrub will not complete.
You can launch a custom IE window or a CMD window to act as the user notification if you wish. As an example, you could add the following to launch a nice notice to the user:
start "----NOTICE----" cmd.exe /t:ec /Q /k "echo OFFICE 2010 IS BEING INSTALLED. THIS WINDOW WILL CLOSE WHEN COMPLETE&&prompt $h"
Then after the install completes, close the CMD notification with: XP taskkill /IM cmd.exe /FI "WINDOWTITLE EQ ----NOTICE----" Win7 taskkill /IM cmd.exe /FI "WINDOWTITLE EQ Administrator: ----NOTICE----" The shortcut detection seems to take a long time. Can it be avoided? A- Yes. The shortcut detection will try to scan all drives on a machine for the Office shortcuts that align with the product being removed. This can be skipped by use a “/s” option switch when running Offscrub.
When automating the removal of Office 2007, we need to call setup.exe to perform the work. Because Office 2007 is a multi-msi based product we cannot use msiexec for the installation, nor the uninstallation of Office 2007.
http://technet.microsoft.com/en-us/library/cc982159(office.12).aspx#BKMK_UninstallProd
To run Setup.exe to remove a specified Office product from the user’s computer, use the /uninstall command-line option, which uses the following syntax:
/uninstall [ProductID]
where:
[ProductID] is the value for the product that you want to modify. Look up the value of [ProductID] in the Setup.xml file for the product.
The following example shows how to use the /uninstall command to remove an Office Professional Plus 2007 installation. Office12 is the root of the network installation point for ProPlus:
\\server\share\Office12\setup.exe /uninstall ProPlus
In enterprise deployments, we recommend that you run a silent uninstall. To run a silent uninstallation of a Office 2007 product that requires no user interaction, you must modify the Config.xml file for the product that you want to uninstall and set the Display element's Level attribute to "none" (Display Level="none"), and then save the Config.xml file as UninstallConfig.xml. You may also want to prevent the reboot of the machine after the uninstallation. We can also set this in a custom Config.xml.
Example Uninstallconfig.xml:
<Configuration Product="ProPlus"><Display Level="none" CompletionNotice="no" /> <Setting Id="SETUP_REBOOT" Value="NEVER" /></Configuration>
<Display Level="none" CompletionNotice="no" /> <Setting Id="SETUP_REBOOT" Value="NEVER" />
To then uninstall Microsoft Office Professional Plus 2007 after you modify the Config.xml to set silent options, use the following command where \\server\share\Office12 is the path of the Office 2007 Professional Plus source files, and <pathtoUninstallConfig.xml> is the location of your modified Config.xml file for Office Professional Plus:
\\server\share\Office12\setup.exe /uninstall ProPlus /config <pathtoUninstallconfig.xml>\UninstallConfig.xml
When automating the uninstallation of Office 2003, we can call msiexec to perform the work from a command line.
Example syntax: msiexec /x {GUID} /qb
*note* You could use /qb for an automated uninstall with a progress bar, or use /qn for a totally silent uninstall. You could also use a /norestart switch to prevent a reboot of the machine after installation. The GUID for the Office 2003 products is different depending on which version of Office 2003 you are using. To find the GUID for Office 2003 products look at the following registry key:
Here is a screenshot of this registry key on my machine
So on my machine I can automate the silent uninstallation of Office 2003 via the following command line:
Msiexec /x {90110409-6000-11D3-8CFE-0150048383C9} /qn /norestart
There are a few upgrade options available when planning to move to Office 2010 from a previous version. Microsoft has a technet article that touches on these various options here:
Plan an upgrade to Office 2010 http://technet.microsoft.com/en-us/library/ee624354.aspx
One of the options that is discussed is performing uninstall-upgrades.
For a single machine this is pretty simple. Remove the previous version of Office via add/remove programs or KB290301, and then manually install Office 2010. For enterprise deployments though this gets to be trickier as these deployments will typically be automated. The purpose of this blog post is to demonstrate how to perform automated uninstall-upgrades.
The idea is that we will create a script that can automatically remove the previous version of Office, and then proceed to install Office 2010. To do this we need to first understand how to automate the removal Office 2003/2007.
There are two methods for automating the removal Office 2003/2007.
1. Uninstall Office using the supported uninstall command line How to automate the uninstallation of Office 2003 products via command line How to automate the uninstallation of Office 2007 products via command line 2. Uninstall Office by utilizing the Office removal tool. (Offscrub.vbs) How to obtain and use Offscrub to automate the uninstallation of Office products When choosing between which method to use for the automated removal of Office there are a couple things to consider. If you choose to remove Office 2003/2007 with the command line uninstall option, keep in mind that the uninstallation could fail if the health of the product is poor. IE… if the source cache directory is corrupt, or if cached patches are broken. If you are removing Office 2007 and are wanting to have the uninstallation be silent, and you want to prevent the reboot, you will need to create a config.xml that contains those options and have it accessible on a share to call via the uninstall command line.
If you choose to remove Office 2003/2007 via the Offscrub technique, be familiar with the switches available for Offscrub and the FAQ.
Now that we know how we can automate the removal of Office 2003/2007 and we have decided on a method, we just need a script that can perform the uninstall actions, and then the install actions for Office 2010. For my examples below I am modifying the script from the technet article entitled Deploy Office 2010 by using Group Policy computer startup scripts. http://technet.microsoft.com/en-us/library/ff602181.aspx *note* If you decide to use GPO to deploy, make sure that you are familiar with the above article as there are some other considerations. If you use this script, ensure that your share for Office 2010 doesn’t have any spaces. ie.. \\server\share\Office14 If you are deploying this script via a deployment mechanism that utilizes the SYSTEM account, make sure the system account can access the shares that are specified in the script.
In the example below, the script will first check to see if Office 2010 is installed, if it is not it will automate the removal of Office 2003/2007 via the uninstall command line, and then perform the installation of Office 2010. Check for Office 2010, if not installed, uninstall Office 2007 via command line, and then after that is finished, install Office 2010. uninstall-upgrade.bat
setlocal REM ********************************************************************* REM Environment customization begins here. Modify variables below. REM ********************************************************************* REM Get ProductName from the Office product's core Setup.xml file, and then add "office14." as a prefix. set ProductName=Office14.PROPLUS REM Set DeployServer to a network-accessible location containing the Office source files. set DeployServer=\\server\Office2010SourceFiles REM Set ConfigFile to the configuration file to be used for deployment (required) set ConfigFile=\\server\Office2010SourceFiles\ProPlus.WW\config.xml REM Set LogLocation to a central directory to collect log files. (the user doing the install needs write access) set LogLocation=\\server\Office2010LogFiles REM ********************************************************************* REM Deployment code begins here. Do not modify anything below this line. REM ********************************************************************* IF NOT "%ProgramFiles(x86)%"=="" (goto ARP64) else (goto ARP86) REM Operating system is X64. Check for 32 bit Office in emulated Wow6432 uninstall key :ARP64 reg query HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432NODE\Microsoft\Windows\CurrentVersion\Uninstall\%ProductName% if NOT %errorlevel%==1 (goto End) REM Check for 32 and 64 bit versions of Office 2010. (Office 64bit would also appear here on a 64bit OS) :ARP86 reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%ProductName% if %errorlevel%==1 (goto DeployOffice) else (goto End) REM If 1 returned, the product was not found. Run setup here. :DeployOffice start /wait \\server\share\Office12\setup.exe /uninstall ProPlus /config \\server\share\UninstallConfig.xml start /wait %DeployServer%\setup.exe /config %ConfigFile% echo %date% %time% Setup ended with error code %errorlevel%. >> %LogLocation%\%computername%.txt REM If 0 or other was returned, the product was found or another error occurred. Do nothing. :End Endlocal
If we wanted to use Offscrub.vbs to perform the uninstall we could use the same script and just change the uninstall line for Office 2007 to use offscrub rather then the uninstall command line. Check for Office 2010, if not installed, uninstall Office 2007 via Offscrub2007.vbs, and then after that is finished, install Office 2010.
uninstall-upgrade.bat
setlocal REM ********************************************************************* REM Environment customization begins here. Modify variables below. REM ********************************************************************* REM Get ProductName from the Office product's core Setup.xml file, and then add "office14." as a prefix. set ProductName=Office14.PROPLUS REM Set DeployServer to a network-accessible location containing the Office source files. set DeployServer=\\server\Office2010SourceFiles REM Set ConfigFile to the configuration file to be used for deployment (required) set ConfigFile=\\server\Office2010SourceFiles\ProPlus.WW\config.xml REM Set LogLocation to a central directory to collect log files. (the user doing the install needs write access) set LogLocation=\\server\Office2010LogFiles REM ********************************************************************* REM Deployment code begins here. Do not modify anything below this line. REM ********************************************************************* IF NOT "%ProgramFiles(x86)%"=="" (goto ARP64) else (goto ARP86) REM Operating system is X64. Check for 32 bit Office in emulated Wow6432 uninstall key :ARP64 reg query HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432NODE\Microsoft\Windows\CurrentVersion\Uninstall\%ProductName% if NOT %errorlevel%==1 (goto End) REM Check for 32 and 64 bit versions of Office 2010. (Office 64bit would also appear here on a 64bit OS) :ARP86 reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%ProductName% if %errorlevel%==1 (goto DeployOffice) else (goto End) REM If 1 returned, the product was not found. Run setup here. :DeployOffice call cscript \\server\share\Offscrub07.vbs ProPlus /bypass 1 /q /s /NoCancel start /wait %DeployServer%\setup.exe /config %ConfigFile% echo %date% %time% Setup ended with error code %errorlevel%. >> %LogLocation%\%computername%.txt REM If 0 or other was returned, the product was found or another error occurred. Do nothing. :End Endlocal
These are example batch files. You could certainly create a VBS script, or use any other method of deployment that follows the same logic. #1. Uninstall Office 2003/2007 using one of the available methods for automated uninstallation #2. Wait for the uninstallation to complete. #3. Install Office 2010.
FAQ Will user settings still migrate if we are removing the previous version of Office 2003/2007 prior to installing Office 2010? A- Any user settings that would migrate during a typical upgrade would still migrate when performing an uninstall-upgrade. The user settings will migrate upon the first user of each Office 2010 application. http://technet.microsoft.com/en-us/library/ee624354.aspx#section2 The registry keys that are included or excluded when you use the in-place upgrade or the uninstall-upgrade option to migrate Microsoft Office 2003 or Office 2007 user data to Microsoft Office 2010 are listed in the following article. http://technet.microsoft.com/en-us/library/ee624352.aspx
We are pushing the uninstall-upgrade using a deployment method that will perform the installation while a user is logged on to the machine. We have elected to use the Offscrub method and hide the CMD prompt window that Offscrub populates, but now find that there is no message to the user that the Office installation is taking place. Can we generate a notice to the users so they know that Office is being installed, and don’t try to shut down or disconnect the PC in the middle of the install? A- It is not uncommon for folks to want to disable the command prompt window that Offscrub generates, because if that command prompt window is closed by the end user, than Offscrub will not complete. See Offscrub FAQ
Then after the install completes, close the CMD notification with: XP taskkill /IM cmd.exe /FI "WINDOWTITLE EQ ----NOTICE----" Win7 taskkill /IM cmd.exe /FI "WINDOWTITLE EQ Administrator: ----NOTICE----" So the portion of the install code above would look like this:
:DeployOffice start "----NOTICE----" cmd.exe /t:ec /Q /k "echo OFFICE 2010 IS BEING INSTALLED. THIS WINDOW WILL CLOSE WHEN COMPLETE&&prompt $h" call cscript \\server\share\Offscrub07.vbs ProPlus /bypass 1 /q /s /NoCancel start /wait %DeployServer%\setup.exe /config %ConfigFile% taskkill /IM cmd.exe /FI "WINDOWTITLE EQ ----NOTICE----" taskkill /IM cmd.exe /FI "WINDOWTITLE EQ Administrator: ----NOTICE----" echo %date% %time% Setup ended with error code %errorlevel%. >> %LogLocation%\%computername%.txt
*note* I am using taskkill twice in my example to ensure that the notice window would close correctly in WinXp or Win7. (cmd.exe operates slightly different in newer operating systems). It is expected that one of the lines will fail silently.
This blog will cover techniques on how to identify and resolve Office installation failures. The techniques described can be applied to the installation of Office 2003-2010, and Office patches.
ENABLE VERBOSE LOGGING The first thing to do when troubleshooting Office install failures is to ensure that MSI verbose logging is enabled. In Office 2007/2010 there is a setup.exe log file that gets created by default, but it does not give the amount of detail that is usually required to diagnose an installation failure. With verbose MSI logging enabled we will get a verbose log file for each component that Office 2007/2010 installs. We will have a verbose log for the install of the Word component, one for Excel, and so on.
To enable verbose logging you will want to set the following registry keys.
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer] "Debug"=dword:00000007 "Logging"="voicewarmup"
If you would prefer to automate the addition/removal of these keys rather than adding them manually via regedit you can use the fixit programs from the following KB article: http://support.microsoft.com/kb/958052 *note* This fix it will also enable verbose logging for the windows updates site but troubleshooting windows update will not be covered in this blog article. We should also enable verbose logging for the setup.exe log as well. This is done by adding the following line to the config.xml that is in the .ww folder of the product you are attempting to install. (This does not apply to versions of Office that are earlier than Office 2007) <Logging Type="verbose” Path="%temp%" Template="Microsoft Office Standard Setup(*).txt" />
For more information on the configuration of the config.xml see here.
PERFORM THE INSTALLATION ATTEMPT
If you are running your installation manually on the machine as a logged in user by double clicking on setup.exe then the log files will get generated in the %temp% directory of the user performing the installation. The easiest way to get there: Winxp-2003 = Click on start, then goto run, and type in %temp% and hit enter. Windows Vista-Win7 = Click on start, and the type in %temp% in the search field and hit enter.
If you are running your installation via a deployment mechanism that utilizes the system account during the install, then the log files will get generated in %windir%\temp. Now that you have enabled verbose logging and know where to look for the logs, go ahead and reattempt your installation. It it failed previously, expect it to fail again but this time we are ready to capture log files that will be detailed enough to help us diagnose the failure point.
ANALYZING THE LOGS After your install attempt you will find that you have somewhere between 1 and 20 logs from the installation attempt in your temp directory.
Here is a screenshot of the verbose logs from an install attempt from my machine.
When looking through the MSI logs we will typically want to look for a value 3 entry in the logs. Windows installer returns codes during the install which will indicate if a particular function was successful or not. Value 1 = Success Value 2 = Cancel Value 3 = Error
In a good install, you would typically not see any value 3 entries in the logs. So there are a lot of logs here to look at. I would recommend that we start with the setupexe log. This log will usually have a value 3 in it when there is a failure, but will not always be clear enough to diagnose the issue. If it doesn’t have a value 3 look for the first instance of Rolling back package. Rolling back package indicates that the Office installation had failed and now is attempting to “roll back” the installation. You should be able to identify the failure immediately above that point. Once you find the value 3 or the Rolling back package in the setup.exe log you should be able to identify which component is failing, and from there look for the particular MSI log that corresponds with that component. There will often be more than one value 3, or rolling back package. You should focus on the first one you find. Below you will find a couple real life examples of office installation failures and how we were able to identify the failure point. ANALYZE LOGS EXAMPLE 1 – Proplus 2010 install In this example, I will search the setup log for a value 3. It is not uncommon to not find a value 3 in the setup log. In this case I didn’t get a value 3 in the setup.exe log, so next I searched the setup.exe log for Rolling back package. Here is what I found:
Error: Failed to install product: C:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C\ProPlusWW.msi ErrorCode: 1603(0x643).
Log level changed from: Standard to: Verbose Rolling back chain 08/30/2010 14:12:56 Rolling back package: ProPlusWW
This does not tell me why it failed, but it does tell me that the failure occurred during the install of the ProPlusWW.msi. Now that I know that I want to find the verbose MSI log that correlates with ProPlusWW.msi. *note* In cases where you know the failure is in the ProPlusWW.msi log but you don’t want to save time in finding which MSI log is for Proplus, it will usually be the largest log file.
If you don’t know which log is the correct log for the ProPlusWW.msi component, open each log one at a time and scroll to the bottom. It will indicate there what component it just attempted to install/rollback.
For example, from the bottom of the MSIb0bc7.LOG: MSI (s) (50:CC) [14:24:12:332]: Note: 1: 1724 MSI (s) (50:CC) [14:24:12:332]: Product: Microsoft Office Outlook MUI (English) 2010 -- Removal completed successfully. So this is the verbose MSI log for the Office Outlook MUI component and was from the rollback. (The install failure would have occurred earlier than this) Eventually I found the ProPlus log (it was the biggest one) and the log does indicates it is the proplus log here: ******* Product: C:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C\ProPlusWW.msi
I searched the log for a “value 3” and this time didn’t find one, but did see this at the bottom of the log when it ended abruptly:
MSI (s) (B0:14) [14:12:56:537]: Internal Exception during install operation: 0xc0000017 at 0x7C812AFB. MSI (s) (B0:14) [14:12:56:537]: WER report disabled for silent install. MSI (s) (B0:14) [14:12:56:537]: Internal MSI error. Installer terminated prematurely.
Out of memory. Shut down other applications before retrying. MSI (s) (B0:14) [14:12:56:537]: MainEngineThread is returning 1603
Now I have something to go off of. So I take this error and search the net for articles that may help with this error. http://www.bing.com/search?q=%22Internal+MSI+error.+Installer+terminated+prematurely%22&form=QBRE&qs=n&sk=
I end up finding this article which lists my error almost verbatim, mentions a known issue with Windows installer 4.5, and an available hotfix. http://support.microsoft.com/kb/972397/EN-US
Turns out that this particular machine is running WI 4.5. After installing the hotfix and rebooting, the install is successful.
ANALYZE LOGS EXAMPLE 2 - Access 2010 standalone install In this next example, again I didn’t find a value 3 in the setupexe log, so next I searched the setup.exe log for Rolling back package.
Here is what I found: Error: Failed to install product: C:\MSOCache\All Users\{91140000-0015-0000-0000-0000000FF1CE}-C\AccessRWW.msi ErrorCode: 1601(0x641).
Log level changed from: Standard to: Verbose Rolling back chain 12/14/2010 12:06:05 Rolling back package: AccessRWW Again, this does not tell me why it failed, but it does tell me that the failure occurred during the install of the AccessRWW.msi. Now that I know that I want to find the verbose MSI log that correlates with the AccessRWW.msi.
Looking through the log files I find the one for the AccessRWW.msi:
******* Product: C:\MSOCache\All Users\{91140000-0015-0000-0000-0000000FF1CE}-C\AccessRWW.msi
I search it for value 3 and found: CAInitSPPTokenStore.x86: OMSICA : Initializing CustomAction CAInitSPPTokenStore.x86 CAInitSPPTokenStore.x86: Error: Failed to initialize the SPP Token store. HResult: 0x80070057. CAInitSPPTokenStore.x86: MSI (s) (2C:D0) [10:12:03:911]: User policy value 'DisableRollback' is 0 MSI (s) (2C:D0) [10:12:03:911]: Machine policy value 'DisableRollback' is 0 Action ended 10:12:03: InstallExecute. Return value 3.
This was resolved by ensuring that the network service is running, and that the following reg keys were present after ensuring the network service was running.
HKEY_USERS\S-1-5-20 AND HKEY_USERS\S-1-5-19
ANALYZE LOGS EXAMPLE 3 - ProPlus 2010 In this next example, I did find a value 3 in the setupexe log.
MSI(ERROR): 'Error 1304. Error writing to file: C:\WINDOWS\winsxs\Policies\x86_policy.8.0.Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_x-ww_5f0bbcff\8.0.50727.4053.policy. Verify that you have access to that directory.' Log level changed from: Standard to: Verbose Not showing message because suppress modal has been set. Title: 'Setup', Message: 'Error 1304. Error writing to file: C:\WINDOWS\winsxs\Policies\x86_policy.8.0.Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_x-ww_5f0bbcff\8.0.50727.4053.policy. Verify that you have access to that directory.' Message returned: 2 MSI(USER): 'Are you certain you want to cancel?' MSI(INFO): 'Action ended 14:03:01: InstallExecute. Return value 3.'
When you do see a value 3 in the setup.exe log it will sometimes give you enough information to resolve the issue without needing to look at the verbose MSI log. In this case the verbose MSI log simply repeated what we found in the setup.exe log as seen below.
MSI (s) (20:DC) [14:02:56:138]: Product: Microsoft Office Professional Plus 2010 -- Error 1304. Error writing to file: C:\WINDOWS\winsxs\Policies\x86_policy.8.0.Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_x-ww_5f0bbcff\8.0.50727.4053.policy. Verify that you have access to that directory.
Error 1304. Error writing to file: C:\WINDOWS\winsxs\Policies\x86_policy.8.0.Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_x-ww_5f0bbcff\8.0.50727.4053.policy. Verify that you have access to that directory. Are you certain you want to cancel? MSI (s) (20:DC) [14:03:01:646]: User policy value 'DisableRollback' is 0 MSI (s) (20:DC) [14:03:01:646]: Machine policy value 'DisableRollback' is 0 Action ended 14:03:01: InstallExecute. Return value 3.
In this case we should consider updating .net framework, and verifying the permissions in c:\windows\winsxs\
-BELOW ARE A FEW KNOWN ERRORS FROM VERBOSE LOGS AND POSSIBLE RESOLUTIONS TO TRY- *NOTE* Some of these suggestions discuss working with the registry. Important- Serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: 322756 (http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows
ERROR 1935 Error 1935. An error occurred during the installation of assembly component {89EDD3A9-944B-3257-8484-D6EB6A00DDF5}. HRESULT: 0x80070003. assembly interface: IAssemblyCache, function: CreateAssemblyCacheItem, assembly name: Microsoft.VC90.ATL,version="9.0.30729.4148",type="win32",processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b"
MSI (s) (1C:9C) [10:14:26:628]: User policy value 'DisableRollback' is 0 MSI (s) (1C:9C) [10:14:26:628]: Machine policy value 'DisableRollback' is 0 Action ended 10:14:26: InstallExecute. Return value 3.
ERROR 1913
Error 1913: Setup cannot update file C:/windows/win.ini. Verify that the file exists in your system and that you have sufficient permissions to update it
http://social.answers.microsoft.com/Forums/en-US/officeinstall/thread/f5f97e01-3b8a-4886-ad49-d11c279b1186
ERROR 1714 Error 1714. Setup cannot remove the older version of Microsoft Office Product_Name 2007. Contact Microsoft Product Support Services (PSS) for assistance. For information about how to contact PSS, seeC:\DOCUME~1\<username>\LOCALS~1\Temp\Setup00000d64\PSS10R.CHM.
ERROR 1719
Error 1719. Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact support personnel for assistance
-Reg keys could be corrupt or incorrect at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSIServer
Export from a known good machine that uses the same OS and msiexec version. Backup and then delete existing msiserver key on the bad machine under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\msiserver Import the reg file from the known good machine. Reboot, and reattempt install
-http://support.microsoft.com/kb/324516 -http://support.microsoft.com/default.aspx?scid=kb;en-us;315346&Product=winxp#kb4
ERROR 1406 'Error 1406.Setup cannot write the value to the registry key \CLSID\{13DE4A42-8D21-4C8E-BF9C-8F69CB068FCA}. Verify that you have sufficient permissions to access the registry or contact Microsoft Product Support Services (PSS) for assistance. For information about how to contact PSS, seeC:\Users\ADMINI~1\AppData\Local\Temp\Setup00000e64\PSS10R.CHM.'
Log level changed from: Standard to: Verbose MSI(INFO): 'Action ended 20:24:59: InstallExecute. Return value 3.'
Possible solution(s) This error indicates incorrect registry permissions. In the example above we would find incorrect reg perms on HKCR\CLSID\{13DE4A42-8D21-4C8E-BF9C-8F69CB068FCA}
ERROR 1920
Error 1920. Service 'Office Software Protection Platform' (osppsvc) failed to start. Verify that you have sufficient privileges to start system services.
Possible solution(s) This error indicates possible incorrect permissions on the OfficeSoftwareProtectionPlatform folder, or incorrect permissions on HKCR\APPID
1. To resolve this issue, give the Network Service account full control on the 'OfficeSoftwareProtectionPlatform' folder. http://support.microsoft.com/kb/2401987
2. To resolve this issue, compare the rights on HKCR\APPID from a good machine, with the problem machine. Try granting “RESTRICTED” the following permissions: Query Value, Enumerate Subkeys, Notify, Read Control
ERROR - IHxRegisterSession::CreateTransaction() returned 8004036e.
IHxRegisterSession::CreateTransaction() returned 8004036e. BeginTransaction() ERROR: Attempt failed because another transaction was running. Trying to Rollback current transaction ({2318682E-D486-40D6-8530-80CEEA1A16B5}) IHxRegisterSession::ContinueTransaction() returned 80004005. BeginTransaction() ERROR: Could not restart current transaction. BeginTransaction() ERROR: Could not Rollback current transaction. HelpFile registration will abort. Registration session {2318682E-D486-40D6-8530-80CEEA1A16B5} was *not* created. Action ended 14:30:54: InstallFinalize. Return value 3.
ERROR: FAILED TO REGISTER PLUGIN. HRESULT: 0x80070005 MSI (s) (08:6C) [12:32:40:502]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI4D4.tmp, Entrypoint: CAInstallSppPlugin CAInstallPlugin.x86: OMSICA : Initializing CustomAction CAInstallPlugin.x86 CAInstallPlugin.x86: Registering PlugIn 'C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\OSPPOBJS.DLL' 'C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\osppobjs-spp-plugin-manifest-signed.xrm-ms' CAInstallPlugin.x86: Error: Failed to register plugin. HResult: 0x80070005. CAInstallPlugin.x86: MSI (s) (08:58) [12:32:42:830]: User policy value 'DisableRollback' is 0 MSI (s) (08:58) [12:32:42:830]: Machine policy value 'DisableRollback' is 0 Action ended 12:32:42: InstallExecute. Return value 3.
Policy set on the problem machine (local or through GPO) that is misconfigured.
Opened Gpedit.MSC Computer configuration/Windows Settings/Security Settings/local policies/user rights assignment Ensure that everyone has rights on Bypass traverse Checking. (Everyone would be listed by default) http://support.microsoft.com/kb/823659
ERROR - Error 0x80070005: CAQuietExec Failed
CAQuietExec: "wevtutil.exe" im "C:\Program Files\Microsoft Office\Office14\BCSEvents.man" CAQuietExec: The publishers and channels are installed successfully. However, we can't enable one or more publishers and channels. Access is denied. CAQuietExec: Error 0x80070005: Command line returned an error. CAQuietExec: Error 0x80070005: CAQuietExec Failed CustomAction RegisterEventManifest returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (88:04) [15:15:03:285]: User policy value 'DisableRollback' is 0 MSI (s) (88:04) [15:15:03:285]: Machine policy value 'DisableRollback' is 0 Action ended 15:15:03: InstallExecute. Return value 3. Possible solution(s) This issue can occur because permissions have been incorrectly set on the folder: C:\Windows\System32\winevt\Logs Grant “everyone” full rights to that folder, and reattempt the install. If this is successful you can remove the everyone group afterwards.
ERROR - Error 0x800706b5: CAQuietExec Failed
CAQuietExec: "wevtutil.exe" im "C:\Program Files\Microsoft Office\Office14\BCSEvents.man" CAQuietExec: The publishers and channels are installed successfully. However, we can't enable one or more publishers and channels. The interface is unknown. CAQuietExec: Error 0x800706b5: Command line returned an error. CAQuietExec: Error 0x800706b5: CAQuietExec Failed CustomAction RegisterEventManifest returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (6C:84) [10:10:59:733]: User policy value 'DisableRollback' is 0 MSI (s) (6C:84) [10:10:59:733]: Machine policy value 'DisableRollback' is 0 Action ended 10:10:59: InstallExecute. Return value 3.
Possible solution(s) This issue can occur if the Windows Event Log service is not running. Click on start, search and type in services.msc and hit enter. Scroll down to the Windows Event Log service, and ensure it is set to automatic. If it is not running right click on it and choose start. If you get an error like the following:
Error 4201: The instance name passed was not recognized as valid by a WMI data provider.
Then please check the permissions on "c:\windows\system32\logfiles\wmi\RTbackup"
If the system account doesn’t have full control, grant the system account full control and reboot. After reboot check and see if the Windows Event Log service is started in services.msc. If it now started correctly attempt your Office 2010 install again.
KMS host key = This key is obtained from the VLSC. This is the key that you would use during the install of the KMS host when setting up a Office 2010 KMS server
KMS Client Key = This is a generic key that is hardcoded into all of the Office 2010 client products. ie.. ProPlus, Visio, Project. This key allows the product to be installed without manually entering a product key. Also, when this key is installed it triggers the Office product to attempt to locate and activate against a KMS server.
Volume license versions of Office 2010 are hardcoded with a generic KMS Client Key. This key can be located by opening the setup.xml file from the *.ww folder of the product.
As an example, here is the built-in KMS Client Key from the Visio 2010 volume license setup.xml
Visio is a unique product in the volume license space in that Visio can install as Visio Standard, Visio Professional, or Visio Premium based upon the key that is input. By default, Visio 2010 uses this Visio Premium 2010 KMS client key, which enables all the features that are available for Visio Premium 2010. If you are licensed to use Visio Standard 2010 or Visio Professional 2010, you must install the appropriate KMS client key. Different features or applications are available, depending on the kind of key that is installed. This makes it easier for you to upgrade or downgrade without having to deploy a different product edition. If your license agreement with Microsoft is for Visio Standard 2010 or Visio Professional 2010, use the appropriate Generic KMS client key shown in the following table.
Visio Standard 2010
767HD-QGMWX-8QTDB-9G3R2-KHFGJ
Visio Professional 2010
7MCW8-VRQVK-G677T-PDJCM-Q8TCP
Visio Premium 2010
D9DWC-HPYVV-JGF4P-BTWQB-WX8BJ
For information about how to plan your Visio Professional 2010 installation, see Plan customizations and options for Visio 2010.
There are two scenarios to consider for installing an appropriate KMS Client key.
Scenario 1 Visio 2010 has already been deployed in your organization. At the time of the deployment no key was specified and as a result everyone has Visio Premium installed although the organization is licensed for Visio Standard 2010 or Visio Professional 2010.
To downgrade these versions from Premium to Pro or STD, they will need to change the installed KMS Client key to the generic PRO, or STD key using a script that calls ospp.vbs , or by using VAMT. After the key is changed it will automatically activate against the KMS s host server, provided the KMS host is healthy and reachable.
Method 1 – Using a script that calls ospp.vbs on the machine to install a new KMS Client key. This script can be pushed out as a startup script via GPO to the affected machines. Here is a simple, example batch file script that I have used to install the Visio 2010 Client key for Standard edition post install. This should work on X86 and X64 machines. I have placed a registry key query in this script so that it checks for the existence of a registry key that does not exist natively, and then when the script runs it adds that dummy registry key. This way the next time the script runs (if deployed as a startup script for example) it will simply end when it locates the dummy key that had been added during the script’s previous run. OSPP.BAT
@echo off
if "%PROCESSOR_ARCHITECTURE%"=="x86" if "%PROCESSOR_ARCHITEW6432%"=="" goto x86 set ProgramFilesPath=%ProgramFiles(x86)% goto OSPP
:x86 set ProgramFilesPath=%ProgramFiles%
:OSPP reg query HKLM\Software\Microsoft\Office\14.0\Common\OSPPRUNONCE if %errorlevel%==1 (goto RUN) else (goto END)
:RUN C:\Windows\system32\cscript.exe "%ProgramFilesPath%\Microsoft Office\Office14\ospp.vbs" /inpkey:767HD-QGMWX-8QTDB-9G3R2-KHFGJ C:\Windows\system32\cscript.exe "%ProgramFilesPath%\Microsoft Office\Office14\ospp.vbs" /act REG ADD "HKLM\Software\Microsoft\Office\14.0\Common\OSPPRUNONCE"
:END Exit
Method 2 – Use the VAMT tool to install a different KMS Client key for Visio 2010 post install. For more information and a walkthrough of the Volume Activation Management tool
Scenario 2
Visio 2010 has not yet been deployed in the organization and we need to ensure that correct edition of Visio 2010 is deployed. If the organization is not licensed for Premium, they will either need to ensure that they modify the config.xml (in the visio.ww folder) and include the generic KMS client key for Pro or STD, or create a custom.msp file with the Office customization tool and specify the generic KMS client key for Pro or STD. After the install Visio will activate against KMS without issue if the KMS host is activated, healthy and has had the 5 minimum unique requests.
Method 1
Modify the config.xml to specify the KMS Client key to use. If we specify the KMS Client key for Standard edition in the config.xml file from the Visio.ww folder, than Visio will install with that KMS Client key instead of the built-in key for Premium.
As an example, here is a modified config.xml with the generic KMS Client key for Standard specified.
Method 2 Create a custom MSP file with the Office Customization Tool to specify the KMS Client key to use. If we specify the KMS Client key for Standard edition in the Office Customization Tool and save the custom MSP in the updates folder, Visio will install with that KMS Client key instead of the built-in key for Premium.
Open the Office Customization Tool by calling setup.exe with the /admin switch
In the OCT under the Licensing and user interface section, you can choose “Enter another product key” and input your generic Pro or STD KMS Client key.
After saving the custom MSP file from the Office Customization tool, make sure to place the custom MSP file in the updates folder of the Visio source. Now when your Visio installation takes place it will use the custom msp file you created in the updates folder and apply your generic Pro/STD key rather than the built in Premium key.
This is also discussed in the following technet article:
Deploy volume activation of Office 2010 http://technet.microsoft.com/en-us/library/ee624357.aspx
Thinking about deploying Microsoft Office 2010 in your environment? Curious about the how, when, and whys of a customized deployment of Office? Do you want your installation of Office to go as easily and smoothly as possible?
If the answer to any of the above questions is yes, you should consider attending one of the Office 2010 Deployment Workshops that will be delivered in cities around the country in the coming months.
These workshops are designed to provide customers with information necessary to design, deploy, customize and manage an Office 2010 installation through instructor-led training and hands-on labs. Instructors are members of the Microsoft Office Deployment Support team, who will draw upon years of real world experience while working with attendees to share tips/tricks/best practices, and engage in fruitful discussions.
Key Focus Areas: • Preparing to Deploy (Requirements, deployment overview, & 32/64-bit considerations) • New Features and Options (Ribbon UI, application changes, Click to Run & Office Web Applications) • Licensing and Activation (Overview, KMS/MAK, troubleshooting) • Multi-Lingual Deployment (Multilanguage pack, proofing tools & considerations) • Customizing the Office 2010 Installation (Office Customization Tool, config.xml files & policy templates) • Enterprise Deployment Methods (SCE/SCCM, Group Policy, Terminal Server, imaging & virtualization) • Troubleshooting and Maintenance (Setup.exe, logging, patching & maintenance) • Application Compatibility Tools (OMPM, OEAT & OCCI)
Recommended Audience: IT Professionals responsible for the deployment, maintenance, and troubleshooting of Office installations. Application-specific and/or help desk-type issues are not included in the scope of this offering.
Delivery Dates and Locations: • January 18-20, 2011 – Downers Grove, IL • January 25-27, 2011 – Alpharetta, GA • February 1-3, 2011 – Tampa, FL• February 8-10, 2011 – New York, NY • February 15-17, 2011 – Irvine, CA New dates and locations will be announced here as they become available.
Pricing: $1500 USD per person
To register or for more information:
• To register online, visit http://www.microsoft.com/events, click the Find Events and Webcasts link, and perform an advanced search using the following EventIDs or keywords "Office 2010 Deployment":
o Downers Grove, IL: 1032469733o Alpharetta, GA: 1032471261o Tampa, FL: 1032471263o New York, NY: 1032471264o Irvine, CA: 1032471267
• To register via email, send mail to ProfessionalServices@Microsoft.com and include the following information:
o Company Name o Attendee Name o Physical Address o Phone Number o Number of Attendees o Desired Event Location/Date
• To register via phone, call 1-888-875-9071
• Email inquiries to ProfessionalServices@Microsoft.com
If you are considering the deployment of a 64-bit version of Microsoft Office 2010, it is important to understand the differences between the 32 and 64-bit versions, and be aware of the deployment considerations.
See the following blog posts and TechNet articles for related information:
Microsoft Office Product Development Group blog post, Understanding 64-Bit Office http://blogs.technet.com/b/office2010/archive/2010/02/23/understanding-64-bit-office.aspx 64-bit editions of Office 2010 http://technet.microsoft.com/en-us/library/ee681792.aspx Deployment considerations http://technet.microsoft.com/en-us/library/ee681792.aspx#BKMK_DeploymentConsiderations Blocking and nonblocking Office applications in 64-bit installations http://technet.microsoft.com/en-us/library/ee681792.aspx#BKMK_AppsAffectingInstall
Microsoft Office Product Development Group blog post, Understanding 64-Bit Office http://blogs.technet.com/b/office2010/archive/2010/02/23/understanding-64-bit-office.aspx
64-bit editions of Office 2010 http://technet.microsoft.com/en-us/library/ee681792.aspx
Deployment considerations http://technet.microsoft.com/en-us/library/ee681792.aspx#BKMK_DeploymentConsiderations
Blocking and nonblocking Office applications in 64-bit installations http://technet.microsoft.com/en-us/library/ee681792.aspx#BKMK_AppsAffectingInstall
The images below are excerpts from a visual representation of the 64-bit Client Installation of Microsoft Office 2010, which can be found at http://go.microsoft.com/fwlink/?LinkId=168620.
By default when you install a volume license version of Office 2010 it will not ask for a product key. All Office 2010 client VL builds are pre-PID’ed with a single global product key. When you install Office 2010 VL without a product key it automatically enables Office to seek out a KMS host to activate against.
You may want to deploy Office 2010 VL with a MAK key however. When you deploy Office 2010 VL with a MAK key you may find that on first launch a user gets the activation screen like so.
You can attempt to avoid this screen by automating the MAK internet activation by adding the following line in the config.xml
<Setting Id="AUTO_ACTIVATE" Value="1"/>
*Note* Activation success will depend upon the internet status of the machine. Naturally if the machine (or the user that does the install) is not connected to the internet, or proxy info for that user is not setup correctly during the install the automatic activation attempt will fail.
When launching Office 2010 applications, a message appears indicating that Office is not activated. Attempts to activate Office may result in the following error:
"Error 0xC004F074: The Software Licensing Service reported that the computer could not be activated. No Key Management Service (KMS) could be contacted. Please see the Application Event Log for additional information."
Error 0xC004F074 equates to, "The Key Management Server (KMS) is unavailable". This error occurs when volume license versions of Office 2010 are installed on client machines using the built-in, KMS client key and an Office KMS host is not available to activate installations of Office 2010.
The following is a partial Office Web Apps Setup product key, required for product installation on Microsoft SharePoint, rather than a product key that is specific to client installations of the Office 2010 suites:
FC7HF-CF42G-xxxxx-xxxxx-xxxxx
Attempting to enter this key via the File/Help and Change Product Key link will result in the error, "This is not a valid Office Product key. See above examples to learn more".
Attempting to input this key via the ospp.vbs script will result in the error, "0xc004f050 The Software Licensing service reported that the product key is invalid"
To resolve this issue, obtain a Multiple Activation Key (MAK) volume license product key for Office 2010, and then do one of the following:
1) Open an Office 2010 application (i.e., Microsoft Word), go to File/Help, and then click on the Change Product Key link. Enter the Office 2010 product key. After the process of installing the product key completes, close all open Office applications, open Microsoft Word, go to File/Help, and check to see if “Product Activated” is displayed.
—or—
2) From an elevated command prompt, run command lines similar to the following (if you are running 32-bit Office 2010 on a 64-bit operating system, the path should include Program Files (x86)):
%windir%\System32\cscript.exe "C:\Program Files\Microsoft Office\Office14\OSPP.VBS" /inpkey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx (where xxxxx-xxxxx-xxxxx-xxxxx-xxxxx is your 25 digit MAK product key for Office 2010)
%windir%\System32\cscript.exe “C:\Program Files\Microsoft Office\Office14\ospp.vbs” /act
For most Microsoft products, there are two ways to obtain volume license product keys:
1) Go to the Product Keys section of the Volume Licensing Service Center (VLSC) for Open, Open Value, Select, Enterprise Agreements and the Services provider License Agreement (SPLA) - https://www.microsoft.com/licensing/servicecenter/home.aspx 2) Call your Microsoft Activation Center - http://www.microsoft.com/licensing/existing-customers/activation-centers.aspx
1) Go to the Product Keys section of the Volume Licensing Service Center (VLSC) for Open, Open Value, Select, Enterprise Agreements and the Services provider License Agreement (SPLA) - https://www.microsoft.com/licensing/servicecenter/home.aspx
2) Call your Microsoft Activation Center - http://www.microsoft.com/licensing/existing-customers/activation-centers.aspx
Related links:
Frequently asked questions: Volume activation of Office 2010
http://technet.microsoft.com/en-us/library/ff678211.aspx
Volume activation quick start guide for Office 2010
http://technet.microsoft.com/en-us/library/ee624359.aspx
Microsoft Volume Licensing Product Activation and Key Information
http://www.microsoft.com/licensing/existing-customers/product-activation.aspx
Microsoft Volume Licensing Frequently Asked Questions About Volume License Keys
http://www.microsoft.com/licensing/existing-customers/product-activation-faq.aspx
If you are running a volume licensed edition of Office 2010 and it needs to be activated, you may see this message when you open any Office 2010 application:
This message means Office is failing to activate against a KMS host on your network. KMS activation is the default activation type when you install a volume license edition of Office 2010. There are two ways of getting Office 2010 activated:
Option 1: Enter a MAK key and activate over the internet or phone
To enter a MAK key, click the “Change Product "Key” button and enter your key when prompted:
Click “Continue”, then “Install Now”.
Office will configure itself. Close any open Office 2010 applications. The next time you launch an Office application you will see a screen like this:
Go through the activation wizard. Once it is done you will be activated and should not see any of these messages again.
Option 2: Setup an Office 2010 KMS host and activate using it.
See this blog post for a very detailed guide on how to setup an Office 2010 KMS Host: http://blogs.technet.com/b/odsupport/archive/2010/06/01/office-2010-kms-installation-and-troubleshooting.aspx
Use the following steps to see detailed information about what type of activation your Office 2010 installation us using and what the status of your activation is.
If Office is KMS activated you will see “KMS_Client edition” in the license name field:
If Office is MAK activated you will see “MAK edition” in the license name field:
If Office is Retail activated you will see “Retail edition” in the license name field: