For lack of a better word

How to configure a HTTP endpoint for Exchange Web Services in Exchange 2010

dvespa — Tue, 22 Dec 2009 13:25:00 GMT

In Exchange 2007 if you wanted to enable HTTP for Exchange Web Services all you had to do was go into Internet Information Services (IIS) and uncheck the box 'Require secure channel (SSL)' on the EWS virtual directory. In Exchange 2010 RTM this is no longer possible. IIS still gives you this option; however it does not give you the behavior you are expecting. If you uncheck this box and attempt to make a request using HTTP you receive a HTTP 404 Resource Not Found.

Exchange 2010 Web Services are now based on Windows Communication Foundation (WCF). You receive a HTTP 404 because WCF attempts to locate the endpoint for HTTP but cannot find it and throws a System.ServiceModel.EndpointNotFoundException exception which bubbles up to the client as a 404. I can't say that this is an intuitive error message but if you think about it long enough it kinda makes sense.

Using HTTP instead of HTTPS is not the recommended approach for Exchange Web Services but sometimes it is helpful in debugging / troubleshooting to have this option. Therefore, if you need to enable HTTP do the following (Note: Please proceed with care, a misspelling here could be the difference between working and non-working):

Confirm that you have unchecked the box 'Require SSL' in IIS.
Navigate to the EWS directory. By default, C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews
Find the web.config file, copy it and rename the copy to web.config.old.
Open the web.config in your favorite text editor.
Replace the element:

<endpoint address="" binding="customBinding" bindingConfiguration="EWSHttpsBinding"

contract="Microsoft.Exchange.Services.Wcf.IEWSContract" />

With the following elements:

<endpoint address="" binding="customBinding" bindingConfiguration="EWSHttpBinding"

contract="Microsoft.Exchange.Services.Wcf.IEWSContract" />

<endpoint address="" binding="customBinding" bindingConfiguration="EWSHttpsBinding"

contract="Microsoft.Exchange.Services.Wcf.IEWSContract" />

Replace the element:

<httpsTransport maxReceivedMessageSize="13600000" authenticationScheme="Anonymous"

maxBufferSize="81920" transferMode="Streamed" />

</binding>

With the following elements:

<httpTransport maxReceivedMessageSize="13600000" authenticationScheme="Anonymous"

maxBufferSize="81920" transferMode="Streamed">

</httpTransport>

</binding>

<httpsTransport maxReceivedMessageSize="13600000" authenticationScheme="Anonymous"

maxBufferSize="81920" transferMode="Streamed" >

</httpsTransport>

</binding>

Save the file

At this point IIS should detect the change in the web.config and reload the settings. Exchange 2010 SP1 should enable the behavior as it was in Exchange 2007.

Note: If you forget that the setting 'Require SSL' is disabled in IIS than enable again it will cause your application to quit working. You will see Internal 500 errors as well as event log entries in the Event log on the Client Access Server. Here is an example of one:

Log Name:      Application
Source:        System.ServiceModel 3.0.0.0
Event ID:      3
Task Category: WebHost
Level:         Error
Keywords:      Classic
Description:
WebHost failed to process a request.
Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/27717712
Exception: System.ServiceModel.ServiceActivationException: The service '/EWS/exchange.asmx' cannot be activated due to an exception during compilation. The exception message is: Could not find a base address that matches scheme http for the endpoint with binding CustomBinding. Registered base address schemes are [https].. ---> System.InvalidOperationException: Could not find a base address that matches scheme http for the endpoint with binding CustomBinding. Registered base address schemes are [https].
   at System.ServiceModel.ServiceHostBase.MakeAbsoluteUri(Uri relativeOrAbsoluteUri, Binding binding, UriSchemeKeyedCollection baseAddresses)
   at System.ServiceModel.Description.ConfigLoader.LoadServiceDescription(ServiceHostBase host, ServiceDescription description, ServiceElement serviceElement, Action`1 addBaseAddress)
   at System.ServiceModel.ServiceHostBase.ApplyConfiguration()
   at System.ServiceModel.ServiceHostBase.InitializeDescription(UriSchemeKeyedCollection baseAddresses)
   at System.ServiceModel.ServiceHost..ctor(Type serviceType, Uri[] baseAddresses)
   at System.ServiceModel.Activation.ServiceHostFactory.CreateServiceHost(Type serviceType, Uri[] baseAddresses)
   at System.ServiceModel.Activation.ServiceHostFactory.CreateServiceHost(String constructorString, Uri[] baseAddresses)
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.CreateService(String normalizedVirtualPath)
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(String normalizedVirtualPath)
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
   --- End of inner exception stack trace ---
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
   at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath)
Process Name: w3wp
Process ID: 1234

If you would like to enable 'Require SSL' again on the EWS virtual directory please follow the instructions below:

Check the box 'Require SSL' on the EWS virtual directory in IIS. Check the 'Require 128-bit SSL box as appropriate.
Rename the current web.config to web.config.HTTP to create a backup
If you still have the old Web.Config change the name of it from web.config.old back to web.config. If not, continue to Step 4.
Remove the element:

<endpoint address="" binding="customBinding" bindingConfiguration="EWSHttpBinding"

contract="Microsoft.Exchange.Services.Wcf.IEWSContract" />

Remove the following element:

<httpTransport maxReceivedMessageSize="13600000" authenticationScheme="Anonymous"

maxBufferSize="81920" transferMode="Streamed">

</httpTransport>

</binding>

Save the file

Exchange 2010 RU 1 has been released

dvespa — Thu, 10 Dec 2009 01:06:00 GMT

http://www.microsoft.com/downloads/details.aspx?FamilyID=371add31-d7a0-4c8b-8325-a6fced2d05e6&displaylang=en

Along with a new version of the MAPI download:

http://www.microsoft.com/downloads/details.aspx?familyid=e17e7f31-079a-43a9-bff2-0a110307611e&displaylang=en

Once the new MAPI download has been installed you should no longer have to disable MAPI Encryption on the Client Access Server

Windows 7 released today, go out and buy your copy

dvespa — Thu, 22 Oct 2009 17:23:00 GMT

http://store.microsoft.com/microsoft/Windows-Windows-7/category/102

Remote Powershell Sample Explained...

dvespa — Thu, 22 Oct 2009 13:45:00 GMT

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

How to call Exchange 2010 cmdlet's using Remote Powershell in code

dvespa — Thu, 22 Oct 2009 13:00:00 GMT

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;
        }

Exchange 2010 Code Complete

dvespa — Sat, 10 Oct 2009 21:29:00 GMT

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

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

Breaking Change : The System Attendant mailbox has been removed from Exchange 2010

dvespa — Tue, 06 Oct 2009 16:45:00 GMT

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.

So what did you say you do here again?

dvespa — Tue, 29 Sep 2009 15:29:00 GMT

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.

How to use MFCMAPI to create a MAPI profile to connect to Exchange 2010

dvespa — Wed, 02 Sep 2009 16:56:00 GMT

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

Open up MFCMAPI, go to Profile > Launch Profile Wizard > Click OK
Then Click Next
Add the name of your Client Access Server, click Next
Click Next
Click Finish
Go To Profile > Show Profiles, select the profile you just created
Select the only service there and double click it
Find the Global Profile Section. It's the provider with the PROVIDER_UID that is 13DBB0C8AA05101A9BB000AA002FC45A and single click it
Select PR_PROFILE_CONNECT_FLAGS and set it equal to 0x8000 (CONNECT_IGNORE_NO_PF)
Select PR_PROFILE_UI_STATE and set it equal to 0x4000 (EDK_PROFILEUISTATE_ENCRYPTNETWORK)
Close all dialogs until the default dialog appears.
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/2008/07/14/getting-a-referral-from-exchange-2007.aspx

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.

[Edit: 12/22] The fix for requiring MAPI encryption is now available. You can download it here: http://www.microsoft.com/downloads/details.aspx?familyid=E17E7F31-079A-43A9-BFF2-0A110307611E&displaylang=en

Exchange 2010 RC has been released

dvespa — Tue, 18 Aug 2009 22:49:00 GMT

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!

Streaming backups no longer supported in Exchange 2010

dvespa — Wed, 10 Jun 2009 01:03:00 GMT

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

Exchange 2010 Beta SDK Released

dvespa — Wed, 10 Jun 2009 00:58:00 GMT

Find more about it here:

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

ECE's will be deprecated in Outlook 2010

dvespa — Tue, 05 May 2009 20:56:00 GMT

ECE's are now officially deprecated in Outlook 2010.

Exchange Server 2010 public beta has been released!

dvespa — Thu, 16 Apr 2009 18:33:00 GMT

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.

New EWS managed client API

dvespa — Sat, 28 Mar 2009 20:33:00 GMT

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