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!

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.

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

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.

Here's an odd one.

Promote Windows Server 2016 to a domain controller.

Using Group Policy Management, edit the Default Domain Controllers Policy as follows:

Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - Security Options - Network security: Configure encryption types allowed for Kerberos

Choose
AES128HMACSHA1
AES256HMACSHA1
Future encryption types

Restart your domain controller.

Using Group Policy Management, edit the Default Domain Controllers Policy as follows:

Computer Configuration - Policies - Windows Settings - Security Settings

Notice that an IP Security Policy Management error appears.

A directory service error has occurred - (80072095)

Also notice that no "IP Security Policies" can be created, under "Security Settings".

This must be a bug, right?

If you add RC4HMACMD5 as a Kerberos encryption type, the error goes away and everything works.

Using MD5 is not recommended, of course, so bascially you can't define Kerberos encryption types?

Thank you.

function SomeFunction
{

Write-Host "SomeFunction calling SomeOtherFunction"

$ht = SomeOtherFunction

Write-Host "Hash Table Returned"

for ($i=0; $i -lt $ht.length; $i++) {

   $arrayEntry1 = $ht[$i][0]

   $arrayEntry2 = $ht[$i][1]

   Write-Host "($arrayEntry1, $arrayEntry2)"

}


Write-Host "SomeFunction calling SomeOtherOtherFunction"

$ht = SomeOtherOtherFunction

Write-Host "Hash Table Returned"

for ($i=0; $i -lt $ht.length; $i++) {

   $arrayEntry1 = $ht[$i][0]

   $arrayEntry2 = $ht[$i][1]

   Write-Host "($arrayEntry1, $arrayEntry2)"

}

}

function SomeOtherFunction
{

Write-Host "SomeOtherFunction added one entry into the hash table"

$myHashTable = @()

$myHashTable += ,@(1,0.99)


Write-Host "This is what the hash table looks like before being returned."

for ($i=0; $i -lt $myHashTable.length; $i++) {

    $arrayEntry1 = $myHashTable[$i][0]

    $arrayEntry2 = $myHashTable[$i][1]

    Write-Host "($arrayEntry1, $arrayEntry2)"

}

return $myHashTable

}

function SomeOtherOtherFunction
{

Write-Host "SomeOtherOtherFunction added one entry into the hash table"

$myHashTable = @()

$myHashTable += ,@(1,0.99)

$myHashTable += ,@([int32]::MinValue,[int32]::MinValue)


Write-Host "This is what the hash table looks like before being returned this time."

for ($i=0; $i -lt $myHashTable.length; $i++) {

    $arrayEntry1 = $myHashTable[$i][0]

    $arrayEntry2 = $myHashTable[$i][1]

    Write-Host "($arrayEntry1, $arrayEntry2)"

}

return $myHashTable

}

When using the startmenu in fullscreen mode, the start menu won't open anymore after a restart. When you disable and re-enable fullscreen mode, it works once again until the next restart.

It seems to be the ShellExperienceHost:

Name der fehlerhaften Anwendung: ShellExperienceHost.exe, Version: 10.0.14393.447, Zeitstempel: 0x5819bf85
Name des fehlerhaften Moduls: StartUI.dll, Version: 10.0.14393.447, Zeitstempel: 0x5819be04
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00000000000b96b0
ID des fehlerhaften Prozesses: 0xa50
Startzeit der fehlerhaften Anwendung: 0x01d2ecced8231441
Pfad der fehlerhaften Anwendung: C:\Windows\SystemApps\ShellExperienceHostcw5n1h2txyewy\ShellExperienceHost.exe
Pfad des fehlerhaften Moduls: C:\Windows\ShellExperiences\StartUI.dll
Berichtskennung: 563781c7-6fab-49ae-b3de-e0dd30c1c08c
Vollständiger Name des fehlerhaften Pakets: Microsoft.Windows.ShellExperienceHost10.0.14393.447neutralneutral_cw5n1h2txyewy
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: App

It's also possible that this happens only to local admins.

Derived from this thread:
https://social.technet.microsoft.com/Forums/windows/en-US/5703e7b0-433a-4347-a572-a6da7938f35d/startmenu-wont-open-if-fullscreen-is-enabled?forum=ws2016

First of all, sorry my poor English. Recently my customer bought two Windows Server 2016 Standard and I have a general group policy to disable autoplay and autorun in all computers in this network. Of course, I have an Active Directory implemented with two DCs, one with W2K8R2 and another with W2K12R2. I´ve downloaded the new ADMX files for Windows Server 2016 and Windows 10 "www.microsoft.com/en-us/download/details.aspx?id=53430" and created a Central Store and I made all steps recomended by Microsoft. This Group Policy works well in all versions of Windows 2012/8.1 and below, but doesn´t work in Windows version 2016/10. I reaserched in the Internet for a similiar problem and I didn´t find anything about this. Does anybody have a clue for this problem??? Thanks for any help.

Cross-posted from Technet forums:

I think we've identified a bug in Server 2016. Long story short:
1. Open lusrmgr.msc
2. Set an active users' properties to require password change at next logon
3. Reboot (or just logout, haven't tried that)
4. Press Ctrl+Alt+Del to logon, enter user's current password
5. Press Cancel when informed you need to change your password
6. Press Ctrl+Alt+Del again, enter user's current password, proceed 7. with password change (notice username is blank at this point)
8. Password gets changed but you are returned to the change password screen with no way to go back or proceed
9. Forced reboot appears to be the only way out but you can logon normally after this

We discovered this when running through the sysprep process and had bypassed the standard OOBE set password screen. Windows Server still wants the password set at first logon so we end up setting the password in the standard password change method instead of via OOBE. I realized this wasn't just a problem with our OOBE process though because just checking the box in user properties will make it happen. Tested this on the built-in Administrator account and a standard account I created after the fact.

Obviously most people won't hit the cancel button here, but we did it just playing around and discovered this.