OK - per MBS' suggestion, I ran 'vssadmin list shadows'.
Here's one stanza:
Contents of shadow copy set ID: {facc10d3-818e-40e8-b7cd-65030507c7f9}
Contained 1 shadow copies at creation time: 2017-03-30 04:00:05
Shadow Copy ID: {8f76f079-7ac6-4fc4-ba2a-61a0327b5b83}
Original Volume:
(U:)\\?\Volume{cc4e4794-f6ef-4141-980a-87a984c191b5}\
Shadow Copy Volume:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy151
Originating Machine: zUSFS01p.zetron.com
Service Machine: zUSFS01p.zetron.com
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessible
Attributes: Persistent, Client-accessible, No auto
release, No writers, Differential
Only the original volume GUID {cc4e4794-f6ef-4141-980a-87a984c191b5}
shows up, with this line:
Information,2016-05-12 11:48:22,Microsoft-Windows-Ntfs,98,None,Volume
\\?\Volume{cc4e4794-f6ef-4141-980a-87a984c191b5}
(\Device\HarddiskVolume113) is healthy. No action is needed.
The other GUIDs don't show ({facc10d3-818e-40e8-b7cd-65030507c7f9} and
{8f76f079-7ac6-4fc4-ba2a-61a0327b5b83})
I'll take a look at the other entries in the output.
Kurt
On Fri, Mar 31, 2017 at 1:32 PM, Miller Bonnie L.
<[email protected]> wrote:
> Windows Volume Shadow Copies?
>
> -Bonnie
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Kurt Buff
> Sent: Friday, March 31, 2017 1:19 PM
> To: ntsysadm <[email protected]>
> Subject: [NTSysADM] WTF? Way too many Volume/Disk GUIDs
>
> I've got a 2012R2 file server with some problems. It recently locked up, and
> we had to force boot it through the VMware interface.
>
> It's got 13 drives with letters, plus the usual system reserved partition.
>
> Here are the volume GUIDs from PS:
> # GWMI -namespace root\cimv2 -class win32_volume | select driveletter,
> deviceid | sort deviceid | ft -auto
>
> driveletter deviceid
> ----------- --------
> T: \\?\Volume{0b58699a-c6d4-11e5-80ef-005056b43cf4}\
> J: \\?\Volume{27499b01-b5b4-43d7-98ae-17dbd948607e}\
> G: \\?\Volume{3e50ec99-13b5-4d52-8091-2feeb695943f}\
> \\?\Volume{3ec25e24-a333-11e3-80b4-806e6f6e6963}\
> C: \\?\Volume{3ec25e25-a333-11e3-80b4-806e6f6e6963}\
> D: \\?\Volume{3ec25e29-a333-11e3-80b4-806e6f6e6963}\
> P: \\?\Volume{410169c9-33c3-11e6-80fb-005056b43cf4}\
> X: \\?\Volume{515ebcdb-5c2e-11e4-80d4-005056b43cf4}\
> K: \\?\Volume{79470a07-567a-11e4-80d3-005056b43cf4}\
> I: \\?\Volume{88aa852a-1610-4875-8265-bb3c0612e5ef}\
> W: \\?\Volume{a94520fe-16c6-11e6-80f7-005056b43cf4}\
> S: \\?\Volume{cba78efd-34cd-11e6-80fb-005056b43cf4}\
> U: \\?\Volume{cc4e4794-f6ef-4141-980a-87a984c191b5}\
> M: \\?\Volume{d1ddfc3d-fa04-11e6-8109-005056b43cf4}\
>
> After the machine was back up and running, I started combing the system
> eventlog, and noticed something weird - there were a lot of volume GUIDs that
> didn't match my list above.
>
> I finally exported the system event log as a CSV file (it goes back as far as
> January of 2016), and cut and sorted the output, and found 2891 unique volume
> GUIDs!
>
> That's just insane, and I have no explanation for this.
>
> Does anyone here have a clue to what this is about?
>
> Kurt
>
>
