For most companies, Configuration Manager is becoming a mission critical service the requires less and less downtime. Upgrading large environments/DBs can take up to 5 hours for the CAS, and 4-5 hours for primary sites. Also, most customers want to get the latest hotfixes installed right after performing an upgrade. In some cases, the hotfixes take just a long to complete as the original upgrade. Overall, this can require long outages (sometimes 2 days) to get current.

Potential Solutions:

1. The ability to upgrade directly to the latest hotfix as noted here:
https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/33166225-upgrade-sccm-directly-to-rollup-version

2. Reduce the time needed to regenerate DRS sprocs and reporting views. These two steps seem to take about 80% of the overall upgrade time.

In the interest in making my OS deployment task sequences as fast and as optimized as possible, I always optimize WIM files anytime they're updated or re-created.

In my build/capture task sequence, I add a step at the very end before capture to run DISM /StartComponentCleanup /ResetBase so that all of the superseded updates are removed from the base image before it is captured. This results in a smaller WIM file and obviously, faster deployment times.

With the built-in Offline Servicing option for OS images, once new updates are added, they remain in the component store of the image when the image is unmounted, and also, all of the deleted/superseded files still remain inside the [DELETED] folder in the root of the WIM database because the image is not exported once it is updated by Configuration Manager so the WIM file continues to grow larger and larger every time it is updated using Offline Servicing.

Presently, I have a script I've created, 'Optimize-WIMFile.ps1', that I run against the WIM file source after it is updated via Offline Servicing that does the following:
- Mounts the specified OS WIM
- Runs 'DISM /Image:Mount /StartComponentCleanup /ResetBase' if
the image supports it (i.e. OS version greater than Windows 7)
- Unmounts the WIM
- Exports the WIM file to remove all deleted or replaced data using
DISM module's Export-WindowsImage

Since Offline Servicing is already mounting the WIM for you on the server when updating it, there should be an option (a simple checkbox would suffice) to "Remove superseded updates" after the image is updated that essentially runs DISM /ResetBase against the WIM while it is still mounted before unmounting it.

After the WIM is updated and unmounted, it should then be exported to clean up the removed data - I'm not sure why this is not already a default. The WIM file will only grow in size with all of the old deleted junk every time you update it if it is not exported. You could even make an option for this as well with a drop-down menu that lets you choose the compression level on the WIM when exporting to the final image.

I've tried to automate this process completely by making a script that triggers the OfflineServicing schedule on all of my OS images in Configuration Manager and then calls my Optimize-WIMFile script, but the problem is that I can't find any way to track status of the offline servicing on each image to know when it's safe to begin optimizing the WIM, as Get-CMOperatingSystemImageUpdateSchedule is not returning anything when the schedule is created to run immediately so I have to wait for all of the servicing to complete, and then manually run the optimizations.

This would make sooo much more sense to have built-in to the OfflineServicing since it's literally two simple commands run against the WIM. Please take it into consideration!

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 Install_Software_Data 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.