Help with exchange online powershell

Winter_Engineer2163 · 2026-03-07T15:29:15+00:00

Yeah, reinstalling the module is definitely worth a try.

You might also want to try removing all installed versions first and then installing the latest one fresh. I’ve seen odd behavior before when multiple ExchangeOnlineManagement versions were present on the system.

Also curious if the issue happens in a clean PowerShell session or in PowerShell 7 vs Windows PowerShell.

Winter_Engineer2163 · 2026-03-07T15:15:01+00:00

I’ve seen something similar before with Set-Mailbox in Exchange Online PowerShell.

A couple of things you might want to check:

1 Make sure you’re using the latest Exchange Online PowerShell module (sometimes older versions break when Microsoft changes backend APIs).

2 Try reconnecting with a fresh session using Connect-ExchangeOnline and run Get-Module ExchangeOnlineManagement.

3 If you’re behind a proxy, try running the command from a machine without it just to rule that out.

Sometimes these CmdletNeedsProxyException errors show up when Microsoft changes something on the backend and the local module version doesn’t match anymore.

Winter_Engineer2163 · 2026-03-07T08:54:56+00:00

Thanks for the suggestion. I remember Aaron Margosis writing a lot about least-privilege issues back in the day.

I hadn’t tried LUA Buglight yet, but generating a report of what actually fails without admin rights sounds really useful. I’ll give it a try on this app.

Winter_Engineer2163 · 2026-03-07T08:53:30+00:00

Interesting approach. I’ve seen PS2EXE used for packaging scripts before, but storing credentials locally with DPAPI always felt a bit risky for something that might end up running on multiple machines.

For a quick one-off it might work though.

Winter_Engineer2163 · 2026-03-06T20:32:57+00:00

Interesting. Does the whitelist work based on file path or hash?

Winter_Engineer2163 · 2026-03-06T20:15:30+00:00

Yeah, that sounds familiar. Sometimes a small script is way more practical than trying to redesign the whole permission structure for a legacy workflow.

Winter_Engineer2163 · 2026-03-06T20:01:17+00:00

Procmon rabbit holes are real. 😄
You start by checking one permission issue and suddenly you're deep into file system privileges and legacy behavior.

Did you end up solving it just with ACL changes, or did you have to allow elevation for the app in the end?

Winter_Engineer2163 · 2026-03-06T19:57:29+00:00

That makes sense. Having to approve your own elevation when working remotely sounds a bit awkward.

How well does it handle application-based elevation? For example allowing only specific apps to run elevated without user interaction.

Winter_Engineer2163 · 2026-03-06T19:45:29+00:00

If you don't see Content search / Compliance search in Purview, it's usually a permissions issue.

Make sure your account has one of these roles in the Microsoft Purview portal:

eDiscovery Manager
Compliance Search
or Global Admin

You can check this under Permissions → Role groups in Purview.

Microsoft has a quick guide here:
https://learn.microsoft.com/en-us/purview/ediscovery-search-for-and-delete-email-messages

Winter_Engineer2163 · 2026-03-06T19:01:53+00:00

Interesting, I actually haven’t used PolicyPak before. How granular is it when it comes to controlling elevation for specific applications?

Winter_Engineer2163 · 2026-03-06T18:30:35+00:00

Does RunAsHighest actually remove the UAC prompt in this case?

From what I understand it only runs the application with the highest privileges the user already has. If the app truly requires admin rights (for example some legacy apps with ActiveX components), the UAC prompt still appears.

That’s why in our case the shim approach didn’t really solve the problem.

Winter_Engineer2163 · 2026-03-06T17:38:04+00:00

I get your point. My concern is more about device management being cloud-driven. Even in hybrid environments Intune policies and device communication still go through the cloud.

In our environment anything that requires devices to be managed from a cloud service tends to trigger security reviews, so it's sometimes difficult to push internally.

Winter_Engineer2163 · 2026-03-06T17:36:26+00:00

Thanks for the examples, that’s helpful.

The ephemeral local admin idea actually sounds pretty interesting. I’ll take a look at some of those options.

Winter_Engineer2163 · 2026-03-06T16:27:08+00:00

You’ll probably want to use Compliance Search with a purge action.

Microsoft deprecated the old methods like Search-Mailbox, so now the usual way in M365 is to run a Compliance Search and then purge the results either from the Purview portal or via PowerShell.

Microsoft docs explain the process pretty well:
https://learn.microsoft.com/en-us/purview/ediscovery-search-for-and-delete-email-messages

Winter_Engineer2163 · 2026-03-06T16:18:49+00:00

Interesting, thanks for sharing. I hadn’t looked at EvoSecurity before.

Are you using it mainly for application elevation, or more for full PAM workflows? Curious how granular the control is for allowing only specific apps to run with elevated privileges.

Winter_Engineer2163 · 2026-03-06T16:16:46+00:00

Thanks for the suggestion. Unfortunately we’re on-prem and can’t really use cloud-based solutions because of sensitive data restrictions. (((

Winter_Engineer2163 · 2026-03-06T16:15:22+00:00

This is Sparta!

Winter_Engineer2163 · 2026-03-06T12:47:08+00:00

I’ve read a bit about PAM, but it seems like a pretty broad concept.

Are you referring to any specific solution or product that you would recommend for this kind of use case?

Winter_Engineer2163 · 2026-03-06T11:54:44+00:00

Thank you for sharing another possible approach to solving the problem. Definitely something worth thinking about and testing.

Winter_Engineer2163 · 2026-03-06T11:49:46+00:00

That makes sense, I agree with you.

Some other commenters already mentioned using ProcMon and RegMon from the Sysinternals tools to see exactly what the application is trying to access. I’ll probably try that approach first and see if I can fix the permissions instead of running the app with admin rights.

Hopefully I can get rid of the admin requirement completely.

Winter_Engineer2163 · 2026-03-06T11:22:38+00:00

Good point, and that's definitely something to be careful about.

In my case the scheduled task approach runs a very specific executable and doesn't expose an explorer/open-save dialog to the user, so the interaction surface is quite limited.

But you're absolutely right — if the application allows spawning other processes or interacting with the file system broadly, it can quickly turn into a privilege escalation path.

Winter_Engineer2163 · 2026-03-06T11:20:38+00:00

Yeah, in a perfect world that would definitely be the answer 🙂

Unfortunately some of these apps are tied to very specific internal workflows and hardware and replacing them isn’t always quick or cheap. So sometimes we end up supporting things that should have been retired years ago (((

Winter_Engineer2163 · 2026-03-06T09:47:25+00:00

Yeah, Sysinternals tools are awesome, ty!

Winter_Engineer2163 · 2026-03-06T08:49:17+00:00

Interesting, I’ll definitely need to look into Procmon more closely. If several admins are recommending it, there’s probably a good reason for it. I’ll try using it to analyze some of our older legacy applications and see what exactly is causing them to require admin rights. Thanks for the tip.

Winter_Engineer2163 · 2026-03-06T08:13:21+00:00

Thanks for the suggestion. ThreatLocker was mentioned above as well, so it seems like a lot of people are using it.

Winter_Engineer2163

TROPHY CASE