Server2016/ADFS 4.0 - OAuth2 Logout endpoint requires id_token_hint before it redirects a user back to the RP. This is good however the value used for the id_token_hint is original id_token issued at the time of sign in. This is not good for few reasons:

1. In a server-side app, id_token is used at the time of sign-in and claims are issued from the id_token which gets saved to the session cookie. After the sign-in step, there's no use for the original id_token. Now with id_token being required for the Logout request, we have to store the id_token in the session cookie as well making it double in size.

2. With oauth2/logout being a GET per the spec, and id_token_hint having the original id_token, it is getting recorded in browser history and other log files. GET parameters are typically considered non-sensitive and now there's a chance that someone could use it to do bad things.

3. Based on the number of claims being issued by ADFS, the size of the id_token can be large in size to a point that some browsers will not support the length of the request. This will lead to poor user experience and broken logout functionality.

Therefore, I suggest you use a different value - some hash or some other value (much smaller in size) that ADFS can trust and validate when given back in a oauth2/logout request (in id_token_hint parameter).

Then you can provide that value as an attribute in the id_token at the time of singing in. Apps can extract that value and store in the session to be used at the time of logout.

SCCM has been redesigned with Windows 10 and Office 365 Consoles. I don't like being forced to use these consoles! We currently have Windows 7 and Office 2013 installs that we support as well as Windows 10 and Office 365. Until these new consoles were FORCED upon us, Everything on my SCCM server was the same and easy for my people to follow and understand. Now Office 365 and Office 2013 updates are different, windows 7 and windows 10 updates are different. This causes confusion for my people! The Root folder in Software Updates is named "All Software Updates", yet fails miserably at containing all software updates... It's fine if you make these changes if for some reason someone asked for them, but the rest of us DO NOT want to be forced into using them. I am extremely FRUSTRATED that these are not something I can work around or defeat.

Currently, Server-based personal desktop sessions are still underrated. Still it has a lot of potential and a lot of users are looking for a way to implement this, assign users to different Terminal Servers manually istead of letting the load balancer do it for them.
Unfortunately to have this configured we are forced to use PowerShell, which is not handy at all times.

To make this more reliable and easy to manage; add Server-based personal desktops to be configurable within the Server Manager under Remote Desktop Services.

IT-staff will then be able to easily assign groups of users to different terminals.

Also, this advertises for the product. It will be used by IT-staff more often because they now stumble upon it in the New Server Manager.

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)