BUG?: [SPOSharingSettings] Settings appear to apply, except for RequireAcceptingAccountMatchInvitedAccount = $True #4771
Comments
|
UPDATE: We modified more settings to this resource , which seem to apply as expected - EXCEPT for RequireAcceptingAccountMatchInvitedAccount. It remains "off"/$false, regardless of what we do. Here is the resource config |
|
I'm seeing the same (unwanted) behaviour. |
|
I'm also having the same issue but it's definitely a backend problem and not specific to M365DSC since my integration tests were working before in changing this specific property to true and now it doesn't. |
Sounds plausible, as other values in this resource deploy as expected. @NikCharlebois any chance to get this fed back to whatever team at MSFT owns this setting? |
|
@ykuijs Hi, are you aware of this issue? The cmdlet was working before and now it doesn't so it's a backend problem which seems to be affecting other people. A simple way to replicate this is to first make sure that the property is set to $false and then do the below, no error messages are shown even with Verbose and Debug enabled. Set-PnPTenant -RequireAcceptingAccountMatchInvitedAccount $true
(Get-PnPTenant).RequireAcceptingAccountMatchInvitedAccount # this always returns $false |
|
If the behavior also occurs when running Set-PnPTenant directly, it has something to do with PnP PowerShell. Could you please create an issue in the PnP PowerShell repo: https://github.com/pnp/powershell/issues At the same time, I will check with a contact in that team |
|
@ykuijs The thing is that this was working just a couple weeks before and nothing changed relative to the PnP module, we don't have updates to it in ages so it's clearly a backend issue, are they able to help with that? |
|
I have been doing some digging on this and came across the following article just as I was about to raise a Bug on the PnP module
Whilst you can define the B2B enabled via Set-PnPTenant it doesn't look like the value is returned when you do a Get-PnPTenant but running Get-SPOTenant confirms that the value is in fact enabled. I will raise a bug for the Get-PnPTenant and link to this issue and would be good to have some logic in the set-logic that removes the sharing option IF the B2B piece is enabled |
|
Odd - just seen - pnp/powershell#3018 that this was resolved but the fix is in PnP version 2.2.0 but DSC still has a requirement for 1.12.0 Is this something that is held back for a reason @NikCharlebois @andikrueger @ykuijs |
|
M365DSC must work with PS5.1 and PnP 2.x branch only works with PS7+ so for the time being it cannot be upgraded, I've also requested something to be changed in PnP and they only applied to 2.x since 1.x is not being upgraded anymore. |
Actually, we checked via GUI - and it also didn't enable. From what we can see, SETTING doesn't work. Looks like this may be inconsistent across different tenants or DSC versions. |
So if the B2B setting is enabled at an SPO level which you can confirm with Get-SPOTenant and the stock MS module (or a sneaky install of PnP v2 latest on your machine you should be able to see the B2B link to Entra is enabled so regardless of what is in your Datafiles for M365DSC it will always return False and fail verification. I've taken the line out of our config to clear the error |
ah ok - makes sense havent dug into their release notes all that much to see what was there |
|
Same problem here. Is there any news yet? |
I don't think that the support from M365DSC for Powershell 7 or the backport of the setting in PnP to the older version would be anything happening short term. I would check that your tenant is setup for B2B guest using the SPO powershell module and then remove the setting from your M365DSC template. I don't see that there is a bug in either product and I've not tried the docs page logic on PS7 support in M365DSC either |
|
There is a pull request #4949 awaiting review for improved PowerShell 7 support. Unfortunately it always takes a long time for those reviews to complete... I personally would prefer to have PowerShell 7 support as quick as possible. |
Description of the issue
Apologies if this is a noob question, but we're only starting out so I might not be asking the right questions in the right places.
We think we finally have a devops CI/CD pipeline running and it seems to execute without errors. I seems to connect to the right target tenant and subscription AND it correctly identifies a different configuration:
Target = [RequireAcceptingAccountMatchInvitedAccount, False]
Desired config = [RequireAcceptingAccountMatchInvitedAccount, True]
(we're only testing with ONE resource for now)
The log suggests that the LCM executes and applies the change (does it tho?), but even an hour later, the target tenant still hasn't implemented [RequireAcceptingAccountMatchInvitedAccount, True]. We verified this through the GUI and with an M365DSC export of that resource, which are both consistent.
What would cause the setting to not apply? Where should we start looking?
Microsoft 365 DSC Version
1.24.605.1
Which workloads are affected
SharePoint Online
The DSC configuration
Verbose logs showing the problem
Environment Information + PowerShell Version
No response
The text was updated successfully, but these errors were encountered: