|
|
-
The following interfaces and properties are defined in the Exchange header file edkmdb.h. They are provided here in case your application has to use them, and you are unsure of their function. Applications implement interfaces according to the IExchangeImportContentsChanges definition. The interface that is used by the Incremental Change Synchronization (ICS) system can notify the application when changes to the mailbox content have occurred. The interface is registered for callback when you configure the synchronizer object that is returned by the MAPI folder object. The interface definition is commented-out in the header file edkmdb.h because Exchange does not actually implement the interface. The application implements the interface. // IExchangeImportContentsChanges
STDMETHOD(GetLastError)(HRESULT hResult, ULONG ulFlags, __in LPMAPIERROR *lppMAPIError);
STDMETHOD(Config)(__in LPSTREAM lpStream, ULONG ulFlags);
STDMETHOD(UpdateState)(__in LPSTREAM lpStream);
STDMETHOD(ImportMessageChange)
(ULONG cpvalChanges, __in LPSPropValue ppvalChanges, ULONG ulFlags, __in LPMESSAGE *lppMessage);
STDMETHOD(ImportMessageDeletion)(ULONG ulFlags, __in LPENTRYLIST lpSrcEntryList);
STDMETHOD(ImportPerUserReadStateChange)(ULONG cElements, __in LPREADSTATE lpReadState);
STDMETHOD(ImportMessageMove)
(ULONG cbSourceKeySrcFolder, __in BYTE *pbSourceKeySrcFolder,
ULONG cbSourceKeySrcMessage, __in BYTE *pbSourceKeySrcMessage,
ULONG cbPCLMessage, __in BYTE *pbPCLMessage,
ULONG cbSourceKeyDestMessage, __in BYTE *pbSourceKeyDestMessage,
ULONG cbChangeNumDestMessage, __in BYTE *pbChangeNumDestMessage) The following interface definition, found in the edkmdb.h header file, is returned by the MAPI folder object. Configure the object properties using the object methods, and then call the Synchronize method to register the custom ExchangeImportContentsChanges callback routine of your application. #define EXCHANGE_IEXCHANGEEXPORTCHANGES_METHODS(IPURE) \
MAPIMETHOD(GetLastError) \
(THIS_ HRESULT hResult, \
ULONG ulFlags, \
LPMAPIERROR FAR * lppMAPIError) IPURE; \
MAPIMETHOD(Config) \
(THIS_ LPSTREAM lpStream, \
ULONG ulFlags, \
LPUNKNOWN lpUnk, \
LPSRestriction lpRestriction, \
LPSPropTagArray lpIncludeProps, \
LPSPropTagArray lpExcludeProps, \
ULONG ulBufferSize) IPURE; \
MAPIMETHOD(Synchronize) \
(THIS_ ULONG FAR * lpulSteps, \
ULONG FAR * lpulProgress) IPURE; \
MAPIMETHOD(UpdateState) \
(THIS_ LPSTREAM lpStream) IPURE;
#undef INTERFACE The PR_CONTENTS_SYNCHRONIZER property is used to request a pointer to the IExchangeExportChanges object. Note that the PT_Object and PROP_TAG are also defined in the edkmdb.h header file. #define pidStoreMin 0x6618
#define PR_CONTENTS_SYNCHRONIZER PROP_TAG( PT_OBJECT, pidStoreMin+0x15) The following flags instruct ICS as to what types of changes the application is interested in receiving. /*------------------------------------------------------------------------
*
* Flags used by Exchange Incremental Change Synchronization Interface
*
*-----------------------------------------------------------------------*/
#define SYNC_UNICODE 0x01
#define SYNC_NO_DELETIONS 0x02
#define SYNC_NO_SOFT_DELETIONS 0x04
#define SYNC_READ_STATE 0x08
#define SYNC_ASSOCIATED 0x10
#define SYNC_NORMAL 0x20
#define SYNC_NO_CONFLICTS 0x40
#define SYNC_ONLY_SPECIFIED_PROPS 0x80
#define SYNC_NO_FOREIGN_KEYS 0x100
#define SYNC_LIMITED_IMESSAGE 0x200
#define SYNC_CATCHUP 0x400
#define SYNC_NEW_MESSAGE 0x800 // only applicable to ImportMessageChange()
#define SYNC_MSG_SELECTIVE 0x1000 // Used internally. Will reject if used by clients.
#define SYNC_BEST_BODY 0x2000
#define SYNC_IGNORE_SPECIFIED_ON_ASSOCIATED 0x4000
#define SYNC_PROGRESS_MODE 0x8000 // AirMapi progress mode
#define SYNC_FXRECOVERMODE 0x10000
#define SYNC_DEFER_CONFIG 0x20000
#define SYNC_FORCE_UNICODE 0x40000 // Forces server to return Unicode properties When combined with the others defined in the ebkmdb.h, the following bit-field definitions are used to indicate the scope of changes that Exchange ICS will report to the application: #define CONVENIENT_DEPTH ((ULONG) 0x00000001
#define SHOW_SOFT_DELETES ((ULONG) 0x00000002)
#define SHOW_SUBFOLDERS ((ULONG 0x00000004) The PR_LOCAL_COMMIT_TIME_MAX property, which is returned for a folder, indicates when any items in the folder were last changed. When this property value is different from the PR_LOCAL_COMMIT_TIME property value, items in the folder have changed since the last time changes to the folder were committed to the database. #define pidAdminMin 0x6690
#define PR_LOCAL_COMMIT_TIME_MAX PROP_TAG(PT_SYSTIME, pidAdminMin+0x7a) The PR_DELETED_COUNT_TOTAL property indicates how many items have been deleted from the folder since the folder was created. #define pidAdminMin 0x6690
#define PR_DELETED_COUNT_TOTAL PROP_TAG(PT_LONG, pidAdminMin+0x7b)
|
-
The Readme for the November 2007 release of the Exchange Server 2007 SP1 SDK include an error. The following statement in the Readme is incorrect:
By default, the Setup wizard installs the Exchange Server 2007 SP1 SDK Documentation and Samples on the drive that contains the operating system (usually drive C), in the folder \Program Files\Exchange Server 2007 SP1 SDK\.
The statement should read as follows:
By default, the Setup wizard installs the Exchange Server 2007 SP1 SDK Documentation and Samples on the drive that contains the operating system (usually drive C), in the folder \Program Files\Microsoft\Exchange Server 2007 SP1 SDK\November 2007.
This error is fixed in the online version of the Readme, but is still exists in the Readme that is included in the downloadable version of the SDK.
|
-
One of the most frequent mistakes that we see developers who are using Exchange Web Services make is the hard-coding of the URL for the ExchangeServiceBinding to a specific location. Hard-coding the URL is not recommended, especially given that Exchange Web Services provides a mechanism for avoiding this: Autodiscover. Autodiscover ensures that your client is always returned the most efficient URL to use for a given mailbox. Are you wondering why we don’t recommend hard-coding the URL? Let me count the ways!
1. The hard-coded URL might point to the URL of a Client Access server that is in a different site from the user’s mailbox. Accessing a Client Access server in a different site from a user’s mailbox results in poorer performance and greater complexity than accessing a Client Access server in the same site as the mailbox. The only way to ensure that you are accessing a Client Access server in a particular user’s site is to use Autodiscover.
2. We may change the URL for various Web services as we consolidate them, or break them up for better architecture between roles, which will complicate migration to later versions of Microsoft Exchange Server.
3. The corporate address could change namespaces (this doesn’t happen often, but we have occasionally changed our namespace at Microsoft). For example, https://mail.contoso.com could become https://portal.contoso.com.
Let me explain a little more about why accessing a Client Access server in a different site from a user’s mailbox is not a good idea. If your enterprise has multiple Active Directory sites (i.e. branch offices that are running Exchange Server 2007), Exchange Web Services in the initial release version of Exchange 2007 will be making cross-site remote procedure calls (RPCs) from the Client Access server that you are accessing to the mailbox in the site where a user is located. Cross-site RPCs are not recommended because RPC traffic is very chatty and high latency networks between sites will degrade the performance of Exchange Web Services significantly. In Exchange 2007 Service Pack 1 (SP1), we have gone the route of Outlook Web Access and ActiveSync and disabled cross-site RPC functionality. Now cross-site calls will fail unless an Exchange 2007 SP1 Client Access server is in the same site as the user mailbox that is set up for EWS proxy. EWS proxy makes these requests more efficient by sending a single HTTP request rather than multiple RPC requests. However, relying on EWS proxy to do the work of getting your request to the right site is also not an ideal solution because it puts unnecessary load on the proxying Client Access server. You can avoid this unnecessary load by making the request to the appropriate Client Access server yourself.
We have some good resources about using Autodiscover. For a sample application that includes downloadable source code that implements an Autodiscover client for you, see Autodiscover Sample Application. For information about the structure of an Autodiscover request, see Autodiscover Request.
One thing to note: Autodiscover is not a SOAP-based Web service. It just uses plain old XML (POX).
Look for more information that describes Autodiscover in more depth soon. Until then, use the examples referenced earlier and always Autodiscover.
|
-
It has come to our attention that there has been some confusion over the mention of EWS.dll in the SDK documentation and Intellisense file. Where can people find it? Actually, you get to generate it. The Exchange 2007 SDK describes how to generate proxy classes by using the Add Web Reference. This may be fine for some of you, but others may want more flexibility with their proxy classes. This is where wsdl.exe comes into the picture. Wsdl.exe parses schema and WSDL files to generate Microsoft .NET code files. These code files contain the types that act as proxies for the serialization and deserialization of the XML messages that are sent to and from the Exchange server. Wsdl.exe is included in the .NET Framework SDK and with Visual Studio 2003 and 2005. Different proxy generators create different object models; in this discussion, I will focus on wsdl.exe version 2.0.50727.42, the version that is included with Visual Studio 2005. Instead of using wsdl.exe, you can use the Add Web References option in Visual Studio 2005 to create proxy classes. (This option will still be available in Visual Studio 2008, except that it will be well hidden). I prefer to use wsdl.exe to generate my proxy classes, for two reasons: 1) I can easily extend the proxy classes to make them easier to use, and 2) I can reuse my compiled DLL in all my Exchange Web Services projects. If I use the Add Web References option in Visual Studio, I have to regenerate the proxy classes for each project and therefore I lose any modifications that I made to the autogenerated classes. Oh, and remember that changes made to autogenerated classes are not supported by Microsoft; you are on your own with those modifications. Let's start by finding wsdl.exe. By default, the Windows SDK installs it to C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\wsdl.exe. You can also access wsdl.exe by using the Visual Studio 2005 Command Prompt. To find the Visual Studio 2005 Command Prompt, from the Start Menu, choose All Programs | Microsoft Visual Studio 2005 | Visual Studio Tools | Visual Studio 2005 Command Prompt. Wsdl.exe has been added to the Path environment variable of the Visual Studio 2005 Command Prompt so that you can access it easily. Now that you know where to find wsdl.exe, you can learn more about it by reading the Web Services Description Language Tool (Wsdl.exe) topic. You are now ready to generate the proxy classes. I like to use the Visual Studio 2005 Command Prompt to access wsdl.exe as it also has the C# compiler in the path. We will use the C# compiler in a bit. In the Visual Studio 2005 Command Prompt, I use the following parameters to generate my proxy classes: wsdl /language:cs /out:EWS.cs /namespace:ExchangeWebServices https://MyCAServer.Domain.com/ews/services.wsdl I chose C# as the output language type for my proxy classes. You can also use Visual Basic .NET or C++ proxy classes. EWS.cs is the output code file for my proxy classes. I used ExchangeWebServices for the name of the namespace that holds all the proxy types; this is consistent with the namespace that is used in the Exchange 2007 SDK documentation and the Intellisense files that are included in the downloadable SDK. The last argument is the URL to my Exchange Web Services endpoint. So now you have a code file with the autogenerated proxies. Next, you compile your code file into an assembly for use in your Exchange Web Services projects. The C# compiler is available with the Visual Studio 2005 Command Prompt. Assuming that you named your code file EWS.cs, you can run the following command at the command prompt to compile your code into an assembly: csc /target:library /out:EWS.dll EWS.cs Notice that EWS.dll is the name of the compiled assembly. This is how EWS.dll is created. Voila! Now you have an assembly that can be reused in all your Exchange Web Service projects. If you currently use the Add Web References option in Visual Studio 2005, I recommend that you start using wsdl.exe instead to generate your Exchange Web Services proxy classes.
|
-
As reported on the Microsoft Exchange Team Blog, Service Pack 1 for Exchange Server 2007 has been released! The Microsoft Exchange Server 2007 SP1 SDK is also available online and for download. If you want to find out about the changes for developers in Exchange 2007 SP1, including additions to transport extensibility, Exchange Web Services, and Outlook Web Access customization, check out the What's New in Exchange Server 2007 SP1 Extensibility article. There's a lot of good stuff in SP1. Go learn. Go develop!
|
-
Exchange Server 2007 Service Pack 1 is coming soon! The service pack includes some Exchange Web Services–related changes that we think you should know about. In fact, you will want to become familiar with these changes so that you can update your client applications to use the new functionality. For starters, we’ve added enhanced delegate access, delegate management, folder-level permissions, public folder access, and identifier translation. For more information about these features, check out the What's New in Exchange Server 2007 SP1 Extensibility article. Consider adding this functionality to your EWS client applications. We’ve also added a new version SOAP header that is used to distinguish client applications, and the schemas they use, between the initial release and SP1 versions of Exchange 2007. Overall, we encourage you to update your EWS applications to use proxy classes that are generated against the schemas that are included in Exchange 2007 SP1. Use the SP1 version header to distinguish the request as coming from an SP1-compliant client application. Client applications that send requests to Exchange 2007 SP1 servers that use the SP1 release version of the Web service schemas must specify the Exchange2007_SP1 enumeration value as the version header. Otherwise, requests that are sent to a Client Access server are assumed to be from Exchange 2007 client applications. These requests are validated against the initial release version of the EWS schemas. Therefore, any clients that use autogenerated proxy classes that are created from the SP1 schemas should use the version headers to distinguish the request version. Any client application that has been upgraded to send requests and receive responses based on the SP1 schemas should also use the version header. Here is an example of how to set the version on the ExchangeServiceBinding to represent an Exchange 2007 SP1 request: ExchangeServiceBinding esb = new ExchangeServiceBinding();
esb.RequestServerVersionValue = new RequestServerVersion();
esb.RequestServerVersionValue.Version = ExchangeVersionType.Exchange2007_SP1; Here is the XML that describes the SOAP header that represents an SP1 request. This is the same XML that is created by the RequestServerVersionValue property of the ExchangeServiceBinding object: <soap:Header>
<t:RequestServerVersion Version="Exchange2007_SP1"/>
</soap:Header> Another important change in Exchange 2007 SP1 is the use of a new identifier format. The identifier format that was included in the initial release version of Exchange 2007 was partially based on SMTP addresses. However, SMTP addresses can change. Therefore, if a client is caching identifier information and an SMTP address changes, any attempts to use those cached identifiers in subsequent requests will fail because the identifier was formed using an outdated SMTP address. This requires a client to resynchronize with the Exchange server any time the primary SMTP address changes. In Exchange 2007 SP1, the identifier is partially based on a unique mailbox identifier that does not change. By default, in both Exchange 2007 and Exchange 2007 SP1, requests are validated against the Exchange 2007 version of the schema, which is the schema that is included in build 685.024. The following table lists the possible identifier scenarios and how requests are handled for each. Scenarios for requests against Exchange 2007 SP1 target servers | Identifier Version | Version Header | Outcome | | E2K7 SP1 | Not set | Schema validation error | | E2K7 SP1 | Exchange2007 | Schema validation error | | E2K7 SP1 | Exchange2007_SP1 | Successful request | | E2K7 | Not set | Successful request; same behavior as request sent against the initial release of E2K7 | | E2K7 | Exchange2007 | Successful request; same behavior as request sent against the initial release of E2K7 | | E2K7 | Exchange2007_SP1 | Schema validation error | But wait! There are other reasons to migrate to Exchange 2007 SP1. The SP1 version of Exchange Web Services also includes the following improvements: - Better time zone support. See Working with Time Zones in the Exchange Web Services GetUserAvailability Operation for more information.
- Improved error responses.
- The Proxy to Best CAS feature. Client Access servers now proxy requests to the most appropriate Client Access server to service a mailbox. This functionality is independent of the version header in the SOAP request.
- Other updates that might affect product behavior. Be sure to retest your client applications after you install Exchange 2007 SP1.
You now have some compelling reasons to install Exchange Server 2007 SP1. So join the Beta fun and download SP1 Beta 2 to learn more about these exciting new features. And while you’re at it, provide us with some feedback through the Exchange Development forum.
|
-
The Exchange Developer Documentation Team is happy to announce the July 2007 release of the Exchange Server 2007 SDK. Read the What's New topic to find out what we added in this release. If you’re working with Exchange Web Services, review the new documentation that covers some of the autogenerated proxy types. And if you like installing the SDK and samples locally, download the SDK here. Thanks again for stopping by our blog. Michael Mainer
Microsoft Corporation
|
-
If you downloaded the code samples for the Exchange Server Developer Center article TechReady 2007 Talk: Developing With Exchange Web Services, you probably had some problems building the projects, because some of the files didn't make it into the download packages. We've corrected that and the updated download packages now contain all the files you need to successfully build the projects. We also updated the Readme file with instructions about how to replace the reference to the Exchange Web Services end point, so the projects use your Exchange Web Services installation. You can find both the English (TechReady2007EWS-en.exe) and French (TechReady2007EWS-fr.exe) download packages on the TechReady 2007 Exchange Web Services Samples download page.
|
-
If you’re reading this, you’re VERY likely a developer with at least some Exchange experience. Well, we need you. Really. The Exchange Developer Documentation team has an open position for a Programming Writer. If you want to help improve the Exchange Developer Center, if you want to write cool code samples and clear documentation, if you want a direct connection with both the product team and the developer community, contact me (thomr@microsoft.com) today! To get an idea what it’s like to work in my team, let’s just say a healthy sense of humor is a plus. The team enjoys working together, we encourage finding innovative ways to create and present developer-focused materials, and we are given the freedom to implement those ideas. We publish the SDKs every few months, technical articles every month, and blog posts like this one at random intervals. We work very closely with the product team, as well as Marketing, and our dear friends in MSDN. If you like what we’re doing, and want to help us add more information and try new ways of reaching out to the Exchange developer community, give us a ring. We’re looking for someone with a well-balanced mix of writing ability (good writing, excellent organizational skills), development experience (VS.NET, a variety of languages, Web services), and knowledge about one or more Exchange programming technologies. Yeah, sure we’re flexible on those. You do NOT need to be a professional writer with a bunch of books in your name. You do NOT need to be a guru-level Exchange solution developer. But, let’s face it: if you ARE those things, we'd love to hear from you! You will definitely need to learn quickly and understand complex technologies clearly enough to explain them to others. On a daily basis we all do a bit of writing, programming, debugging, looking at product source code to understand how an API works, planning for the next release, and answering questions from a variety of good-natured people. We sit in meetings, we go to lunch, and do all the normal things of working for a living at Microsoft. To get the official scoop on the position, check it out here . Give me a call (425-705-8271) or e-mail your resume (thomr@microsoft.com) if you think you might fit well here. Ray, Laura, Michael and I would like to meet you! And of course, if you know someone else who might fit our needs, be sure to send them our way! Thom Randolph
Documentation Manager
Exchange Developer Documentation
Microsoft Corporation
|
-
Starting in May 2007, the Workflow Designer for Exchange, and the Exchange SDK Workflow Application Templates will no longer be available for download. Support for existing installations of the Workflow Designer for Exchange (ExWFD) and templates will continue until support for Microsoft Exchange Server 2003 ends. Contact Microsoft CSS if you need the ExWFD installation package. You can find a complete list of Microsoft Customer Support Services telephone numbers and other information http://support.microsoft.com/contactus/?ws=support. If you’re creating new workflow-based applications, we recommend using the Windows Workflow Foundation. If you’re maintaining existing applications based on Exchange workflow, consider moving to the Workflow Foundation if the application needs to stay in service for more than a couple years. What is this WF thing? Windows Workflow Foundation (WF) is a programming model, orchestration engine, and design tools for quickly building workflow-enabled applications on Windows. WF consists of a .NET Framework namespace, an in-process workflow engine, and designers for Visual Studio 2005. Windows Workflow Foundation applications can be developed and run on Windows Vista, Windows XP, and the Windows Server 2003 family. Windows Workflow Foundation includes support for both system workflow and human workflow across a variety of scenarios. Line-of-business applications, user interface page-flow, document-centric workflow, human workflow, service-oriented composite workflows, business rule-driven workflows, and workflow for systems management are only a few of the applications where WF excels. Yeah, but Exchange Workflow worked fine for my needs… 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. Need some links? These links provide more information on the Windows Workflow Foundation. Windows Workflow Foundation Overview:
http://msdn2.microsoft.com/en-us/library/ms734631.aspx Windows Workflow Foundation Programming Guide:
http://msdn2.microsoft.com/en-us/library/ms734702.aspx Windows Workflow Foundation Tutorials:
http://msdn2.microsoft.com/en-us/library/ms735927.aspx Windows Workflow Foundation Samples:
http://msdn2.microsoft.com/en-us/library/ms741723.aspx Visual Studio 2005 Designer for Windows Workflow Foundation Overview:
http://msdn2.microsoft.com/en-us/library/ms441543.aspx Windows Workflow Foundation Developer Center:
http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx Introduction to workflows on the Microsoft Office SharePoint Server site:
http://office.microsoft.com/en-us/sharepointserver/HA101544241033.aspx?pid=CH101782961033 Understanding Workflow in Windows SharePoint Services and the 2007 Microsoft Office System (5Mb Word Format):
http://www.microsoft.com/downloads/details.aspx?FamilyId=DBBD82C7-9BDE-4974-8443-67B8F30126A8&displaylang=en
|
-
A just-posted technical article by Jim Kleewein and Ray Dixon describes how to combine the SQL Server Tables and Exchange Web Services to access your Microsoft® Exchange Server 2007 Inbox data from Microsoft SQL Server™ 2005. This cool integration enables you to provide data from both Microsoft Exchange and SQL Server to client applications so that the data appears as if it were stored in SQL Server. As the article show, this creates some exciting development scenarios. You can find the article here.
|
-
Search folders in Exchange are a very powerful tool, but there is one quirk that often hangs developers up when they try to use them: “How do you create a search folder that can be seen in Outlook?”. Creating a search folder that is viewable in Outlook is important because it allows you to debug your search restriction and also allows you to present a search folder that an end user can interact with through Outlook or OWA.
The magic dust to creating a search folder that is viewable in Outlook is to make sure that you create it under the “Finder” folder which sits in the root of your mailbox heirarchy. If the folder is created anywhere else it will not be viewable in Outlook, though will contain the items that were specified in the query and can be access via EWS. The code below creates a search folder under the “Finder” folder which is referenced with the DistinguishedFolderIdNameType.searchfolders enumeration. The code below creates a search folder under the “Finder” folder and looks for all messages in your deleted items folder with “OOF” anywhere in a string in the subject. (For those of you that are wondering what an “OOF” is, it is what all we Microsofties call being “Out of Office”, supposedly the feature used to be called “Out of Facility”).
After this folder is created it will show up in Outlook online mode and OWA immediately, Outlook cached mode may take a bit longer to sync down the search folder, but it will eventually be populated as well.
ExchangeServiceBinding esb = new ExchangeServiceBinding();
esb.Url = "https://yoururl/ews/exchange.asmx";
esb.Credentials = CredentialCache.DefaultNetworkCredentials;
FolderIdType folderID = new FolderIdType();
//Now create the request that will create a new searchfolder under the finder directory
CreateFolderType folderType = new CreateFolderType();
SearchFolderType[] folderArray = new SearchFolderType[1];
folderArray[0] = new SearchFolderType();
folderArray[0].SearchParameters = new SearchParametersType();
folderArray[0].SearchParameters.Traversal = SearchFolderTraversalType.Shallow;
folderArray[0].SearchParameters.TraversalSpecified = true;
folderArray[0].SearchParameters.BaseFolderIds = new DistinguishedFolderIdType[1];
DistinguishedFolderIdType dType = new DistinguishedFolderIdType();
dType.Id = new DistinguishedFolderIdNameType();
dType.Id = DistinguishedFolderIdNameType.deleteditems; //search in the deleted items folder
folderArray[0].SearchParameters.BaseFolderIds[0] = dType;
PathToUnindexedFieldType path = new PathToUnindexedFieldType();
path.FieldURI = UnindexedFieldURIType.itemSubject; //search on subject
folderArray[0].SearchParameters.Restriction = new RestrictionType();
ContainsExpressionType expressionType = new ContainsExpressionType();
expressionType.Item = path;
expressionType.ContainmentMode = ContainmentModeType.Substring; //seach for substrings
expressionType.ContainmentModeSpecified = true;
expressionType.ContainmentComparison = ContainmentComparisonType.IgnoreCaseAndNonSpacingCharacters;
expressionType.Constant = new ConstantValueType();
expressionType.Constant.Value = "OOF"; //search for any string containing "OOF"
folderArray[0].SearchParameters.Restriction.Item = expressionType;
folderArray[0].DisplayName = "OOF Search"; //Name the searchfolder OOF Search
folderType.Folders = folderArray;
TargetFolderIdType targetFolder = new TargetFolderIdType();
//Create the searchfolder under the Finder Folder
DistinguishedFolderIdType searchFolder = new DistinguishedFolderIdType();
searchFolder.Id = DistinguishedFolderIdNameType.searchfolders;
targetFolder.Item = searchFolder;
folderType.ParentFolderId = targetFolder;
//Create the search folder
CreateFolderResponseType createFolderResponse = esb.CreateFolder(folderType);
//Return the ID of the newly created search folder
FolderInfoResponseMessageType folderInfo = (FolderInfoResponseMessageType)createFolderResponse.ResponseMessages.Items[0];
return folderInfo.Folders.Length == 0 ? null : folderInfo.Folders[0].FolderId;
|
-
Okay, all you Exchange Web Services programmers out there. Since probably half of you have asked this question already, let me save the other half from half a day of half insanity trying to figure it out. The question in question? “Where the @#$($ is the message Body?” When you’re using Exchange Web Services to retrieve messages from an Inbox, if you need to get the message Body or attachments, you need to use GetItem. Yeah, we know that FindItem would seem to get you there, especially with the AllProperties BaseShape. But, it doesn’t. Check out the new Exchange Server Developer Center article, Finding the Message Body, for the full scoop on which properties GetItem and FindItem return. You’ll be glad you did.
|
-
Hi, and welcome to the Microsoft Exchange Development Blog. This post kicks off a new avenue for getting information to you about Microsoft Exchange development. We (the Exchange SDK UE team) coordinate the Microsoft Exchange Development Blog and are made up of our Documentation Manager, Thom Randolph, two Programming Writers, Michael Mainer and, me, Ray Dixon, and our editor, Laura Graham. However, we aren't the only people who will post here. Contributers will also include Microsoft Exchange developers, testers, program managers, and more. In the near future, you will see content that describes techniques used in Microsoft Exchange application development, coding tips, and code samples, among other things. We also want to hear what you have to say and want to know what content you would like to see. Please comment on posts if you have suggestions, questions, criticisms, or kudos. Also, please send us your ideas for blog posts. This helps us tailor the content to you. To share your blog post idea with us, just send an e-mail describing your idea to exsdkfb@microsoft.com. Thanks for stopping by the Microsoft Exchange Development Blog. We hope you enjoy your (current and future) visit!
|
|
|
|