When performing the Graph request /me/drive you are able to retrieve the id of the drive.
I'm wondering how unique this id is. Is it only unique in your tenant or is it unique in the whole Office 365 / Microsoft cloud?
It should be unique in the whole O365/Microsoft cloud, so Microsoft can maintenance the rule in the later period,just like the GUID. Of course, the id format rule are different from OneDrive(e.g. 3c67c2629e95add3) and OneDrive-For-Business(e.g. 05kpQIVuAkebEbnq3ftalG9eKBXqLXRJiiiQGZjVlDqML5T888BfS4YjkXMj9Exl).
You can see the definition of the Graph:
Microsoft Graph is the gateway to data and intelligence in Microsoft 365. Microsoft Graph provides a unified programmability model that you can use to take advantage of the tremendous amount of data in Office 365, Enterprise Mobility + Security, and Windows 10.
https://developer.microsoft.com/en-us/graph/docs/concepts/overview
The onedrive id maybe fully public, so it should be unique identity.
The onedrive-for-business maybe private, so it maybe not unique. But for the standardization, it should be unique identity too.
Related
The Power Shell cmdlet Get-MsolSubscription has a NextLifecycleDate field which gives me the expiry data of my Office 365 subscription. Microsoft Graph Get subscribedSku does not appear to include this info.
Is there a Graph API to get the the expiry data?
None of the endpoints in Graph return a NextLifecycleDate property. The Get-MsolSubscription is most likely retrieving this data from another source (i.e. the O365 cmdlets may not always be using the Graph behind the scenes).
In outlook I can lookup all users in my organisation, including phone number, address etc.
I guess using EWS I could do the same...
With Azure AD graph (https://graph.windows.net) I can get ALL(!) properties on all (GAL) users as well - without the option to select a smaller property subset…
In Microsoft Graph (https://graph.microsoft.com) I can get all users (GAL), but not (all) properties like phone number, title etc. without an admin allows access… Why is this different (more restricted) than the other APIs ?
ex. the permission; Directory.AccessAsUser.All (Access the directory as the signed-in user)
In Microsoft Graph user is UNABLE to consent
In Azure AD Graph - does NOT require admin
Using the /me/people (in preview) in Microsoft Graph I can get all properties on a lot of users in my organisation - but not all. And I might get some users that my nearest colleague can’t (why? - is it still buggy)
Every one tell you to use Microsoft Graph but it seems to be more restricted than the old APIs
I'd be interested to know a little more about the restrictive nature that you are describing. For the most part (with respect to Directory/Azure AD), Microsoft Graph exposes the same data secured by the same permissions model as Azure AD Graph. Please see https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference#user-permissions for more details on the available user permissions and what they allow.
What you might be seeing with Microsoft Graph is the fact that when you query the /users entity set in v1.0 (i.e. GET https://graph.microsoft.com/v1.0/users) Microsoft Graph will return only a key set of user properties by default. The user entity type is pretty big, and growing all the time - it has more than 40 properties and 25 navigation properties. Serializing and de-serializing large objects, especially when paging collections can be expensive and non-performant, both for the client and for the Microsoft Graph service. Hence we return a default set. If you want other properties then you need to use the $select parameter. For example: GET https://graph.microsoft.com/v1.0/users?$select=displayName,givenName, officeLocation,postalCode,state. This is documented here: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/user_get for example, but we are working on making some improvements to the documentation in this area too. If you want to see the full set of properties exposed by the Microsoft Graph user entity type, please look at the schema here: https://graph.microsoft.com/v1.0/$metadata.
[NOTE: $select is not supported in Azure AD Graph API, so we always return the full set].
The people API - ../me/people is about the people who you (the signed-in user) communicate with most often - it could also contain people outside of your organization. Hence, the list of people is likely specific and different for each user (even colleagues). It also is not the full directory of users in your organization.
I'd also like to get to the bottom of why you are seeing a difference in terms of consent - Directory.AccessAsUser.All always requires admin consent for web apps (for both Microsoft and Azure AD Graph).
Hope this helps,
Office 365 administration center allows to create organizational contacts which are shared with all users in organization.
In MS Graph documentation API of this functionality is badly documented and located in BETA section. Moreover, there is no command to create such a contact: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/orgcontact
It looks like in Graph this functionality was not implemented. Using typical POST request to the /beta/contacts ends with an error response in Json structure: Unsupported resource type 'Contact' for operation 'Create'.
Note 1: I don't have any user logged in. My application uses service/daemon authentication.
Is there any other way to create organizational contact?
At this time, creating new orgContact objects isn't supported by the Graph API. You also cannot create organizational contacts with the Azure AD Graph API. For more information about organizational contacts, including how they are created in your tenant, see the Contact Entity documentation.
Organization Contacts are documented in the beta section because this API is in fact still in beta. I'm sorry you ran into issues here but with any beta endpoint there is always likelihood of missing/broken features and sparse documentation. There is also a substantial likelihood of breaking changes being rolled out to beta endpoints. As such, we do not recommend using them in production scenarios.
Using PHP and the Microsoft Graph API I'm fetching a user by querying:
https://graph.windows.net/<tenant>/users/<userId>?api-version=2013-11-08
This works fine, but only returns the standard fields for the user object. According to the documentation I'm supposed to be able to use $select=* to get all the user data, like this:
https://graph.windows.net/<tenant>/users/<userId>?$select=*&api-version=2013-11-08
However this gives me the following error:
{"odata.error":{"code":"Request_BadRequest","message":{"lang":"en","value":"The ability to use the $select query option to define a projection in a data service query is disabled. To enable this functionality, set the DataServiceConfiguration. AcceptProjectionRequests property to true."}}}
How can I enable "AcceptProjectionRequests"? I find nothing about this in the documentation or in other SO-threads.
The APIs you are referencing above are Azure AD Graph which is different than the Microsoft Graph APIs. It might be worth your time to have a look at the Microsoft Graph APIs and consider transitioning away from Azure AD Graph. The general guidance from the Azure AD Graph team recommends using the Microsoft Graph instead of the Azure AD Graph. You can read more about the differences and the Azure AD guidance here.
Having said that, Azure AD Graph does not support $select (as stated in the blog posting I linked to above). Microsoft Graph does support $select for doing query projections (see Microsoft Graph or Azure AD).
Currently (as of 7/8/2016) Microsoft Graph supports most of the directory features that Azure AD Graph supports, but not all. In some cases, Microsoft Graph supports functionality that is not in Azure AD Graph (such as ability to make $select projection queries).
Per OData spec, $select=* can either return all entity properties or a default set of properties (provided the default set contains all key properties). The Microsoft Graph implementation is the latter and it will return a set of key properties. In order to get all the necessary properties you need, you will need to explicitly request the entire list you want unless they happen to be within the default set.
The reading I'm doing here seems to indicate that Microsoft Graph is for exposing Office 365 as an API.
The same link indicates its Office 365 and Azure AD. But you have to have an O365 account to interact with the graph.
That eliminates the use case of people who use only Azure AD, say for authentication and authorization in SaaS apps.
So, I've been asking about using Micrsoft Graph vs using Azure AD. Is it that as long as I'm not interested in the 0365 side of things that I should stick to the AD graph?
Update: Here's a blog from Microsoft on the matter. They said, "We strongly recommend that developers start using Microsoft Graph over Azure AD Graph, unless specific gaps prevent you from using Microsoft Graph right now."
Even if all you want to use are directory features, I would encourage you strongly to use Microsoft Graph. We are adding new directory features to Microsoft Graph that may not show up in AAD Graph and we are busy working to make sure that Microsoft Graph provides all the directory features that AAD Graph provides (and more).
You don't have to have an O365 subscription to use Microsoft Graph (just an AAD tenant) - it's just that Microsoft Graph exposes a lot of rich data that comes from Office 365, including calculated insights.
Please let me know if you are having any challenges with this.
Hope this helps,