This is a continuation of my previous post.  I wanted to take a moment and discuss the intent of the sample, how to get it working, and some caveats when you attempt to take the sample and turn it into production ready code.

Purpose

The purpose of the sample is to demonstrate how to use Remote Powershell from several different clients and then call an Exchange 2010 cmdlet.

Components

There are several components that make up the sample, the RemoteExchangePS proxy DLL, the managed client and the native client.

The Native Client

The purpose of the native client is to demonstrate how to call Powershell from an unmanaged C++ application.  I used COM Interop for this because it's the simplest and easiest way (in my opinion).  There are a few things that you need to know about this particular component. 

First, this is compiled as a x64 binary.  If you are running this on a 32 bit machine you need to recompile the COM Client application in order to run it.  However, before you do that you will need to also recompile the Type Library (TLB).  To do that run the following at the command prompt:

Tlbexp.exe RemoteExchangePS.DLL

Since you are now building a x86 binary you need to use the x86 version of Tlbexp.exe.

Regardless of the bitness of the binary you will need to register RemoteExchangePS.dll with COM.  To do that you should run the following at the command line:

RegAsm RemoteExchangePS.DLL /codebase

I did not sign this assembly so you will receive a warning saying that you should not use the codebase switch with an unsigned assembly.  Since this is only a sample you can ignore that warning.  Note: You will need to use the correct RegAsm for the correct bitness of the target (i.e. if you are running this on a 32 machine you will need the 32 bit version of RegAsm).

Second, the way this sample is architected is not ideal if you are going to be calling Remote Powershell from unmanaged code over and over again.  Crossing the unmanaged / managed boundary is expensive so you should make "chunky" calls and not "chatty" calls and this sample illustrates.

To actually run the sample, run the following at the command line:

ComClient.exe <SERVERNAME> <USERNAME> <PASSWORD>

The Managed Client

The managed client just demonstrates taking the input from the user and passing it to the GetExchangeServers method.  You will need to supply the ServerName, UserName and Password.

RemoteExchangePS.DLL

This is where the magic happens.  The method GetExchangeServers creates a Powershell class (which is new in .NET 2.0 and encapsulates the pieces necessary to run cmdlets).  It then creates a runspace using the WsManConnectionInfo class. Local Powershell developers will note that we are not adding the Exchange snapin.  You don't need it for Remote Powershell.  This means this code could run anywhere whether or not the Exchange Management Tools are installed.  This was not possible with Exchange 2007.  It then adds the cmdlet Get-ExchangeServer by using the AddCommand method and executes the cmdlet by calling Invoke.  It's at this point that the remote call is made.  This is a synchronous call but you could easily make it an asynchronous call.  When the call returns the code checks to see if there are any errors. If there are not then it just wraps up the names of the Exchange Servers in the organization in an array and returns it.

You can download the sample here

I have seen this question posed a lot so I decided that I would post a quick code sample here and the complete sample on my samples site.

In my sample I created a managed client and a native client which both call into a managed DLL that runs the Get-ExchangeServer cmdlet using Remote Powershell.  Here is the method that actually does the work if you don't want to download the entire sample:

        private const string SHELL_URI = "http://schemas.microsoft.com/powershell/Microsoft.Exchange";
        public void GetExchangeServers(string serverName, string userName, string password, out string[] servers)
        {

            System.Uri serverUri = new Uri(String.Format("http://{0}/powershell?serializationLevel=Full", serverName));
            string[] retVal = null;
            System.Security.SecureString securePassword = new System.Security.SecureString();
           
            foreach (char c in password.ToCharArray())
            {
                securePassword.AppendChar(c);
            }

            System.Management.Automation.PSCredential creds = new System.Management.Automation.PSCredential(userName, securePassword);
           
            RunspaceConfiguration rc = RunspaceConfiguration.Create();
            WSManConnectionInfo wsManInfo = new WSManConnectionInfo(serverUri, SHELL_URI, creds);

            using (Runspace rs = RunspaceFactory.CreateRunspace(wsManInfo))
            {
                rs.Open();
                PowerShell psh = PowerShell.Create();
                psh.Runspace = rs;
                psh.AddCommand("Get-ExchangeServer");

                Collection<PSObject> results = psh.Invoke();

                if (psh.Streams.Error.Count > 0)
                {
                    foreach (ErrorRecord err in psh.Streams.Error)
                    {
                        // handle the error some how
                    }
                    rs.Close();
                    servers = null;
                    return;
                }
                retVal = new string[1];

                foreach (PSObject result in results)
                {
                    if (null == retVal[0] || retVal[0].Length == 0)
                    {
                        retVal[0] = result.Members["Name"].Value as string;
                    }
                    else
                    {
                        string[] newVal = new string[retVal.Length + 1];
                        retVal.CopyTo(newVal, 0);
                        newVal[retVal.Length] = result.Members["Name"].Value as string;
                        retVal = newVal;
                    }
                }
                rs.Close();
            }
            rc = null;
            servers = retVal;
        }

Congratulations to the Exchange product team, Exchange 2010 has been released to manufacturing.

 http://msexchangeteam.com/archive/2009/10/08/452775.aspx

In previous versions of Exchange, the System Attendant (SA) Mailbox was used by the link monitoring service and for publishing Free / Busy information.  However, this functionality is no longer needed in Exchange 2010.  As such the mailbox has been removed.  One catalyst to this change was the new High Availability (HA) features in Exchange 2010.  Having the System Attendant mailbox on servers presents a problem when the server needs to failover to the passive mailboxdatabase copy.  Since only one SA mailbox can exist per server which SA mailbox do you use? The mailbox database's passive copy or the one from the mailbox that just failed over?

As pointed out in Evan's blog post (See Additional Resources), there are two components to the System Attendant mailbox, the directory object and the mailbox object.  The key here is that the directory object has _not_ been removed, only the mailbox object.  Therefore, you will still be allowed to connect to Exchange using the System Attendant however you will not be able to logon (effectively open the mailbox object).

So what are your workarounds?

1. You can still use the per mailboxdatabase System mailbox (See Additonal Resources for more information about this mailbox).

2. You can change your application to rely on a user created account and mailbox.

Additional Resources
=======================

Exchange Special Mailboxes - Part 1 System mailbox

http://blogs.technet.com/evand/archive/2004/12/17/323636.aspx

Exchange Special Mailboxes - Part 2 System Attendant Mailbox

http://blogs.technet.com/evand/archive/2004/12/21/329172.aspx

Exchange 2010 High Availability

http://technet.microsoft.com/en-us/library/dd335211(EXCHG.140).aspx

Note : I have enabled comments on my blog again but all comments are moderated.

I was recently asked the following questions regarding my blog and it's purpose.  I decided that it would be good to post them here so my reader can understand the motivation of this blog.

1.       Have you defined a purpose or strategy for your blog? If so, what is it?

The purpose of my blog is to write content concerning using APIs to extract information and extend Outlook or Exchange.  In the practical sense it’s a way of distributing important information to developers of problems and limitations with messaging development.

2.       Who is your audience?

Anyone writing an application that targets Exchange or Outlook or an application which has built-in email capability.

3.       How often do you update your blog and what types of information do you feel appropriate for your blog vs publishing other types of Content?

I update my blog on an as-needed basis. Typically it’s in a response to a solution I have found for a customer’s problem.

** The following article is for only the Exchange MAPI / CDO download.  Outlook users will not have to use these steps.  Also this configuration may not work on previous versions of Exchange.

1. Open up MFCMAPI, go to Profile > Launch Profile Wizard > Click OK
2. Then Click Next
3. Add the name of your Client Access Server, click Next
4. Click Next
5. Click Finish
6. Go To Profile > Show Profiles, select the profile you just created
7. Select the only service there and double click it
8. Find the Global Profile Section.  It's the provider with the PROVIDER_UID that is 13DBB0C8AA05101A9BB000AA002FC45A and single click it
9. Select PR_PROFILE_CONNECT_FLAGS and set it equal to 0x8000 (CONNECT_IGNORE_NO_PF)
10. Select PR_PROFILE_UI_STATE and set it equal to 0x4000 (EDK_PROFILEUISTATE_ENCRYPTNETWORK)
11. Close all dialogs until the default dialog appears.
12. Select Session > Logon and display store, and select the profile if not already selected

 Once you have the profile working in MFCMAPI, you can do the same thing programmatically.

Notes:

You can also walk through the manual way (Profile > Shows Profile > Create Profile, etc) of creating a profile in MFCMAPI but I will leave that as an experiment for the reader. 

You must be using the Exchange 2010 RC or higher for these instructions to work

You will need to disable encryption to use the Exchange MAPI / CDO download.  This should be fixed by RTM (See Below).  To disable encryption please run the following cmdlet:

Set-RpcClientAccess -Server <FQDN of CAS> -EncryptionRequired: $false

 Additional Resources:

http://mfcmapi.codeplex.com/

http://blogs.msdn.com/stephen_griffin/archive/2007/03/19/mapi-and-exchange-2007.aspx

[Edit: 11/23] The fix for requiring MAPI encryption is made in the Exchange CDO / MAPI download and will be available in the next refresh of that component which is currently scheduled for early December.

The Exchange 2010 Release Candidate has been released to download.

http://technet.microsoft.com/en-us/evalcenter/dd185495.aspx

Stay tuned for my post on how to configure your MAPI profile when using the Exchange MAPI/CDO download to connect to Exchange 2010!

The Exchange 2010 Beta SDK just released and I wanted to call out that using the Backup and Restore API (i.e. Streaming Backups) is no longer supported.

"Exchange 2010 does not support streaming-style backups. In versions of Exchange earlier than Exchange 2010, backup applications use the ESEBCLI2 interface to perform streaming backups. This SDK does not contain information about the ESEBCLI2 DLL. For information about this interface, see ESEbcli2 DLL Functions Interface."

http://msdn.microsoft.com/en-us/library/dd877018(EXCHG.140).aspx

Find more about it here:

http://msdn.microsoft.com/en-us/library/dd877024(EXCHG.140).aspx

ECE's are now officially deprecated in Outlook 2010.

Read more about it here

Exchange Server 2010 beta was released to the public this week.  The beta for EWS managed client API has also been released.

Check it out the related blog posts:

Presenting Exchange Server 2010

http://msexchangeteam.com/archive/2009/04/14/451032.aspx

Introducing the EWS Managed API

 http://blogs.msdn.com/exchangedev/archive/2009/04/15/introducing-the-ews-managed-api.aspx

This is especially exciting for me because I am currently working as the beta support engineer for developer support.  What that means is that I am support customers who are working with Exchange Server 2010.  I hope to post some content here about what's available to developers in Exchange Server 2010.

The Microsoft Exchange Team blog has a video about the new EWS managed client API coming in the next version of Exchange.

http://msexchangeteam.com/archive/2009/03/24/450892.aspx

I wanted to point out that the VSTO team had created some great content for developing VSTO solutions. They even have the Outlook developer covered.

 Check it out:

http://msdn.microsoft.com/en-us/library/bb386094.aspx

Q: How do I signal to Outlook to sign and / or encrypt a message from the Outlook object model?

A: There is not a first-class object or property to do this within the object model.  However, you can set the MAPI property PR_SECURITY_FLAGS.  The code below demonstrates this using the PropertyAccessor object:

Sub SignAndEncrypt()

    Const PR_SECURITY_FLAGS = "http://schemas.microsoft.com/mapi/proptag/0x6E010003"

    Dim mi As MailItem

    Set mi = Application.ActiveInspector.CurrentItem

    Dim prop As Long

    prop = CLng(mi.PropertyAccessor.GetProperty(PR_SECURITY_FLAGS))

    ulFlags = ulFlags Or &H1 ' SECFLAG_ENCRYPTED

    ulFlags = ulFlags Or &H2 ' SECFLAG_SIGNED

    mi.PropertyAccessor.SetProperty PR_SECURITY_FLAGS, ulFlags

    Set mi = Nothing

End Sub