This page states that before an application can access the API (I'm particularly interested in the Calendar API), it must be registered with Azure AD. Is this also true for organizations that may host their own Exchange servers?
Could someone provide a breakdown of what's necessary for me to get started with accessing the API to access the users' Calendar? I'm aware of the API reference, but I'm not entirely sure what's necessary to do before I can use the API.
That page is for Office365, not self hosted ones.
You can access your local/self hosted Exchange server with Exchange Web Services by using username/password, or even your local AD if you set it up correctly.
The API it is talking about is not available to on-premise Exchange Server, it is only available to Exchange Online in Office 365. This may change in the future, but currently you cannot use it in on-premise. Exchange Web Services is the way to go for on-premise.
Related
I´m trying to get data from On-Prem Exchange Server (2016, with latest version) using MS Graph API in a non-hybrid environment.
I´ve registered the application in Azure AD, using application permissions and granted the admin consent already. After performing a http get operation it will give the following error:
Error authenticating with resource
After some research throughout the web I´ve found this article https://www.signorellidenis.com/en/graph-authenticationerror-trying-to-get-the-exchange-server-on-premises/
It seems that on Exchange side there is a missing authentication provider, so that all requests aren´t even forwarded from MS Graph to Exchange.
My questions are:
Does it work to perform requests to Exchange via MS Graph in a non-hybrid environment? There are no information in the official documentation about this issue.
Does it work without an authentication provider? Is there another way to perform requests in the environment? Or is the hybrid authentication necessary to do this?
Thank you very much in advance for any hints on this issue!
Just get a confirmation from Microsoft Support that It's not supported to make requests to pure on-premise Exchange 2016 via MS Graph.
MS Graph is designed for O365 cloud data. There is no permission to access on-premise resources.
In a hybrid environment, we can say that we use MS Graph as the interface to require the data. But it still most likely uses EWS to request data from on-premise.
The only way to access data from on-prem Exchange 2016 currently is hybrid deployments. See this document.
Good morning everyone,
My apologies if this post is too similar to this post:
Dynamics 365 and Azure integration
but I am struggling to understand exactly what is needed in order to setup a web service on an Azure server that is consumable by a Dynamics 365 plugin. Based on my research it appears that it goes as follows but I would like to see if any knows of a better guide.
1.) Construct the web service as normal on the Azure Windows Server.
2.) Register a proper DNS Domain name (friendly-name) and route it to the Azure server.
3.) Secure that Azure server/URL with a certificate.
4.) Call the web service from my C# Dynamics 365 plugin.
Is that everything or might I be missing something critical? Thank you!
4 might be an issue, given you want to use certificate based security, not sure that will work, you might need to use another mechanism, e.g. basic user name and password. Otherwise looks okay.
Plug-in isolation, trusts, and statistics
Web access
Sandboxed plug-ins and custom workflow activities can access the
network through the HTTP and HTTPS protocols. This capability provides
support for accessing popular web resources like social sites, news
feeds, web services, and more. The following web access restrictions
apply to this sandbox capability.
Only the HTTP and HTTPS protocols are allowed.
Access to localhost (loopback) is not permitted.
IP addresses cannot be used. You must use a named web address that requires DNS name resolution.
Anonymous authentication is supported and recommended. There is no provision for prompting the logged on user for credentials or saving
those credentials.
Im currently using the Exchange EWS api to sync two calendars. There is a customer that does not want open up EWS to the public.
Are there any other methods, apis, etc to CRUD Exchange calendars?
DavMail is a POP/IMAP/SMTP/Caldav/Carddav/LDAP exchange gateway. It's implemented in Java and should run on any platform.
It's been a while since I've implemented it on local machines for single app use inside a WAN and also on web facing servers as a general gateway into Exchange for Linux users.
I don't know if it plays well with O365 etc, as I haven't needed to find out yet.
Its a SourceForge project with some sponsorship from the French Defense Agency.
I am curious to know why we always need to register our CRM online instance on an Azure Active Directory in order to authenticate the Web API while accessing from outside CRM domain.
That is, for example, if I need to access CRM online instance through another website using CRM's Web API endpoint, then I must register my CRM instance to Azure Active Directory.
Though I am aware that, its a very nominal charge to create an Azure Active Directory, still I would need to subscribe to Azure even if I just want to perform some general research for CRM connectivity through Web API.
Why this is must? Are there any security considerations behind this?
Why can't we use the same authentication mechanism as we used to do with Organization service?
Any details on this will be much appreciated.
The CRM WebAPI uses OAuth2 and Azure AD is the only currently supported authentication platform to provide this (Windows Server 2016 will support OAuth2 for on-premise).
The Organisation service is a WCF service and as such uses SOAP for authentication and authorization. This is an entirely different technology stack that brings it's own set of problems, many of which the OAuth2 protocol tries to solve in this scenario.
Although you manage your CRM Online users through the Office 365 portal the underlying technology for these accounts is also Azure AD. Check if you can use this existing AD tenant created as part of your subscription rather than having to create another.
If you are using CRM online you already have aan Azure Active Directory. If you haven't already done so, you can signup for an Azure subscription and import the underlying AAD into your Azure subscription. You will need a credit card, but as far is I know using the Azure AD is free.
I'm using Exchange Web Services Managed API 1.0 to access the Exchange servers (2007) in my organization. I need to iterate over all the mailboxes on a given server. I haven't seen a way to get the list of mailboxes defined for a given Exchange server. I have been able to use the AutoDiscover service to find the address of a hub server for a specific mailbox, but I'm interested in getting a list of all mailboxes. Can someone point me in the right direction?
If your problem is not yet solved I would you recommend use just pure LDAP queries instead of Exchange Web Services. The information which you need are saved in homeMDB, msExchHomeServerName and probably homeMTA Active Directory attributes. You can modify LDAP query from http://www.msexchange.org/tutorials/Creating_a_list_of_Users_and_their_email_addresses_in_Exchange_2000_2.html or http://technet.microsoft.com/en-us/library/bb125087(EXCHG.65).aspx to receive information which you need.