KB: Automation Error 0x8007007f when Invoking Exchange 2007 Powershell Cmdlets

  • Comments 2

...Here are the details of a new KB article I just submitted.  I will update this post when it is published...

 

Symptoms

 

When using CDOEXM to manage Exchange 2003 and Powershell cmdlets to manage Exchange 2007 in the same application you may come across the following error:

 

"Retrieving the COM class factory for component with CLSID {08D1AA55-704E-4397-AB29-55D2A3972BCB} failed due to the following error: 8007007f.”

 

This would typically be seen when calling Invoke on a System.Management.Automation Pipeline when automating a cmdlet such as Move-Mailbox.

 

…To indentify this issue use a couple simple WinDbg commands to identify if CDOEXM is loaded in the process and see where CDOEXM, EXCHMEM, and other dependencies are loading from as well as their version numbers.  Here are some of the commands I used and what the output was in the traces I saw.  Simply snap a hang dump or attach WinDbg to your application’s process and run these commands…

 

lmf – This command lists all the loaded modules and the file path they are loaded from.  Look for CDOEXM and EXCHMEM to see if they have been loaded yet and if so where they are loading from.  For Exchange 2000/2003 the path to Exchange components should be “C:\Program Files\exchsvr\bin” for Exchange 2007 it will be “C:\Program Files\Microsoft\Exchange Server\bin”.

 

 

lmvm [module name] – This will gives verbose output about a particular loaded module.  Use this to get the version number and path for a particular module like EXCHMEM.  Exchange 2000 binaries’ version numbers are 6.0.*, Exchange 2003 binaries are 6.5.*, and Exchange 2007 binaries are 8.0.*.  Be sure that Exchange system modules like ESE, EXCHMEM, PTTRACE, ADDRESS, and GLBLNAME match the version of Exchange you are testing…

 

Cause

 

This is caused when Exchange 2003 System Manager and Exchange 2007 Management Console are installed on the same application server for an application that is intended to manage Exchange 2003 and Exchange 2007.  Calls to Exchange 2003’s management API, CDOEXM, load the Exchange 2003 version of libraries such as EXCHMEM.dll into the application process.  When the Exchange 2007 cmdlets are used they end up using the already loaded Exchange 2003 library.  This causes the Exchange 2007 cmdlet to fail.

 

Resolution

 

To avoid this conflict Exchange 2003 CDOEXM should not be loaded in the same process where Exchange 2007 cmdlets will loaded or automated.

 

More Information

 

Exchange 2007 cmdlets should not be used to create or edit objects such as mailboxes or storage groups on an Exchange 2003 server.  CDOEXM and Exchange 2003 System Manager should be used to manage these servers.  For more information on managing Exchange 2003 in a coexistence environment with Exchange 2007 see the following articles on TechNet:

 

Managing Exchange 2003 Settings in a Coexistence Environment

http://technet.microsoft.com/en-us/library/aa995972.aspx

 

Planning for Coexistence

http://technet.microsoft.com/en-us/library/aa998186.aspx

 

For more information about automating Exchange 2007 Powershell cmdlets see the following article on MSDN:

 

Using Exchange Management Shell Commands With Managed Code

http://msdn2.microsoft.com/en-us/library/bb332449.aspx

  • I've put together a list of articles which cover common questions on Exchange Web Services (EWS). These

  • The easiest solution is to create a COM component and register that component with component services

Page 1 of 1 (2 items)