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.

Today, when you install the CM Console, the PowerShell module will be placed under the %CMInstallDirectory%\AdminConsole\Bin\ConfigurationManager.psd1

This makes sense given where the user is choosing to install the console, and that's fine. But placing it here off the beaten path means that it is not importable using PowerShell's module autodiscovery features. For instance, if a module is found in any of the standard user or system paths (or registered under the $ENV:PsModulePath) the user can easily import the module without having to specify the full path, a big user quality of life win. This is the way that SQL Server handles their modules, and they are the golden child, beloved by all PowerShell nerdoes like me.

So, my suggestion is to continue placing it where it is today, and also register the path using the standard mechanism, excerpted below.

[Environment]::SetEnvironmentVariable("PSModulePath",$p)

https://msdn.microsoft.com/en-us/library/dd878350(v=vs.85).aspx

There is the great functionality of tagging "new" software in the software center and showing this software right at the top of all apps. Today this tag is dependent on the date the deployment has been created and or set to be available for 7 days as a global setting. It would be great to show this tag from a users perspective. This would also align to the often used concept of having a collection with the software deployed and the members get added on demand. So if a customer is ordering a software it is shown on his client to be new for 7 days from the time of arrival.

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.

With the release of CB 1806 we are now able to publish third party updates using custom catalogs. Ideally, third party patches would function exactly like first party patches from an administration and automation perspective. Currently there's two main areas where this is not the case.

Synchronization Schedule:
I could be wrong on this but I believe that subscribed catalogs sync automatically every 24-hours. While that's nice, it would be great to simply integrate with the existing sync schedule. Sync the catalogs, publish relevant metadata to WSUS, then sync the SUP(s).

Automatic Deployment Rules:
Currently, only update metadata is published by the automated sync process. In order to actually deploy an update you must manually right click on it and select 'Publish Third-Party Software Update Content'. That a big cold automation wet blanket. A few ideas, in increasing order of greatness:
-Publish the full content of a given catalog. Not ideal, but it solves the automation problem.
-Publish full content for only the product selected to sync in ConfigMgr. Much better than everything, solves automation, but still will include updates you don't want.
-Publish full content when selected by an ADR. A bit tricky since you'd need to publish the content, resync, and then deploy but your the best team ever so I know you have it in you.

Bryan

This would allow a Secondary Site to operate disconnected from the hierarchy for a set amount of time. During this disconnected state the Primary above it would not try to reach out to the Secondary (and vice versa) but would wait (similar to a prestage DP) for the interval specified before trying. Also the Secondary while disconnected would process its client information similar to a Primary and optimize the replication data so that when the connection was re-established there wouldn't be a huge backlog. This would allow hierarchies with devices that have limited or no connectivity for extended periods at a time to be efficiently managed.

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!

The recent Servicing Stack Update released out of band in May was made a requirement for the June cumulative updates but itself did not require a reboot. This created a conundrum for organizations patching devices with maintenance windows. Because of the lack of reboot on the servicing stack update there was no option to run a full evaluation that would detect that the cumulative update was now applicable and install it within the same maintenance window.

A few ways to solve that problem but the one that strikes me as straight forward is to modify, extend, or duplicate the "if any update in this deployment requires a system restart, run updates deployment evaluation cycle after restart" feature introduced in CB 1606 to allow it to run a full evaluation after all of the updates have installed, regardless of the reboot condition. Where maintenance windows allow this would enable the user to install updates that are newly available regardless of reboot.

Bonus Points: Support an option that does so even if the updates fail. So many times simply retrying an install solves the problem.

Issue: Scanning for EXE files during software inventory keeps getting killed by ModernSleep behavior on "tablet style" devices across our enterprise.

On a users machine you can see after his machine is locked a “CSEvent Enter Event” is recorded. Within seconds the Inventory process detects the event and is shutting down. This process repeats several times daily and the scan never gets completed.

One article I read talks about disabling ModernSleep on Dell computers has already caused issues for them. Contacting Lenovo they say that disabling this is not recommended as it may impact the ability to talk to drivers for their hardware.

Lenovo pointed to this as an OS setting. I believe this is correctly an OS/SCCM related issue. Is there a way to get the Software Inventory to pause instead of terminating so the scan could continue when the system state resumes?

I think the value of ModernSleep is present so I cannot see disabling it as most customers appreciate the time it takes to resume their system. But from an enterprise management perspective there has to be a better way!

Thanks,
Brian