Disk Resource defines CIM class MSFT_Disk which is a Windows built-in CIM class

[PlagueHO]

While adding PartitionStyle parameter to Disk (see #137), I realized that the name of the CIM class implemented in the Disk resource (MSFT_Disk) is the same name as the built-in CIM Class (https://msdn.microsoft.com/en-us/library/windows/desktop/hh830493(v=vs.85).aspx).

This causes some odd behavior, such as Get-TargetResource to return an object that contains both the parameters defined in the resource MOF and the built in CIM class definition. This also results in any property that exists in the build in CIM Class definition can not be set when returned by Get-TargetResource. So when I tried to implement the PartitionStyle parameter, it worked correctly in Set-TargetResource and Test-TargetResource, but Get-TargetResource would always return the default value from the built-in CIM class (which was Unknown).

This behavior only resulted when xStorage was renamed StorageDsc.

To work around this issue for now I'm going to use the name PartitionFormat for the resource parameter.

In the longer term I think it might be worth considering renaming the resource as I'm not sure if there are any other nasty side effects with conflicting with one of the built-in CIM classes. This would be a significant BREAKING CHANGE however.

@johlju - any thoughts on this?

[johlju]

As per discussion on Gitter, let see if we can change the prefix 'MSFT' to 'MSFTDSC' for this particular resource to avoid a breaking change.

[NeoBeum]

This looks like something I complained about on MSDN late 2017, with issues stemming from 2015

Get-Disk -BusType now has an enumeration for NVME, however the same information is harder to collect in traditional cmd.
The objects use different source classes and at one stage I had a Samsung 850 Pro report it was using IDE.

DISKPART
WMIC DiskDrive
Get-Disk
Get-PhysicalDisk
DevCon

A moderator on MSDN told me that MSFT_Disk wasn't a base class.. so I stopped bothering to provide feedback and just use my own fixes for WinPE.

I also believe that the recent SD Card fiasco is related to this.

I'll be back when I return to my pc as I'm afk

found the post: adding so I can continue my old project https://social.microsoft.com/Forums/en-US/e3b57025-a37f-48e2-b260-c92845fd5132/help-a-student-with-consumeroem-windows-redeployment-solutions-to-prevent-bad-upgrade-or-install?forum=Offtopic

[PlagueHO]

Thanks for the info BeoBeum!

[NeoBeum]

@PlagueHO
I found the other mismatch or wmi class that doesn't provide information if querying BusType. Specifically querying BusType "NVME".

SCSIBus and InterfaceType don't have any corresponding data pairs with MSFT_Disk.

As I'm not at my computer, I haven't checked, but I'm fairly sure that Win32_DiskDrive has no way to return a BusType for NVME since I last checked in #2016.

https://docs.microsoft.com/en-us/windows/desktop/cimwin32prov/win32-diskdrive