We need a quick way to quickly populate or empty collections. Targets should be imported as rules without triggering other processes in the background (eval/re-built). The same also applies to removal rules.

Please implement something like an cmdlet “Add-CollectionMemberRules” / “Remove-CollectionMemberRules” with fast adding rules method, without delays, without rebuilding the complete collection sets in the background. The cmdlet should support especially adding rules like "DirectMembers".

Note:
This will help to control and steer application (ramp-up / ramp-down) rollouts, depending on device target lists, created by internal IT or delivered by business partner. The lists could based on different information like department code/name, cost center, contacts etc. Based on such a target lists, the deployment phases are planned and controlled.

Issue: Support for custom table synchronization into Data Warehouse

Currently, although a method exists to extend tables that can be imported into the Data Warehouse, we learnt recently that this is not supported. We feel this represents a gap with the following impacts:
- Not all tables from the SCCM database are currently synced into the DW. Even a common AI table like InstallSoftwareData must be synced via this custom process. This is a table used heavily in AI based software title reporting and therefore a common addition to the DW.
- Custom inventory tables – inventory extension/customization is a common action in many medium-large customer environments, thereby presenting a usability gap with the Data Warehouse
- Long-term Reporting/Warehouse need – customers have been longing for an alternate reporting mechanism in SCCM which other applications can integrate into without impacting Site/Hierarchy operations. Our view is that the DW should facilitate more of these scenarios and not limit them by only allowing a limited subset of data to be imported in.
- Performance impacts to the SCCM DB are avoided if reporting can be shifted to the SCCM Data Warehouse

Our view is that the DW has the potential to solve various reporting challenges with the existing SCCM database and if more investments are made in this role, it will eliminate pain points related to maintenance of custom reporting solutions, promote standardization and eliminate usage of unsupported actions such as database mirroring/log shipping etc.. We would also advocate for a GUI based add-in to allow customers to extend the default tables imported into the SCCM DW.

nable to import status message when following condition.
　・Clients with co-management enabled
　・If the state message(.SMX) contains Japanese

◆Error Log
[statesys.log]
SQL MESSAGE: spProcessStateReport - Error: Message processing encountered a SQL error 241 at record 53 for TopicType 810:
" Conversion failed when converting date and/or time from character string.", Line 0 in procedure ""

◆state message(.SMX)
-<StateMessage SerialNumber="593" MessageTime="20180427063011.557000+000">

          <Topic UserSID="" User="" IDType="0" Type="810" ID="CoManagementState"/>

          <State ID="105" Criticality="0"/>

          -<StateDetails Type="1">

                        -<![CDATA[<ClientCoManagementMessage><MDMEnrollment><Enrolled Value="0" /><ServiceUri Value="" /><RegistrationKind Value="0" />

                        <ScheduledEnrollTime Value="04/27/2018 06:30:11 午前" /><ErrorCode Value="2147549183" />

                        <ErrorDetail Value="MDM enrollment hasn't been configured yet on AAD, or the enrollment url isn't expected." />

                        </MDMEnrollment><CoMgmtPolicy><Enabled Value="1" /><PolicyReceived Value="1" />

                        <WorkloadFlags Value="1" /></CoMgmtPolicy></ClientCoManagementMessage>]]>

          </StateDetails>

          <UserParameters Count="0" Flags="0"/>

</StateMessage>

◆Possible causes
Cannot be imported if it contains two-byte character data

Could you fix this behavior?

Per: https://docs.microsoft.com/en-us/sccm/sum/deploy-use/manage-express-installation-files-for-windows-10-updates

"Using express installation files provides for smaller downloads and faster installation times on clients."

Through a case I opened with Microsoft, it was communicated to me that the current express update design is solely meant to reduce network bandwidth. There is no promise of expedited installation time. This is misleading and limits the purpose of express updates for remote office scenarios.

Additionally the express update deltas have to be decompressed and recombined in order to complete the installation which requires significant CPU usage.

The combination of these issues causes express updates to provide little benefit to customers in it's current state. I propose that express updates be reworked for faster client installation.