“The user mailbox couldn’t be permanently deleted. The user mailbox has at least one type of hold or hold policy applied to it.”

The annoying thing about it was that this mailbox fell under a retention policy in the Security & Compliance Center – which are great, don’t get me wrong – but one of my biggest concerns with using these retention policies is that you can’t easily tell which mailboxes fall under this hold:

I found a few blog posts out there that mentioned different approaches of identifying these mailboxes with PowerShell, but none of them were working for me – all I was getting was that the policy applied to ‘All’. Not very useful at all!

I tried several approaches including trying to exclude the mailbox from the retention policy (didn’t work), applying litigation hold and removing it (no dice), and then I was going to attempt to restore the mailbox, remove it from the policy, and then delete it again – thankfully, I found a better way! There’s an -IgnoreLegalHold switch you can use, which will still allow you to delete the offending mailboxes:

Now, you’d think I was done, but not quite! Two of the four mailboxes hadn’t been properly deleted from the Deleted Users container in Azure AD, so Exchange would not allow me to delete the mailboxes:

Thankfully, this one is a bit easier – I’ve had to do this one quite often. Start out by searching for your deleted users – in this case I used a search string, because as you can sort of see from the screenshot below, I had two identical users in Azure AD – same Display name, same User Principal Name, and of course… Different Object Ids.

Now that I had my object Ids, I could safely go in and remove them – it’s always a good idea to use the Object Ids or Exchange GUIDs, because you know you’re targeting the object directly, and there’s no chance of an ambiguous name coming back and biting you in the butt. Measure twice and cut once!

After about 10 minutes or so, I was able to delete both of those mailboxes in Exchange Online:

Definitely a bit of a puzzler, but all sorted out now with another tool in my PowerShell toolbelt – hope this helps someone who is scratching their head trying to figure it out!

I ran into an interesting scenario yesterday during a tenant migration where users from tenant A were successfully migrated to Tenant B, but their accounts remained logged into Teams – even changing the user account names to their onmicrosoft.com domain and removing their Teams license wouldn’t force them to log out… talk about a token that won’t quit!

The goal here was that the users would log out of Teams – and since their old UPNs were changed behind the scenes – when they tried to log back in using their regular username and password, they’d be passed into the new tenant instead of remaining in the old one. However, this was not happening, and users were remaining signed in to the old tenant – very frustrating!

Initiate Sign-out (the Ctrl-Alt-Del of the cloud)

Now, you should normally be able to force this logout by going to the admin portal, clicking on the user account, then the OneDrive tab, and using the Initiate sign-out option:

In fact, this was a step that was already tried by the team working on the migration (and it didn’t work), before the question even made it across my inbox to see if there was a way I could help force the logout and get this migration wrapped up successfully. This was indeed puzzling, as my expectation was that initiating a one-time sign-out like this would indeed work across all sessions, the way it promised, so I needed to do some testing, and some research!

First off, it turns out that the sign-out option does work – it just takes a while. In my initial testing, web sessions, Office clients, mobile clients, etc. will log out within 5-15 minutes, as promised. However, the Teams client holds on to that token a lot longer after it’s been invalidated and will not sign out until after an hour. Now, that’s not horrible, but it’s still not going to give me the controlled experience that I was looking for, so I needed to dive a little deeper – especially as I wanted PowerShell options… no way would I click through hundreds of users to make this happen!

Force Kick – the Way of the Shell

To do this through PowerShell, you first need to have the Azure AD Preview module installed – if you don’t have it on your system already, open an admin shell and install it by using the Install-Module AzureADPreview command. After that, you can go ahead and connect to Azure AD using Connect-AzureAD, and logging in as normal.

First thing to do is find your user, and see when their current access token is valid from, like so:

Get-AzureADUser -SearchString "Lester Tester" | Select *token*

This will return the RefreshTokensValidFromDateTime, which essentially tells you that any token issued AFTER this date/time is valid – note that the time is in UTC, so you’ll need to adjust for your own time zone.

So far this is just informational, but still useful – especially if you want to find any users you might have missed, or who still have old tokens sticking around. Now, to revoke this access token, simply use the following command:

Get-AzureADUser -SearchString "Lester Tester" | Revoke-AzureADUserAllRefreshToken

This command won’t return anything in the Shell, but if you run the Get-AzureADUser command from above one more time, you should see that your refresh token validation date has been set to the current date and time (again, don’t forget you need to convert from UTC to your own time zone – very annoying!!).

Now that we have the PowerShell basics down, we can easily take this command and scale it out to as many users as we want by filtering on an available attribute – let’s take for instance, the Test family in my tenant:

Get-AzureADUser | ? {$_.DisplayName -match "Test"}  | Select DisplayName,RefreshTokensValidFromDateTime

Once you have your filter working the way you want, just go ahead and re-run that command and pipe it out to the Revoke command:

Get-AzureADUser | ? {$_.DisplayName -match "Test"} | Revoke-AzureADUserAllRefreshToken

If you run your Get command again, you can see that all our users in scope have had their old tokens invalidated:

Now we have a process set that we can scale out and revoke the tokens for hundreds or even thousands of users if we need to. However, that still didn’t solve our timing problem, so I logged in to the Azure AD portal to see if there was somewhere else that I could make this sign-out happen when I wanted it to, and not after an hour (or whenever Teams felt like letting go of its token). Unfortunately, there is not any other magic kill switch in the Azure AD portal, but I did discover something interesting – both running the initiate sign-out option, and revoking the access token through PowerShell do the exact same thing, but with different actors initiating the change:

Sadly, this doesn’t really get us any closer to the final answer – it simply tells me that either method is essentially doing the same thing behind the scenes, and you should have the exact same experience in both cases. Now let’s see what we can do about that delay!

Tweaking that Token

I knew that some time back, Microsoft had introduced the option to configure token lifetimes, so I wanted to see if there was a way I could shorten that process, and get these Teams users logged out when I wanted, not lingering around on the old tenant the way they were. If you check the link above, you can find a lot of interesting info about this whole process, but here’s a handy reference to the defaults, and what they can be changed to:

Seeing that I could get my tokens down as low as 10 minutes was starting to sound a lot more interesting to me, so I wanted to build this out and do some more testing. Here’s what I did:

Start by checking to see which policies you have in place by using Get-AzureADPolicy. If your tenant is like mine, it probably looks like this:

By default, there are no Token Lifetime Policies in place, so we’re going to go ahead and create one.

New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"00:10:00","MaxInactiveTime":"00:10:00"}}') -DisplayName "OrganizationDefaultPolicyScenario" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"

Voila:

Make note of your policy ID so that you can use it to target this policy if you want to update it (using Set-AzureADPolicy) or delete it (using Remove-AzureADPolicy). Now that our Access Token Lifetime and Max Inactive Time were both set to 10 minutes, I tested again revoking an access token with a user that was signed into Outlook on the Web, Teams in a different browser, the Teams desktop client, and Teams on a mobile device.

Here’s how they behaved:

1. Outlook on the Web: logged out immediately
   
2. Teams Web & Mobile: logged out about 2 minutes later
   
3. Teams Desktop: logged out in less than 5 minutes
   

Sweet, sweet victory!

Final thoughts

After all this fun, here’s a couple of things to keep in mind:

You can revert your settings to default by either deleting the policy you created, or by using the following PowerShell command:

New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"00:10:00","MaxInactiveTime":"00:10:00"}}') -DisplayName "OrganizationDefaultPolicyScenario" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"

If for some reason you need to keep your existing policy in place, just target it using the Set-AzureADPolicy command, and update the pieces you need to change – worst-case scenario, delete the policy and create it fresh using the command above. (more info here)

I’m not 100% sure of the impact of running your long term with your access tokens refreshing this quickly – I assume that if Microsoft is allowing you to change the token lifetimes down to 10 minutes, that it’s acceptable to do so. I did run for a couple of hours like this without any adverse side effects, but that’s in my test tenant, not a production environment. If I needed to fulfill the scenario that started this whole thing, I’d probably change my token lifetime policy a day or two before my migration cutover so that all the users would be revoked immediately upon cutover. After that, I’d personally set it back to defaults unless I had a compelling reason to keep the lifetime shorter.

Also, I wouldn’t waste too much time with this, as they’ve already announced that they’re deprecating this feature and instead moving it to a conditional access policy. No clue what that looks like yet but know that it’s coming.

All in all, an intriguing problem, and a fun trip to the solution – hope this helps someone else! Feel free to leave a comment below if you have any questions, or to let me know if any of this was helpful.

—————————————————————————————————————

I’ve done some work recently with Azure AD Privileged Identity Management, and I wanted to find a way to streamline the request process for an administrator who needs to run some PowerShell scripts or commands so that the whole request/approval process can be simplified and streamlined.

Enabling Privileged Identity Management

Note that if you haven’t activated or configured PIM for your tenant yet, you need to have Azure AD Premium P2 to enable and use this feature.

If you don’t have Azure AD P2 on your tenant, you can add a 30 day trial that will allow you to configure PIM and start checking out the functionality. You’ll need to assign the AAD P2 license to everyone that needs to interact with PIM – both approvers and requesters. After you’ve activated AAD P2, come back and refresh the PIM sign-up blade, and complete the sign up process.

Activating a Privileged Role – GUI Style

Once you roles have been assigned and configured, you would typically need to navigate to the Azure Portal (https://portal.azure.com/#blade/Microsoft_Azure_PIM/CommonMenuBlade/QuickStart), then to the PIM blade, and then click on your eligible roles, and then click through the Activation process.

After the request has been submitted, you need to wait for approval – or you can start working if auto-approval is configured for that role.

PowerShell and the PIM Module

Thankfully, we can use PowerShell to automate this request process – it takes a few moments to install the PIM PowerShell module due to it being published on the PowerShell Gallery.

From an admin prompt, run the following command:

Install-Module Microsoft.Azure.ActiveDirectory.PIM.PSModule

Once the module is installed, you can view all your available commands using Get-Command:

Get-Command -Module Microsoft.Azure.ActiveDirectory.PIM.PSModule

There’s not that many commands included in the module, but we still have all we need for this little task of ours:

Now that you’re all ready to go, connect to the PIM Service using Connect-PimService. The connect command supports both the -credentials and the -username switch.

Using -credentials allows you to capture and store the admin creds and connect using basic authentication:

The –username switch will start the connection process using modern authentication.

Don’t forget that you’ll need to use the Modern Auth path if you have MFA enabled on your account, but you can still use basic auth if there’s no MFA in the picture.

Now that we’re connected, get a list of all the privileged roles assigned to you by running Get-PrivilegedRoleAssignment.

Putting it all together

Ok, now we have all the pieces we need, let’s apply this process to a real-world scenario. Let’s say I have a number of Exchange scripts that I use on a regular basis, and I don’t want to go in to the Azure Portal to request elevation every time I need to run a script. Simply incorporate the following commands into your Exchange scripts:

# Connect to the PIM Service

Connect-PimService

Connecting like this will open an interactive auth window for you to type in your username and password (Modern Auth) – don’t forget to add the -username or -credentials if you want to reduce the typing you need to do when authenticating.

From the list above, we already know that the role ID for Exchange Administrator is 29232cdf-9323-42fd-ade2-1d097af3e4de, so we’re going to use that in our elevation request:

Enable-PrivilegedRoleAssignment -RoleId 29232cdf-9323-42fd-ade2-1d097af3e4de -Reason “I need to update transport rules”

You can easily update this command to use target whatever RoleId you need to activate, and even provide your reason at the same time. Since we’re activating an admin role, you’ll be prompted for MFA (another setting you can configure in PIM):

If you’re curious to check, you can now verify that your role has been assigned, and you can initiate your Exchange connection:

When you’re finished running your scripts, you can easily disable your Role Assignment like so:

Disable-PrivilegedRoleAssignment -RoleId 29232cdf-9323-42fd-ade2-1d097af3e4de

You don’t have to add the disconnect piece if you don’t want to, since your admin access should be configured to age out automatically – I just like the idea of holding to the Just In Time ideology, and disabling my elevated role as soon as I’m finished my tasks. This reduces your risk even further, as your admin access will only be assigned for the duration of your scripts, and then your account goes back to normal right afterwards.

Nice and clean, nice and quick!

Presenting like this is one of the things I love most about being an MVP – we work in an industry full of smart people, and I often learn new things even while talking about technology I already know! There was a great turnout, lots of great questions and feedback – overall, a really fun night

I promised I’d post a link to my presentation if anyone is interested – here it is:

Like most things, if I end up having to do it more than once or twice, I’m going to script it and keep that script close for whenever I need to reuse it. I always find it helpful to keep a repository of all my migration scripts as I find I’m often going back to them and pulling sections forward into new scripts.

Start by building yourself a CSV file – you only need two columns: UserPrincipalName and ForwardingAddress.

This script has only one required parameter, and that’s the CSV file – if you run the script without any other switches, it’ll import your user list, check their forwarding information and report it back to you.

Getting info only: .Bulk-Forwarding.ps1 -CSV c:scriptsusers.csv

(make sure you update the paths as necessary so the script can find your CSV file.)

The other two switches available to you are -SetForwarding, and -RemoveForwarding, which do exactly what it sounds like they do – set or remove the SMTP forwarding from a user’s account.

Setting forwarding: .Bulk-Forwarding.ps1 -CSV c:scriptsusers.csv -SetForwarding

And then finally, to remove the forwarding: .Bulk-Forwarding.ps1 -CSV c:scriptsusers.csv -RemoveForwarding

Not overly complicated, but robust enough to do the job, and a great timesaver! If you’re interested, head over to GitHub and download the script – feel free to check out the other scripts I have posted there as well. If you have any questions, leave a comment below, or even just to let me know this was helpful.

Good luck; have fun!

That said, one of my biggest frustrations in using Teams on a day to day basis is my inability to log in to multiple clients / Teams tenants at the same time – switching back and forth is time consuming and annoying, not to mention the further annoyance of missing out on notifications from one or the other when you’re switched.

Looking around on the web, I can see that I’m not the only one with this frustration – fellow MVPs Steve Goodman and Tom Arbuthnot have suggested some pretty cool solutions to the problem, so feel free to go down that route if you want to manually create the Chromium/Electron web apps yourself. Alternately, you can go the route of using multiple browsers, or even multiple Chrome “people” to have separate identities.

As much as I love the idea of having separate apps for my different Teams Identities, I’d prefer a more integrated approach if possible, so I don’t have to keep an eye on a bunch of different windows and screen clutter, etc.

Meet Franz.

I’m not even sure where how I first stumbled across Franz, but it’s quickly become one of those apps that I can’t imagine living without! Franz essentially performs those web connections for you, and allows you to maintain multiple different accounts across a fairly large amount of services that you might want to connect to. For example, I am currently logged in to four different Teams tenants at the same time. :O

On top of the different Teams tenants I connect to, I also have my WhatsApp and Discord accounts added, which is pure win in my books!

Installing the app is as easy as you’d imagine it to be – once you have it installed, you’ll be prompted to add your first service, and then you can add as many others as you’d like. You can see that there are both a lot of services to choose from, and you can request missing services you’d like added as well:

Yammer is still missing, but I’ve requested it be added – I might not use it as much as I’d like to, but it sure would be useful to have it all in one spot.

Pros & Cons

Lots to love, and nothing to hate… that’s for sure.

Pros:

• All my accounts are in one app, and I don’t have the pain of trying to maintain separate browser windows, etc.
  
• Notifications work great across all the services I’m connected to.
  
• My taskbar icon is badged when I have a notification (like you’d expect), and
  
• Connections are sticky enough that I don’t have to log in constantly.
  
• Since it’s a web/modern auth connection under the hood, MFA works correctly, and I’m prompted to authenticate when necessary.
  
• My accounts are neatly stacked, and notification badges show up on the appropriate service, making it easy to switch between them and reply to messages.
  

  
  

• Guest accounts!! This deserves its own section, so I’ll get into it below.
  

Cons:

Not really much in the way of cons, but there’s a couple of things I notice that are worth mentioning.

• Incoming calls can be a bit confusing, and it doesn’t always ring through the web client – I keep my main Teams client running anyway, and answer calls on there. I haven’t needed to take calls on my other logons yet, so it hasn’t been a problem for me.
  
• Remember that you’re essentially accessing each of these services through the web client – every now and again I get prompted to “download the app” which wants to of course download the app for whatever service your connected to. Nothing much to do about that, again, just recognize that it’s a web application and you’ll be fine.
  

Adding Teams Guest Accounts

Ok, I didn’t actually even realize this was possible until I was writing this post – now that I know I can do this, I love it even more! I’ve been logging in to my individual Teams accounts but hadn’t even thought of maintaining a separate connection for each tenant that account is a guest on.

Setup is just as easy as it should be – simply add a new Teams service in Franz, log in with your regular Office 365 credentials, and then click on the little drop-down beside your picture in the top right of your screen:

Switch over to whichever Guest tenant you want to set this service to and then (if you’re like me) give it a name and a logo to differentiate it from your other Teams logons. Since each connection is being maintained individually, you’ll be able to switch between your main and Guest tenants quickly and easily.

Chalk up another win for Franz!

As you might expect, there are several approaches you can take that allow you to maintain the balance between security and allowing your users to keep working, even when the service is not functioning properly.

Option 1: Configure a global admin “break glass” account.

This is a great option, and endorsed by Microsoft as a best practice for overall tenant management and security – just keep a couple of things in mind:

1. Make sure that this account is properly locked down and not tied to a specific individual. If you can lock it down as tight as Microsoft recommends (credentials kept separate, locked in a fireproof safe) then great – if not, at least make sure that you make the password suitably difficult, and keep these credentials on lockdown.
   
2. Set this account to use your @domain.onmicrosoft.com account – if you’re using ADFS or PTA, and you’re unable to authenticate back on premises because of issues with your federated domain, setting it up this way will allow you to log back in to your tenant using Microsoft authentication, rather than your on prem infrastructure (which might be down as well).
   
3. Exclude this admin account from MFA Policies. There are additional ways that you can lock down this emergency account, such as creating a Conditional Access Policy that ensures that this account can only be used from a domain joined PC, on your corporate network, etc. Just remember that you might still be painting yourself into a corner if the Conditional Access service goes down and you have no way of validating your access conditions. You always have to choose to balance between how much controls you put in place, and how much of a back door you want to leave behind – your security and risk posture is really going to be the deciding factor here.
   

Exclude your emergency account from MFA Policies

Let’s say for instance that I have my baseline policy enabled: Require MFA for admins (because I do). Automatically all my global admins are required to use MFA, and my security posture has gotten a bit stronger, along with my Secure Score.

However, since I want to make sure my emergency account is able to access the system even if MFA is down, I simply set an exclusion on the policy so that this account does not require MFA.

Like I mentioned before, you can configure other conditional access policies that might further limit this account – maybe you might want to ensure that it’s only logging on from a trusted location, trusted machine, etc. In this case, I simply have this account excluded from the policy, and I use my own security rigor to control access to this account.

Audit access to this account and configure alerts

Ensure that you are auditing this account’s access on a regular basis to ensure that it’s not being misused (or maybe even to ensure it’s not being used at all). If you have access to Cloud App Security (requires EM+S E5 licensing on your tenant), you can configure an activity policy that will alert specified people any time this account is used, like so:

Click the button to Edit and preview results in order to test your filters and ensure they’re working properly.

Once you are satisfied that your activity filters are catching the required account logon activities, configure an alert to send an alert email or text message:

Creating your emergency access / break glass admin account is going to cover a number of scenarios, and not just the MFA service being down. The point of having this account, of course, is that you can log in to Azure AD and disable your conditional access policy which requires MFA, and get users logging back in again.

Option 2: Create an MFA exclusion group

Another option that addresses the specific scenario of quickly and easily allowing your users to log in to Office 365 without requiring MFA is to create a security group on prem, sync it up to Azure AD, and set it as an exclusion on your MFA Policy.

For example, I’ve created two groups in Active Directory named MFA_Enabled and MFA_Disabled to keep things simple:

These two groups are used when I create my MFA Conditional Access Policy – one to target specific users for MFA, and the other for my MFA exclusion group.

Conditional Access Policy: Include Users and groups

Conditional Access Policy: Exclude users and groups

Once you have this set up, you can keep your MFA_Disabled group empty, and just have it ready in case something like this happens again. As soon as you get a report that MFA is down, and your users are impacted, you can simply move your affected users (or all of them if you prefer) to the MFA_Disabled group and run a quick sync in AAD Connect.

If you like, you can even use a simple script like this to move your users from the MFA Enabled to the Disabled group:

$mfaEnabled = Get-ADGroupMember -Identity “MFA_Enabled”

foreach ($m in $mfaEnabled){

Remove-ADGroupMember -Identity MFA_Enabled -Members $m.SamAccountName -Confirm:$false

Write-Host “Moving $($m.name) to the MFA_Disabled group” -ForegroundColor Yellow

Add-ADGroupMember -Identity MFA_Disabled -Members $m.SamAccountname

}

And then just do the reverse to bring them back in to the MFA Enabled group:

$mfaDisabled = Get-ADGroupMember -Identity “MFA_Disabled”

foreach ($u in $mfaUsers){

Remove-ADGroupMember -Identity “MFA_Disabled” -Members $u.SamAccountName -Confirm:$false

Write-Host “Moving $($u.name) to the MFA_Enabled group” -ForegroundColor Green

Add-ADGroupMember -Identity “MFA_Enabled” -Members $u.SamAccountname

}

Now obviously you need to be running these cmdlets from a system with access to your Active Directory, with admin rights to move users from one group to another. You can also make this part of a more complete script by adding logging, parameters to -enableMFA or -disableMFA, etc. These are just simple building blocks to get you started.

When you’re done, initiate a quick sync using the following command from your AAD Connect server:

Start-ADSyncSyncCycle -PolicyType Delta

Within a few minutes you can easily exclude some or all of your users from MFA, and just as quickly re-enable it for them, even if you can’t log into the portal yourself. Since this action is completely triggered from your server on prem, I believe it gives you an avenue to very quickly re-establish access should another MFA outage occur.

Hopefully this helps give you some ideas around how best to manage and control access to your Office 365 tenant, even when certain parts of it are outside of your control (looking at you, MFA!) – good luck!

I recently ran into a situation where I needed to export all the Sent Items from a number of mailboxes within a very specific date range – we needed to export these items so that they could be ingested into a journaling mailbox later.

Since you can’t directly export a mailbox from Exchange Online, the best way to make this happen is to do an eDiscovery search from within the Security and Compliance Center. Once you have your search parameters defined, you can export them all as a single PST, or as multiple PSTs (one per mailbox). Since we would later be ingesting these sent items into a Proofpoint journaling archive, this was the option I chose.

Required Permissions

In order to perform these searches, you need to be at least an eDiscovery Manager – I went with eDiscovery Administrator in this instance, as it gave me all the permissions I needed. The eDiscovery Manager role would work fine if someone else were assigning cases to me to work with, but since I was doing the whole thing here, I just went with the greater permissions level.

Start out by giving yourself (or the account that needs to perform this export) permissions in the Security & Compliance Center:

Click on the eDiscovery Manager role to edit it:

As I mentioned above, you can assign the eDiscovery Manager role to the person who needs to be able to perform these searches if you want to keep the permissions as contained as possible – since I was the only one working on eDiscovery in my tenant, and it was ok for me to see all eDiscovery cases, I just went with the eDiscovery Administrator.

Here’s the breakdown of the differences between the two roles:

Members (of this role group) can also create and manage eDiscovery cases, add and remove members to a case, create and edit Content Searches associated with a case, and access case data in Office 365 Advanced eDiscovery.

An eDiscovery Administrator is a member of the eDiscovery Manager role group who has been assigned additional permissions. In addition to the tasks that an eDiscovery Manager can perform, an eDiscovery Administrator can:

• View all eDiscovery cases in the organization.

• Manage any eDiscovery case after they add themselves as a member of the case.

From <https://docs.microsoft.com/en-us/office365/securitycompliance/permissions-in-the-security-and-compliance-center>

So just remember – an eDiscovery manager can manage cases they’re assigned to, but an eDiscovery administrator can assign themselves to any case an manage it. Now that we’ve gotten that out of the way, let’s move on.

While editing the role group, click Edit to add someone as a Manager or Administrator:

On the next screen that opens up, click on the Choose eDiscovery Administrator link to add someone to this role group:

Pick your user from the GAL, and select their name to add them to the list:

Click Done, and then Save:

Creating a new eDiscovery search:

Now that you have the permissions you need to run your search, head over to Search and Investigation – Content Search:

You can obviously create and edit searches both through the GUI and the Shell – we’ll start with the GUI, and head over to the Shell afterwards.

Click on +New search:

Clicking on New Search will open your search query window so you can start editing directly – a Guided Search will open a wizard to walk you through your options, and searching by ID List requires you to upload a list of Exchange IDs to search against. For what we need to achieve here, we’re just going to be doing a regular search, and applying some logic and filters to get exactly what we need to export (Sent Items within a date range).

Refining your search query:

Now that we have a new search created, we need to go ahead and refine our search query to get the results we need. In the query window, start by removing the keywords condition, and then adding a new one:

For this search, we’re going to use two conditions: Sender and Sent

(For a full description of all the keyword queries and search conditions available, check out the Microsoft Docs here.)

The Sent field is going to give us our date range option, and our Sender field is going to identify the emails that have been sent by those specific people.

The Sender field does not allow for you to add multiple people at once – which is why we’ll be switching to PowerShell shortly – you can easily add people one at a time by typing their names in, resolving them in the GAL, and then clicking on their names to add them. If you need to search against multiple people, this is going to drive you crazy, so we’re going to update that through PowerShell instead.

The last thing to do before saving your search query is to choose the locations you want to search against:

You obviously have a number of options here, depending on what it is you’re trying to get done – since this scenario requires a specific scope, we’re going to narrow this down to only searching in specific user’s mailboxes. Click on the Choose users, groups, or teams option to select your mailbox locations:

Next, click Choose users, groups, or teams:

Once again, you can type people’s names in individually and select them from the list – but that’s not the kind of people we are, is it now?

I’m just going to go ahead and set my first location, and then edit the list through PowerShell. Click Choose, Done, then Save.

Lastly, click Save & Run, and let’s head over to PowerShell:

You’ll be prompted to name your search at this point – just go ahead and give it something easy to recognize so you can find it through PowerShell later.

Need more Power(Shell)!

Ok, now that our search is running, let’s bring it up in PowerShell and edit it – note that you could easily have created your search from within PowerShell if you wanted to, and in fact you might find that way easier… up to you. Start by getting connected to the Security & Compliance Center admin shell.

From here on in, I don’t have a shiny script that will do this all for you, but I’ll show you the commands that I run to give myself some more control over the whole process here.

Let’s start out by creating a variable with the name of our Compliance search:

$cSearch = “Sent Items – November 13th to 23rd”

Next, I want to confirm what my current search parameters are, so I have a baseline to go back to if I mess up, and also just to see what the language looks like:

Write-Host “Original Search Query:” -ForegroundColor Yellow

Get-ComplianceSearch -Identity $cSearch | Select -ExpandProperty ContentMatchQuery

This is what we get:

The (c:c) is the equivalent of an AND operator, and then we have our from field, and the sent field – identifying the date range and the senders in question.

Ok, now we want to go in and add a bunch of users – in this case, I’ve created a CSV file that contains two columns: DisplayName and UserPrincipalName. I used these ones specifically so I can target these users for different things. Let’s go ahead and import those users as a variable:

$cUsers = Import-Csv .Desktopcompliance-users.csv

Now that we have our users ready to go, we can start editing our query:

Since we know we want to keep our date range as is, we’re going to store it in a variable so we can build on it:

$daterange = “(c:c)(sent=2018-11-13..2018-11-23)”

Now comes the fun part – we’re going to run a foreach loop on our $cUsers variable, and add each user to the query – many thanks to my homie and partner in crime Brendan for helping me with my string manipulation here:

# Update Search Query to include emails sent by specific users:

foreach ($c in $cUsers){$query = $daterange += “(from=””$($c.DisplayName)“”)”}

And then I’ll just check to see how my query has changed:

Write-Host “Updated Search Query:” -ForegroundColor Magenta

$query

Voila!

Now, you’re obviously not going to necessarily use PowerShell if you really only needed to add three users – but this will definitely come in handy if you’re adding tens or hundreds of users to your query.

Next, let’s update our Compliance Search with our new query, and get it started:

Set-ComplianceSearch -Identity $cSearch -ContentMatchQuery $query | Start-ComplianceSearch

So far so good… however, you’ll remember that we want to find all the sent items in a set of mailboxes, and when we set this search up, we only added a single mailbox to the search locations.

Get-ComplianceSearch -Identity $cSearch | Select ExchangeLocation

Let’s go back and fix that now:

foreach ($c in $cUsers){

Write-Host “Adding $($c.DisplayName) to the Exchange Search Scope”

Set-ComplianceSearch -Identity $cSearch -AddExchangeLocation $c.UserPrincipalName

}

Start-ComplianceSearch -Identity $cSearch

You can re-run your get- command to make sure that your search has updated correctly:

As before, you can start your search using the following command:

Start-ComplianceSearch -Identity $cSearch

And then use this one to check on the status of the search:

Get-ComplianceSearch -Identity $cSearch | Select Status

Now we can go back into the Security & Compliance Center and see what we find – note that our query has updated with all the changes we’ve been making in the shell:

Now that you’ve gotten your search results, you can go ahead and export them all to a single PST, export to a PST per mailbox, or just export the individual emails – depending on your requirements. As you can see, there’s a fair amount you can do from within the Security & Compliance Center, and using PowerShell gives you even greater control and flexibility in structuring your queries however you want.

Hope this helped – peace out!

Of course, first things first is getting connected – Microsoft has made the connectivity easy using the Exchange Online Modern Auth PowerShell Module, which allows you to connect to both an Exchange Online admin session, as well as to the Security & Compliance Center using Connect-IPPSSession.

Mind you, if you’ve seen any of my stuff before, you know I’m going to want to find a way to connect using PowerShell ISE – because that’s just how I roll!

As before, I was able to update my Exchange Online connection script to target the protection.outlook.com URI instead of the Exchange Online admin URI, like so:

#Connect to the Security & Compliance Center

Write-Host “Connecting to the Security and Compliance Center” -ForegroundColor Green

$UPN = Read-Host “Enter the UPN of the user you want to connect with”

Import-Module $((Get-ChildItem -Path $($env:LOCALAPPDATA+“Apps2.0”) -Filter Microsoft.Exchange.Management.ExoPowershellModule.dll -Recurse ).FullName|?{$_ -notmatch “_none_”}|select -First 1)

$EXOSession = New-ExoPSSession -ConnectionUri “https://ps.compliance.protection.outlook.com/PowerShell-LiveId” -UserPrincipalName $UPN

Import-PSSession $EXOSession

You’ll notice we’re using the same module we use to connect to Exchange Online using MFA – I’ve simply updated the connection string to go to the Security & Compliance Center instead of Exchange Online. Apart from that, it’s more or less the same. As before, I still pass along a connection to Azure AD in case I want to be able to manage those attributes at the same time. You can also modify this to connect to the ExO (Exchange Online) shell at the same time if you like, or just keep them separate – up to you.

I’ve also updated the script to check for an existing connection to the Security & Compliance Center, as I like to be able to run my scripts multiple times without re-authenticating – head on over to GitHub and grab yourself a copy if you’d like.

Thanks for reading!

It was happening so many times that I ended up writing a script to automate the process – I figured it might be useful (or at least components of it), so I’m sharing it here. I drew heavily from Rhoderick’s process – I just put it all together so I could simply run the script whenever I needed to reset the configuration in one simple step.

Start by getting your ADFS certificate thumbnail, and storing it as a variable – remember that you should have the same third-party certificate installed on all your STS and WAP servers, so once you’ve gotten this variable set once you should be good to go until you have to renew your certificate. Your ADFS certificate will be installed in your local computer store, and will more than likely be named something like sts.domain.com:

[powershell]
Get-ChildItem -Path "Cert:LocalMachineMy"
[/powershell]

Now that we have our thumbprint, we’re going to store it in a variable – we’ll also capture our admin credentials at the same time so that we’re ready to use those when we need to reconfigure the Web Application Proxy.

[powershell]
$creds = Get-Credential
$cert = "C9ADFCB04C432C4C0F213BA6DECBDB107B76F102"
[/powershell]

The next piece of the puzzle here is to reset the reg key needed to tell the Web Application Proxy that it hasn’t been configured yet – a key value of 1 means Configured, while a key value of 1 means Not Configured.

[powershell]
# Set variables for updating the registry, in order to reset the WAP Config status
$regpath = "HKLM:SOFTWAREMicrosoftADFS"
$keyname = "ProxyConfigurationStatus"
$keyvalue = "1"
&nbsp;
# Reset WAP Configuration Status
New-ItemProperty -Path $regpath -Name $keyname -Value $keyvalue -PropertyType DWORD -Force
[/powershell]

If you want to check what the current status of the key is, simply uncomment and run this line:

[powershell]
# Use this key to check the value of the registry key above.
# Get-ItemProperty -Path $regpath -Name $keyname
[/powershell]

This next step is my own personal housekeeping step – every time the WAP service resets, it creates a new “ADFS Proxy Trust” certificate, causing your certificate store to get cluttered. This next step simply deletes them all – there’s no problem doing this, as when you complete the script to re-install the web application proxy, it creates a new one.

[powershell]
# Remove all old WAP certificates from the local store – a new one will be generated once trust is established
Set-Location Cert:LocalMachineMy
Get-ChildItem | where {$_.Subject -match "CN=ADFS ProxyTrust"} | Remove-Item
Set-Location C:
[/powershell]

All clean!

The final step now is to install the Web Application Proxy – make sure to replace the Federation Service Name with your own STS server:

[powershell]
# Re-establish Federation Trust with the sts service.
Install-WebApplicationProxy -CertificateThumbprint $cert -FederationServiceName sts.masterandcmdr.com -FederationServiceTrustCredential $creds
[/powershell]

If all goes well, you should have a nice minty fresh WAP server ready to go, trusting the world as it once did!

If you found this useful, feel free to let me know – head over to Github if you’d like to download the whole thing and use it for yourself.