[BUG] Add-PnPGroupMember randomly fails with "User cannot be found" #2301
-
|
While running a script that creates a new sharepoint site, invocations to Add-PnPGroupMember will randomly fail with "User cannot be found.". I am trying to add Azure AD users and groups to a sharepoint group. I am using the format " Expected behaviorI expect the user or group to be added to the sharepoint group. Actual behaviorSometimes the call will randomly fail for no obvious reason. Adding user 'c:0t.c|tenant|GUID' The error comes up completely randomly, and repeated executions of the script may or may not work fine. Steps to reproduce behaviorI have no idea how to reproduce this consistently. The issue is more likely to appear in the middle of the afternoon for some reason, but that's all I've been able to determine. What is the version of the Cmdlet module you are running?1.10.0 Which operating system/environment are you running PnP PowerShell on?
|
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 2 replies
-
|
Please set tracing to "debug" using Set-PnPTraceLog and provide further information. This will allow the community to better understand the issue. |
Beta Was this translation helpful? Give feedback.
-
|
Different error this time, and strangely, trace didn't return anything for that cmdlet. I'm using PS $MYPATH> ./MasterSiteCreateScript.ps1 -SiteIdentifier ilsatest -SiteTitle "Ilsa Test Site" -SiteType Internal -ProgramCode test -ProgramDesc "Test Program" -DocketNumber 4567 -DocketDesc "Test Docket" -DeleteOldSite Write-Error: $MYPATH/MasterSiteCreateScript.ps1:307:5 |
Beta Was this translation helpful? Give feedback.
-
|
Are you deleting a site and then recreating it with the same URL? |
Beta Was this translation helpful? Give feedback.
-
|
@iloving Could you please share your "MasterSiteCreateScript.ps1" File content? I'm wondering what exactly you are doing to throw those errors. |
Beta Was this translation helpful? Give feedback.
-
|
Same here as well, will have to move this to discussions since this an issue with the environment or the script itself and not the cmdlet. As @Studermarc said, deleting and recreating the sites immediately will have an impact on the cmdlet operations. |
Beta Was this translation helpful? Give feedback.
-
|
I know about the recycle bin which is why I add -Force -SkipRecycleBin to the command. I don't know if I can post the full script because it contains a lot of details specific to our organization, and at this point a bunch of other stuff has come up so I can no longer spend significant time on this. And yes, I'm recreating the sites with the same URL otherwise I'll be polluting our tenant with a billion sites with of all my testing. However, I have occasionally run into these issues creating all new sites as well. I can accept that recreating an existing site can impact the time required to do certain things (for example, I am not going to expect indexing to be up to date), there are some things where I do not accept this as a reasonable explanation. I may be recreating the site, but I'm not recreating our tenant or our AD configuration. It is unacceptable that the cmdlet returns "User not found" or "Tenant not found". There is no possible justification for such an error to occur. If this is an issue on the cmdlet side, then the cmdlet needs to be fixed. If it's an issue on the Sharepoint side, then the cmdlet needs to retry the operation X number of times to be absolutely sure that it is, in fact, an error. |
Beta Was this translation helpful? Give feedback.
-
|
I have found that even when I delete a site permanently, that I am unable to access it programmatically for some time after recreating it with the same URL. This is a bug at SharePoint CSOM level. I would recommend you talk to Microsoft support about this because there is nothing we can do about it here. It's as if the site remains in the SharePoint site cache for a while and only after recreation does it disappear but this takes time as well. The retry option would only incur further throttling, as the exceptions pile up against your tenant. This would not be wise. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like you know what to do this weekend then 😊
Jokes aside, remember that this is a community driven effort done by people
in their spare time. "demanding" a fix is not really gonna get you that
far. If on the other hand your testing show an issue with the endpoints,
create a ticket with Microsoft support.
ons. 7. sep. 2022 21.05 skrev iloving ***@***.***>:
… I know about the recycle bin which is why I add -Force -SkipRecycleBin to
the command.
I don't know if I can post the full script because it contains a lot of
details specific to our organization, and at this point a bunch of other
stuff has come up so I can no longer spend significant time on this.
And yes, I'm recreating the sites with the same URL otherwise I'll be
polluting our tenant with a billion sites with of all my testing. However,
I have occasionally run into these issues creating all new sites as well.
I can accept that recreating an existing site can impact the time required
to do certain things (for example, I am not going to expect indexing to be
up to date), there are some things where I do not accept this as a
reasonable explanation.
I may be recreating the site, but I'm not recreating our tenant or our AD
configuration. It is unacceptable that the cmdlet returns "User not found"
or "Tenant not found". There is no possible justification for such an error
to occur. If this is an issue on the cmdlet side, then the cmdlet needs to
be fixed. If it's an issue on the Sharepoint side, then the cmdlet needs to
retry the operation X number of times to be absolutely sure that it is, in
fact, an error.
—
Reply to this email directly, view it on GitHub
<#2301 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMTDTX4FEQYW7TIVCGOFBDV5DROPANCNFSM6AAAAAAQHBIP3E>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Understood. It's just really frustrating because this is literally the only reasonable option for automating sharepoint management. If this doesn't work, the next step is to go into C# and I very much want to avoid that route. Doing things manually is obviously not an option at all. I apologize if I came across as demanding. I just thought that, given how woefully unpredictable Sharepoint is, incorporating retries into PnP is the only logical option. As I mentioned, certain operations such as pulling a tenant or user information has nothing to do with the site in question so when those operations fail, confusion is going to be inevitable. And they aren't going to know if it's a Sharepoint issue or a PnP issue. Maybe have a -retry parameter as one of the "Common" parameters? |
Beta Was this translation helpful? Give feedback.
@iloving Could you please share your "MasterSiteCreateScript.ps1" File content? I'm wondering what exactly you are doing to throw those errors.
Like @CallumCrowley asked, if you delete a site and attempts to recreate it with the same url/alias, this won't work. Sites are soft deleted, hence it is still there but not accessible.
After creating a site, many actions are taken server side to get the site fully provisioned. This can sometimes take seconds, minutes, or even hours in worst case scenarios for some features (taxonomy is a good example). Depending on what you would like to achieve, you might need to change how you do things a bit.