Powershell: Dedup feature behving strange in PowerShell Core

Created on 17 May 2020  路  23Comments  路  Source: PowerShell/PowerShell

I tried to use PowerShell Core with the Get-DedupStatus and Get-DedupVolume.

First of all, in an unelevated shell it just shows "A general error has occured" without more specific message (like Windows PowerShell does, from this message it is possible to understand that we got an ACCESS DENIED error).

Now, in an elevated shell the table formatting is buggy. I.e. for Get-DedupStatus the columns "FreeSpace" and "SavedSpace" are just empty (while they are filled in Windows PowerShell), the same for Get-DedupVolume (columns SavedSpace and SavingsRate are empty) and Get-DedupSchedule (column "StartTime" is also empty).

This is not really deal-breaking, but seeing this type of bugs when Windows PowerShell nags to try out PowerShell Core makes me wondering if it is really ready for this...

Issue-Question Resolution-Answered

Most helpful comment

Made a UserVoice related topic: https://windowsserver.uservoice.com/forums/295047-general-feedback/suggestions/40450393-make-deduplication-powershell-commands-compatible

Windows Server
Right now when trying to use commands like Get-DedupStatus or Get-DedupVolume from PowerShell Core - the output is incorrect, i.e. content of some tables aren't displayed. If before using I load the module via Import-Module -SkipEditionCheck Deduplication, it starts working fine. Please mark the module as compatible with PowerShell Core and/or test if it is actually compatible! Related bug in PowerShell Core repository: https://github.com/PowerShell/PowerShell/issues/12702

All 23 comments

/cc @anmenaga for information.

@Evengard Please share .psd1 file of the module.

I can't share it as it is a feature of MS Windows system, it is a system component. Even if I managed to pull it off my system somehow, I'm not sure it would work "as is".
It is the Windows Server deduplication system component.

If this module shipped with a Windows feature, it's quite possible the module has not been updated to work correctly in PowerShell 7.

The Windows component modules are generally owned by the respective product teams rather than the PowerShell team, so there's a limit to what we can do from PowerShell itself, especially if the module happens to require some .NET API that did not get reimplemented in .NET Core.

I'd give it a try with an explicit Import-Module -UseWindowsCompatibility for the relevant module to see if it can be handled that way without losing too much functionality, but beyond that your best bet is usually filing a UserVoice ticket for the relevant feature so the team is aware that there is demand for their PowerShell module to continue to be updated.

I've actually tried to load the module with Import-Module -SkipEditionCheck Deduplication and... Well, it actually worked! The FreeSpace, SavedSpace and all other columns actually DID appear in the output exactly as expected!

Can it be that the bug is in the WinPSCompatSession remoting session?

Deduplication.zip

Pulled the actual module files from C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Deduplication

Can it be that the bug is in the WinPSCompatSession remoting session?

Yes and no. 馃槃

Essentially whenever you have to go over a remoting session, PS has to serialize the data between the sessions, it's not able to just reach in and read the memory or whatever to see what's up. In some cases, that doesn't play well with how something needs to work, methods on the objects are typically missing, and the object type ends up changing, because oftentimes they don't have public constructors so you can't re-instantiate objects.

So... yeah, depending on how reliant the original code is on the objects being precisely as they originally were, passing objects over a remoting session absolutely can break things. It's hard to call it a bug when it's just the only way that can work at all currently. 馃榿

If it's able to work as-is in pwsh with just a -SkipEditionCheck that's probably the best way to handle it, but a lot of the Windows modules don't play so well with that either.

Is there any way to force skipping edition check "on the fly" for some modules (some kind of per-module configuration)? Because this exact module is actually made available "by default" by the system, and usually no Import-Module is needed for using it.

Is there any way to force skipping edition check "on the fly" for some modules

The module is OS component so it should be tested and marked as Core compatible by MSFT.
You could use UserVoice site and/or Windows 10 Feedback tool to send the request to the module owners.

So is there not a "hack" how to make it "marked" on my end only, by patching some files and whatnot?

Made a UserVoice related topic: https://windowsserver.uservoice.com/forums/295047-general-feedback/suggestions/40450393-make-deduplication-powershell-commands-compatible

Windows Server
Right now when trying to use commands like Get-DedupStatus or Get-DedupVolume from PowerShell Core - the output is incorrect, i.e. content of some tables aren't displayed. If before using I load the module via Import-Module -SkipEditionCheck Deduplication, it starts working fine. Please mark the module as compatible with PowerShell Core and/or test if it is actually compatible! Related bug in PowerShell Core repository: https://github.com/PowerShell/PowerShell/issues/12702

@Evengard if the module in question has a PSD1 file you can look to add the PSEdition (or was it CompatiblePSEditions? one of those) field in the manifest with 'Desktop', 'Core' values in order for pwsh to always attempt to import it directly rather than via remoting.

YMMV though, but worth a shot I suppose. 馃檪

There is nothing of the sorts. The only thing which may be kinda close is PowerShellVersion="3.0", but there is nothing about PSEditions

Yeah, you'll need to add the key to the manifest, it doesn't usually exist on older modules. Best check one of the builtin powershell module manifests to see what the expected key name is.

Yup, adding CompatiblePSEditions="Core","Desktop" actually worked. Although I'm a bit worried about Windows System File Protection...
UPD: yup, sfc /scannow actually fails after this change. Too bad... There is no way to override a module definition file elsewhere?

Not that I'm aware of. You could opt to copy the module completely into a powershell 7-specific modules directory on your PSModulePath with the modified manifest and leave the system copy untouched?

Yep, that actually worked!
Actually I went even further:
mklink /J %userprofile%\Documents\PowerShell\Modules\Deduplication C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Deduplication
After this I didn't even needed to edit the module definition file at all! It just loaded natively.
I consider this kinda "workarounded" for now.

If you want it to apply to all users, do
mklink /J "C:\Program Files\PowerShell\Modules\Deduplication" C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Deduplication

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.

Is there any way to force skipping edition check "on the fly"

This is deliberate, since it's not really something we want to encourage.

You could create a wrapper module with the same manifest. Then add a psm1 with the single line: Import-Module <path-to-system-module> -SkipEditionCheck. That way, if the module is updated in some way, everything will still work.

I guess a junction link would act similarly after all, except that we would also use the actual module definition?

Yeah a link should work fine. The issue there is that the manifest expects things to be loaded alongside, so the PSM1 with some stars in the exports might be easier. You might also consider opening an issue in https://github.com/PowerShell/WindowsCompatibility so we can track the need to port the module

GitHub
Module that allows Windows PowerShell Modules to be used from PSCore6 - PowerShell/WindowsCompatibility

Opened the issue in there too (https://github.com/PowerShell/WindowsCompatibility/issues/83)

Was this page helpful?
0 / 5 - 0 ratings