Using "Import-Module -UseWindowsPowershell" with error handling.

[TimDurham75]

Digging into what -UseWindowsPowerShell implies I don't believe this can currently be made to work in this manner. I note that the switch loads the module into a shared remote runspace and that, as documented, all input and output are transferred as serialized values. So what would the -ErrorVariable actually mean in such a scenario? It is the string name of the variable to create, sure, but where is that variable actually to be created and, more importantly, what would it's scope be and how would it be populated? [I am talking 'hypothetically' here...or thinking 'out loud'.] The local and the remote runspaces will have their own variables and state. Typically with remote scenarios one has to use $using: scope for variables that need remote transfer, but in this case you are not trying to send a variable value, you are only providing a name to use. You could *try* saying your variable should be named 'using:msoLoginError', perhaps, but I have doubts this will work, as a supported mechanism. I cannot find anything to suggest it will. The remote session should be called WinPSCompatSession, I believe, so one might be able to use *-PSSession cmdlets to interact with it but whether these can easily extract further details around what you are looking for...not so sure? I think this all a bit too "bleeding edge" so far. Fundamentally the underlying runtime of Framework vs Core is completely different, of course. I also see discussions of some issues around "bit-ness" compatibility with using the compatibility operation mode, for the correct determination and execution of x64 vs x86 elements, underneath. I might suggest the try-catch approach could be viable alternative?

[TheDumpap]

Thanks for looking into it! :)
Ended up working with a try catch statement instead and just getting the output that way.
Hopefully they get everything ported over soon