Could this be a result of the known memory leak in Exchange Online Powershell Module?

Explains why a restart of the relevant services solves the problem (for a while)

Hi,

it’s not related to the EXO memory leak.

I saw that I had 2 Get-Mailbox cmdlets in my driver (deprecated) so I don’t know if this is the main cause(as you know these cmdlets are deprecated).

“Explains why a restart of the relevant services solves the problem (for a while”

I don’t know but it’s true, after a restart of the driver and the exo service all work perfectly.

Thanks

regards

The error message is a generic PowerShell error.

Essentially the expected pipeline of data is empty and PowerShell doesn't like that at all.

if it is triggered by a custom cmdlet that is failing in some manner, then this could also explain the issue.

Also, if the problem only started once you upgraded to driver version 5.2.0.200 - maybe the upgrade process wasn't entirely successful.

When you refer to Get-Mailbox - are you really referencing Security & Compliance features.

For example: In 2020, Microsoft deprecated *-MailboxSearch which instead became  *-ComplianceSearch

Pretty sure that the regular Get-Mailbox remains supported.

You are right, Get- Mailbox is supported yet, Search-mailbox is deprecated.

Yes the issue appears with 5.2.0.200 but I think is not related to an unsuccessful upgrade.

I think this error is related when driver get informations from the Tenant, Users and groups.

regards

carnold said:

Yes the issue appears with 5.2.0.200 but I think is not related to an unsuccessful upgrade.

I think this error is related when driver get informations from the Tenant, Users and groups.

Have you managed to narrow down if this query for info from the tenant that you mention is a custom one that you have added to the driver policy or to a built in query? If they are built-in does disabling some of the less used options via the provided GCVs might help narrow down the issue.

Might your issue be related to this old thread. community.opentext.com/.../azuread-driver-idm-4-7-roles-query-fails-status-400

Regardless, there are two debugging steps that I have used on several occasions to try and understand what is happening between driver shim and exchange service. That usually helps me quickly identify the underlying issue.

1. A MITM tool like fiddler can intercept some of the traffic and allow you to view what actually is sent and received.

2. It is possible to enable some Microsoft debugging for the Exchange service by tweaking an XML file. 

Achieved the first by installing fiddler as a MITM system proxy.
This picks up the calls made by PowerShell modules as they respect the system proxy settings.
IDM exchange service can be configured to use a proxy by modifying the ExchServerHost.exe.config file - that should proxy outgoing traffic from this service.

Had to resort to a slightly nasty hack to be able to intercept the loopback traffic from driver shim to IDMExchange service.

Configured the driver shim to specifically connect to 127.0.0.1 and port 8888 (the port that fiddler was listening to) using HTTP (not HTTPS)

Then I used a simple FiddlerScript to transform the now proxies connection to HTTPS, change the port to 9001 and the hostname to the machine’s DNS name. That ensured the traffic was routes to the correct location.

For the Microsoft debugging stuff, that is described in the thread I linked to. Put simply, one can edit the same .exe.config file and add:

<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
<listeners>
<add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="path to a \Trace.svclog"/>
</listeners>
</source>
</sources>
</system.diagnostics>