mstehle: The CDOs and CDONTS of Messaging Development : CDOEXM

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

mstehle — Tue, 03 Jul 2007 21:18:00 GMT

...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

HOWTO: Using CDOEXM in ASP.NET (.NET Framework 2.0 Walkthrough)

mstehle — Fri, 11 May 2007 22:13:00 GMT

I just finished updating a support document which walks through creating a simple COM+ component and ASP.NET page to illustrate how you have to use CDOEXM with ASP.NET due to impersonation limitations of CDOEXM...enjoy...

...Use all code in this post at your own risk, etc...

CDO for Exchange Management (CDOEXM) is a management API for Exchange 2000 and 2003. While using CDOEXM in an ASP or ASPX web application you may get unexpected Access Denied or Catastrophic Failure errors. This is because CDOEXM only supports process-level impersonation and not the thread-level impersonation required by a web application using Windows Integrated for example. Due to impersonation limitations of CDOEXM, the only method supported by Microsoft for using CDOEXM from ASP or ASPX is to create a COM component and register that component with component services (COM+) running the component in a specific user identity.

Below is a walkthrough of how to create a simple .NET component which wraps CDOEXM and ADSI code to create users and associate mailboxes. There is also a function to illustrate the security context of the component which you can compare to the context of your application. We will illustrate this difference in a simple ASP.NET web application.

Environment Setup

This walkthrough is based off of Exchange 2003 and Visual Studio 2005 running off of Windows 2003. The code in this walkthrough is C#.

This code should be run from a Windows Server 2003 client that has Exchange 2003 Administrative Tools installed if you are targeting Exchange 2003 or an Exchange 2000 server. If you are targeting an Exchange 2000 server, you could also use a Windows 2000 client that has Exchange 2000 Administrative Tools installed. The CDOEXM version that is included in Exchange 2003 must be used when you access Exchange 2003. The Exchange 2003 CDOEXM can also be used to access Exchange 2000. The CDOEXM library that is included in Exchange 2000 is not supported for accessing Exchange 2003.

Creating the C# Component

Build and configure a COM+ component to host the CDOEXM code and ensure that it is running with the credentials of a service account and not inheriting any credentials from the caller.

Create the project…

Start Visual Studio 2005
Select File->New->Project…
Under C#, select Windows
In the “Template Types” select “Class Library”
In the Name box type “CDOEXMComponent”
Click OK.
Add references to System.EnterpriseServices, System.DirectoryServices, CDOEXM (listed on the COM tab), and Active DS Type Library (also listed on the COM tab).

Sign and Create Interop Libraries for ActiveDS and CDOEXM…

1. Right click on the CDOEXMComponent project in the Solution Explorer and click properties. In the signing tab check the box to “Sign the assembly” and create a new strong name key called “CDOEXMComponent.snk”.

2. Still in the project properties window, select the Application tab and click “Assembly Information…”, check the box that says, “Make assembly COM-Visible”.

3. Open the AssemblyInfo.cs and add “using System.EnterpriseServices;” to the top and the following lines at the bottom of the file…

[assembly: ApplicationActivation(ActivationOption.Server)]

[assembly: ApplicationName("CDOEXMComponent")]

[assembly: Description("Simple CDOEXM Component Sample")]

Add the CDOEXMSample class…

Select the “Solution Explorer” view tab.

Rename the class1.cs file to “CDOEXMSample.cs”.

Remove the code generated by the Wizard.

Cut and past the code provided below:

using System;

using System.Collections.Generic;

using System.DirectoryServices;

using System.EnterpriseServices;

using System.Runtime.InteropServices;

using System.Text;

using ActiveDs;

using CDOEXM;

public class CDOEXMSample:

System.EnterpriseServices.ServicedComponent

{

public void CreateUserWithMailbox(string strFirstName,

string strLastName, string strSamName,

string strBaseContainer, string strHomeMDB)

{

// Start local variable definitions

DirectoryEntry oCont =

new DirectoryEntry("LDAP://" + strBaseContainer);

IADsContainer oDSCont = null;

IADsUser oUser = null;

IMailboxStore oMailBox = null;

try

{

oDSCont = oCont.NativeObject as IADsContainer;

oUser = oDSCont.Create("user",

string.Format("CN={0} {1}",

strFirstName, strLastName)) as IADsUser;

oUser.Put("sn", strLastName);

oUser.Put("givenname", strFirstName);

oUser.Put("samaccountname", strSamName);

oUser.SetInfo();

oUser.AccountDisabled = false;

oUser.SetInfo();

oMailBox = oUser as IMailboxStore;

oMailBox.CreateMailbox(strHomeMDB);

oUser.SetInfo();

}

finally

{

oCont.Dispose();

if (oDSCont != null)

{

Marshal.ReleaseComObject(oDSCont);

oDSCont = null;

}

if (oUser != null)

{

Marshal.ReleaseComObject(oUser);

oUser = null;

}

if (oMailBox != null)

{

Marshal.ReleaseComObject(oMailBox);

oMailBox = null;

}

public string GetIdentity()

{

AppDomain.CurrentDomain.SetPrincipalPolicy(

System.Security.Principal.PrincipalPolicy.WindowsPrincipal);

System.Security.Principal.WindowsPrincipal user =

System.Threading.Thread.CurrentPrincipal

as System.Security.Principal.WindowsPrincipal;

return user.Identity.Name;

}

Create and Configure the COM+ Component

1. Build the CDOEXMComponent project in Visual Studio

2. From the Visual Studio command prompt run “regsvcs CDOEXMComponent.dll”

3. Open “Component Services” from “Administrative Tools”

4. Under “Component Services”, “Computers”, “My Computer”, “COM+ Applications”, find “CDOEXMComponent” and right click on it then select “Properties”

5. On the security tab:

a. Under “Authorization” uncheck “Enforce access checks for this application”

b. Select “None” for “Authentication Level for Calls”

c. Select “Identify” for “Impersonation Level”

6. On the identity tab:

a. Configure “This user” as an account that has Exchange Admin privileges on your Exchange server. You could use the Administrator account for testing purposes.

7. Click OK

Create Web Application to Consume CDOEXMComponent

Create a folder and application files

1. Create a folder called “CDOEXMComponent” on the file system of your web server. For example, “C:\inetpub\wwwroot\CDOEXMComponent”.

2. Copy CDOEXMComponent.dll, Interop.ActiveDs.dll, and Interop.CDOEXM.dll from the output directory of the CDOEXMComponent project to a folder named “bin” under the folder you just created in Step 1.

3. Create a new file in the “CDOEXMComponent” folder called “web.config”

a. Copy the following XML and paste it in the web.config file

<?xml version="1.0"?>

<system.web>

<add assembly="System.DirectoryServices,

Version=2.0.0.0,

Culture=neutral,

PublicKeyToken=B03F5F7F11D50A3A"/>

</assemblies>

</compilation>

</system.web>

</configuration>

4. Create another file in the “CDOEXMComponent” folder called “Default.aspx”

a. Copy the following code and paste it in the aspx file

b. Notice you will have to change the variables to match your test environment

<%@ Page Language="C#" %>

// CreateUserWithMailbox Input, change to match

// your test environment.

string firstName = "Matt";

string lastName = "Stehle";

string samName = "mstehle";

string baseContainer = "CN=Users,DC=mstehle03,DC=extest,DC=microsoft,DC=com";

string homeMDB = "CN=Mailbox Store (MSTEHLEEX03),CN=First Storage Group,CN=InformationStore,CN=MSTEHLEEX03,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mstehle03,DC=extest,DC=microsoft,DC=com";

// Print out the security context of the web application

Response.Write(string.Format(

" Web Application Context: {0} ",

System.Threading.Thread.CurrentPrincipal.Identity.Name));

// Create component

CDOEXMSample obj = new CDOEXMSample();

try

{

obj.CreateUserWithMailbox(firstName, lastName,

samName, baseContainer, homeMDB);

Response.Write(" Mailbox Created! ");

}

catch (Exception ex)

{

Response.Write(" Error when creating mailbox... ");

Response.Write(string.Format("Message: {0} ", ex.Message));

Response.Write(string.Format("Stack Trace: {0} ", ex.StackTrace));

}

// Print out the security context of the component

Response.Write(string.Format(

" CDOEXMComponent Context: {0} ",

obj.GetIdentity()));

Create and Configure the virtual directory in IIS on your web server

1. Click Start, select “Run…” and type “inetmgr”, Click OK

2. Expand the “Web Sites” folder

3. Select a Web Site, right click and select New, “Virtual Directory…”

a. Click Next

b. For the alias, type “CDOEXMComponent”

c. Click Next

d. Set the appropriate path to the folder where you just created the ASPX file.

e. Click Next

f. Select Read and “Run scripts (such as ASP)”

g. Click Next

h. Click Finish

4. Right click the CDOEXMComponent virtual directory you just created and select Properties

a. Click the “Directory Security” tab

b. In “Authentication and access control” click the “Edit…” button

c. Uncheck “Enable anonymous access”

d. Check only “Integrated Windows Authentication” under “Authenticated access”

e. Click OK

f. Click OK

Talking a look at the results

When you access this page from another machine as different user than the administrator account configured in the COM+ component you will notice that the web application and the COM+ component are running in different security contexts. For example in my test, I was logged in a user called Green Giant and when I hit the web I got the following result…

Web Application Context: MSTEHLE03\ggiant

Mailbox Created!

CDOEXMComponent Context: MSTEHLE03\Administrator

…The key here is that Green Giant is just a simple User in my test domain. He has no permissions to create new Active Directory Users or Exchange mailboxes. However, all he has to do is authenticate against the domain to gain access to this web form. The web form makes the call to our COM+ component which always executes the CDOEXM code in the context of Administrator, not matter who the calling process is running as. Again, this is because CDOEXM does not support thread level impersonation.

Therefore it is very important to pay attention to the directory security configuration in IIS and what users will have access to the web application in this scenario as well as who has rights to create and make calls to the COM+ component. Anybody who can call this component can create a mailbox.

FYI: Glen's Exchange Dev Blog is awesome...

mstehle — Wed, 29 Nov 2006 00:51:00 GMT

If you are an Exchange developer and haven't checked out Glen Scales's blog then you are missing out. Chances are he has written part of your project for you and posted it on his blog. Check out his latest post for a script which generates a report of mailbox size broken down by the age of messages...

FYI: Supportability of Exchange API's in Managed Code

mstehle — Tue, 22 Nov 2005 23:21:00 GMT

As more and more developers move to managed code (.NET), especially with the release of Visual Studio 2005, it is important to be reminded of what current API's are supported for use in managed code and which are not. The following KB article is a must read when starting .NET development against Exchange, Outlook, or SMTP.

http://support.microsoft.com/default.aspx?scid=kb;en-us;813349

...We all would like to see more supportability with .NET from our Exchange API's. Exchange 12 could offer some more options to that end. It is important to know the basics about all our API's, their functionality limitations, and supportability concerns. Exchange development often requires blending multiple API's to get the job done; you should be open to that possibility.