Different Disk Size Information

This case might be a good question for some windows os certification exam. The scenario is that disk size shown in disk management console or diskpart for the affect disk drive was 120 GB, but from windows explorer disk size for H: drive was 105 GB. Here are the captured screenshots:

Disk management console

Windows Explorer

And, finally the reason for this behavior is simple hard quota template assigned for this drive, and here is the screenshot for the quota assignement:

Quota

I hope this post will help getting the answer for the question "How it is possible same disk drive to be presented differently in different parts of the operating system?".

The User Profile Service Failed The Logon

In this case, there was a Windows 8.1 workstation with corrupted Default profile. All domain users with or without previously created profile on that machine were unable to logon with following error message:

"The User Profile Service failed the logon. User profile cannot be loaded."

I've logged on to the workstation with local admin account, and opened the Application Event Log, a warning event with id 1509 was logged, from source Microsoft-Windows-User Profiles General with following description:

Windows cannot copy file \\?\C:\Users\Default\AppData\Local\Microsoft\Windows\WER to location \\?\C:\Users\TEMP\AppData\Local\Microsoft\Windows\WER. This error may be caused by network problems or insufficient security rights.

In order to resolve the issue, I've forced permission propagation to all child objects on C:\users\Default:

After successful permission replacement on all child object of C:\Users\Default, domain users were able to successfully log on to the workstation, again.

KB3161608 & KB3161606 replaced by KB3172605 & KB3172614

KB3172605 (Windows 7 and Windows Server 2008 R2 Sp1) and KB3172614 (Windows 8.1 and Windows Server 2012 R2) are July 2016 update rollups, and are replacing the update rollups from June 2016 (KB3161608 and KB3161606). July 2016 update rollups are fixing the issues that were caused by the June 2016 update rollups (for example: Hyper V and Integration Services issues).
All other updates introduced in June 2016 update rollups are present also into July 2016 update rollups.
So, introduction of new cipher suites to Internet Explorer and Microsoft Egde in Windows introduced in June 2016 update rollups, might break access to some old https enable sites.
This issue can be resolved by uninstalling these update rollups, or in my case adding the following registry key on affected machines (lowering the DHE key length on clients to 512bits, instead using the default 1024bits):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
"ClientMinKeyBitLength"=dword:00000200

After adding the registry key (restart is not necessary), https "oldies" started to open with Internet Explorer.

Happy Patching :)

Source Path Too Long and Volume Shadow Copies

In this case a Windows Server 2008 R2 file server was hosting company's file shares. This Windows File Server was having several disk volumes with file shares and scheduled volume shadow copies. Users with necessary access permissions to file shares were able to restore previous version of files and folders. In this case a user was complaining that he was unable to restore the previous version of file, because Windows Explorer was preventing to do so, with following error message:

The source file names(s) are larger than is supported by the file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation...

The solution provided in the error message "Try moving to a location ..." is not applicable because shadow copies are read only. In order to restore this file from volume shadow copy, I have exposed the volume shadow copy as a directory symbolic link.
Finding the necessary volume shadow copy can be achieved using vssadmin or diskshadow. Because the Windows File Server was having several disk volumes, I wanted to list the shadow copies of the affected volume only. This can be done using vssadmin:

vssadmin list shadows /for=driveletter:

From the output of the command, I've found the needed volume shadow copy (for example: Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1007) . Next, I've created directory symbolic link using mklink :

mklink /D "c:\temp\vss" \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1007\

Now browsing the into c:\temp\vss, I was able to access the "problematic file" from the volume shadow copy and recover the requested version of the file. At the end, I've deleted the created directory symbolic link.

How to find matching mount points and volume guids ?

In this case I was experiencing VSS error events in application event log on one of the file servers. The related logged events were containing error information with associated Volume GUID instead of mount point (drive letter). Here is the example of the error event:

Volume Shadow Copy Service error: The shadow copy could not be committed - operation timed out. Error context: DeviceIoControl(\\?\Volume{GUID}

Since this error event was generated on file server with bunch of disk drives, I was wondering which mount point (drive letter) was associated with this Volume Guid.
One way to achieve this task was to run mountvol.exe without any switches. The output from this command looks like this:

Also, from Run dialog:

I could browse the contents of the drive, and figure out the drive letter.
Browsing the contents using Volume Guids from command prompt using dir requires additional backslash "\" at the end:

Another way is by comparing values in Registry in HKLM\System\MountedDevices for DosDevices and Volume Guids (picture contents are cropped):



At last, and I guess the best option is to use PowerShell and wmi. Win32_Volume class (not applicable for XP) will provide the necessary data by using DriveLetter an DeviceID properties. All filtering capabilities for filtering data using powershell are available, including querying the remote machines. For example, the following singleliner will return VolumeGuids and DriveLetters associated:

I guess all these methods will help you to find the matching pair :) If you have another way for matching volume guids and mount points, feel free to comment.