Allow for more granular OS selection in Application Requirements
Right now there is no way to distinguish between flavors of Windows 10 when configuring OS-based Application requirements. Please split it up into different OS flavors such as 1507, 1511, 1607, 1703...etc.
along the same lines, we were looking at RSAT also. we got around this by doing a custom condition for the OS build, however custom conditions behave differently to inbuilt conditions.
for example for RSAT 1803
If I say requirement of Windows 10, RSAT does not appear in software center at all on a windows 7 computer ( doesn't exist)
However, if I use a custom Condition directed using WMI at the build number of the OS, the software appears in Software Center on the Windows 7 devices, however when run, it then evaluates that the device doesn't meet the requirements.
same with various builds of Windows 10 - no matter what build the requirement is, the software will appear, but will fail when the user tries to run it with "software isn't applicable" message.
having the builds for W10 as built-in options would simplify the whole process.
Tony Klassen commented
Hope this gets some traction, I recently discovered a very handy use for this logic and was surprised when I couldn't find it anywhere in the console. We updated our techs' workstations to 1803, which I already knew would kill off RSAT. I went to create a new requirement-based Deployment Type for Win10v1803's RSAT, and behold, there found no meaningful way to differentiate any version-specific requirements. Solved the problem by scripting the install, but when we have robust tools like SCCM, it seems pretty heavy handed to force a client to download all the installers, then let a simple script choose which one to actually install.