"Resource not found for the segment" using Graph subscription beta - subscription

Im using the Microsoft Graph to get calendar event with application permission. It works perfectly. Now Im trying to set up a subscription to listen to event changes however the normal v1.0 do not suport this. However beta, at least in the description, say it works.
From the page: https://graph.microsoft.io/en-us/docs/api-reference/beta/api/subscription_post_subscriptions
"Note: the /beta endpoint allows Application permissions as a preview feature for most resources."
So I tried this with the URL:
https://graph.microsoft.com/beta/subscriptions
Sending in a json object like this:
{
"changeType":"created,updated,deleted",
"notificationUrl":"https%3A%2F%2FXXX.com%2Fo365.php",
"resource":"%2Fusers%2Fooom%40xxx.com%2Fevents",
"clientState":"1486588355561",
"expirationDateTime":"2018-11-20T18:23:45.9356913Z"
}
Doing this I get the result:
{
"error": {
"code": "BadRequest",
"message": "Resource not found for the segment '/users/room#xxx.com/events'.",
"innerError": {
"request-id": "d9ca58b1-ee1f-4072-81d5-0f1a25dcdd45",
"date": "2017-02-08T21:26:51"
}
}
}
I have tried all types of combos in the resource but cant get it to work.
Anybody that have an idea on how to do this?

The value of json properties don't need to be url encoded. The resource also doesn't need a '/' in front of "users" (although this isn't what is causing your issue).
Try changing your JSON to:
{
"changeType":"created,updated,deleted",
"notificationUrl":"https://myurl.com/o365.php",
"resource":"users/person#myemail.com/events",
"clientState":"1486588355561",
"expirationDateTime":"2018-11-20T18:23:45.9356913Z"
}
Feel free to respond back if this doesn't address the issue.

Related

Error using '/directoryObjects/validateProperties' API: Invalid entity type provided

When using the directoryObjects/validateProperties API for creating/validating AD Group properties, a 400 error is returned indicating 'Invalid entity provided. Supported entities include: Group'. I have confirmed that the only entityType I am providing in the request is 'Group' or 'group'.
{ code: 'Request_BadRequest',
message:
'Invalid entity type provided. Supported entities include: Group.',
innerError:
{ 'request-id': '4949163f-43c4-42e8-b016-436af61e4eb5',
date: '2020-06-11T10:29:08' } } }
The error occurs in both /v1.0 and /beta versions of the MS Azure AD API, with the body/payload stringified or not.
Not exactly sure what is expected. Can someone please provide assistance on this? Thanks.
I have validated the properties by using the same JSON Data from the document in the Graph explorer and it worked for me.
This is the below data which I have given
{
"entityType": "Group",
"displayName": "Myprefix_test_mysuffix",
"mailNickname": "Myprefix_test_mysuffix",
"onBehalfOfUserId": "1ab4e79f-5f52-44b8-8c72-7d03c05e6ff4"
}
And I am hitting the V1.0 endpoint
https://graph.microsoft.com/v1.0/directoryObjects/validateProperties
Try with my sample copying it change the onBehalfOfUserID to your userID and hit the same Http call in Graph Explorer.

Updating Skills property of User through MS Graph API fails

I'm trying to update the "Skills" property of a user (note: NOT using the Me endpoint). This returns an exception. I'm using the .NET SDK GraphServiceClient to do so, using the latest 3.6.0 version.
To Reproduce
Steps to reproduce the behavior, use the following sample code:
var user = new User()
{
Skills = skills
};
await graphClient.Users[userId].Request().UpdateAsync(user);
Expected behavior
I'd expect this code to send a POST request to the Graph API endpoint and that request should update the Skills property of the given used, provided that the authenticated service has been granted the User.ReadWrite.All permission in Azure AD (which it has).
Instead, the following error is being returned by the Graph endpoint:
"error": {
"code": "-1, Microsoft.SharePoint.Client.InvalidClientQueryException",
"message": "A type named 'Microsoft.SharePoint.user' could not be resolved by the model. When a model is available, each type name must resolve to a valid type.",
"innerError": {
"request-id": "1948a4ec-60fd-4212-873f-3d34f62f5601",
"date": "2020-05-25T09:35:33"
}
}
}
Not sure why this would not work. I followed the samples although those do not specifically mention updating the Skills property, you'd expect that to work equally for all properties. When I omit the property from the updated User object, I do not get an error in return (but obviously there's nothing updated in that case).
Till it is fixed in v1 as mentioned by baywet you can also use the following as work around for your scenario.
Graph client by default adds odata.type as microsoft.graph.user and sharepoint doesn't expect that value. You could change the oDataType to "https://graph.microsoft.com/v1.0/$metadata#users/$entity" or "Microsoft.SharePoint.user" or null, so that sharepoint can understand the type.
You can set the oDatatype by
var user = new User()
{
Skills = skills
};
user.ODataType = "https://graph.microsoft.com/v1.0/$metadata#users/$entity";
await graphClient.Users[userId].Request().UpdateAsync(user);
This is an ongoing issue that is being addressed in the service. The beta version should already be fixed and the v1 is in progress.
As a workaround you can either use the beta version or craft the request manually without an odata type.

Ability to filter users with onPremisesSamAccountName with Microsoft Graph API

I would like to filter Users from Microsoft Graph API based on onPremisesSamAccountName, which is currently not available with Graph API.
We have the internal employee id to be stored with onPremisesSamAccountName variable which is present in users API of Microsoft Graph. We are trying to filter with onPremisesSamAccountName property to filter based on the internal employee id. Currently, we are not able to do that with Graph API but we really need this to be working or would be happy if we get to know any possible workarounds.
https://graph.microsoft.com/v1.0/users?$filter=onPremisesSamAccountName eq '[some-id]'&$select= userPrincipalName,displayName,department,jobTitle,companyName,onPremisesSamAccountName,....[more list of fields for select]
The expected outcome is to show the required result but the response what we got is as follows:
{
"error": {
"code": "Request_UnsupportedQuery",
"message": "Unsupported or invalid query filter clause specified for property 'onPremisesSamAccountName' of resource 'User'.",
"innerError": {
"request-id": "[request-id from request]",
"date": "[date on which request is made]"
}
}
}
As you can see, the filter is not supported for property 'onPremisesSamAccountName'.
If you do have this requirement, you can post your idea at Microsoft Graph UserVoice.
I was able to do a filter using onPremisesUserPrincipalName - you could check what is returned using this property and see if you can make it work

How to update the users birthday

I want to update the birthday of a user using the patch request.
Updating other properties works as expected but the moment the birthday property is included, the following error returned:
The request is currently not supported on the targeted entity set
I already tried to update the user to be sure the permissions are fine.
Application permissions are used.
This PATCH request to /V1.0/users/{id} works:
{
"givenName": "Fridas"
}
Passing this request body however:
{
"givenName":"Fridas",
"birthday" : "2014-01-01T00:00:00Z
}
throws an error
{
"error":
{
"code":"BadRequest",
"message":"The request is currently not supported on the targeted entity set",
"innerError":
{
"request-id":"5f0d36d1-0bff-437b-9dc8-5579a7ec6e72",
"date":"2019-08-13T15:27:40"
}
}
}
When I update the birthday separately, I get a 500 error. Print screens below. Updating the user id works fine, birthday does not.
Same user id is used in the request.
I'm not sure why this happens, but a workaround, albeit an annoying one, is to update birthday separately from other attributes.
E.g.
PATCH https://graph.microsoft.com/v1.0/users/userid
{
"birthday" : "2014-01-01T00:00:00Z"
}
Here is a screenshot from MS Graph Explorer:
In fact, this is a limitation in the current system.
User is a composite type. Under the covers some properties in user are mastered by different services, and we currently don't support updates across multiple services.
"birthday" is not mastered by Azure AD. So we can't update it with other properties mastered by Azure AD in the same call.
It is strongly recommended that you update this property separately. I can update it from my side. So you need a backend engineer to track this request for you.
This seems to affect more than Birthday.
Skills[] and Responsibilities[] are also returning 500 Internal Server Error when using PATCH request via REST API with:
{"skills": ["TESTING", "ANOTHER SKILL"]}
Same happens via the GraphServiceClient - except the result is:
Failed to call the Web Api: InternalServerError
Content: {
"error": {"code": "-1, Microsoft.Office.Server.Directory.DirectoryObjectUnauthorizedAccessException",
"message": "Attempted to perform an unauthorized operation.",
"innerError": {
"request-id": "1c2ccc54-0a0c-468f-a18c-6bdfbad4077d",
"date": "2019-08-28T13:23:55"
}}}
These requests work on the Graph Explorer page, but not via calls to the API.

Azure Search service set up

Hello I am trying to create a new azure search service with S2 or S3 tier.
However, as I try to create, I am getting validation error:
Any idea how to resolve this?
below are raw error details:
{
"telemetryId": "127e12a7-2de5-420d-8ce3-181a5e663337",
"bladeInstanceId": "Blade_f10d818ac9854758a2308220f06e7274_5_0",
"galleryItemId": "Microsoft.Search",
"createBlade": "CreateBladeV3",
"code": "InvalidTemplateDeployment",
"message": "The template deployment 'Microsoft.Search' is not valid according to the validation procedure. The tracking id is 'd2a97835-fd96-4b15-95f9-416e19086f31'. See inner errors for details. Please see https://aka.ms/arm-deploy for usage details.",
"details": [
{
"code": "ServiceQuotaExceeded",
"message": "Operation would exceed standard3 service quota"
}
]
}
It looks to me like either the subscription you are using doesn't allow for paid services or you are trying to create an index in the service via import that is too large. However, S2 and S3 allow quite large indexes, so my guess is the former.

Resources