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: Calendar permissions in an Office 365 Group - Microsoft Community More info about the Set-UnifiedGroup command is found here: Set-UnifiedGroup (ExchangePowerShell) | Microsoft Learn 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?Get-MailboxExportRequest doesn't accept Export from date A to date B
Hi everyone, I'm faceing a strange error, when I want to export between 2 dates. We've tried infinite ways of exporting between 2 dates, but me and my colleagues can't get it. For easier reading, I reduced the following code to the minimum. We are successfully exporting with Case 1, but as soon as we want to set a end date, it will automatically fail with the wildest excuses. (See 2nd code) #Define Dates $start = (Get-Date -Day 1 -month 6 -year 2021 -Hour 00 -Minute 00) $end = (Get-Date -Day 31 -month 12 -year 2023 -Hour 23 -Minute 59) #Case 1: Export the MB works with following command WORKS. (So Export from Date X until today): New-MailboxExportRequest -Mailbox "PrimarySmtpAddress" -ContentFilter "((Received -ge '$start') -and (Sent -ge '$start'))" -FilePath "Path\file.pst" #Case 2: To keep it simple, I'll just export the received Messages (Export from Date X to Date Y (NOT NOW) doesn't work.: New-MailboxExportRequest -Mailbox "PrimarySmtpAddress" -ContentFilter "((Received -ge '$start') -and (Received -le '$end'))" -FilePath "Path\file.pst" Get-MailboxExportStatistics Error: ContentFilter is invalid. The value "31.12.2023 23:59:00" could not be converted to type System.DateTime. --> The value "31.12.2023 23:59:00" could not be converted to type System.DateTime. $end is definitely a system.datetime type; We've also used different System Cultures, f.e.: [System.Threading.Thread]::CurrentThread.CurrentCulture = "en-US" I've been working on this for a long time, please only respond, if you were able to reproduce this in your own Exchange Environment, since I want a confirmation, that this is a (currently) unhandable bug. Best regards, Florian edit: I updated the official MS docs.Teams and Microsoft Exchange PowerShell Modules Clash Over Required DLL
After updating a bunch of PowerShell modules, I was dismayed to find a PowerShell module clash caused by a dependency on the Microsoft.Identity.Client DLL. The Exchange Online management module wanted a higher version of the DLL than the one loaded by the Teams module, so the Connect-ExchangeOnline cmdlet barfed. It’s easy to understand the logic behind the problem, but it’s hard to understand why Microsoft let it happen. https://office365itpros.com/2023/10/20/powershell-module-clash-exo/
