One possibility: if you can find the GUID volume name (your question doesn't make this clear) and if the volume has a drive letter assigned, then Win32_Volume will link the GUID volume name to the drive letter and Win32_LogicalDiskToPartition will link the drive letter to the disk number and partition number.
However, MSiSCSIInitiator_SessionClass
looks to be a better option. This command works for me:
PS C:\Windows\system32> (get-wmiobject -namespace ROOT\WMI -class MSiSCSIInitiator_SessionClass -filter "TargetName='iqn.2001-05.com.equallogic:0-8a0906-d27481f06-93a000d015c4ed69-oslo-san-1'").Devices | Select -property LegacyName
LegacyName
----------
\\.\PhysicalDrive2
If there might be more than one partition, the Win32_DiskDriveToDiskPartition
class can be used to list them.
According to the Microsoft support engineer I spoke with... and the Microsoft engineer he escalated me to... and their manager, the short answer is that the only way to rid myself of this cursed object is to do an authoritative restore to before this object's appearance in the LostAndFound
container. I'm convinced I could also rid myself of it by booting all the domain controllers to LiveCDs and manually editing the AD database, but short of those two non-options, I'm stuck with it.
As to how and why this is the case:
We ran a repadmin /showobjmeta
against the object (to peek into its metadata) and were able to determine from the object's isDeleted
version (2
) that it was deleted, then unexpectedly and unsuccessfully/partially restored, which is what is causing the problem. It was suggested, and seems likely to me, that after the object was restored, but before the change had completely replicated, it was deleted again, along with its parent OU, causing the restore to fail, and resulting in it being considered an orphaned object by at least some of our domain controllers, landing it in the LostAndFound
container.
As a result of the partial restore, it cannot be restored. As a result of the object's SAMAccountType
being empty, it cannot be deleted (or modified).
The SAMAccountType
attribute is a value that cannot be changed by any user, and attempting to do so throws the below error:
Operation failed. Error code: 0x209a
Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM).
0000209A: SvcErr: DSID-031A1021, problem 5003
(WILL_NOT_PERFORM), data 0
We can't restore the object to get the system (Security Accounts Manager) to set this attribute because of the partially-restored state it's in, and we can't delete it (or modify it) without a valid value for that attribute.
However, since this is too interesting of a case for me to simply walk away from, I'm going to poke around for a while and see if I can't come up with a way around this, or at least expand my knowledge of AD a little bit more in the attempt. Beats troubleshooting printers... and frankly, it turns out that a computer telling me "WILL_NOT_PERFORM" is a challenge I cannot resist.
Oh yes you will perform, dammit!
Best Answer
I know this is old, but in case anybody else is looking for the answer, this should solve for many "volume to disk" scenarios. For your scenario (and many others), you can use Get-Partition which can return the disk number. Give it the drive letter where the volume mount point resides. Using the $Volumepath variable in your example: