Currently volume licensing and most other MS portals don't provide (SHA, MD5 or any) filehashes.
I learned that later this year MS is planning to update the VLSC portal to support this. That's good news.

It would be a bonus to see the hashes on a true public part of the portals or otherwise on www.microsoft.com without any form of subscription.
Reason is that only a limited number of persons have an account that can actually download ISO’s from VLSC. On the other hand, a lot of IT admins cannot download themselves but use these ISO’s and have to rely on the hashes provided by the first group.

Could be done for all types of downloads (.ISO, setup.exe, msi etc).

Hash access without an account would enable everyone to directly verify with the source at MS which enhances integrity and security !

When accessing resources the user Token is presented and granted or denied access based on SIDs presented (Not taking DACL in to account). Tracking stale groups and ACLs is difficult in an environment, especially if there are multiple granting ACLs to a resource.

It would be good if there could be an event or log that would show an audit of not just a principal getting access, but how they got access. E.g. SID of the user is present on the Resource and gained access by proxy of direct permissions... or by proxy of a SID of a group in their tokens that gave them access. It would also be good to seperate out SID History as this could act as a validation of SID history use declining or being used heavily.

This would allow for stale principals to be cleaned up and for a better audit of how access was granted to a resource in a retrospective audit.

If you have several types of clients updated by a wsus server, the software vendor for some of the clints might have found some updates to cause problems for their software so that the specific updates should be possible to decline for specific computer groups while still being available for other groups. I really do not understand why there is no such possibility in wsus.. As it is now, "not approved updates" could mean two things. Either you specifically do not want to install the update or you have just not decided over the update yet, it really should be an easy way to distinguish the two..

"netsh trace" and/or NetEventPacketCapture lacks capable packet filtering. A lot of secure and change managed environments do not [easily] allow the installation of packet capture tools for collecting network data, like Wireshark (or the now defunct netmon and Message Analyzer).

The two built-in packet capture tools in Windows, "netsh trace" and NetEventPacketCapture, can only filter packets by IP address, MAC, and protocol. This makes collecting a targeted trace, sometimes needed when collecting traces on sensitive networks, impossible.

This is a request to add, at a minimum, the ability to filter packets by TCP port and UDP endpoint. Ideally, Windows inbox packet filtering should be on par with the industry standard tcpdump(*nix)/npcap(Wireshark for windows) filter format.

It would be great if students could submit technical support requests for free, and if they are serious enough, get assistance with the issue for free.

Backstory:
Why Give Out Software to Students and Charge Us When We Need Assistance? - I have been using Microsoft products for everything school related, but now I have an issue with my server, you want to charge $500 for assistance with something critical and can't fix ourselves. I think I made a big mistake trying to learn Microsoft for my career, because I wouldn't be having the issue I have now if I chose Linux.

I setup a Server 2019 VM and migrated our old 2008R2 file server, to this server with the Storage migration services through Windows Admin Center.

It seems to work as designed and seems to be a great tool for admins.

However on our current production file server, the migration takes 7 days. Too long to perform it out of hours, and too long to downtime the server. The result is outdated files on the destination side. I haven't found a way with SMS to resolve the issues with latest files being left behind on the source machine.

I'm not sure if this is come up in future updates but it would be great/necessary in fact to re-sync changes after this process, or during cut over (however i suspect the rate of change would make during cut over too lengthy process). Incorporating a simple re-sync changes/update file sync, within, or at the end of the cut over would make this method 100% perfect.