Also reachable via jb365.ca (for now).
This repo is where I maintain most of my PowerShell scripting work. So far it always seems to come back to Exchange for me and PowerShell, so most of my work here caters to that. My only real boundary for what will live here though is that it’s PowerShell (scripts, functions, modules, etc.), so over time the content will surely bounce around between more topics.
ℹ Most of my scripts / functions have detailed comment based help to make using them easier. This can be read here on GitHub by viewing the code (which is syntax-highlighted for easy viewing), or directly in PowerShell which can also be handy.
PS C:\> .\Get-EXOMailboxTrustee.ps1 -? PS C:\> Get-Help Get-MailboxTrustee.ps1 -Examples PS C:\> Get-Help Get-MailboxTrusteeWebSQLEdition.ps1 -Full
While the repo’s content is an ever changing (mostly growing), list of items, this splash page is where I list some of my favorite ones.
This is the EXO-exclusive successor to Get-MailboxTrustee.ps1. It was written from scratch, rather than modified from the earlier script, and solely uses the new EXO V2 PS module cmdlets which consume the MS Graph / EXO REST API. The hope is that this one will be able to handle org-wide reporting for even the biggest of EXO tenants.
It’s worth noting, I won’t be creating an EXO-exclusive successor to the Get-MailboxTrusteeWeb.ps1 lineup. The use case for those was planning migration batches to EXO. If/when offboarding from EXO becomes popular, I’ll definitely tackle something like this then.
A recent addition, one that attempts to extend the built-in alerting capabilities of Microsoft 365’s Security and Compliance Center (SCC) for potentially-malicious mailbox rule activity. The problem being addressed, or at least attempting to be, is that only OWA-based activity is able to be further parsed for specifics to generate alerts for, in the M365 SCC. Search-InboxRuleChanges.ps1 further expands the dynamically nested multi-valued properties that are contained within the Unified Audit Log’s AuditData proerty. This in turn renders the Outlook-based (Unified Audit Log activity: UpdateInboxRules) much more friendly to work with. The only caveat is that you will need to schedule this check on your own (rather than set it up in SCC), and you’ll also need to look after your own solution for getting alerts sent out (e.g. via email).
UseClientIPExcludedRanges parameter ([bool] / $true by default) allows you to further scope the output to just changes made from non-recognized IP’s. Head on in and check it out.
Conex has been retired since the Exchange Online PowerShell V2 module has been released and takes away half the need of conex in the first place. It was fun, and might be back later for an on-premises Exchange exclusive. Time will tell…
This script’s target audience is anyone who needs to find mailbox permission relationships*, for example when planning a migration to Office 365. The script outputs one object for every mailbox-trustee relationship, a format that works well for direct usability in a database or Excel table, from which pivot tables can very easily be crafted in seconds.
If you give it a try, try using it with -Verbose. This, combined with its detailed progress, allows me to forego tracking with a processesd.csv etc.
*Note: For Exchange Online, it’ll be best to use Get-EXOMailboxTrustee.ps1 instead.
New-MailboxTrusteeReverseLookup.ps1 is the sister script to Get-MailboxTrustee.ps1. What to do after you’ve extracted your entire Exchange organization’s list of mailbox & mailbox folder permissions (maybe even on a scheduled basis)? Well, one thing you can do is respond to requests for mailbox permsission reverse lookups (e.g. User: ‘What mailboxes do I have access to and what is my access level to each of them?’ Answer: ‘Coming right up!’)
The SQL Edition is now at parity with the original version, and beyond (the database storage/engine really help tremendously). If you have a large data set from Get-MailboxTrustee.ps1, this script has you covered with zippy speeds as it identifies webs. The parameters allow for repeated trial and error / trial and cancel runs, as you fine tune the parameters to persuade the resulting web as desired..
While the original version (combined with the input-optimizing brother) works fine for small data sets, the SQL Edition is better suited to larger sets. Requirements? SQL Express (only 2017 tested), and a database (default is TempDB) where current user has permissions to create/delete tables.
This script pulls some key details together to help determine how a mailbox is used. Details include AD user account’s last logon date, the mailbox’s last logged on date / last logged on user, the newest item in the Inbox and Sent Items folders, and a few other items. This one is arguably overlapping of Office/Microsoft 365’s usage reports. Its intended use is strictly with mailboxes, for tasks like determining if a UserMailbox is a good candidate for conversion to SharedMailbox, or Room/EquipmentMailbox. Being that it can also be used with Exchange On-Premises or EXO, it rather compliments the O/M365 usage reports.