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.
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?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/FolderId's not unique without factoring in case-sensitivity, PowerShell issues...
Hello, I like using Get-/Set-/Add-/Remove-MailboxFolderPermission cmdlets. One of my favorites. There are times when there are special characters in the folder names, so I use the FolderId instead. For example: Add-MailboxFolderPermission -Identity "User1:LgAAAAC5KVkA/5dLTL13II/kvsaqAWCosJLoiFIBRbYcQ3Ny3l9TAAAAfag/AAAB" -User "User2" -AccessRights FolderVisible,ReadItems This has been fantastic to save the day in those cases. My latest issue though is that there turn out to be many duplicate FolderId's if we disregard case-sensitivity. If I import a CSV which has UN-tampered FolderId's (case-preserved and confirmed) with Import-Csv, and then to this: Add-MailboxFolderPermission "User1:$($csv[0].FolderId)" -User "User2" -AccessRights FolderVisible, ReadItems ... the actual folder to be updated with this new permission entry (ACE) may be the one I intended, or it may be one of the other folders with a matching FolderId (ignoring case-sensitivity). What I've found is that it is possible but difficult to bounce back from that problem state. You need to report all permissions before and after and verify the differences are only the intended changes. Super tedious, effectively a dangerous exercise overall. I don't see any alternative solutions for this problem. MFCMAPI I think, as well as Outlook/OWA, are definite workarounds. Wondering if there is anything in-built with the *-MailboxFolderPermission / *-MailboxFolderStatistics cmdlets that can help PowerShell here?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?
