Following this discussion:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/c5f2786c-ffac-4f14-b7a9-00612cdf784e/server-2016-vm-hangs-shutting-downrestarting-when-the-pagefile-is-on-a-different-vhdx?forum=winserverhyperv

The core problem is the following, for example (simple config), for Exchange or SQL servers in a HYPER-V VM under Windows 2016:

systemdrive for windows system (and sql, exchange core),
datadrive for mbx data or sql-databases
datadrive for log file
drive for pagefile

We create for all this drive a separat VHDX file and add this to the VM as SCSI drive.

The drive for pagefile (fast SSD, NVMe or other) is exclusiv for the pagefile reserved. No other data on it. The drive for pagefile is the only drive with a pagefile for this vm. No second pagefile on the systemdrive or elsewhere.
In this case a running VM can't restart or shutdown.
When you do this, the VM hangs. This did not happen with earlier versions of Windows.
It is not recommended (MS Exchange or SQL recommendations) to set up two Pagefiles (split pagefiles), as this greatly reduces performance.

So we must disable the debug funktion completely in the Windows VM - that works. But not a good way.

Please rerelease the functionality as in previous windows versions!

If a Powershell script creates a DFSR RG and invokes the CmdLet "Set-DfsrMembership" multiple times to add several member servers then there is a high probability that the CmdLet will fail.
I have a PowerShell script than creates a new DFSR RG, adds the local server and a folder, then calls the above CmdLet.
if the script is run in a loop (deleting the RG between iterations) then the script will fail after 2 - 5 loops.

I've used .NET Reflector to debug the DfsrPowershell, DfsObjectModel and DfsrHelper DLL's and I found that the error is as follows:
Set-DfsrManagement attempts to modify the Replication Group object under the target computer in Active Directory. It first attempts to perform the operation using the currently logged on user's credential and when that fails it retries using using the target computer account. This normally succeeds however, when it does fail the LDAP response is invalidAttributeSyntax
Examining the modifyRequest command I see one of the attributes is:
modification item operation: delete (1)
modification msDFSR-DfsLinkTarget
type: msDFSR-DfsLinkTarget
vals: 1 item
AttributeValue:
And the AttributeValue is empty - which is invalid!
Now the modifyRequest that was sent using the logged on user's credentials is correct:
modification msDFSR-DfsLinkTarget
type: msDFSR-DfsLinkTarget
vals: 0 items
The difference is the first modifyCommand is built and sent by the DfsObjectModel DLL while the failing command is sent by the DfsHelper DLL which is native code and described in the MS-DSFRH document.
I have debugged the code as far as the interface into DfsrHelper and confirmed that the attributes passed into the DLL are correct i.e. the msDFSR-DfsLinkTarget attribute operation is "delete" and there are no values set. Therefore I am of the opinion that there is a defect in the DfsrHelper DLL implementation that incorrectly appends an empty value when constructing the LDAP command.
I opened a MSDN case with the breakfix group who confirmed it was a bug but were unable (due to internal policy??) to submit their findings to the DFSR dev team.

In a certain powershell script i'm working on i get the following error when i try and debug:

E:\logs\Invoke-IISGraphInteractive_V1_4.ps1 :
Exception : System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: length
at Microsoft.VisualStudio.Text.Span..ctor(Int32 start, Int32 length)
at Microsoft.PowerShell.Host.ISE.ISEEditor.MarkPosition(Int32 lineNumber, Int32 startPosition, Int32
endPosition, String marking)
at Microsoft.PowerShell.Host.ISE.ISEFile.SetDebuggerCurrentPosition(Int32 lineNumber, Int32
startColumn, Int32 endColumn)
at Microsoft.PowerShell.Host.ISE.PowerShellTab.DoEnterDebugger()
at Microsoft.PowerShell.Host.ISE.PowerShellTab.DoEnterNestedPrompt(Object context)
at
Microsoft.Windows.PowerShell.Gui.Internal.WPFHelper.<>c__DisplayClass9.<SendToUIThread>b__8(Object obj)
TargetObject :
CategoryInfo : OperationStopped: (:) [Write-IISResponseCharts], ArgumentOutOfRangeException
FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Write-IISResponseCharts

here is the code block:

$DataToUse = $data.data |Where {$_['time']}| where $CoreFilterSB | where $FilterSB
$TransformedData = $DataToUse |
select @{n='Series';e={Invoke-Command $seriesSB -ArgumentList $_}},
@{n='Time-taken';e={
[int]$TimeSec = [Math]::Round(([double]($_['time-taken'])/1000.),0)
if ($HistogramLogScale)
{
if ($TimeSec -eq 0)
{
0
}
else
{
#round down the call time as a log base 2, then re-raise so get original scale but bucket by powers of 2
#e.g. 0.5,3,5,6,8 --> 1,4,8
([math]::Pow(2,[math]::Floor([math]::Log($TimeSec,2))))
}
} else {
$TimeSec
}
}}
$DataArray = $TransformedData |
Group-Object Series,Time-Taken |
select @{n='Series';e={$_.Group.Series | select -first 1}},
@{n='time-taken';e={$_.Group.'time-taken' | select -first 1}},
@{n='Count';e={$_.Group.Count}} | Sort Series,'time-taken'

it crashes when i put the break point on $TransformedData = ... line

Name Value
---- -----
PSVersion 4.0
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.42000
BuildVersion 6.3.9600.18773
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2

Hello, after applying the below listed patches this past Sunday on Windows Server 2016 dedicated to File / Print services, searching for files on Windows Server 2016 results in the search that appears to be searching but unable to display properly.

If possible I'll send a picture comparing Windows Explorer search results from both Win10 & Win7 (both systems are up to date with latest patches, though the same view from Win 10 happens on Win 2016), a description of what I'm seeing can be described as follows:

Win 10 / 2016; you see the file name only, the rest of the search area is blank (normally it shows content and meta-data) and unlike before, right click doesn't bring up any menu options (such as opening the folder the file is saved in);
Win 7; you see blank lines, as if the fonts were white on white background, so it appears to bringing up similar results as the Win 10, but you only see the light grey line separating each search result;
Running the same search from both client machines on a Windows 2008 older file server (is also up to date on patches) shows the expected results (File name, content below file name, Meta data on the right), which is what I was seeing last week on the Win 2016 server / before applying the patches.
Look forward to feedback and confirmation if there's something else that needs to be enabled on the 2016 file print server.

Thank you,

Updates Applied on Sunday, March 4th:

Update for Windows Defender antimalware platform - KB4052623 (Version 4.12.17007.18022)
2018-02 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4074590).
Windows Malicious Software Removal Tool x64 - February 2018 (KB890830)

If have some issues with Dism after a new Installation with Windows 10 1709 and Upgrade from Windows 1703 to 1709.

Get-WindowsCapability : Error "Get-WindowsCapability". Errorcode: 0x800f0954
Line:1 Zeichen:1
+ Get-WindowsCapability -online
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-WindowsCapability], COMException
+ FullyQualifiedErrorId : Microsoft.Dism.Commands.GetWindowsCapabilityCommand

Some Lines from Dism Logfile:

DISM OS Provider: PID=7180 TID=6088 Unable to set the DLL search path to the servicing stack folder. C:\Windows may not point to a valid Windows folder. - CDISMOSServiceManager::Final_OnConnect

DISM Provider Store: PID=7180 TID=6088 Failed to load the provider: C:\Users\ADMIN~1.TES\AppData\Local\Temp\38977CD8-C67C-463B-8721-E72E5E46A990\PEProvider.dll. - CDISMProviderStore::Internal_GetProvider(hr:0x8007007e)

DISM Provider Store: PID=7180 TID=6088 Failed to get and initialize the PE Provider. Continuing by assuming that it is not a WinPE image. - CDISMProviderStore::Final_OnConnect

2017-10-19 17:39:03, Error DISM DISM Package Manager: PID=7180 TID=6088 Failed enumerating capabilities - CDISMPackageManager::GetCapabilityCollection(hr:0x800f0954)
2017-10-19 17:39:03, Error DISM DISM Package Manager: PID=7180 TID=6088 Failed to get capability collection. - CPackageManagerCLIHandler::ProcessCmdLine_GetCapabilities(hr:0x800f0954)
2017-10-19 17:39:03, Error DISM DISM Package Manager: PID=7180 TID=6088 Failed while processing command get-capabilities. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x800f0954)
2017-10-19 17:39:03, Info DISM DISM Package Manager: PID=7180 TID=6088 Further logs for online package and feature related operations can be found at %WINDIR%\logs\CBS\cbs.log - CPackageManagerCLIHandler::ExecuteCmdLine
2017-10-19 17:39:03, Error DISM DISM.EXE: DISM Package Manager processed the command line but failed. HRESULT=800F0954

Thanks

Whilst working through some of the DNS records for our network, we noticed we were seeing some records from 2015. We tried to sort the 'Date' column in ascending/descending order and found that the fields were not formatted as 'Date/Time' but rather as a text format as the timestamps were sorted in ascending order of the first 2 numbers of the date.
As an example:
Timestamp 1: 05/04/2015
Timestamp 2: 01/02/2017
Timestamp 3: 15/03/2016
Timestamp 4: 19/06/2015

When sorted in ascending order by timestamp, the DNS records SHOULD be organised in the following format:
1: 05/04/2015
2: 19/06/2015
3: 15/03/2016
4: 01/02/2017

However, they are sorted thus:
1: 01/02/2017
2: 05/04/2015
3: 05/03/2016
4: 19/06/2015

We took a look at one of our 2008 servers and found this was the case there also.

I have been redirected here by recommendation of MSFT CSG in response to post on the Windows Server forum here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/4d27b27b-5354-413f-8eeb-48ae9fb1e795/ntfs-rights-unc-vs-mapped-explorer-vs-command-prompt?forum=winserverfiles. Apparently, my question has exceeded the limits of "how do I do this?" and entered the realm of "why does Windows behave inconsistently?", which I call a bug.

Scope
The behavior below is the same for at least Server 2008 R2 & 2012 R2, both with Windows 7 workstation. I have not tested elsewhere.

Scenario
User has only traverse & permissions NTFS rights at root of share but full share-level permissions. User has full access to a subfolder of that folder. I set traverse-only at the parent level because:
1. I do not want users to be able to browse to the parent folder, even if they know the share name. Instead, I provide explicit shortcuts to applications in downline folders where users have read/write access.
2. There there is no need to disable inheritance for downline folders. I can make all rights additive at those lower levels. Since the only NTFS rights to the parent folder (which will be the root of a share) are traverse/permissions rights, and these will be required by anyone also need read/write to downline folders. I can just add read or read/write NTFS rights to downline folders by group.

Symptoms
The user can edit/copy/create/delete files from that full-rights subfolder when accessing it via its UNC path; however, when mapping a drive to the parent folder where the user's rights are traverse/permissions only, the user can still edit files in that subfolder but not create, copy from/to or delete from the subfolder via Windows Explorer; the user gets a "[DriveLetter] invalid/inaccessible" message. However, the user can create and delete files from the subfolder via command prompt, so we know the issue is not NTFS rights, but apparently the fact that Windows denies rights to create/delete/move files to/from the subfolder based on the rights at the parent level.

Here is how to duplicate

Setup
1. Create folder "Test" on any domain-member server.
2. Ensure "Everyone" group has either no rights, or at least only these rights, to "Test" folder: Traverse folder / execute file, Read attributes, Read extended attributes, and Read permissions
3. Assign Authenticated Users these rights to the "Test" folder: Traverse folder / execute file, Read attributes, Read extended attributes, and Read permissions
4. Create a subfolder like this: "Test\SubTest"
5. Assign Authenticated Users full rights to the "SubTest" folder only (not the "Test" parent)
6. Share "Test" folder as "TestShare" (the name is not important; I use TestShare here only to differentiate it from the actual folder name "Test")
7. Give Everyone share permissions Change and Read.
8. From a workstation, log on as a member of Domain Users that is NOT in Domain Admins or any other group having elevated rights to the Test folder (or downline) on the server housing the TestShare.
Test
1. Open Windows Explorer and paste this into address bar, using your own server name: \\[ServerName]\TestShare\SubTest. (Can also just do Window-R and paste that UNC path into run window, then press Enter).
2. This should open [ServerName]\TestShare\SubTest.
3. Copy a text file from the workstation (Copy/Paste or drag-and drop) to that folder. This should succeed.
4. Now map any drive letter to \\[ServerName]\TestShare, either by net use or right-click Computer/Network & Map Network Drive.
5. After the map completes, it will (correctly) generate an error indicating the driver letter is invalid. This is only because, once the drive is mapped, Windows Explorer then attempts to display the root, but the user has only the traverse-related rights above to the root. So ignore this error.
6. Instead, open Windows Explorer and paste this into address bar, using the driver letter just assigned: \\[DriveLetter]\SubTest.
7. This should open \\[DriveLetter]\SubTest, where you should see the first file you copied there previously.
8. Now try copying another file from the local computer to that subfolder. It should fail saying that [DriverLetter is invalid].
9. However, open the text file previously copied, make a change and save it, then re-open. You can see that you can change the file.
10.Open command prompt. Change to [DriveLetter], then dir to \SubTest. Enter dir > dri.txt. The text file is correctly created. Then del dir.txt. The text file is deleted. So the user retains full NTFS rights to the subfolder; it is only in the Windows Explorer environment that the user cannot copy to the subfolder when the parent is a drive letter instead of UNC path.

Further test
But now do this: map any drive letter to \\[ServerName]\TestShare\SubTest, either by net use or right-click Computer/Network & Map Network Drive. This should succeed. You can now copy files to/from the same folder via mapped drive--as long as the root of the mapped drive is an upline folder having at least List Folder Contents.

Conclusion:
1. You can copy to (or create in or delete from) the subfolder when accessing it via its UNC path, even when the user is invoking traverse-only rights at some higher level to get to the folder
2. This also works if you map the drive directly to the subfolder having full rights, even though this also invokes traverse-only rights to get to the folder.
3. This does not work if the mapped drive letter points to the traverse-only folder itself, even though all the same NTFS rights exist identically throughout all three scenarios and even though the user can open and edit files inside the subfolder when mapped this way.
Change required
Do not limit create/delete/move access within Windows Explorer by parent folder rights when user has additive rights to the subfolder.