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.
Related
When creating Calendar Events via the Graph API, the events are created correctly in the calendar of the organizer but the invites to the participants get bounced. The organizer gets a 'Delivery has failed...' message with the following error message:
Remote Server returned '550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP. For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653 AS(7171)
Sending emails manually through Outlook (web) from the organizer to the participants works fine.
The issue is intermittent. After changing the DNS server, everything worked fine for some time.
I checked https://protection.office.com/restrictedusers as suggested in the answers to similar posts, but this list is empty.
I also tried delisting the IP address (my own?) through https://sender.office.com/, but to no avail.
The tenant is linked to the Microsoft Developer Program and would allegedly have a 'bad reputation'. However, I don't understand how that would explain the fact that it sometimes works and sometimes doesn't when sending exactly the same API request and hence 'triggering' exactly the same emails...
I think the best way to overcome this would be to add a domain to your developer tenant as per the guidance here:
https://learn.microsoft.com/en-us/Exchange/mail-flow-best-practices/non-delivery-reports-in-exchange-online/fix-error-code-5-7-700-through-5-7-750#57750-client-blocked-from-sending-from-unregistered-domain
Add and validate all domains in Office 365 that you use to send email messages. For more information, see Add a domain to Office 365.
I'm not guaranteeing this will resolve it. You have to understand that those developer tenants are only meant for experimentation and so there are checks and balances to ensure they are used in a bad manor.
How many emails are you sending through this tenant?
Calendar events are sent out via email. Add the "Mail.Send" permission to you App Registration.
This solved it for me.
I've developed an add-in for Outlook, it needs to be able to access attachments to emails.
On the desktop app, if I move an email with attachments from a shared folder to my main inbox, then try to run the add-in on it, i get the error:
The specified attachment Id is invalid.
However, if I perform exactly the same operation through the web app, it works fine.
I have checked and the Office.context.mailbox.item.itemId and Office.context.mailbox.item.attachments[i].id are exactly the same whether on web or desktop.
Emails with attachments that have not been moved from a different folder, and emails without attachments work fine.
I am fetching the attachment on a remote server through a PHP script, using a callback token I orginally get from Office.context.mailbox.getCallbackTokenAsync. The requests are made via EWS requests.
I am running Office 365 and the Outlook version is 1910 (Build 12130.20390), running on Windows 10.
Can somebody please help?
After some helpful suggestions from #OutlookAdd-insTeam-MSFT, I've come to a solution for this.
The problem is, after moving a message from a shared folder to the main inbox, when using the desktop app, the Office.context.mailbox.item.attachments (created when we run Office.initialize) no longer returns the correct ID's, instead it seems to return the old cached/out of date ID's from before the email was moved. The ID's returned when using the web app are correct using this method.
However, requesting the ID's from the exchange server, via an EWS request (or a REST call, but I use EWS) always returns the correct attachment ID's, whether called from the web app or the desktop app.
So, the solution I have come to is to make sure and request all of the attachment ID's from the exchange server, rather than using the Office.context.mailbox.item object. It means adding in an extra step of having to get a callback token first to then be able to request the info from the exchange server, but it means you always get the correct ID's.
I hope this is of help to someone else.
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.
I can't get TFS 2010 to send email alerts. I've tried setting up everything mentioned here:
http://social.technet.microsoft.com/wiki/contents/articles/how-to-configure-tfs-notifications-in-team-foundation-server-2010.aspx
It's configured to send to a local IIS SMTP instance. SharePoint 2010 is on the same box and is also configured to use the same local SMTP server and it works fine sending emails, no problem. It's also using the same "from" email address as TFS is configured to without issue.
TFS isn't even trying to send anything as far as I can tell - I don't see anything from it in the SMTP log (C:\Windows\System32\LogFiles\SMTPSVC1...).
I have the default "My Work Items changed" alert set up and enabled. I try logging in as another user, assigning a work item to me, then assigning it back...nothing happens...no email. I don't see any error in the event viewer from TFS.
What can I do to troubleshoot this?
I had added alerts in Alert Explorer without specifying any Team Project. Once I added the Team Project filter it started working.
Try other method,
I configure the Email using Gmail Account and it is working very well, try it! if you would like? see this link for steps how you can do it?
http://mohamedradwan.wordpress.com/2011/06/26/configure-tfs-2010-alert-using-local-smtp-that-use-gmail-account/
Thanks
M.Radwan
Try this out
http://ravendra.wordpress.com/configuring-email-alert-settings-in-tfs-2010/
Or else you can go with the option of relay mail. Create a local SMTP server and relay it with the main mail server.
Note : If you mail server requires advanced authentication then you need to follow the second option only.
I actually wanted to add this answer to give ppl an idea of what to look for when they come across 'why doesn't the email get sent out'. The reason i came across this thread was for the same reason, it seemed that tfs wasn't sending out the email. But it was! the problem turned out to be the 'group' that I was sending the email to wasn't permitted to receive email. here is the situation, TFS server located at a DATA CENTER. The email ALERTS that i configured were to a group in our local office DOMAIN.
Apparently,in Active Directory that group didn't have the "All users need to be authenticated" checked OFF. Meaning, the TFS server 'sender of the email' wasn't authenticated to send emails to that group. once i sat with my MIS guys, they finally noticed that was checked on, and once DISABLED. Problem fixed! Hope that helps someone.
I am trying to send an outlook appointment through code. My code is posted below. When I run it on the server with IIS 6 and an app pool under a domain account identity, it throws this error. I have tried changing various settings on the server and none worked. Outlook 2007 is installed. I have even made the domain account a local admin. Please help!
Description: An unhandled exception
occurred during the execution of the
current web request. Please review the
stack trace for more information about
the error and where it originated in
the code.
Exception Details:
System.Runtime.InteropServices.COMException:
Operation aborted (Exception from
HRESULT: 0x80004004 (E_ABORT))
Line 201: objAppt.Send();
Code below:
Microsoft.Office.Interop.Outlook.Application objOL
= new Microsoft.Office.Interop.Outlook.Application();
Microsoft.Office.Interop.Outlook.AppointmentItem objAppt
= (Microsoft.Office.Interop.Outlook.AppointmentItem)objOL
.CreateItem
(Microsoft.Office.Interop.Outlook.OlItemType.olAppointmentItem);
objAppt.Start = startTime;//datetime
objAppt.End = endTime;//datetime
objAppt.Subject = subject;
objAppt.Body = body;
objAppt.Location = location;
objAppt.MeetingStatus
= Microsoft.Office.Interop.Outlook.OlMeetingStatus.olMeeting;
objAppt.RequiredAttendees = "test#test.com";
objAppt.Send();
objAppt = null;
objOL = null;
Yes as casperOne said I wouldn't use outlook on the server. I would use CDO or RDO(redemeption) for this. or even use vcal and send the vcal on a system.Net.Mail.
Update:
Take a look at http://www.dimastr.com/redemption/rdo/RDOAppointmenItem.htm
Show you how to do excatly what you want to do using RDO. You can do the same with CDO as well. Check out CDOLive.com
You will have to construct a teh login details as you are on a server that has no Outlook profile (thats if you remove the one that you allready have on there)
Quite simply, you shouldn't be doing this. It is not recommended that you run Office in a server environment because of the threading (and desktop session) requirements that Office has.
Are you trying to do this on an Exchange server? If so, then I would interact directly with the Exchange server (using WebDAV perhaps?).
If not connecting with Exchange, then take a look at the headers for an invitation to the event. The invitations should be nothing more than regular emails with custom header information.
I guess the reason you cannot use Outlook from an IIS application is because the current user the IIS app is running under does not have an Outlook profile associated.
Therefore you can instantiate Outlook objects and set their properties, until profile-specific functionality is required, such as the Send() command, which would store the outgoing mail in the user's/profile's (non-existing) pst file.
Don't do this using Outlook automation.
Straight from the horse's mouth:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
http://support.microsoft.com/kb/257757
Examine email headers sent by Outlook when it's doing this job to work out how this is done, and emulate it using the standard .NET SmtpClient stuff.