DNS Flag Day

Starting from today February 1, 2019 (DNS Flag Day), DNS (Domain Name System) providers will stop supporting DNS servers that are non compliant with Extension mechanisms for DNS (EDNS) protocol. In order to be compliant for EDNS, not only DNS servers should support this protocol, but also network devices (firewalls) should be aware for the necessary adjustments to support this protocol as a benefit for all us (internet users). Currently all major "players" are supporting DNS Flag Day.
For more info regarding DNS Flag Day, you can find on https://dnsflagday.net/. There you can also check your domain (hosting DNS zone servers) if EDNS is fully supported.
Microsoft DNS servers are supporting EDNS, but tests will show minor issue on implementation on some extensions of the protocol. Those errors will not affect domain name resolution on February 1, 2019 and later. According from Microsoft, those errors will be fixed in some of the next patch Tuesdays.

More info from Microsoft about this issue on Windows Server Domain Name System (DNS) Flag Day Compliance.
And, also please check if you're having some older network appliance which will prevent EDNS usage on your DNS servers. Please don't disable EDNS as a permanent problem resolution, Some DNS name queries are unsuccessful after you deploy a Windows-based DNS server.

Happy DNS Flag Day !

List MPIO disks active paths

This is a single liner PowerShell for listing active paths on MPIO disk devices:

(gwmi -Namespace root\wmi -Class mpio_disk_info).driveinfo | % {Write-host "Name: $($_.name) Paths: $($_.numberpaths)"}

Tested on Windows Server 2012 R2. This single liner should also work on other Windows Server editions.

And in case if there are multiple servers for checking the active paths on MPIO disk devices, here is the modified single liner (it's presumed that user running the bellow single liner owns the necessary permissions, and there are necessary firewall rules for accessing remote servers):

"server1","server2","server3" | % { write-host $_ -ForegroundColor green  ; (gwmi -ComputerName $_ -Namespace root\wmi -Class mpio_disk_info).driveinfo | % {Write-host "Name: $($_.name) Paths: $($_.numberpaths)"}}

Tested also on Windows Server 2016. 

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.