Please make an easy way to query Driver Versions of all drivers on a system from SCCM Hardware inventory without creating a custom MOF or looking at registry files? I found a forum thread on TechNet a few years old that said Microsoft said that using WMI class win32_pnpsigneddriver was unreliable and is why it was not available in SCCM hardware inventory and they were considering removing the class entirely. However the class remains in win 10 and is still the only way to query driver version using a script. It would be really useful to be able to have SCCM compare driver versions on a system verses the drivers in a sccm driver pack so we can ensure systems are compliant.

Content Replication from Site to DPs should be a frustration free Process or SCCM Admins. Unfortunately, I know no customer without smaller or bigger issues in this area.
Here is an uncomplete list of some issues I´ve noticed:
• Content Eval - Scheduled Task lost
o SCCM does not check if the schedule task got lost/deleted
o Suggested Solution: SCCM should verify the Scheduled Task on Service Startup
• Content Eval - Hash mismatch/Eval fails for package
o When content Eval fails for a package, the admin must manually redistribute it / take care of the error
o There should be an option in SCCM to automatically fix packages where Content Eval fails
• Content Eval - Immediately validate content after distribution
o When an invalid package gets send to a DP, it can happen that it goes into the state "Successfully distributed content"
o However, to content is invalid. If you run a content validation immediately will go to "Could not validate…"
o Makes troubleshooting much harder, as you must verify every package before it is "really" OK
o Suggested Solution: Immediately validate content after distribution
• Content Eval - Failed to retrieve the package list on the DP
o If DP has this error, it never gets fixed automatically
o If WMI Entry is missing and .INI file is there, smsdpmon.log does not tell which package is affected
o Content Eval Task does just use package list in local WMI (SMS_PackagesInContLib), but it should verify all packages assigned to it.
o WMI/INI fix script (eg: here, but many scripts like this exist on the internet) can fix the error, but will cause other issues.
o Suggested Solution: When Content Eval runs, the DP should download a list of Packages to verify (PkgServers Table?)

• Waiting for Content - Content did not arrive from CAS
o Content available (and verified) on Primaries - however some Secondary Sites have the status "Waiting for Content from CAS”
o Workaround: Reset Status in DB for Primary and Secondary and Redistribute
• DP and Pull DP - Handle Empty Packages
o SCCM DPs cannot handle Packages without content
o Scenario 1: Deployment Packages get empty automatically, because Updates expire
o Scenario 2: Create Package with content and deploy to DPs – Remove “this package has source files” checkbox
o Content Validation on DP will fail - DP will go to warning state
o Workaround: Detect and remove empty packages
o Suggested Solution1: DPs should be able to handle empty packages
o Suggested Solution2: SCCM should detect empty packages and remove them from all DPs
• DP and Pull DP - Redistribute does not fix .INI file issues
o If Content of INI file in PkgLib is invalid, a redistribute does not fix it
o Suggested Solution: Always rewrite INI File on redistribution

• Database - PkgServers, ContentDPMap and PkgStatus not in Sync
o Content is distributed and verified successfully to DPs
o Content is not written correctly to ContentDPMap Table (can happen if status message gets lost)
o PullDPs and Clients can´t download the Package
o Workaround: Redistribute affected Package
o Suggested Solution: If Content is OK on a DP, the ContentDPMap+PkgStatus should reflect this => When Package is successfully validated on a DP, all needed Tables should get checked/updated

When an optional AD attribute has been selected for inclusion in AD discovery, if that attribute has a value at time of discovery, it is included in the discovery and reflected as part of the information for the user/computer/group object in CM. If that AD attribute is later cleared (changed to <not set> / NULL value in AD), discovery identifies that the attribute is a NULL value and purposely skips it from the discovery. As such, the user/computer/group object in AD falls out of sync with the AD attributes and continues to report the value even though it has been cleared in AD.

This behavior is clearly documented in all the "ad???dis.log" files, with lines that read:

WARN: ConvertADstoSQLType: pADsValues is NULL
WARN: Type not supported for the follwoing [sic] optional attributes, <attrib1>,<attrib2>,...,

For example. An AD employee has the employeeId attribute populated with their employee number. It is synced into CM. The employee quits and HR clears that information from the employeeId field. It is subsequently not cleared in CM. A similar action can occur with msRTCSIP-PrimaryUserAddress, whereby a once mail-enabled object is no longer mail-enabled, but the CM object still shows the information.

This matches the 2014 Microsoft Connect posting: https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/1000189/pfe-additional-ad-discovery-attributes-when-changed-from-a-value-to-not-set-in-ad-retain-a-value-in-the-configmgr-database

SCCM 1702 introduced the Install Behavior tab for deployment types which lets you specify executables for the application to monitor during deployment. Currently, if the deployment is "Available" or "Available but before the deadline" then the install fails and users receive a pop-up indicating which executables need to be closed prior to your application running.

Enhancements:
1. Modify the feature so that the pop-up appears before the application install fails. If the user clicks "OK" then the application will perform the check again. If the executables are still open then the pop-up appears again. The pop-up will continue to appear until the user successfully closes the executables. Then the application install will continue. If no action is taken then the install will fail after the maximum allowed run time. This is similar behavior to the PowerShell App Deploy Toolkit.

1. Modify the feature to work even if a required deployment has hit the deadline. If the required deployment is past the deadline then the pop-up should appear until the monitored executables are closed. Again, if no action is taken then the install will fail after the maximum allowed run time.




2. Allow the same behavior to occur for both Install and Uninstall deployments.

The changes described above would allow for required deployments to exceed the deadline and always prompt a user to close applications before an install/uninstall occurs. It would also reduce confusion caused by failure messages presented before the pop-up explaining which executables need to be closed.

While testing some new functionality in SCCM 1602 current branch I inadvertently searched for a possible new variable using the 'set dynamic variable' step.

Unfortunately that doesn't list read only variables in the 'existing variables' list (read only variables begin with _). It would be awesome if this gui would list all built-in variables (including read-only ones) as this would make searching for a particular variable easier than having to google or bing it.

Secondly, how about the option to list all custom defined variables in this gui, along with their values (if any). today we get the following headings Name, Description, how about adding one more, Value.

The reasons I think this is important is

• saving time searching for new variables on Technet


• as ConfigMgr changes version often, being able to list all current variables available to that product version would be great


• debugging task sequences to see what custom variables values are set to what value

cheers
niall

It would be great to be able to customize the Windows 10 image or allow a "clean up script" to run post install. I like the concept of the Windows 10 Servicing part of the SCCM console. I think it will become important as upgrades start rolling out 1-2 times a year and majority of companies have Windows 10 clients that need servicing. Being able to create Servicing plans will help keep IT on top of the upgrade process through different updates.

The current model just doesn't work for a lot of companies. Not many places allow games such as the Xbox app for corporate use. Candy Crush? come on.... Twitter? Maybe.

I think if you start with the ability to tag on a PowerShell script to run, it would make this much more usable to many companies. Down the road I would like to see the different security updates for the different builds put in there as well. It's going to get messy getting the same vulnerability patched in 3-4 different builds.

Another idea might be to ability to link task sequences into servicing plans.

Right now, the automatic Client upgrade scheduled Task is not aware of any running installations. So if appenforce.log shows a running Installation and at the same time the randomly timed scheduled tasks kicks in, the Installation cannot finish without error and will randomly leave the Installation or the SCCM Client itself in a unhealthy state. A reinstallation is the only way out.

Repro steps
- Activate automatic Client Upgrade in Hierarchy settings
- Exclude some test clients from automatic client upgrade
- Create an Application with a deploymenttype using a custom script
- As the script, use a batch file pinging localhost with parameter -t so that the dummy installation will newer end. That gives you time for the test.
- Deploy the app to the excluded test clients
- Let the installation run
- Set the clients to not be excluded from automatic client upgrade, so that the scheduled task for the upgrade will be created locally
- run the scheduled task manually to simulate the client upgrade
- you will see some errors in appenforce.log telling you that the installation could not be finished without error

Expected behaviour:
- The automatic client upgrade function should not run if an installation is allready running
- instead of scheduling a scheduled task you should schedule a package install, so that the sccm client can only start the package/upgrade if no other installation is running