microsoft
EXOOrganizationConfig: Unable to find type [short].
Description of the issue
While running Microsoft365DSC for the resource EXOOrganizationConfig the error "Unable to find type [short]." is thrown repeatedly.
This seems to be a current issue with the ExchangeOnlineManagement module in PowerShell 5.1 (https://www.reddit.com/r/PowerShell/comments/1n99vq2/getting_unable_to_find_type_short/).
The corresponding commands (e.g., Set-OrganizationConfig -BookingsEnabled $true) can be used in PowerShell 7 without facing similar issues.
Microsoft 365 DSC Version
V1.25.910.1
Which workloads are affected
Exchange Online
The DSC configuration
EXOOrganizationConfig 'EXOOrganizationConfig' {
IsSingleInstance = "Yes";
AutoExpandingArchive = $False;
}
Verbose logs showing the problem
Unable to find type [short].
+ CategoryInfo : InvalidOperation: (short:) [], CimException
+ FullyQualifiedErrorId : TypeNotFound
Environment Information + PowerShell Version
PSVersion: 5.1.17763.7786
True dat... [short] is a type accelerator (meaning an "alias") for [int16]. So this is the issue with Windows PowerShell 5.1:
# Does not work
PS> [short]$a = 1
Unable to find type [short].
At line:1 char:1
+ [short]$a = 1
+ ~~~~~~~
+ CategoryInfo : InvalidOperation: (short:TypeName) [], RuntimeException
+ FullyQualifiedErrorId : TypeNotFound
# Works
PS> [int16]$a = 1
The type accelerator was then added in PowerShell 6.2 if I'm not mistaken with my Google search. In PS7, it looks like the following:
PS> [short]$a = 1
PS> $a.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True Int16 System.ValueType
Guess we have to wait until the next version... How I despise those clunky, unfinished modules. Just as bad as the Graph modules.
I'm curious as to what drove the decision to use [short] knowing that there are compatibility issues? This makes even less sense when [int16] is available across all PowerShell versions.
What am I missing here?
The Exchange PowerShell team probably aren't considering PS 5.1 compatibility a priority?
@Borgquite I'm having trouble understanding how this is an Exchange PowerShell compatibility issue and not a Microsoft365DSC (or possibly Windows DSC in general) issue? To my untrained eye, the error appears to come from creating the parameter splat that Set-TargetResource is building to be used with the Set-OrganizationConfig cmdlet. Is this not the case? Again, just me guessing here, but it looks like there's some sort of normalization of parameters going on, but I'm unsure as to where that's happening.
If I'm completely off, please let me know, I'm just trying to understand the root cause of what's going on here so we can build a workaround if needed.
It's an issue with Exchange PowerShell. In the original example above, Microsoft365DSC is sending AutoExpandingArchive as a Boolean parameter (which is the correct type), but Set-OrganizationConfig is still failing.
Take a look at the linked Reddit post. There are no [int16] or [short] parameters involved at all, yet Set-OrganizationConfig still fails (this time with RejectDirectSend).
So the DSC module is sending the parameters with the types required by the Exchange Online PowerShell module, but that module is failing under PS 5.1, hence the error.
@WilsonAcosta44 A bit more to the story here: Microsoft365DSC is a PowerShell module just like ExchangeOnlineManagement. We consume other modules for their functionality so that we don't have to build them ourselves. These modules then export cmdlets (binary representations of functions) or functions (code that can be invoked with a command name). We utilize those cmdlets and functions, such as Set-OrganizationConfig, to invoke a behaviour from inside those other modules. Just like Connect-MgGraph or any other Graph cmdlet you might know or think of.
Inside those modules, they do some stuff with the parameters and also have sophisticated code that makes sure everything is "good" to go or handle edge cases, errors and more. Somewhere in the EXO module, they did use the [short] type, which is not naturally known to Windows PowerShell 5.1.
Unfortunately, there is nothing we from the Microsoft365DSC community or even team can do here - We have no influence whatsoever for the EXO module since we are only consuming its functionality and not developing it. If we were, we could simply update the type. That's probably what the responsible team(s) of the module will do at the end, replace the invalid [short] with e.g. [int16].
I think this issue arose because most of the devs at Microsoft are familiar with C#, where this type is widely known and used. However, it's not known natively to PowerShell until the Core edition. They most likely forgot about the fact and only tested the functionality in their Dev environment with PowerShell 7. Unless their build pipeline would do the exact same thing and enter the code block that contains the invalid type, they won't discover that there is an issue. To be fair, we from our side could potentially detect this if we were to run full end-to-end or integration testing, but this requires a whole lot of extra setup that currently is not there.
Hope that clears it all a bit up. Feel free to add more questions if you have any, I'd be glad to answer them.
@FabienTschanz Is it worth proposing switching EXOOrganizationConfig to internally use PowerShell 7 with the work you did under #5433?
Just that although Windows PowerShell 5.1 is supposed to be supported with all module versions, there doesn't seem to be much interest within the PowerShell module authors in making sure that promise is true, for example:
https://www.reddit.com/r/PowerShell/comments/1hrrecu/issues_running_the_connectexchangeonline_command/ https://www.reddit.com/r/PowerShell/comments/1jywcpn/exchange_online_powershell_module_37x_ise_issue/
I had a discussion with @NikCharlebois one time. The moment we want to introduce the PS7 compatibility layer, we have to also make PS7 a hard dependency on the module, which would be a breaking change. I'm not quite certain what the result of the discussion was, but it was then decided to not make this shift happen (reasons unknown to me, forgot them, sorry).
Personally, I'd like this change to happen. It introduces the "modern" experience with PS7 and all of its benefits, and a more stable environment for the modules since they're mostly targeted at PS7.