SCCM 1906 introduced scopes on folders which would be fine for a new SCCM install but not for an existing SCCM infrastructure that relies heavily on RBAC. Users don't understand why they can't find folders others have created in 1906.

During upgrade from 1902 – 1902 SCCM automatically “fixes” all your folders so they behave just like they did with 1902. It does this be setting them with every security scope allowing users to still see these folders in 1906.

Once 1906 is installed any new folder is created with the scope of the user creating it.

Example:

SCCM 1902 - Geneva user with Geneva scope creates a folder in 1902 anyone could see the folder.

SCCM 1906 - Geneva user with Geneva scope creates a folder only users with Geneva scope will be able to see the folder and no other users causing mass confusion in the console.

If RBAC on folders was available when SCCM 1st came out years ago we could have designed RBAC accordingly.

MS can’t just introduce this mandatory “feature” on an SCCM environment that has been up for years without breaking/redesigning RBAC.

RBAC on folders should be something that can be turned off during the upgrade to keep 1902 folder behavior.

Microsoft Premier Field Engineering has created custom Configmgr dashboards. These are available for purchase though Premier Support Contract. I'd like to suggest these be included in the Configmgr distribution.

Overview
The CMAD solution (Configuration Manager Advanced Dashboards) delivers a data-driven reporting overview of the System Center Configuration Manager environment.
This solution consists of a rich set of dashboards designed to deliver real-time reporting of ongoing activity in your Configuration Manager environment.
Native Configuration Manager Reports are not replaced with this solution, the CMAD solution amplifies the data they show by providing additional data insights.
The dashboards in this solution were created based on field experience and on customers’ needs to provide an overall view of various Configuration Manager functionality. The embedded charts and graphics provide details across the entire infrastructure.
Key Features and Benefits
The CMAD solution consist of 130+ dashboards covering the following Configuration Manager topics:
•Asset Inventory
•Software Update Management
•Application Deployment
•Compliance Settings
•Infrastructure Monitoring:
•Site Replica
•Content replication
•Software Distribution
•Clients Health
•Servers Health
•SCEP
Technical Highlights
The CMAD is supported on Configuration Manager 2012 and later releases (including Current Branch versions).
The CMAD is supported on Reporting Services 2008 R2 and later releases.
The solution does not requires extra workloads:
•It is deployed on the existing Configuration Manager Reporting Services infrastructure
•The solution provides a tool to easily deploy all of the dashboards
•The tool can also backup all the deployed reports
The reports are provided as part of the solution delivery, but no support for failures of any of the reports will be provided after the delivery.

In VPN scenarios the DNS resolution is missing or delayed very often. To troubleshoot a device the current device IP-address is important.
You can force a DDR /heartbeat from the console, but this take a while until the information is arrived and actually it is unnecessary because the IP-address Information is already existing in the SCCM database from the NotificationAgent update cycle.
(SELECT vGSNETWORKADAPTERCONFIGURATION.ResourceID, vGSNETWORKADAPTERCONFIGURATION.IPAddress0, vSMSRSYSTEM.NetbiosName0
FROM vGSNETWORKADAPTERCONFIGURATION
inner join vSMSRSYSTEM on vGSNETWORKADAPTERCONFIGURATION.ResourceID = vSMSRSYSTEM.ItemKey
where vSMSRSYSTEM.NetbiosName0 = 'DEVICENAME')

It would be nice to get the Information directly in the console. And it would be nice as well, when the Client-Agent-Push use the IP-address info as fallback, too.

The device categorisation feature as introduced in v1606 in principle is a great idea only it has a couple of major flaws in implementation that make it in practical terms largely unusable in a production environment:

1. As it currently stands, it seems that there is no way to get devices to automatically choose a category without offering the choice to the user at enrolment time. Which is kind of what we would want for most people much of the time. Sure you want to have the choice for some users but also for ease and simplicity of use in enrolment you sometimes want to define a user such that all their devices end up with a particular category and without the option to pick the wrong category. You only really want the enrolment choice for people you define as special cases where they could have multiple category types on offer.
2. As far as I can see (and it is hard to be sure without actually doing it in production), the moment you create any category at all, even for testing purposes and even if it is not used to populate a collection yet, any user from then on is going to be offered at the point of enrolment the screen where they have to choose between whatever categories you have created, regardless of whether they are only for testing, in development or ready for production use. So it would be hard to develop this without it being quite visible for anyone enrolling devices and potentially confusing them into picking categories that are not ready for production use yet or are simply not appropriate for them. you really need the option to hide certain categories from certain types of users which you could define by say user based collection memberships.

Sure you can have a test CM2012 environment, however that often is of limited us unless you also have test AD and then have both kept in close production lockstep with your production environment. You would also need an additional Intune subscription just for testing and that simply is going to be a hard business case to make in a lot of organisations.