Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inactive Custodian Not Adding Correctly #418

Closed
JoshuaSchmidt-Epiq opened this issue Mar 24, 2022 · 18 comments
Closed

Inactive Custodian Not Adding Correctly #418

JoshuaSchmidt-Epiq opened this issue Mar 24, 2022 · 18 comments
Assignees

Comments

@JoshuaSchmidt-Epiq
Copy link

I have been working with Microsoft on the AeD APIs for over a year. Originally the API required placing a "." before an email address to signify it was an inactive user. A change was made in the API to check passed email addresses so the "." was no longer required. This worked and I have been able to add inactive custodians without issue. About a month or two ago, inactive custodians began experiencing issues. In some situations the custodian would be added as an Active user where other times the same user (different AeD case) would be added as Inactive. In either case once the custodian is created, I am no longer able to add data sources to the custodian.

A couple weeks ago the AeD API was updated to include some OneAPI changes. This further broke inactive custodians that they now displayed with a blank name. This issue was fixed by the API team but I am still having the previous issues where Inactive custodians are not being added correctly. The API team has come to the conclusion the issue is in the SDK not the API.

I am using VB.Net 2019 and my MSGraph library (Standard 2.0) is using the Beta 4.29 version. I have a WinForm program (4.6.2) that references my MSGraph library.

The process I use to add custodians is as follows:

Pass 1: I attempt to add a custodian
-If this returns successful I move to adding sources
Pass 2: If Pass1 reports an I try to add the custodian again. Basically I just re-try the call. This was due to some custodians not correctly adding during the first attempt which I believe are due to buffer issues in the Graph API.
-If this returns successful I move on to adding sources
Pass 3: If the previous to attempts failed I insert a “.” at the start of the email address. This covers custodians which are actually inactive but were not identified as such by GSK. Previously, I believe Microsoft had made a change to check for this so it should be caught by the first pass but my code still makes this last attempt.
-If this returns successful I move on to adding sources. If this still returns an error, then I assume the custodian can’t be added and mark it as such. No further work is done with this custodian.

The error reported is either:

MSGraph.AddCustodian : Code: NotFound
Message: Custodian not found
Inner error:
AdditionalData:
date: 2022-03-10T19:13:49
......

or

MSGraph.AddCustodian : Code: Conflict
Message: Custodian creation failed {"BatchResponses":[{"Id":"####","ErrorMessage":"Failed to create","ErrorCode":"BadRequest"}]}
Inner error:
AdditionalData:
date: 2022-03-10T19:14:01
.....

The API team looked into the logs at Microsoft and found the following:

'https://substrate.office.com:444/complianceworkbench/compliance/ediscovery/cases('####')/custodians('userSources')'."
URI 'https://substrate.office.com:444/complianceworkbench/compliance/ediscovery/cases('####')/custodians('siteSources')'

Above request URI should be in format : /custodians('id’)/userSources or /custodians('id’)/siteSources

This indicates the call begin made is not passing the correct CustodianID when adding sources. We have verified my code IS passing the IDs in the correct manner but the actual web call is not being made correctly by the SDK.

It was suggested by the API team to update my SDK version. I updated from 4.29 to 4.34. In doing so I now get the following error when making any Graph Calls:

{"Only HTTP/1.0 and HTTP/1.1 version requests are currently supported." "Parameter name: value"

When I downgraded back to 4.29 the code works as normal.

@ghost ghost added the Needs: Triage label Mar 24, 2022
@StefanieBier
Copy link

Are there any updates here, graph team?

@andrueastman
Copy link
Member

{"Only HTTP/1.0 and HTTP/1.1 version requests are currently supported." "Parameter name: value"

Hey @StefanieBier, @JoshuaSchmidt-Epiq.

Thanks for raising this. With regards to this error, are you able to share the runtime info of your environment (OS/Dotnet runtime version)?
Also are you able to share how you are creating the GraphServiceClient?

@JoshuaSchmidt-Epiq
Copy link
Author

I am a little confused by your question as it seems you did not read the entire message as this information is already in there.

I am using VB.Net 2019 and my MSGraph library (Standard 2.0) is using the Beta 4.29 version. I have a WinForm program (4.6.2) that references my MSGraph library. All running on Windows 10 19041.1415

The "Only HTTP/1.0..." issue was something that popped up when I updated from SDK v4.29 but this is a minor issue compared with my larger issue related to adding inactive custodians which is the bulk of my message.

I need some people from Microsoft to look into this asap as this is part of a large ongoing project that I have been working directly with the AeD API team on for over a year.

@andrueastman
Copy link
Member

Hey @JoshuaSchmidt-Epiq,

Apologies for this. I was hoping to first unblock you while using the latest SDK version to eliminate the possibility of it being an outdated version issue.

However, with regards to the issue, are you able to share the code example you are using for this? Is it consistent with the examples provided here? It would also be great if you could share the "client-request-id" from the failed request so that we can see if anything is amiss.

@JoshuaSchmidt-Epiq
Copy link
Author

JoshuaSchmidt-Epiq commented Mar 30, 2022 via email

@andrueastman
Copy link
Member

andrueastman commented Mar 31, 2022

Thanks for this @JoshuaSchmidt-Epiq,

When I look up the request Id, the logs show that 404 response is returned.
Furthermore, The URI generated seems to be consistent as seen below.

image

@andrueastman
Copy link
Member

Hey @mahage-msft,

Any chance you could help figure out what could be going wrong with this request? The client error received seems to be inconsistent with the graph logs.

AdditionalData:
date: 2022-03-30T18:23:57
request-id: 4ac1ef84-4e2b-421e-8fed-2f90f167be28
client-request-id: 4ac1ef84-4e2b-421e-8fed-2f90f167be28

Your logs should show something similar to the following which appears as though I am adding the site source to the Custodians collection not a specific custodian object:

MSGraph.AddCustodianSiteSource : An Error Occured: PNDB_Sync_16//https://epiqsandbox-my.sharepoint.com/personal/MDrone_epiqsandbox_onmicrosoft_com

MSGraph.AddCustodianSiteSource : Code: UnknownError
Message: {"Message":"No HTTP resource was found that matches the request URI 'https://substrate.office.com:444/complianceworkbench/compliance/ediscovery/cases('5d4c9c87-fbdc-4883-b971-16f14b710815')/custodians('siteSources')'.","MessageDetail":"No type was found that matches the controller named 'cases'."}

@StefanieBier
Copy link

@andrueastman MaHa's team has already triaged.

@mahage-msft
Copy link

@SeunginLyu - Can you follow up on this?

@SeunginLyu
Copy link

Previously we did below experiments to find that C# SDK and graph explorer both are working fine for our Apis for adding sitesources to custodian.

We suspect it is VB.net SDK generation issue. Can you check if your SDK version is greater than or equal to our SDK experiment version.

Also if you can use C# SDK and see if it works.

Experiments:

  1. We tried from graph explorer for test tenant in same region and it is working. Public Documentation https://docs.microsoft.com/en-us/graph/api/ediscovery-custodian-post-sitesources?view=graph-rest-beta&tabs=http
  2. We tried to add siteSource in custodian using below C# code and it is working.

Graph SDK Nuget Version: 4.32.0-preview
Newtonsoft.Json: 13.0.1
Azure.Identity: 14.0

var siteSource = new SiteSource
{
AdditionalData = Utils.GetSiteAdditionalData(siteUrl),
};

GraphServiceClient.Compliance.Ediscovery
.Cases[eCase.Id]
.Custodians[custodian.Id]
.SiteSources.Request()
.AddAsync(siteSource).Result;

public class Utils
{
public static Dictionary<string, object> GetSiteAdditionalData(string siteUrl)
{
Dictionary<string, object> additionalData = new Dictionary<string, object>();
additionalData.Add("site", new { webUrl = $"{siteUrl}" });
return additionalData;
}
}

@JoshuaSchmidt-Epiq
Copy link
Author

JoshuaSchmidt-Epiq commented Mar 31, 2022 via email

@andrueastman
Copy link
Member

I point it out only as it may pertain to some sort of validation checking that may be occurring in the SDK perhaps?

The SDK doesn't perform this validation. But builds the requests based on input parameters and makes the call to the API.

AdditionalData:
date: 2022-03-30T18:23:57
request-id: 4ac1ef84-4e2b-421e-8fed-2f90f167be28
client-request-id: 4ac1ef84-4e2b-421e-8fed-2f90f167be28

@SeunginLyu Any chance you are able to look up the requestId provided by @JoshuaSchmidt-Epiq from your end to confirm that the error is indeed a 404 and not an incorrect URI being built as the error returned to the client suggests?

@SeunginLyu
Copy link

I point it out only as it may pertain to some sort of validation checking that may be occurring in the SDK perhaps?

The SDK doesn't perform this validation. But builds the requests based on input parameters and makes the call to the API.

AdditionalData:
date: 2022-03-30T18:23:57
request-id: 4ac1ef84-4e2b-421e-8fed-2f90f167be28
client-request-id: 4ac1ef84-4e2b-421e-8fed-2f90f167be28

@SeunginLyu Any chance you are able to look up the requestId provided by @JoshuaSchmidt-Epiq from your end to confirm that the error is indeed a 404 and not an incorrect URI being built as the error returned to the client suggests?

Regarding this 404, Advanced eDiscovery logs are indicating that the site source
"epiqsandbox-my.sharepoint.com:/personal/adelev_epiqsandbox_onmicrosoft_com" doesn't exist.
@JoshuaSchmidt-Epiq could you double check the above finding is correct? Could it be an error in your code constructing the site URL?

@JoshuaSchmidt-Epiq
Copy link
Author

JoshuaSchmidt-Epiq commented Apr 4, 2022 via email

@SeunginLyu
Copy link

Summarizing the discussion & issues so far :

@SeunginLyu
Copy link

@JoshuaSchmidt-Epiq, meanwhile I see v.4.37 has just been released, could you update the SDK to this version and try again?

SDK v4.37: NuGet Gallery | Microsoft.Graph.Beta 4.37.0-preview

@maisarissi
Copy link

maisarissi commented May 6, 2022

@JoshuaSchmidt-Epiq version 4.40 was released 2 days ago. Can you validate?

Also, there is a new version of the SDK out, 5.x. You can check more for information and how to upgrade here.

@SeunginLyu any updates?

@maisarissi
Copy link

Per my last conversation with @SeunginLyu , the eDiscovery team has fixed this.

Closing this.

@ghost ghost locked as resolved and limited conversation to collaborators Aug 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants