You will recieve the following exception while calling Discover method of ExchangeServiceBinding
System.InvalidOperationException: Discovery document at the URL http://SERVER/EWS/services.wsdl could not be found. ---> System.ArgumentException: The document format is not recognized.--- End of inner exception stack trace ---at System.Web.Services.Discovery.DiscoveryDocumentReference.Resolve(String contentType, Stream stream)at System.Web.Services.Discovery.DiscoveryReference.Resolve()at System.Web.Services.Discovery.DiscoveryDocumentReference.get_Document()at System.Web.Services.Protocols.SoapHttpClientProtocol.Discover()at EWS_Test_Anything.Tasks.TestConnection()
If I do not call Discover method rest of code is working fine, i could access Exchange without any problem.
So what happens when we call Discover method?Following is the finding from my colleague Matt
Looking at MSDN, http://msdn2.microsoft.com/en-us/library/system.web.services.protocols.soaphttpclientprotocol.discover.aspx, the Discover method is actually part of the base class, SoapHttpClientProtocol, and seems to be looking for the *.disco URL not the *.wsdl URL.
If you look at the MSDN information on Web Service Discovery, http://msdn2.microsoft.com/en-us/library/fxx6cfx2.aspx, you will see the following quote indicating that a DISCO file is not required by a web service…
“…However, a Web site that implements an XML Web service need not support discovery. Another site could be responsible for describing the service, such as an XML Web services directory. Alternatively, there might not be a public means of finding the service, such as when you create the service for private use…”
Looking at the Exchange 2007 virtual directories it doesn’t appear that Microsoft have supplied at DISCO file and being that we have so few entry points we don’t really need one.
Resolution.... Do not call Discover method... there is no need doing it.
MAPI is one of the most sophisticated set of APIs
Read the full story here...
Today I ran into a problem where the customer was using OOM to fetch contacts from Outlook... they had more than 3000 contacts in there Mailbox and it was taking forever to loop through all the contacts and storing them into a dataset... hmmm I could run the same code fine on my machine... what could be the problem.
After some research I realized if I disable Cached Exchange Mode from my Outlook I could also reproduce the problem.
Its recommended if you are using Outlook and Exchange together to enable cached mode to increase the performance.
How cached mode impact performance?
In cached mode a copy of your mailbox is stored on your computer and this copy provides quick access to your data and is frequently updated with the mail server.
Suppose due to a connection problem you are working offline but your data is still available to you instantly wherever you are. If a connection from your computer to the computer running Exchange server isn't available, Outlook switches to Trying to connect or Disconnected. If the connection is restored, Microsoft Outlook automatically switches back to Connected or Connected (Headers). Any changes you make while a connection to the server isn't available are synchronized automatically when a connection is available. You can continue to work while changes are synchronized.
Trying to call Powershell from .net ?
Following are few good articles to read, from my colleague Matt
Cut Down APIs from Exchange 2007
• Queue Viewer API (QAPI)
• WMI Classes for Exchange
With the release of Exchange 2007 all of exchange management is done via cmdlets in PowerShell™.
• EDK Gateways
• Routing Objects
• Transport Event Sinks
Store Access APIs
• CDO for Workflow
• Workflow Designer
• Exchange 5.5 Event Service
• Exchange Installable File System (ExIFS)
• Web Storage System Forms (WSS Forms)
The above cut store access APIs are replaced by Windows Workflow Foundation and ASP.Net.
De-emphasized APIs in Exchange 2007
With the release of Exchange 2007, message routing and manipulation is done using core namespaces that can be used with Exchange Agents and Foreign Connectors.
• CDO 1.21
• OWA URL Commands
• Store Events
The above de-emphasized APIs are replaced by Web Services.
So what is de-emphasized API?
De-emphasized APIs are not recommended because there are other APIs available to perform the similar operations, these new APIs are more efficient and recommended because they are designed for the latest version of exchange and would be supported in longer run.
I have seen this problem many times where people complain me that they are recieving the following error
Error: Error in loading DLL: 'oExch.DataSource.Open', Code 800A0030
DataSource.Open command returns instance of CDO.IDataSource interface which is part of CDOEX.dllPossible cause could be CDOEX.dll not registered properly
Re-register CDOEX.DLL which should resolve the problem
Search folders are very useful but there is no way available using Outlook Object Model to delete them, you need CDO to delete them.
Below code can help you remove the SearchFolders from Outlook
Function RemoveSearchFolder(ByVal strProfile, ByVal strFolderName As String) As Boolean
Const CdoPR_FINDER_ENTRYID = &H35E70102
Dim objSession As MAPI.Session
Dim objInfostore As MAPI.InfoStore
Dim objFinderFolder As MAPI.Folder
Dim objFolder As MAPI.Folder
Dim strFinderEntryID As String
Set objSession = New MAPI.Session
objSession.Logon ProfileName:=strProfile, ShowDialog:=False
Set objInfostore = objSession.GetInfoStore(objSession.Inbox.StoreID)
strFinderEntryID = objInfostore.Fields.Item(CdoPR_FINDER_ENTRYID).Value
Set objFinderFolder = objSession.GetFolder(strFinderEntryID, objInfostore.ID)
For Each objFolder In objFinderFolder.Folders
If LCase(strFolderName) = LCase(objFolder.Name) Then
RemoveSearchFolder = True
So you are not able to see the Macro script under Outlook rules wizard?
Outlook Rules Wizard macros have a particular format and would not be visible until we match the format
Per http://support.microsoft.com/kb/306108, all the rules macro must accept 1 parameter of either of type Outlook.MailItem or Outlook.MeetingItem
Whenever the rule would be executed the related MailItem or MeetingItem is passed to the Script and you have full control over it....
....got your Script dude ???
So you have an ASP.Net application that creates a user account in Active Directory and a Mailbox using the CDOEXM library. When you execute the following code in your ASP .Net application
Dim oMailbox As CDOEXM.IMailboxStore
oMailbox = ADEntry.NativeObject()
You receive the following error executing the CreateMailbox line on Windows 2003:-
System.Runtime.InteropServices.COMException (0x80072020): An operations error occurred. at CDOEXM.IMailboxStore.CreateMailbox(String HomeMDBURL)
When you execute the following line of code:-
objDE= New DirectoryEntry(strOU, strUser, strPwd, AuthenticationTypes.Secure)
You are contacting Active Directory to retrieve the objDE object using the credentials (rights or token) of strUser. ADSI (the layer used by the
namespace DirectoryServices of .NET) creates a new thread for the current process with the token of strUser to contact AD.
When you subsequently call the CreateMailbox method of CDOEXM, the token of the process and not the token of the thread is used to contact AD. So, if the process
is launched by a classic domain user without any specific rights or a local machine account, the operation will fail.
This is the behaviour of CDOEXM with CreateMailbox under Exchange 2000. You have to be sure that the process is launched using the credentials of an Exchange
Under Exchange 2003, the security checks are tightened. Even if the process runs properly under the right credentials, passing credentials to the DirectoryEntry
object will result in an error - 2147016672 (0x80072020). You must connect to the AD using the default credentials of the process and then call CDOEXM using still the same credentials.
To resolve the issue, do not specify credentials to when binding to AD. Use the following code:
objDE = New DirectoryEntry(strOU)
objDE = New DirectoryEntry(strOU)
It's not a easy task to remember all the Cmdlets to manage Exchange 2007.
This topic lists all the cmdlets that manage features of Microsoft Exchange Server 2007 together with the server roles on which they are used http://technet.microsoft.com/en-us/library/bb123703.aspx