I have a need to connect to Office 365 in order to get some scheduling appointment for a room, make a book on a room if is available, modify and detele room's booking.
Log time ago I used Exchange 2007/10 for synchronisation, but now I'm a little lose in the Office 365 environment ...
I try to use Microsfoft Graph API and my personnal (just a mail on outlook.live.com) or company Outlook account in order to play with the use case.
But I don't understand how to connect a C# program to the new Office 365 access, because I Exchange 07/10 it was with a IIS actived EWS service with a certification. Now It seem to be with a Azure ID, but I don't understand if is really reccured even if you only use a simple C# program with you personnal account, you don't have a Azure App IP ...
Someony can give me some clues to create my connection plz ?
Thank a lot
I try to use Microsfoft Graph API and my personnal (just a mail on outlook.live.com) or company Outlook account in order to play with the use case.
You can get a proper Office365 to learn with by joining the Office365 developer program which is free https://developer.microsoft.com/en-us/microsoft-365/dev-program. You will also get an Access to the Azure Portal with this and be able to create Application registrations for oAuth
I would also suggest you look at using the Graph explorer https://developer.microsoft.com/en-us/graph/graph-explorer this allows you to test and learn how the Graph works
When you ready to code you can use the QuickStart for the Graph https://developer.microsoft.com/en-us/graph/quick-start which is quite good and step you through what you need to do.
Related
Need feedback and input. Here's a scenario. End goal is to update a custom list in Office 365 SharePoint site using data from external site. Note that SharePoint is not on-premise.
End-users fills out a form online at a 3rd party web site
-- Assume that your org does not want to drop this 3rd party web site for any reason
Form data is posted to an internal database
-- Assume DB is inaccessible from 3rd party site except via web form grid view and managed exports via CSV
Web Hook endpoint is configured to also send form data to receiver on MS Azure
Azure endpoint "receiver" gets and stores form data in Azure storage account queue
That's the first phase. How would you "feel" about the second phase being this scenario?
A web service coded in C# installed on a local server that periodically wakes up
-- Yes, I know that you can also store a C# developed service on Azure cloud. But let's assume that you are a frugal penny savings minded accountant in a previous life.
-- Yes, I'm also aware that a local service approach short-circuits the entire online path that the form data would otherwise take. But let's assume that at least one other person in the team agrees that locally, we have much more control with what we can do with the data, assuming that it's final destination as a new item a SharePoint list is just the tip of the iceberg.
Connects to Azure online storage
Downloads all queue items for processing
Saves queue items as new items in Office 365 SharePoint List
Dequeue items in Azure queue
Note: In this scenario, we're not taking advantage of Azure Queue Trigger which would require the second phase of the project code to reside in Azure also. Either as a Azure function or function app. Whichever the correct nomenclature is. The strategy for this approach is to save time from having to go through all the steps for coding authentication (OAuth or otherwise) to access the Office 365 SharePoint List. Lots of steps here and various choices for which SharePoint access methodology to use, i.e. REST, CSOM, etc.
Note2: A local service app in customer domain using local domain credentials (credential also added to Office 365 SharePoint site) will have trusted access to SharePoint list so there's no need to configure AD nor configure any certificates just for adding a new item to a SharePoint list.
-- Assume you already have some C# plumbing for Queue Trigger and that you can successfully read items in the queue. The only missing piece at this point is sending the data to Office 365 SharePoint online.
So, Yay or Nay? To help with understanding, what are the flaws in the second phase thinking/strategy and how would it negatively impact you if you were a developer having to maintain this solution in the event I am abducted by outer space aliens or fall into a very deep sinkhole that winds up somewhere on the other side of the planet, after the solution goes into production? Would you lay flowers on my cemetery headstone or spray paint graffiti on it?
What would you prefer, if any, to see as the second phase of the solution (that's all after storing form data into Azure Storage Queue?) (Keep in mind the monthly costs of Azure).
I've got to write some tool that will track meetings among the whole company. To do this I need to have the information on all appointments from all folders of all users. EWS API seems to only work with one user at the time and requires user credentials (did I miss something important here? ). Is there other options or a strategies to implement this approach?
P.S. I also found that there is OAuth that probably can help me with this task, but I didn't find any information whether it works the way I need it with Exchange Server 2013
I have read a lot of articles about Office 365 API but I need additionnals informations. My goal (MVC Projet) is to collect some data (read only) of my tenant (and customers tenants) like licences subscription (like csp), user informations (like affected , affected licenses), ...
I think to use Microsoft Graph .Net Library.
Is it possible to interact by the api with tenant of my client (I'm Office 365 Partners) by login in my tenant (as the delegate permission in the admin portal) ?
Is it possible to have only an application authentication without requierd an additionnal MS account to login to the api.
Thanks for help,
Regards,
Yannick
Using the CSP/partner model to call Microsoft Graph (and either have your app pre-consented for application permissions/auth OR for your Agents to log in using delegated admin privileges to your customer tenants) is NOT yet supported, but is coming soon.
Please take a look at https://dev.office.com/blogs/microsoft-graph-or-azure-ad-graph for what is supported (Directory features) in Microsoft Graph. This article was updated very recently.
Hope this helps,
I am using Azure Active Directory as a base for security/permissions to a Sharepoint 2013 portal. I developing an administration UI using Graph API to load and edit data from the Azure Active Directory. The setup also includes Exchange Online, such that each user defined in the system will be given a mailbox in my domain. The Groups and Users in the Azure Active Directory are synced to the Sharepoint 2013 and Exchange Online using DirSync.
The plan is to use the administration page to consolidate certain expected actions, including creation of new users, connect them to the relevant security groups, as well as creating new mail-enabled security groups.
As is described in the Graph API Group Overview, only "pure" security groups are allowed to be created. Further more, the Graph API does not allow the mailEnabled field to be updated to true after creation... In fact, the Azure Active Directory management screen is so limited that a mail-enabled Group cannot be created there either (or am I missing something?).
I am trying to find a solution that will let me still to consolidate all of the actions that I wish to allow under one administration application.
It seems that PowerShell might be an option, though I am not exactly well-versed in using PowerShell.
I have tried to find an API that would allow me to connect to Exchange Online and perform similar actions - DirSync seems to sync everything from there to Azure Active Directory just fine - I create a mail-enable security group in Exchange and I get a mail-enabled security group in Azure Active Directory moments later - I have not been able to find such an API. Does it exist?
Am I looking at it all wrong? Is there a simply solution to my needs as stated above that I am simply not aware of?
Doesn't sound to me like you're missing something. The thing is, mail-enabled security groups only make sense if you have something providing the "mail". For Microsoft's online services, this would be Exchange. Azure AD and "pure" security groups apply everywhere, but one could argue mail-enabled group only applies if Exchange is in the picture. Anyway, that's an attempt to explain the why.
As to programmatically accessing Exchange, you have many options (see Exchange Online and Exchange 2013 development (in no particular order):
a) Exchange PowerShell cmdlets
Exchange allows you to programatically create and manage distribution groups with the Exchange Online PowerShell cmdlets. For example, the New-DistributionGroup cmdlet:
New-DistributionGroup -Name "My Favorite People" -Type "Security"
As you've noticed, these groups will be synced back to Azure AD as read-only. You can then use them (for example) with Azure AD Graph API to do RBAC based on group membership.
a.1) Exchange PowerShell cmdlets run from C# code
If you want to run these cmdlets from other .NET code (e.g. C#), it is doable. Take a look at the example in How to: Get a list of mail users by using the Exchange Management Shell. It can easily be used to get/set groups instead of users.
b) Exchange Web Service and EWS Managed API
Your best bet at this point might be to use EWS Management API:
Get started with EWS client applications
Get started with EWS Managed API client applications
c) Office 365 API (although this scenario is not currently supported)
Keep an eye on the Office 365 API, which doesn't look like is support this scenario yet, but looks promising: http://msdn.microsoft.com/en-us/library/office/dn605892(v=office.15).aspx
I'm trying to create a client-server application, with authentication through Office 365. I`ve chosen this way: client send login/password to server and server just check if they are correct.
I dont know how to create such checking of login/password.
I have found some OAuth samples, but they are all about authentication in apps, created for services like Twitter,Facebook etc. This is the way they are obtain consumer key and secret.
I have aslo found how to sign in programmicaly with help of PowerShell or WebClient class, but that is just signing in, how would i know in login/password are correct?
Maybe those are very close to what i want to do, but i can not change and tie them to my programm. Please, help me with that.
What's your goal? To build an app that works with Office 365 assets? If yes, look for Apps for SharePoint. If no, then look for Windows Azure Directory Services and Access Control Services—that's the authentication and user management engine behind Office 365.
Try the following solutions:
http://blogs.msdn.com/b/cjohnson/archive/2011/05/14/part-2-headless-authentication-with-sharepoint-online-and-the-client-side-object-model.aspx
http://blog.kloud.com.au/2013/03/24/sharepoint-online-web-service-authentication-using-wcf-client-side-behaviour/