I need to develop an Add-in for Outlook for a Microsoft Exchange Server. The add-in has to communicate with an external API other than the Microsoft API. Is this allowed?
Yes, it is. You can develop your own service which can perform some tasks on behalf of the add-in. See Create a web service for an app for Office using the ASP.NET Web API
When making calls outside the domain your add-in is hosted in, you need to specify those domains in your add-in's manifest:
<AppDomains>
<AppDomain>http://mysite1.yourdomain.net/</AppDomain>
<AppDomain>https://mysite2.yourdomain.net/</AppDomain>
</AppDomains>
You may also find the Addressing same-origin policy limitations in Office Add-ins article.
Related
I want to know if it is possible to publish an Outlook add-in made in on VsCode on other servers like Cpanel or it's exclusive on Azure?
And after only put the manifest to point the domain that was publish.
You can publish/host your add-in on any web sever of your choosing.
One thing to keep in mind, however, is that, for your add-in to support Single Sign-On, you need to register it via the Azure portal for app registrations using the credentials of a Microsoft 365 tenant. Otherwise, you don't need to worry about Azure here. Just set the SourceLocation in the manifest to point to the location of your add-in's code on your domain.
If you only use Outlook to connect to Exchange Online then you don’t
need to worry, as long as you are using Office 2019 or Office 2019 Pro
Plus you’ll be fine come October 2020.
Quote link
I am using Outlook version 2101 from Microsoft 365. I am not using custom API's, but I still see Outlook using basic authentication. For example, I pulled four log entries that occurred with using Outlook. Log details:
Application: Office 365 Exchange Online
Client App[1]: Offline Address Book
Client App[2]: MAPI Over HTTP
Client App[3]: Autodiscover
Client App[4]: Exchange Web Services
All 4 client applications fail to support modern authentication, which will fail when basic authentication ends. What do the users of Outlook at my company need to do to suspend using basic authentication? I have been attempting to enforce MFA but cannot get past Outlook continuously prompting users for their login credentials.
Solution:
Check org setting for modern authentication. This must be turned on before MFA will work properly. You can also enable security defaults in the Azure portal, but this approach does not allow you to selectively enroll users into MFA.
Open Microsoft 365 admin center
Show All
Settings
Org Settings
Modern authentication
Turn on modern authentication for Outlook 2013 for Windows and later
This setting allows for multiple exceptions, which will support your organization to continue to use basic authentication while you transition to modern authentication.
With this setting in place, you can selectively enforce Office 365 MFA on users. Each user will have to rebuild their locally installed Outlook profile before being able to use Outlook.
Our setup consists of on-premises CRM 2016 in IFD configuration with ADFS. We have several custom web apps that are embedded in iframes in CRM as well. Our web apps are MVC running in IIS on .NET 4.7 and use the WS-Federation IIS module for authentication. This provides a pretty seemless experience where the embedded application does the redirect to and from ADFS to authenticate the user after they're already logged into CRM.
Our applications also call APIs we have created, which in turn make calls to Dynamics CRM web API using OData. Our APIs are setup to make calls to the CRM web API as a specific user chosen at deployment (it's a bit ugly, but it works). This causes issues associating created entities with the actual user, as CRM considers them created by the user in the API deployment. We need to fix that so that the user authentication is passed from our web application to our API and then to the CRM OData API.
From searching this site and other resources, I have determined this is not possible with WS-Federation and I would need to use OIDC. But, all the documentation that I have found about using OIDC in this manner has involve using Azure Active Directory and Dynamics 365, which does not apply in my scenario. I haven't found any information for the configuration of a local CRM 2016 instance or ADFS.
How is this accomplished for an all on-premises deployment?
To impersonate a user, set the CallerId property on an instance of
OrganizationServiceProxy before calling the service’s Web methods.
via https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/org-service/impersonate-another-user
Or
To impersonate a user based on their systemuserid you can leverage
MSCRMCallerID with the corresponding guid value.
via https://learn.microsoft.com/en-us/powerapps/developer/data-platform/webapi/impersonate-another-user-web-api
Although I can't guarantee that it will work in version 8.1 and below.
I'm trying to connect an application I've written with an old on-premise Exchange 2010 server. Obviously this is not supported, I was wondering if Outlook 2010 end users + Exchange online server would allow the use of Microsoft Graph API?
If the Mailbox is an Office365 Mailbox (or you've configured hybrid https://blogs.msdn.microsoft.com/deva/2019/03/16/deep-dive-how-to-configure-exchange-on-premise-server-hybrid-integration-with-office-365-test-rest-api-calls/) then you can use the Graph API to access that Mailbox. The version of Outlook doesn't really matter as the API is strictly service side, but depending on what your actually doing client side you may find a lot client side integration pain and you would be better to upgrade the latest version of Outlook on the clients. That would give you more options when you redevelop your application as you can make use of the new Addin's platform etc.
I need to be able to extend CRM 2011 which is running in the cloud. I need to be able to perform CRUD operations from a completely separate internet web site. What options do I have? I have zero experience with CRM. I just found out that the OOB web services can only be accessed within the context of CRM.
I just found out that the OOB web services can only be accessed within the context of CRM.
This is only true for the REST endpoint. Not for the other endpoints. You can access the IOrganizationService if you use .NET as basis or you could access the web services via SOAP.
Use the WSDL Endpoint
http://blogs.msdn.com/b/girishr/archive/2011/03/22/crm-online-2011-web-services-soap-sample-now-ready-for-emea-amp-asia.aspx
CRM 2011 exposes webservices through oData and SOAP endpoints. If you are using CRM 2011 Online you can hit these endpoints over the internet. If hosting CRM yourself, you can set it up for IFD (Internet Facing Deploy). I would suggest taking a look at the CRM 2011 SDK for oData and SOAP examples.