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

Business Case (I know how you PMs love these):
The current CB 1902 implementation is going to make this conversation part of our helpdesk script:
“What screen is the app on?”
“Can you move that window to the monitor where X is showing?”

“No, not that one.”
“Nope, still don’t’ see it”
“Ok let me reconnect in full screen, please accept the prompt again.”
“No no no, don’t hang up the phone, that’s not how this works.”
“Ok, you should see a prompt to allow me to connect.”
“Nope it’s there, trust me.”
“Got it, thanks. Ok, let me move that over here.”
“Ok, I’m going to reconnect again so I can see what’s going on.”
Click
“You just hung up, didn’t you?”

This is going to waste time on support calls and leave both sides dissatisfied with the entire experience. In turn, customers will continue implementing other third party remote control tools. Remove Viewer was absolutely a selling point for ConfigMgr and was one of the features that lured us away from our previous solution.

Solution:
1) The ability to select any single screen connected to the remote device in addition to the current all screen view.
2) The ability to change monitor selection without having to reconnect the remove viewer.

Notes:
I could probably live with automatic reconnection provided that the admin stays in the Remote Viewer app at all times and doesn’t need to retype anything (device name/credentials) nor the end user re-accept the prompt if one is configured.
In my dreams the ability to pick a single screen is built into the full screen mode. In full screen mode the admin clicks a button that overlays each monitor with a number and an outline. If this sounds like display setting’s ‘Identify Monitors’ that’s because that’s exactly what I’m thinking of. However, don’t stop there. In that identification mode make the monitors selectable such that when I click on one it immediately becomes the single monitor I’m connected to.

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

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

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

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.

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.

The way collection membership updates are handled is completely flawed. Should this be fixed, the (soft) limit of collections that can have incremental updates enabled should also be changed.

We all know that when a collection is updated, all collections limited to it are also updated. And should any of the children collections be updated, then so will the children of the children, and so forth and so on.

However, there is a massive design flaw that in this system that means a huge number of collections that should never be updated are being updated.

Imagine this scenario:

CollA is created and limited to All Systems
CollA has no collection membership rules at all.
Whether CollA has incremental updates or not is irrelevant, as the result will be the same.

When All Systems updates and something changes within All Systems, CollA will also be updated. Yet, in this particular scenario where there are no membership rules specified on CollA, it's impossible for something to have changed and it's an effort in futility to evaluate its membership.

Second scenario:
CollB is created limited to All Systems
CollB only has direct membership rules
All Systems is updated and at least a resource has changed, so CollB's membership rules are also updated.

Again, in the scenario where only direct membership rules are used in a collection, that collection should not be updated if its parent has updates and found that resources changed.

Scenario 3:

CollA is limited to All Systems
CollB is limited to All Systems
CollB contains a single collection rule - include collection CollA

In this scenario, if All Systems updates and at least a resource changed, both CollA and CollB will be updated as well - even if CollA's membership hasn't changed. What should happen is that the system identifies that CollB contains a single collection include collection rule set to CollA and first process CollA. If CollA's membership changed, then update CollB, else leave CollB alone.

Scenario 4:

CollA is created with no membership rules.
CollA has an update scheduled of every 7 days (default).

In this scenario, despite the fact that CollA has no collection membership rules at all, its membership will still be evaluated.

In an ideal scenario, SCCM would ignore collections with no collection membership rules from full or incremental evaluation schedules.

I could keep going with the scenarios as this applies to exclude collections, collections with incremental updates enabled, etc etc etc.

Basically the bottom line is:

• If a collection has no membership rules, it should never be updated.




• If a collection only has direct membership rules, it should never be updated (I believe a collection update is not required when a device is deleted from the database?)




• If a collection only contains include/exclude membership rules, it should only be updates on a schedule (if set to update on a schedule) or if one of the include/exclude collections it references has changed - as oppose to when the parent collection has changed.

Where I work we have over 1300 collections limited to 'All Systems'. Over 90% of those collections only contain direct membership rules, or no rules at all (because no direct membership rules were added yet).

Yet, every time something changes in 'All Systems', all 1300 collections are updated. This takes well over 5m to do.

As mentioned above, if this is changed I think the soft limitation of 200 collections with incremental updates can be raised, as a lot less collections will be updating overall.

DSC is a wonderful framework for handling baseline configurations across Windows and Linux machines, but it's completely unsupported in SCCM directly. While a Pull server is certainly more simplistic than an SCCM hierarchy, it would still be very beneficial to have some integration in a couple of areas:

Management Points can easily be configured to host mof configurations for clients, and a new client policy class for allowing the SCCM agent to configure the pull server settings on a host would be great. Alternatively a new role could be made ... not sure that would feel as elegant.

The baseline section could contain DSC configuration files or items for a more open/standard baseline control. THe current baseline scripts feel so dry it would be great to see it replaced with a standard DSC formatting.

The certificates store under administration can hold public keys for password encryption for MOF files when generated.

Distribution Points could house modules for said Pull server calls. Want to get clever? Blend in some chocolatey goodness and allow us to create ADRs for pulling the latest versions down on an interval.

Reports! Yes, the reporting module in DSC is dry ... and how great would it be to have some canned DSC reports for easy at a glance compliance settings.

Needs for confiuration are changing ... some great work is being done to make declarative configurations happen ... but SCCM still uses simple and clunky scripts for baselines. Lets standardize on power-shell already.