Most of the support desk do not have the needed knowledge to go to all the logs on a client and check why an application is not installed or do not appears in Catalog.
Is it a policy issue , a Global conditions issue , does a requirement is not met , is a dependencies not installed ?
Add to this one time to go to log you need ScopeId or CI , or Policy ID , all this make difficult the job for a SD Level 1 or 2
Results it come too often to Level 3 and Admin level and cost money for nothing

Starting with ConfigMgr 2010 the functions of the CEviewer are being moved into the console. One thing that the old tool was useful for was quickly showing how many incremental collections were in in an environment and what their total runtime was. Since there are performance limits to incremental evaluation it would be helpful to show inexperienced admins that they might be running into trouble by having too many or poorly performing collections set this way. I suggest that functionality be added either to the user/device collections view to show if incremental is set or not for a collection and that a I notification be shown in Insights if there are issues found (too many incremental or processing time too long).

The sccm client startup process is very heavy. On our machines we have a very demanding security baseline which gives us a huge windows security eventlog. Reading out this eventlog alone takes over 30 seconds at 25% CPU which makes the startup process of the computers even slower than it is. As we understand it SCCM reads pretty much the entire security log every time the service is started. Even if it's started twice in 30 minutes for whatever reason. We aren't sure what the point is of reading out 100MB of security logs, but it seems a waste. We'd like to see the startup routine be lighter, tweakable or maybe that it would just read out the delta with the previous time it read out those logs?

It would be very helpful if the Properties window of a device included all of the information in the Resource Explorer.

Motivation:
1. I almost never open the Properties view because it rarely contains the information I'm looking for. The Resource Explorer, on the other hand, has almost everything.
2. Having the Resource Explorer buried under a sub-menu makes it difficult to train and convince technicians to use it in their day-to-day workflow to find information and solve problems.
3. Since Resource Explorer is far more useful than Properties, it should be the easier of the two things to get to. Currently, Properties is a simple double-click while Resource Explorer is a right click, two mouse movements and one or two single clicks.

Implementation Ideas:
1. It could be a tab contained within Properties (while retaining a full version of Resource Explorer for when you need a larger window), or it could be a complete rework of the Properties GUI.
2. All information currently accessible still needs to be accessible.
3. Combined window still needs to be resizable like the Resource Explorer window.
4. Double-click on the device should open the combined window.
5. Lazy loading of data may be helpful if opening the embedded resource explorer hurts the responsiveness of the Properties window.

Alternative Suggestion: As an alternative, I'd be OK with having a console option that replaces Properties with the existing Resource Explorer as the double-click target. This may be more polarizing among the user base though as some users may prefer the quick access of the Properties window as the default target. If this alternative were implemented, it should allow the user to choose which view is their default.

We get about 1000 deltamismatch BADMIFs generated each day.

Here is the case of sccm client Inventoryagent.log says successfully sent but the ccmessaging.log shows the upload failed.
Why can’t the client inventory agent act on the status back from ccmmessaginglog and if the upload of the inventory fails, don’t increment the delta number.
This would greatly reduce the number of deltamismatch files generated each day and improvement keeping the inventory up to date without having to force a full inventory sync for this case.

Here are the details:

Dataldr.log for computer: CHOSIJ1-L2

Thread: 6108 will use GUID GUID:c28fa179-d722-4692-be69-a71f5a81e75c SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Processing Inventory for Machine: CHOSIJ1-L2 Version 2.7 Generated: 06/23/2020 14:04:44 SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Begin transaction: Machine=CHOSIJ1-L2(GUID:c28fa179-d722-4692-be69-a71f5a81e75c) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
WARNING - Attempting to resync due to missed delta reports (sp return code = 7) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
Rollback transaction: Machine=CHOSIJ1-L2(GUID:c28fa179-d722-4692-be69-a71f5a81e75c) SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)
SQL MESSAGE: dbo.spAddInventoryLog - Inventory Log for machine:CHOSIJ1-L2,Server:2.5,Client:2.7,Message:Missing Delta. Resync,Detail: SMSINVENTORYDATALOADER 6/23/2020 4:06:34 PM 6108 (0x17DC)

Shows processing 2.7 but database is 2.5 – force a re-sync

Client tried to send delta 2.6 at 6/22/ 10:55am – but the network was not working client probably dropped vpn or connected vpn

Client Inventory Agent.log at 6/22 @ 7:41am starts processing delta 2.6
Inventory: Action=Hardware, ReportType=Delta, MajorVersion=2, MinorVersion=6
Reports successfully sent at 10:55am
Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: {1090DA21-86C6-44C8-9C38-260F7824060E}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted

CCMMessaging.log @ 10:55AM shows it failed:
[CCMHTTP] ERROR: URL=https://MSPM1BADP20.ent.core.medtronic.com/ccmsystem/request, Port=443, Options=448, Code=12007, Text=ERRORWINHTTPNAMENOT_RESOLVED

In summary if the InventoryAgent.log could detect that the Inventory was not successfully sent then don’t increment delta to 2.6 leave at 2.5

Thanks

We have a lot of different kinds of Dell client computers and some of the model names are very alike.

We also have a network which doesn’t allow us to use peer-to-peer techniques to lower bandwidth usage so we need to create rings and make a couple of computers at the time pre-download osupgrade packages and drivers before deploying an IPU to the mass.

Two of the models we have are "Latitude 7390" and "Latitude 7390 2-in-1".
(This is not the only combo of models that suffers from this behavior)
We've created one driver package for each of them.
But the "Latitude 7390 2-in-1" will always download them both due to what is stated here:
https://docs.microsoft.com/en-us/mem/configmgr/osd/deploy-use/configure-precache-content

"The actual query uses a LIKE statement with wildcards: select * from win32_computersystemproduct where name like "%yourstring%". For example, if you specify Surface as the model, the query matches all models that include that string."

"Latitude 7390 2-in-1" LIKE "%Latitude 7390%" will always be evaluated as true so a "Latitude 7390 2-in-1" will not only download the correct driver package, but the package for the "Latitude 7390" as well.

This is the direct opposite of what we're trying to accomplish, saving bandwidth.

Suggestion:
Add an "Exact match of model name"-kind of checkbox to driver packages and make the query model="yourstring" if it's checked.
Or even better, let us write the query, just as with conditions of a TS step.

The Current Branch 2002 release introduced a feature to install SSUs first but only when triggered by the deadline.
From the docs:
"SSUs are installed first only for non-user initiated installs. For instance, if a user initiates an installation for multiple updates from Software Center, the SSU might not be installed first."

A lot of work has been put into encouraging user-participation in the patching process. I want the user to decide when they're ready to install the updates and avoid situations where the deadlines impact their work. In those scenarios the behavior introduced in 2002 therefore not helpful.

I realize that if a user manually triggers the installs one-by-one that there's not much you can do about it. However, in pretty much every other scenario I would like to see the SSU install first.

For example:
User schedules the install from the update notification dialog.
User clicks 'Install All'.
User select multiple updates, including an SSU.