I'm trying to query the Global Address List using Microsoft Graph. I've worked with and adapted the sample code from https://github.com/microsoftgraph/console-csharp-snippets-sample.git -- however, I'm still having trouble. I've seen this article -- Global Address List Graph API -- which indicates I need to use the "/contacts" endpoint. However, I don't see how this helps me when I'm using the Microsoft.Graph library. Is there some method or collection within the Microsoft.Graph library that will allow me to read the GAL?
"GAL" is a MAPI concept that doesn't really apply to Graph. With Graph, you just read the users or contacts in your company's Active Directory. By combining both lists, you come close to what you'd see in the GAL in a MAPI client.
To do that, you would list users as doc'ed here: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/user_list
Using the library, I believe this will get you started:
client.Users.Request().GetAsync();
For contacts, it's a lot trickier with the Graph library. Organizational contacts are only supported in the beta version of Microsoft Graph, which the client library doesn't support unfortunately. (See this issue for info). Michael Mainer did a write up of how you can generate your own beta version of the library if you're interested.
The info on querying organizational contacts is found here: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/orgcontact.
As of late 2021, doesn't appear to be an easy "Export Global Address List" API from Microsoft. There appear to be manual methods (e.g. using the Exchange Admin interface) but nothing programmatic.
Below is broad strokes exercise for creating an approximation (that may be sufficient for your needs). A more accurate exercise may be to export the GAL from a official client (e.g. Outlook/Outlook Web/Exchange Admin interface). Its possible that in some cases the GAL is user specific which may make GAL export concept significantly more involved.
GAL export exercise:
APIs:
MS Graph API (available via HTTP, e.g. GET/POST)
Users
Groups
Some of the above only allowed certain properties accessible by individual record query - I needed to get the whole list then iterate through each record one by one to get all needed properties.
Exchange Powershell (available via Powershell)
Get Mailbox (for flags not exposed by Graph/Users)
Get-DistributionGroup (for flags not exposed by Graph/Groups)
Azure Functions can be used to run these queries serverless/"API-ified". Azure App Registration can be used as OAuth app that can be granted the permissions to access the above. Microsoft Graph Explorer is handy for testing Graph requests.
Put it together:
Smash the datasets together and then filter out on fields. Some flags are:
hideFromAddressLists
hideFromOutlookClients
HiddenFromAddressListsEnabled
showInAddressList,
some conditions you have to manually check for, e.g.
if no provisioned plans (i.e. unlicensed)
if no email address
etc.
Related
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,
I'm using the Microsoft.Graph NuGet package v1.4 to connect to Microsoft Graph. Setting up the connection works fine and I'm able to connect and retrieve my contacts:
var client = AuthenticationHelper.GetAuthenticatedClient();
var contacts = await client.Me.Contacts.Request().GetAsync();
This works like a charm and I'm able to retrieve my contacts. Now I'm looking to delete some of my contacts ( my duplicates in fact ). The REST methods are there:
Described here:
DELETE https://graph.windows.net/myorganization/contacts/{object_id}[?api-version]
But I'm not able to do it through the NuGet package. Is this not implemented in the .NET API?
Looks like you are mixing and matching a few things here. So in Microsoft Graph, we have the notion of personal (or my) contacts. which you are able to find with the nuget package - it should support delete too. But then you are looking at the Azure AD Graph contacts API documentation, which is different (and is about organizational contacts only).
The documentation you want is here: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/contact
If you also want to manage organizational contacts (different from personal contacts), this is only available in /beta (preview) and is not exposed through the Microsoft Graph nuget (since we currently only expose v1.0 GA API through the client libraries). I just noticed that while we have org contacts documented (in GitHub), it's not in the table of contents, so I'll file a bug for this.
UPDATE (based on comment): Please see https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/contact_delete for info on deleting personal contacts. This should also be available through the client library, my guess is through a DeleteAsync() method on a selected contact.
Hope this helps,
Since Graph is a self-documenting language, I wanted to use this to my advantage and write PowerShell functions to automatically generate cmdlets based on metadata. I've got a lot of this complete, but am having problems figuring out scopes. Is there a way to find scopes? It's not stored in the metadata and the documentation doesn't have scopes listed for everything (for instance, nothing in Excel has scopes listed).
The Graph Explorer seems to request correct permissions, so that has access to this list somewhere.
It depends on which API you are looking for.
Scopes for Azure AD Graph API is at https://msdn.microsoft.com/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes.
There is a huge list for different parts of the Microsoft Graph API at https://developer.microsoft.com/en-us/graph/docs/authorization/permission_scopes.
When you first sign in to Graph Explorer, you give it these permissions:
Based on the descriptions and the link above you can figure out what the scope name is for each of the items in the list. (E.g. the first one is Mail.ReadWrite).
When you create an application in Azure AD, you configure which applications it needs access to, and what access it needs. That results in the list which the user grants access to on first signin.
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.
I am researching the available methods for surfacing content in Delve from external systems.
The only two options for pushing information into O365 that I can find are Office 365 Connectors and Graph Data Extensions (openTypeExtension resource type).
My questions are:
How are these technologies designed to work and will either of them be included in Graph -> Users -> Insights -> List trendingAround and List workingWith?
Is there a way to surface the Connector Cards in Delve?
Are there any other mechanisms available to include 3rd party data in Delve?
There was a session at Microsoft Ignite 2015 that demonstrated the features that I'm looking for, which were unavailable to the public at the time but it looks like that was before Connectors and Data extensions became available.
https://channel9.msdn.com/Events/Ignite/2015/BRK3193
From the description: "We’ll also demonstrate how you in the future can push external content and signals into the Office Graph from Line of Business systems and 3rd party services to enrich it even further."
The demo is at about the 30:00 mark.
There has been contact with some people at Microsoft and they told us it isn't possible at the moment, but all the data show that it will be in the future. More will be made known at //Build.
The Connector cards probably will be made available via the Office Group Connectors in your Office365 Outlook account; in a Group, at the top right, there is a button 'Connectors'. I'm guessing you already found those.