I've been supporting Messaging development for quite a while and had a lot of fun doing it, but a few months ago, I decided to change focus and dig into a new different product. I'm now supporting the Microsoft side of the Microsoft | SAP Duet product. So as you would assume the focus of this blog will be changing greatly, there may still be some occasional messaging development entries, but the main focus will be the Duet product the majority of the time now.
My hope with the blog now is to raise the awareness around what we can be done with Duet along with getting some good troubleshooting steps and hopefully get some common issues documented.
More to follow soon...
- Jeff
I recently worked on a issue where the customer was programmatically creating mailboxes on an Exchange server with CDOEM and ADSI, and were having some issues trying to access these newly created mailboxes with their WebDAV code.
This is a known issue that occurs because the mailbox is not available to WebDAV until a client logs on to that mailbox. Additionally this problem is documented in the following article:
839422 When you try to log on to an Exchange 2000 or an Exchange 2003 mailbox by using a WebDAV program, you receive a 401 status code in Internet Explorer
http://support.microsoft.com/default.aspx?scid=kb;EN-US;839422
For this issue the following options are different approaches that can be used to workaround this issue. I wanted to get them combined and noted here for reference, since it didn't seem like there was a lot of information available to specifically address this issue:
- After Creating the mailbox send a welcome message to the new mailbox, this will force the creation of the mailbox and you will be able to use WebDAV against the mailbox (Although the article above states that you cannot)
- Manually log into the mailboxes after they are created (Not very practical if you are creating a lot of mailboxes at one)
- Use either MAPI or CDO 1.21 to logon to those mailboxes BEFORE we use our WebDAV code to access that same mailbox. Note: MAPI development needs to be done in VC++ but CDO 1.21 can be done in either VC++ or VB or VBScript.
- Do a simple GET request (non-WebDAV) to the root of the newly created mailbox while NOT specifying the translate header to true. This will also force the creation of the mailbox with just the HTTP GET request.
Related information:
A special thanks to Dan Bagley who blogs at http://blogs.msdn.com/webdav_101/ and has some good information on WebDAV and messaging development.
Knowledge base articles:
195662 How to log on to Exchange with the ProfileInfo parameter
http://support.microsoft.com/default.aspx?scid=kb;EN-US;195662
180597 How To Get the Name of the Profile you Logged On With
http://support.microsoft.com/default.aspx?scid=kb;EN-US;180597
MSDN references:
CDO 1.21 Session logon method:
http://msdn2.microsoft.com/en-us/library/ms526377.aspx
CDO 1.21 GetDefaultFolder method:
http://msdn2.microsoft.com/en-us/library/ms526181.aspx
MAPILogonEx documentation:
http://msdn2.microsoft.com/en-us/library/ms529409.aspx
-Jeff
If you've been bit by the problems with the web download of CDO 1.21 returning a 8004011D when trying to access an Exchange 2003 server then this post may help you out.
First the history of the problem and then what options are available to avoid this issue. So as you probably already know, with Exchange 2007 we don't have to have a Public Folder tree. This new scenario is the main cause behind this problem with the downloadable version of CDO 1.21. Steve Griffin does a great job of explaining how this came into being and where the CONNECT_IGNORE_NO_PF flags comes from in his post.
So with the downloadable versions of the CDO 1.21 library, this flag is passed by default now, remember this download was intended for use in a Outlook 2007 / Exchange 2007 environment. So this really isn't a big deal right? Wrong, the problem occurs when we use these CDO 1.21 web download bits and try to access an existing Exchange 2003 server. The result is your code fails with an error: 8004011D (MAPI_E_FAILONEPROVIDER error or "The Server is not available") error when trying to access the Exchange 2003 server. The reason is that the Exchange 2003 server you are trying to access doesn't know how to handle this new flag its being passed and returns this error.
Luckily there are now two options to approach this issue and I've documented them for your reading pleasure:
-
Make sure that your Store on your Exchange 2003 server is updated to the latest security fix. Why? These updates now include logic for the store to recognize the new the CONNECT_IGNORE_NO_PF flags that CDO 1.21 passes. So if you update your server, you may not have to do anything else, you can use the downloadable CDO 1.21 normally without having to anything else or make any other changes. And you'll still be able to access your Exchange 2007 server without a worry.
KB Article 929751 documents/explains the changes for Store so that the it will properly recognize the new flags.
- The other option is to use the updated CDO 1.21 web download (Available since the August 1st) and you will be able to set the option whether or not CDO 1.21 will pass these flags or not. The setting to control whether or not CDO 1.21 will pass these flags is added to the registry. (CDO 1.21 version 06.06.7940 or greater)
The registry changes required to make this work needs to be set as follows:
HKLM\Software\Microsoft\Windows Messaging Subsystem\CDO
"Ignore No PF"
DWORD
Value: 1 : Means CDO will send the "CONNECT_IGNORE_NO_PF". Anything else, we won't send the flag. The default behavior with this update is to not send the flag.
For accessing Exchange 2003 servers, I suspect that as the updates to store get out there and people get them installed on their 2003 servers, this will be less of an issue. But with this update, there is another complexity to be aware of here is that now with the default configuration of the CDO 1.21 web download being that we don't pass the "CONNECT_IGNORE_NO_PF" flag, and you try to use these binaries in environments with no Public Folder stores on Exchange 2007, you will fail until you change the key to 1.
Resources:
The link to the web download for CDO 1.21 is here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=2714320D-C997-4DE1-986F-24F081725D36&displaylang=en
The link to the web download for CDO 1.21 and MAPI is here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=E17E7F31-079A-43A9-BFF2-0A110307611E&displaylang=en
I wanted to get this blogged until we get an article published on this. Here's the problem that were recently encountering and what we found, after the fact it all makes sense when you think about.
When using CDO 1.21 and trying to cancel an existing meeting from an organizer's mailbox you find that the cancellation requests remain in the Outbox and are not sent.
The key to determining the root cause of this issue is that the original meeting request was sent out to a Outlook personal distribution list and does not occur if you send the same meeting request to a Exchange distribution list.
So what is the difference when sending to a Outlook personal distribution list, and why would it matter? In this case we were using the CDO 1.21 from a ESM (Exchange System Manager) install, and not an Outlook install, and were using dynamically generated profiles. The Personal distribution item is a Outlook object that MAPI and CDO don't specifically know about.
The problem that we are seeing here is related to the contab32 (Outlook Address Book service). This is the service that Outlook uses to resolve these personal DL's to an email address. So when we create a profile with ProfileInfo option in CDO logon call this service is not added to the dynamically generated profile. When we try to go and resolve this personal DL to a email address, we fail since we do not have a service loaded capable of resolving this address. So the mail just sits in the outbox of the organizer's mailbox, unresolved and unsent.
Secondly you would also experience this same problem without any meeting requests in the mix at all. You can also reproduce the same problem and actually get a error returned on send. This is easy to do by composing an email to the same personal DL in Outlook. Instead of actually sending the email, just save it in the drafts and then use CDO to get the Entry ID and try to send the message. When CDO tries to send this saved message, using ProfileInfo, the following error is returned:
E_INVALIDARG(80070057)
Again we've run into the limitation that the Outlook Address Book service isn't loaded when we use ProfileInfo with CDO's logon call and dynamically create a profile. This is "by design" since CDO can't do anything to load this service within the dynamic profile.
So how do you work around this?
We really have the following options to avoid this issue:
- One way would be to use a previously (programmatically or through the Profile wizard) created profile that has this contab32 service loaded. Then when logging on with CDO instead of using the ProfileInfo parameter in Logon call, we specify this profile to logon with. Hence, when we go to resolve the personal DL, we have the Outlook Address Book service available to CDO. This of course would require you to run your application on a machine that had Outlook installed to get the contab32 service. If you are planning to use your CDO code in a service, then this option may not be the best option since the Outlook installed bits are suited very well to being used in a service.
- Another option, if you are in a Exchange environment, would be to use a Exchange Distribution List instead of a Personal DL. Here we would have no limitation on using the dynamic or static profiles to logon and send mail or cancel the meeting request. This is probably the better option if you are looking to use your CDO code in a service-type application. This option wouldn't require that you have Outlook installed on the machine where this application it running, you could just have ESM installed on this machine to get CDO and MAPI.
This was a straight forward issue that I worked on a short period of time ago and thought that it was worthy of posting the results.
The issue that we were encountering was with a service application that a customer had written that was doing a lot of repeated calls to some Exchange mailboxes using CDOEX. Over time, as any good leaky application will, the memory being used by this application began to grow and grow. I bring this issue up since it could be something that you might encounter, since it doesn't take much to expose the problem. It just so happens that this can occur with some really simple CDOEX code. For this problem to occur you really only need to be using code similar to the following:
Dim Conn As ADODB.Connection
Dim objAppt As CDO.Appointment
Dim i As Long
For i = 1 To 50000
Set objAppt = New CDO.Appointment
Set Conn = New ADODB.Connection
Conn.Provider = "exoledb.datasource"
Conn.Open "http://ExchangeServer/Exchange/user/Calendar", "", "", 0
objAppt.DataSource.Open "http://ExchangeServer/Exchange/user/Calendar/item.eml", Conn, ADODB.ConnectModeEnum.adModeReadWrite, ADODB.RecordCreateOptionsEnum.adFailIfNotExists, ADODB.RecordOpenOptionsEnum.adOpenSource, "", ""
' Do other logic here...
'Clean up
Conn.Close
Set objAppt = Nothing
Set Conn = Nothing
Next
After some amount of time of researching this with various tools including UMDH, it turned out that this problem was an issue with the ADO components that CDOEX and ExOLEDB uses to access the Exchange store. And to resolve this issue all you just need to do is make sure that you are running at least this version of msado15.dll (2.82.3959.0), which luckily is now available publicly in Windows 2003 SP2.
So if you are seeing anything like this I suggest that you go ahead and give Windows 2003 SP2 a try.
Thom just published a post about the removal of the Exchange workflow designer from the Exchange downloads. And I just posted my comments about troubleshooting the workflow engine in Exchange. :)
Here's the link to the Exchange API-spotting post about this:
http://blogs.msdn.com/exchangedev/archive/2007/05/15/microsoft-office-workflow-designer-for-exchange-is-no-longer-available.aspx
I have to say that I saw this coming with the release of Exchange Server 2007 and the lack of workflow libraries. Really though, I think in the long run for developers of workflow enabled applications it's a great thing. The new strategic direction is a more direct and much more robust solution that what we can offer with just the Exchange workflow designer.
Here's the reasoning behind this:
"There are several reasons why moving away from Exchange Workflow and the Workflow Designer for Exchange, and moving to WF is the right thing:
- WF is Microsoft’s strategic direction for workflow applications.
- WF leverages current technology and a better programming model.
- WF can be used in managed code (ExWFD and CDOWF cannot).
- WF will also be used in other Microsoft applications.
- ExWFD and CDOWF are not compatible with Microsoft Exchange Server 2007."
So as it's noted in Thom's post, if you are planning to develop any new workflow projects, you should really start investigating the new Workflow Foundation that's now available. He's also gone ahead and added a bunch of links and resources to get you started in that direction.
I've seen this issue posted in the newsgroups a couple of times now along with a case or two on this coming to my attention. So based on this, it seems like a good topic to bring up here.
The problem that you run into here is that the custom Exchange web forms that you have registered on your Exchange 2003 server don't work properly when viewed with IE 7.0. The same forms still work properly if viewed with IE 6.0 or when IE 7.0 is used with the "User Agent String Utility" to browse the custom web form. In the cases that I've seen all are involving the web forms view control and issues with this being properly rendered client side in IE 7.0.
We actually dug into the source on this one and saw that this was caused because of the way that we are detecting the browser that is requesting the content. So the way that fix this issue is very similar to what is outlined in the following article:
How to modify the Browscap.ini file to enable script-based detection of Windows Internet Explorer 7 from a Web page - http://support.microsoft.com/default.aspx?scid=kb;EN-US;929744
The main differences that are required, in addition to what is outlined above, to make this work properly with your Exchange web forms are the following key settings:
As per the article, add the following updates to the browsecap.ini, after the IE 6.0 section that already exists. To make sure that Exchange uses these new settings, you need to make sure that the updates are added to the browsecap.ini that resides in the C:\Program Files\Exchsrvr\bin directory and not the one in the IIS server directory.
<Modifications>
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; IE 7.0
[IE 7.0]
browser=IE
Version=7.0
majorver=#7
minorver=#0
frames=True
tables=True
cookies=True
backgroundsounds=True
vbscript=True
javaapplets=True
javascript=True
ActiveXControls=True
Win16=False
beta=False
AK=False
SK=False
AOL=False
Update=False
WebFormsBrowserFlags=SupportsRichEdit&NoViewRender
[Mozilla/4.0 (compatible; MSIE 7.*; Windows NT*)]
parent=IE 7.0
platform=WinNT
beta=False
[Mozilla/4.0 (compatible; MSIE 7.*)]
parent=IE 7.0
beta=False
</Modifications>
The key entry here being the "WebFormsBrowserFlags=SupportsRichEdit&NoViewRender"
So, save these changes to the correct browsecap.ini and then go back and browse to your web form custom application with IE 7.0 and you should see the custom forms rendered correctly.
As many of my co-workers know, one of the messaging technologies that is near and dear to my heart is our beloved workflow components that are available to developers in Exchange 2000 and 2003. Over time and after working with numerous developers on various Exchange workflow related issues, I've attempted to compile a list of commonly used troubleshooting steps. I'm hoping that these may help a workflow developer resolve some of the more common roadblocks that they he/she can encounter while developing a project with the workflow components.
My goal with this post is to try to provide as many steps, tricks, and information as possible here to to knock out some of the low hanging fruit of workflow issues.
Here's the common list of basic steps to check off:
General troubleshooting:
- Make good use of "Exchange Explorer" form the Exchange SDK tools. With Exchange Explorer you can view the items that have been posted into a workflow enabled folder and determine all kinds of things about the state of the workflow on that item.
Creating/Registering workflow processes in a public folder:
- Can you connect to the same public folder with OWA & Outlook? If not, why?
- Verify the person trying to register the workflow process has the appropriate permissions to properly register a workflow project in that public folder. Specifically "Can Register Workflow", and if needed "Privileged Workflow authors" roles in the COM+ application.
- Get and review Event Logs, System & Application specifically from the Exchange server that the workflow process is attempted to be registered on.
- Make sure that you are connecting to the server that has an instance of the public folder where we are trying to create the workflow process. Also make sure that for each of the public folder servers that has/will have an instance of the public folder hosting the workflow process also has the workflow COM+ component installed and is configured correctly on each one of those servers.
- Make sure the person registering the Workflow has a mailbox.
- Make sure the person registering the Workflow is the owner of the Public Folder, or at least has enough permissions to create and modify items created in the folder.
- Make sure Basic Authentication is checked on the Public Folder Virtual Root.
- Make sure "Execute Permissions" for scripts is checked on the Public Folder Virtual Root.
- Get and review network traces of the traffic from the machine registering the workflow process to the Exchange server for errors.
- On the Exchange server, take a look at the IIS logs for any errors related to WebDAV verbs being performed on the workflow public folder.
Workflow COM+ component:
- Confirm NT System/Authority account is listed in the "Privileged Authors" Role.
- Make sure the workflow account that is set as the account for the Workflow package is part of Exchange Domains Servers group.
- Make sure the account NTAuthority/System is the member of Privileged Workflow Authors Role.
- If, for some reason you need to recreate the Workflow COM+ application, run regsvr32 on the CDOWFEVT.DLL. This will recreate the COM+ application for the workflow event sink. If COM+ application is already present, another one will be created, so I suggest that none exist before doing this suggestion. After the new application and component is created, you would need to reconfigure the COM+ settings and roles manually or use the following scripts from the Exchange SDK: (addwfrole.vbs or wfsetup.vbs) to configure these roles in the COM + application.
Workflow Events not firing:
-
Try creating a synchronous OnSyncSave sink in the folder and post a new message to that folder. What this will help you determine is if any events are getting fired for the store. This can be useful information since that's the same thing that the Workflow engine is using to do all of its magic. Generally you'll see that if the workflow events are failing to fire so do normal synchronous sinks. If you find that the sinks are not firing the next item below is a good bet to investigate here.
-
You can also check for duplicated StoreEvents{GUID} system folders on your exchange server. From experience, this has accounted for quite a few issues where the workflow engine is not doing its job correctly. This article show how to check for this:
924171 Error event ID 116 is logged in the Application log every time that you start a server that is running Exchange 2000 Server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;924171
Troubleshooting specific Workflow errors:
EventID 4098 appears while posting message to a workflow-enabled folder
http://support.microsoft.com/kb/297508
Cannot Register Workflow Events After You Change Permissions for the Exchange Domain Servers Group
http://support.microsoft.com/kb/315526
You cannot synchronize offline changes with a workflow-enabled public folder in Exchange 2000 Server
http://support.microsoft.com/kb/810018
INFO: Workflow Behavior When Folders Are Replicated
http://support.microsoft.com/kb/309469
Other interesting bits of information:
Description of how to obtain Microsoft Workflow Designer for Exchange
http://support.microsoft.com/kb/318895
Support policy for Microsoft Exchange APIs with the .NET Framework applications
http://support.microsoft.com/kb/813349/en-us
Understanding Exoledb’s default folders
http://blogs.technet.com/exchange/archive/2005/05/11/404826.aspx
Understanding Public Folders and System Folders
http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3AdminGuide/c9040a64-ee66-445f-92b7-825db0da732f.mspx
If you know of any other tips that you have used to get through a sticky Exchange workflow issue, comment this post and we'll see about getting it added to the list above.
This is one of those issues that seems that it could be related to any array of issues, and really can only resolved by debugging into a local repro of the problem. In this case we were trying to open a connection to an Exchange server with CDOEXM to do some typical management work with the server. What happened in this this particular case is that the following error was returned when trying to open a connection using the IExchangeServer Interface to the Exchange server. The error that we received:
0x8000FFFF - E_UNEXPECTED
Here's a simple script that demonstrates the problem:
Dim objExchangeServer
Set objExchangeServer= CreateObject("CDOEXM.ExchangeServer")
objExchangeServer.DataSource.Open("MyExchangeServerName")
... your other logic here ...
Cause:
When our script here is doing the Datasource.open(“MyExchangeServerName”) the CDOEXM code that is being used is doing some LDAP queries behind the scenes against the AD, this is all in preparation to connecting to the requested Exchange server. What happens when we get this 0x8000FFFF error returned, the LDAP query that CDOEXM used returns us two objects. This then indicates that we have two Exchange servers or other type of naming conflict in this ORG. And for CDOEXM to properly connect to the Exchange in this instance we can only have one item returned to CDOEXM from the LDAP query.
So this means that we probably have one of the two items existing in this ORG:
> 2 Exchange Servers with the same name, possible but unlikely.
> A system Policy defined that has the same name as the Exchange server that we are trying to connect to with the CDOEXM code.
In this case it was a system Policy that was defined in the ORG with the same name. Merely, going to the System Polices node and renaming the policy to something other then the name of the Exchange server allow the query to execute properly.
So how do you tell if this is the issue here?
The best way to confirm this is to use LDP to query the AD using the same query that CDOEXM is going to do to see if we get more than one result returned. Do the following steps and query in the LDP tool and examine the responses that are returned:
Launch LDP (Start --> Run --> LDP)
Connection Menu --> Connect...
Connection Menu --> Bind...
Browse Menu --> Search
In the Search dialog:
=============================================================
In "Base Dn", enter: Select the second entry in the list.
In "Filter", enter: "(&(objectClass=msExchExchangeServer)(cn=<Exchange Servername here>))"
For "Scope", select: Subtree
Choose "Run" and see how many results you get.
You can also do the following search:
=============================================================
In "Base Dn", remove the text, so this textbox is empty.
In "Filter", enter: "(&(objectClass=msExchExchangeServer)(cn=<Exchange Servername here>))"
For "Scope", select: Base
Choose "Run" and see how many results you get. For CDOEXM to properly do the Open method, we should only get one item returned here.
For more information on the LDP tool:
224543 Using Ldp.exe to Find Data in the Active Directory
http://support.microsoft.com/default.aspx?scid=kb;EN-US;224543
Note: From what I've seen this is not an issue with Exchange 2003 server.
Here’s a scenario that I ran into with a customer recently.
You’re a developer that's using the CDO 1.21 Session’s SetOption method to set the "FreeBusyMonths" and have setting it with a value of 36. However, after some time, some of your users are reporting that they are seeing that it looks like the max of the Free/Busy information that is published is 12 months. Further inspection indicates that anything over 12 months does not seem to be published, even though you are specifically setting this option to 36 in your application.
For more background, let's look at the following article to help explain CDO 1.21’s SetOption method and what can be set and retrieved with it:
MSDN Documentation : SetOption Method (Session Object)
http://msdn2.microsoft.com/en-gb/library/ms526854.aspx
So in my example. I specifically used the SetOption method to set the “FreeBusyMonths” to 36 months and created a recurring appointment with no end date. I then looked at the Free/Busy data from an Outlook client and noticed that we did not see any Free/Busy data being published past the 1 year point.
So what gives?
After some research, what is actually happening here is the following:
CDO will allow you to use SetOption method to set the “FreeBusyMonths” OptType to whatever you want, meaning there is no limits on what you can set for the Free/Busy Publishing months. But, as we know from the articles below, CDO acts like a client and will create the Free/Busy message in the Public Folder, much like Outlook does.
The following articles explain CDO 1.21’s role with regards to Free/Busy publishing.
XADM: CDO Changed to Regenerate Public Free-and-Busy Message
http://support.microsoft.com/kb/313569
XCLN: CDO Only Publishes Three Months of Free/Busy Data
http://support.microsoft.com/kb/188833
http://msexchangeteam.com/archive/2004/06/02/146939.aspx
The problem occurs when CDO goes through its logic internally to create the Free/Busy message, as it has to do here to be a good client, it will actually enforce a 12 month Free/Busy publishing limit.
So the information noted above in the MSDN is still valid, but doesn’t mention that there are other things that occur under the covers with CDO 1.2x with regards to the actual publishing of Free/Busy data.
