Can't connect with GDAP using ExchangeOnlineManagement 3.7.0/3.8.0, but 3.6.0 works
Since upgrading to ExchangeOnlineManagement version 3.7.0, I've been unable to connect to any of my clients using GDAP. I thought I'd try upgrading to 3.8.0, but I still get the same error: PS C:\Users\username> connect-exchangeonline -userprincipalname email address removed for privacy reasons -DelegatedOrganization contoso.com ---------------------------------------------------------------------------------------- This V3 EXO PowerShell module contains new REST API backed Exchange Online cmdlets which doesn't require WinRM for Client-Server communication. You can now run these cmdlets after turning off WinRM Basic Auth in your client machine thus making it more secure. Unlike the EXO* prefixed cmdlets, the cmdlets in this module support full functional parity with the RPS (V1) cmdlets. V3 cmdlets in the downloaded module are resilient to transient failures, handling retries and throttling errors inherently. REST backed EOP and SCC cmdlets are also available in the V3 module. Similar to EXO, the cmdlets can be run without WinRM basic auth enabled. For more information check https://aka.ms/exov3-module Starting with EXO V3.7, use the LoadCmdletHelp parameter alongside Connect-ExchangeOnline to access the Get-Help cmdlet, as it will not be loaded by default ---------------------------------------------------------------------------------------- The role assigned to user email address removed for privacy reasons isn't supported in this scenario. Please check online documentation for assigning correct Directory Roles to User. At C:\Users\username\OneDrive - MSP\Documents\WindowsPowerShell\Modules\ExchangeOnlineManagement\3.7.2\netFramework\ ExchangeOnlineManagement.psm1:758 char:21 + throw $_.Exception; + ~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (:) [], SystemException + FullyQualifiedErrorId : The role assigned to user email address removed for privacy reasons isn't supported in this scenario. Please check online documentation for assigning correct Directory Roles to User. You'd think there'd be something wrong with my GDAP permissions, but there doesn't appear to be. I can do anything via the Microsoft 365 Admin Center. Plus, most notably, if I manually load ExchangeOnlineManagement 3.6.0, everything works perfectly. I'm running Windows 11, and this behavior is reproducible on Windows PowerShell 5.1 as well as my preferred PowerShell 7.5.2. How can I troubleshoot this?
Add-PublicFolderClientPermission: Object reference not set to an instance of an object.
Running into an issue with adding public folder permissions in Exchange Online. I've used this PowerShell script for a few years without any issues, but suddenly getting this error no matter what I try. I do have Owner permissions and there are Default and Anonymous permissions on the public folder, tried completely removing and reinstalling the ExchangeOnlineManagement module as well. Anyone else having this problem? $PF = Get-MailPublicFolder -Identity "\pf1" $User = Get-User -Anr "User1" $AccessRights = @( "ReadItems", "CreateItems", "EditOwnedItems", "EditAllItems", "FolderVisible" ) Add-PublicFolderClientPermission -Identity "\$($PF.Id)" -User $User.UserPrincipalName -AccessRights $AccessRights -Verbose VERBOSE: Returning precomputed version info: 3.9.2 VERBOSE: Requested HTTP/1.1 POST with 227-byte payload VERBOSE: Received HTTP/1.1 response of content type application/json of unknown size VERBOSE: Query 1 failed. Add-PublicFolderClientPermission: Object reference not set to an instance of an object. Thank youExchange Online PowerShell Dumps the Credential Parameter
On February 12, Microsoft announced the deprecation of the Credential parameter for the Connect-ExchangeOnline cmdlet in the Exchange Online PowerShell module. The deprecation won’t affect interactive sessions (which should all be protected by MFA), but it might stop some background jobs running when Microsoft retires the server components that currently support the ROPC authentication flow. Time to check scripts! https://office365itpros.com/2026/02/16/exchange-online-powershell-ropc/
The term 'Get-MessageTraceV2' is not recognized as a name of a cmdlet
I am writing a function app to get message delivery status. I have the package defined in requirements.psd1 as such: # This file enables modules to be automatically managed by the Functions service. # See https://aka.ms/functionsmanageddependency for additional information. # @{ # For latest supported version, go to 'https://www.powershellgallery.com/packages/Az'. Uncomment the next line and replace the MAJOR_VERSION, e.g., 'Az' = '5.*' # 'Az' = 'MAJOR_VERSION.*' 'ExchangeOnlineManagement' = '3.*' } This is the error we get: The term Get-MessageTraceV2 is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct, and try again. The bizarre thing is that it sometimes works and sometimes doesn't without any changes to the code. Even when several of my colleagues and I try the command locally, we have the same error.EOL - DDG - EQ operator wildcard bug fix
EOL > MSFT recently announced (i/t Health - Message center - MC912176) a bug fix related to the -eq operator and use of wildcards ('*') to compile the member list for Dynamic Distribution Groups. When the update takes effect, the * character will be treated as a literal value and not a wildcard. Therefore, expressions using the -eq operator will only evaluate to true if the right-hand side value matches the property values exactly. For example, the expression (WindowsLiveID -eq '*@microsoft.com') will only return true if the recipient’s WindowsLiveID property is exactly "*@microsoft.com". The current behavior will no longer function after the fix, and this may impact any processes that rely on this behavior. To distinguish the DLs (for corporate communication) membership of internal employees only and external consultants/contractors, we've created several DDGs using PowerShell to define the Recipient filter options based on our internal naming conventions (FTEs get FN.LN@emaildomain whereas consultants/contractors get FN.LN.ext@emaildomain). The formula was based on -eq operator combined with '*' wildcard > formula extract > -RecipientFilter {(( RecipientType -eq 'UserMailbox') -and ((WindowsLiveID -eq '*.*.ext@emaildomain') ... When the bug fix is corrected the formulas will no longer return the expected members. We've tried already several alternatives w/t -like operator but were not able to retrieve the same list. Other operators as -contains and -match are not supported i/t context of EOL. Are there other operators or other parameters to compile a filtered list using wildcards?Get-Mailbox Versus Get-ExoMailbox
Microsoft’s advice is to use the Get-ExoMailbox cmdlet instead of its older Get-Mailbox counterpart. Generally, this is good advice that you should follow. However, the older cmdlet can do a job in certain circumstances, so don’t write it off completely. More importantly, make sure that filtering of objects is done using server-side filters. This will improve script performance significantly. https://office365itpros.com/2024/09/19/get-exomailbox/Modify Email Address Policy via powershell
We have to remove several accepted domain, via powershell, from our Exchange domain. Before doing so, however, we need to remove the references for that accepted domain from several email address policy. The idea is to cycle through all the email address policy searching for the accepted domain to be removed and remove it from the policy Is there a way of doing it, any example ?
Can't make a goup calendar readonly anymore with Powershell (again...)
About a year ago the command Set-UnifiedGroup -Identity "MYGROUP" -CalendarMemberReadonly was giving problems. See this post: Can't make a goup calendar readonly anymore with Powershell - Microsoft Community Hub This lasted from june 2023 to august 2023 and then it was fixed. After that, aside from the error message it gave, it used to work fine. But since about a week or 2 the command is giving problems again. I get this error message: Write-ErrorMessage : |Microsoft.Exchange.Configuration.Tasks.TaskException|We failed to update the unified group. Please try again later. At C:\Users\some.user\AppData\Local\Temp\tmpEXO_gny3w2ea.ldk\tmpEXO_gny3w2ea.ldk.psm1:1204 char:13 + Write-ErrorMessage $ErrorObject + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Set-UnifiedGroup], TaskException + FullyQualifiedErrorId : [Server=DBBPR04MB7929,RequestId=<xxx>,TimeStamp=Mon, 10 Jun 2024 06:36:03 GMT],Write-ErrorMessage Do other people get this error to? How can I fix this? Kind regards, PaulCan't make a goup calendar readonly anymore with Powershell
Hi, We have some groups where regular group members are not allowed to make changes to the group calendar. I was able achieve this with Powershell as described in this post: https://answers.microsoft.com/en-us/msoffice/forum/all/calendar-permissions-in-an-office-365-group/b5f7cacc-bc11-4b8c-adf1-e94f11616ae2#:~:text=Below%20are%20the%20steps%3A%201%201.%20Connect%20to,command%20to%20check%20the%20CalendarMemberReadOnly%20in%20this%20group. More info about the Set-UnifiedGroup command is found here: https://learn.microsoft.com/en-us/powershell/module/exchange/set-unifiedgroup?view=exchange-ps All of a sudden I now am only able to read the settings and can't change them anymore. So this still works: Get-UnifiedGroup -Identity "MYGROUP" -IncludeAllProperties | Format-List *Calendar* But this gives an error: Set-UnifiedGroup "MYGROUP" -CalendarMemberReadOnly The error is: Write-ErrorMessage : Object reference not set to an instance of an object. The strange thing about this, is that I am able to change other attributes, like: Set-UnifiedGroup -Identity "MYGROUP" -AccessType Private I use an account with Global Admin rights to execute the commands and we have an educational tenant. What is going wrong here?
