microsoft
Reduce memory consumption by implementing recommendations for Exchange Online PowerShell V3 module
Description of the issue
The Exchange Online team recently posted some recommendations on reducing memory consumption of the Exchange Online PowerShell V3 module:
- Do not load the help package (using Connect-ExchangeOnline -SkipLoadingCmdletHelp
- Load only specific cmdlets which are required by a script (using Connect-ExchangeOnline -CommandName)
- Create a new PowerShell process for each new Exchange Online connection (using Start-Process / Exit)
Feels like some or all of these could be well used when connecting to Exchange Online using the Microsoft365DSC module - e.g. 'SkipLoadingCmdletHelp' is probably a really quick and easy win?
https://techcommunity.microsoft.com/t5/exchange-team-blog/reducing-memory-consumption-of-the-exchange-online-powershell-v3/ba-p/3970086
Microsoft 365 DSC Version
1.23.1122.1
Which workloads are affected
Exchange Online
The DSC configuration
All DSC configurations (see blog post)
Verbose logs showing the problem
N/A
Environment Information + PowerShell Version
N/A
Agreed on the -SkipLoadingCmdletHelp. We will go ahead and implement it right away. The two other recommendations however would require some more thinking and probably so fair amount of refactoring. We want to make sure MSCloudLoginAssistant continues to be an independent module outside of M365DSC. This means that we would have to add additional properties to the Connect-M365Tenant that would accept a list of command to be loaded, and that M365DSC would have to pre-determine the ones required upon connection. This in itself would require a lot of work.
-SkipLoadingCmdletHelp got recently added to MSCloudLoginAssistant in V 1.1.1 and is available in M365DSC starting with V 1.23.1129.1
I've updated to 3.5.1 and am now using the -SkipLoadingCmdletHelp option, however sometimes the Help.xml files are still downloaded to the tmpEXO folder and not purged after running the disconnect command
Options 1 and 2 are implemented by now and available in MSCloudLoginAssistant (and now leveraged by Microsoft365DSC). The third option doesn't seem feasible at the moment and would require a massive rework and performance overhead. Do we want to close this issue and keep the last option in the back of our heads? Now it's about time to check if the latest updates to Microsoft365DSC actually did help in reducing the memory consumption.
@FabienTschanz We're using -CommandName (option 2) in M365DSC now? Didn't realise that had happend!
It's in the making for some resources, but not yet finished. I will start the implementation for some resources soon.
@Borgquite Seeing how much faster the connection handling is now, I suggest we put additional measures on hold. Do you agree? I think it's so much better that any more effort, if not desperately required, can be omitted.
@FabienTschanz I'd agree - let's put it on hold. In theory I'm guessing the memory issues may arise after many, many LCM resource runs (particularly if connections need to be reset or tokens expire) but not worth spending too much time unless the issue arises again.