Nik Charlebois

@banned1996 as part of our breaking change release on October 5th, we will be renaming the O365User resource to AADUser and will introduce support for roles.

Since we already have an EXOSafeLinksPolicy resource that uses this cmdlet, would the appropriate fix not be to remove these parameters from the EXOAtpPolicyForO365 resource altogether instead?

Will be removing BlockedURLs alongside other deprecated parameters and will be included in breaking change release 1.22.1005.1. Defender resources will be addressed separately at a later time.

I am not able to reproduce the issue on our end. Please confirm that you have the latest versions installed as @andikrueger mentions above. Thanks

@salbeck-sit can you please take a look at the failing Unit Tests? Thanks

I have not yet done any investigation, but it may make more sense to modify DSCParser to properly handle the Settings parameter. Ideally we would like to keep the parameter...

Your statement is correct. However, M365DSC handles the connection to SC via the Exchange Online Management Shell module so this should be a non-issue. Can you confirm if and where...

What role is the account you are using assigned?

Thanks for reporting this. This would need to be addressed inside the MSCloudLoginAssistant module which is the component that handles all authentication for M365DSC. Will investigate further.

For whatever reason, I am not able to reproduce this behavior. For every instance of a resource, we call back into the New-M365DSCConnection cmdlet which then verifies if the context...