What is the simplest EWS call to test connectivity? - exchange-server

Among all the Exchange Web Services Operations I'm looking for the simplest one I can initially use to check if my connectivity to the EWS endpoint works.
The low-level code I use to build and execute SOAP calls expects valid results so whatever operation I use should not return with an error message.
I have considered several but don't find them satisfactory:
GetServerTimeZones is only supported from Exchange 2010, and I need 2007+
ResolveNames needs a (partial) user name, but I want it do to be user independent. Also, it could return errors (not match) or maybe hundreds of matches (match with 'e').
GetUserConfiguration works for the currently logged in user, but is only supported from 2010.
Any other ideas?

I have decided to use ResolveNames - further processing needs a user anyway.
This gives me the opportunity to do several checks at once: general connectivity, user exists, exchange server version, etc.
EDITED 2 Aug 2013
I have switched to using FindFolder, this has further simplified my code.
This changes the check 'user exists' to the check 'default calendar folder exists', which the app assumes.
There is another assumption in the code, namely that time zone W. Europe Standard Time exists, but as my original question stated, I can only verify that for Exchange 2010 and later.
UPDATE 27 dec 2022
FindFolder lists the subfolders and we don't do anything with that information. We switched to GetFolder.

Related

Create Exchange Meeting Programmatically

Is it possible to create a meeting or appointment on someone else's Exchange 2010 account, without them needing to accept the meeting? Ideally, we want to have a delegate account, or similar strategy, to place appointments/meetings onto people's calendars. We want to bypass the normal request/accept model, and force these meetings into the calendar.
I looked at CreateItem() in the Exchange 2010 documentation, but it is unclear as to what happens once the method is executed. Does the user receive a normal invitation? We don't want that. We want a model where our system has full control over the users' calendars, without them receiving a traditional meeting invitation, and with automatic acceptance. I would prefer not to have to use VBA hacks or plugins, also.
I think it's possible in case of usage ApplicationImpersonation (the usage of ImpersonatedUserId). It 's important that you have to configure the Exchange first. Then you can set NetworkCredential use ImpersonatedUserId to direct access to the destination calender. See here for more information and the code example.
What I would do is grab a copy of MFCMapi (mfcmapi.codeplex.com), and then create a meeting request in a traditional way and send it to a couple mailboxes. Accept it in a couple, mark tentative in a couple, etc.
Take a look at the resultant calendar item created in the invitee mailbox. I expect you should be able to create the appointment and then set the necesary MAPI properties to make it appear as accepted. You can set the arbitrary properties with EWS, it's just going to take a bit of digging to figure out which ones to set. MFC Mapi is a good tool for that.
On the organizer side, you'll need to make some tweaks so it looks like everyone accepted.

Exchange 2010 EWS cannot access 2007 MailBox - AutoDiscover?

The hosting company that my employer uses upgraded to Exchange 2010 over the weekend. This caused a service we use that access a mailbox to break. The hosting company said our mailboxes were still 2007. When trying to access them now using the Exchange 2007 Webservice, I get the following error:
The Client Access server version doesn't match the Mailbox server version of the resource that was being accessed. To determine the correct URL to use to access the resource, use Autodiscover with the address of the resource.
I have done some Googling on this error, and have found some posts about using AutoDiscover to get around this. I tried the Microsoft Example I found here, but I am unclear as to what the output from the console is telling me or how I use it.
It looks like it tries hitting some URLs and then reports on what it found. I either have Exceptions, "The e-mail address cannot be found", or "Site mismatch"
Edit: I got the sample application to return some information. Now my question is, how do I translate what this output is into accessing the mailbox I need?
Here is a list of properties that is returned with their actual values omitted.
=? Trying 'Email#myDomain.com' at 'https://myDomain.net/Autodiscover/Autodiscover.xml'
User/DisplayName=
User/LegacyDN=
User/DeploymentId=
Account/AccountType=
Account/Action=
Account/Protocol/Type=
Account/Protocol/ASUrl=
Account/Protocol/DirectoryPort=
Account/Protocol/MdbDN=
Account/Protocol/OABUrl=
Account/Protocol/OOFUrl=
Account/Protocol/Port=
Account/Protocol/ReferralPort=
Account/Protocol/Server=
Account/Protocol/ServerDN=
Account/Protocol/ServerVersion=
Account/Protocol/UMUrl=
Account/Protocol/PublicFolderServer=
Account/Protocol/AD=
Account/Protocol/EwsUrl=
Account/Protocol/Type=
Account/Protocol/AuthPackage=
Account/Protocol/CertPincipalName=
Account/Protocol/DirectoryPort=
Account/Protocol/OABUrl=
Account/Protocol/Port=
Account/Protocol/ReferralPort=
Account/Protocol/Server=
Account/Protocol/SSL=
Account/Protocol/Type=
Account/Protocol/DirectoryPort=
Account/Protocol/Port=
Account/Protocol/ReferralPort=
Account/Protocol/External/OWAUrl[#AuthenticationMethod="Fba"]=
Account/Protocol/External/OWAUrl[#AuthenticationMethod="Fba"]=
Account/Protocol/Internal/OWAUrl[#AuthenticationMethod="Basic, Fba"]=
Account/Protocol/Internal/OWAUrl[#AuthenticationMethod="Basic, Fba"]=
Account/Protocol/Internal/OWAUrl[#AuthenticationMethod="Basic, Fba"]=
Account/Protocol/Internal/Protocol/Type=
Account/Protocol/Internal/Protocol/ASUrl=
Can someone point me in the right direction toward solving this problem?
Also, I do not have access to make any changes on the Exchange Server itself.
I found the answer with a bit more of googling. The URL being returned from the "Account/Protocol/EwsUrl=" property gave me the value I wanted to point my webservice at.
I had the same error:
The Client Access server version doesn't match the Mailbox server
version of the resource that was being accessed
..but the EwsUrl was correct
The server platform had been upgraded to 2013, but the target mailbox was still in 2007 mode.
The fix was to migrate the mailbox to 2013 and it started working again.
So it was an environmental rather than code fix.

Can an arbitrary email address be used in workflow send email activity

I'm wondering if there is any way to be able to include an arbitrary email address as the To:, From:, CC: or BCC: fields of a send email activity? It appears that they must be contacts in the CRM.
I ask this because I have a requirement to cc a known group email (no actual user associated with the email...something like support#mycompany.com...though it's not a queue at all). I'm concerned that if I create a CRM user for this email, that when I move to production, I'll have to change all the workflows using this email to point to the CRM entity on the production box (assuming GUID is saved with activity).
If an arbitrary email isn't possible, any other suggestions?
I'm not quite sure, if I have unterstood your question right:
You want to create a workflow which contains a send mail activity. You would like to set one of the address fields (To:, From:, CC:) to a plain mail address like 'foo#bar.org'?
It is possible if
you enter the mail address by hand (do not use the field assistant)
you have configured that e-mails with unresolved recipients are allowed to be sent.
See Settings -> Administration -> System Settings -> E-Mail Tab
you don't want to set the e-mail address with another workflow step
To my knowledge, the only way to do this would be to create a custom workflow assembly. This may be more trouble to you than it's worth.
I doubt it. Not without horrible SDK or Custom Workflow Activity machinations, which even then may not work. Unless you have a truly gargantuan number of workflows that must be altered, the manual approach may be the best.
It may be a terrible hack, but you might be able to replace instances of the development environment support account GUID with its production counterpart directly in SQL Server. Not in the SystemUserBase table, but in whatever workflow activities mention the support account as a CC field in an e-mail. But that is scary stuff.
You may also want to take another look at your process; a significant portion of Dynamics CRM is dedicated to handling support issues, and that includes fairly robust e-mail tracking and storage; there probably shouldn't be a need to CC this support mailbox to which you refer.
In summary: All of the options I've listed are terrible. Find a way to avoid them. :-P
I've had this requirement before, and even with workflow activities, there doesn't seem to be a way to handle this (even though CRM will allow it through the UI).
Your instinct is right that if you create a user separately in both environments and then try to move a workflow that references that user between the environments, that the workflow references will have to be updated.
The best solution, to me, would be to go with just creating the contact/user in one environment. But then, create the contact/user in your other environments with the same Guid. You can do this through the API quite easily, or for a no-code solution, there is a Microsoft provided CRM Configuration Data Utility (http://msdn.microsoft.com/en-us/library/dd442453.aspx) that you can use. (Note that the utility will want to migrate all records from the chosen entity, so you might want to export it to a file, edit the resulting file which is just XML, and then import to your target).
This is something that you can do with CRM 2011, CRM 2013, or CRM 2015 if you have a custom entity that is email enabled and then copy the email address from your core entity even if that email address is in a custom text field to it and relate it back via a lookup field. Doing that would require a plugin in Microsoft CRM 2011, but is possible to do with real-time workflows in Microsoft CRM 2013 and Microsoft CRM 2015. This method would allow you to have email addresses associated to the records and available for usage with the CRM workflows to send emails without needing to create an additional user or contact record. This is also handy if you are working with an entity like Incidents that is a core CRM entity and is not email enabled, yet you wish to be able to send emails related to that entity. You could use this method in conjunction with the steps ccellar provided.
I've got a blog post that goes through an example of this here: http://dynamicsuniversity.com/steps-to-send-emails-to-custom-email-address-text-field-from-a-workflow/
You can write custom workflow or you should go for plugin development.
You will get details for it on below blogs.
For custom-workflow
https://msdn.microsoft.com/en-us/library/gg334455.aspx
Blog:-
https://lakshmanindian.wordpress.com/2012/10/14/custom-workflow-activity-in-microsoft-dynamics-crm-2011/
more knowledge on your email sending requirement.
https://social.microsoft.com/Forums/en-US/375f5dad-0382-4112-ab0d-5b42ba235d96/crm-2011-workflow-sending-email-problem?forum=crmdevelopment

Different Unique Ids created using WebDAV and Exchange vs Outlook

I am creating an appointment in Exchange via WebDAV, but the UId created is not the same as if I create the appointment in Outlook. The UId I believe is the same as the GlobalObjectId and should be unique and not change.
The UId if created via WebDAV is:
CD0000008B9511D182D800C04FB1625DDD67374428B4C644A0A359A2586E30B3
The UId if created through Outlook is:
040000008200E00074C5B7101A82E008000000002005332BA3A8CA01000000000000000010000000DD67374428B4C644A0A359A2586E30B3
If I open the appointment created via WebDAV in Outlook and then save it again the UId changes which is annoying (The UId changes to one above beginning with 04).
The second half of the UIds are the same GUID {DD673744-28B4-C644-A0A3-59A2586E30B3} and never change. The document here http://msdn.microsoft.com/en-us/library/cc425490 (EXCHG.80).aspx explains how the GlobalObjectId is constructed. Outlook seems to follow these rules, but Exchange doesn't. I am using Outlook 2007 and Exchange 2007.
There seems to be a myriad of different ids that can be used to identify appointments and I'm just looking for one that stays the same so I can track the appointment over time.
If anyone can help to explain why this UId changes or a way of creating it so it doesn't change it would be much appreciated. My limitations are supporting Exchange 2003 SP2 and Outlook 2003.
Oh yes Id can change, it can depend on the client and the way that you access the items. It a right PITA
I think the link may should help you though , (not knowing excatly what you are doing).
There are mapi proerties that you can use as well but you may have to explain what you are doing a bit more ... are you only doing WebDav ?
How to use WebDav to match dav:href to Outolook Interop href value

Exchange 2007 master category list

We are constructing an application that will be interacting with Exchange 2007 calendar functions. We will be using the Outlook Redemption Objects dll’s. Our design relies upon the outlook 2007 meeting Category features. We would like to ensure that specific mailboxes have a standard set of category names and colors.
We can’t rely on users to set these up. We also can’t rely on users running the exchange client, many users will be on MAC’s and will be using OWA to manage their calendar.
As I understand it the master category list is stored in each users mailbox in an hidden message in a property named IPM.Configuration.CategoryList. I haven’t found any reference on how to set this yet.
The only things that I have found to help us are:
Group policy objects: http://technet.microsoft.com/en-us/library/cc179073.aspx As I understand this, it won’t manage the color’s and relies upon the exchange client.
A third party tool - http://www.vboffice.net/product.html?id=2006063&cmd=detail&lang=en&pub=6 The enterprise edition appears to do what we want but is expensive for a once per mailbox operation on 100 or so mailboxes.
Basically, our preferred solution is to be able to produce a script that accepts a mailbox name and sets up a standard master category list.
we were able to accomplish our task using the code at http://gsexdev.blogspot.com/2007/08/adding-categories-to-master-categories.html
AFAIK, the categories for mail box items are stored in local outlook profile and not on the exchange server.Before Ol 2K7, these were stored in registry so I doubt if category master list can be set on E2K7.

Resources