ConfigMgr 1511 with CAS and multiple primaries - problem getting started

Marco

Has anyone encountered a limit to the number of Apps and Programs that can be deployed to a client?

A friend is trying to migrate from SCCM 2007 to 1511 and when they setup a new client in 1511 it initially has 600 or more items in Software Center but they start decreasing over time.  They have a lot of apps and packages deployed to All Systems..

I’m about to dive in but wanted to see if this rings a bell as a common undocumented problem.  They have a MS support ticket open but have not made any progress in a week or more.  They have been cleaning up deployments but the problem persists.  Create a new virtual machine, install the client, everything is there.. a few hours later some deployments are missing.  A few more hours later and more deployments are missing.  They say database fragmentation is not bad (that was my first idea).

Thanks!

73/N5ZY

wally_mead

I am not aware of any 'capacity' limits on deployments displayed in Software Center. When I was at Microsoft in the Configuration Manager product group, our standard test bed was 10,000 objects (so packages/apps). I don't recall what the deployment test was. 3,000 is a lot, but I assume not all 3,000 are to all systems/users, so would not all expect to be in Software Center at the same time. Above you mentioned 600, which sounds like a perfectly valid number.

There certainly are some differences with the new Software Center in Configuration Manager current branch, but overall, I think it works pretty much the same.

Oh, and by the way, there is no '1604' release. From 1511, it is either 1602 or 1606 :-) I'd do 1606, as it includes everything from 1602 as well.

And you have a fantastic weekend. Brett is from Australia, so this weekend is nothing special for him (at least not a national holiday like we have :-)

Brett_Moffett

I've never seen this before but it sounds like the client is dropping out of collections within ConfigMgr over time.
Check that the client records for the machines in question are active and are int he collections that contain the deployment for the apps you are missing.

wally_mead

I would agree with Brett's assessment. It does sound like the client is getting removed from the collections that are targeted with those deployments. It could very well be that when they installed current branch, the client generated a new resource ID, so that it is not the same 'client' as was in the old environment, especially if they were using direct membership rule collections. That would be different now if they reinstalled the client. Check the Resource ID value for a client, then check the collections to ensure that the 'member' in the collection has the same Resource ID as the current client does.

Marco

Thank you Brett and Wally.  That is what I wondered originally.  They are moving from CM07 to CMCB build 1511.  Microsoft was telling them it was a capacity issue (they have 1,900 packages/apps) and over 3k deployments.  We found some CI evaluation errors on clients pointing to corrupt policies.  Those are being deleted now and recreated.

If we open the new client interface it looks fine..  But the old client interface is where the problem of disappearing deployments occurs.  So we are also thinking about applying the update to 1604 (the goal was to migrate from CM07 to build 1511 so now another change has to be approved).

I wonder how the new client UI works under the hood in comparison with the legacy Software Center we used in CM12..

Have a great Labor Day weekend!

wally_mead

I am not aware of any 'capacity' limits on deployments displayed in Software Center. When I was at Microsoft in the Configuration Manager product group, our standard test bed was 10,000 objects (so packages/apps). I don't recall what the deployment test was. 3,000 is a lot, but I assume not all 3,000 are to all systems/users, so would not all expect to be in Software Center at the same time. Above you mentioned 600, which sounds like a perfectly valid number.

There certainly are some differences with the new Software Center in Configuration Manager current branch, but overall, I think it works pretty much the same.

Oh, and by the way, there is no '1604' release. From 1511, it is either 1602 or 1606 :-) I'd do 1606, as it includes everything from 1602 as well.

And you have a fantastic weekend. Brett is from Australia, so this weekend is nothing special for him (at least not a national holiday like we have :-)

Brett_Moffett

Thanks @wally_mead.....    My weekends are not special......         (Sigh)

Marco

Wally, I will relay the information about capacity as not a likely issue but to continue the focus on deleting unnecessary deployments and recreating deployments (manually instead of using a script - or at least check if the SDK in use has been updated).  There are quite a few deployments to 'All Workstations'.  I believe today we are just trying to remember where we were in the troubleshooting before the holiday.  

Sorry, yes that was a typo when I said 1604!  1606 is the update in the console that is pleading to be deployed.   

Brett, it sounds like your weekends are like mine.  mowing, trimming, or repairing around the house.

wally_mead

You can safely ignore the installation of any update packs that you want to skip. They are cumulative, so if you skip 1606, then its features would come in 1610 (or whatever the next release is). Personally, I'd stay up to date with the builds and install them all, unless political or environmental issues were preventing me from doing so :-)

Brett_Moffett

As @wally_mead said in his previous post, Make sure that you are not running with direct memberships as these will drop out as the client gets a new GUID.
My advice is always use a query based membership for collections. That way you always have the clients you are after even if they change name, client, network etc.

wally_mead

I always prefer query-based collections too, however it is fairly common to use direct membership rule collections, especially for collections designed for software installs, or collections of servers to spread out the patch installation loads. However, whenever possible, use query-based collections.

Marco

So this is difficult to figure out where the client is stumbling in the processing of policy.
I'm looking at a 1511 client.  ROOT\CCM\ClientSDK, CCM_Application has 594 instances.

25 have an ApplicabilityState = "Unknown" and InstallState = "Unknown". 
80 have an ApplicabilityState = "NotApplicable"
490 have an ApplicabilityState = "Applicable"

These 25 do not appear in Software Center.  I've been told if we open the Application Catalog and click install then they do appear and install.

This is really strange.. so for some reason the client doesn't finish reviewing all the policies it downloads but you can manually invoke one from the web services..

I would love to hear suggestions if you have any.
I believe right now the team is manually deleting and recreating each of these "Unknown" status apps/packages.

wally_mead

Sounds like you are making progress in the determination of the issue, and resolution, even if it is hard to pin down. I don't recall that the Application Catalog does any applicability checks until the user tries to install the app from it. Then it checks the requirement rules, detection methods, etc. to see if it should try to install the app or not. You can see that in some of the client logs, such as AppIntentEval, etc.

Software Center never used to show user targeted deployments (those that would show up in the Application Catalog), rather only those targeted to computers. That changed in the current branch product. However, I know that it has some different methods to identify what to display, and I believe those are different than the Application Catalog. Thus, it does not surprise me at all that the Software Center UI would not display something with an Unknown state but the Application Catalog does.

Before I went to the trouble of recreating those apps, I'd force an Application Deployment Evaluation Cycle on the client and then see if the state changes at all. That process should run automatically (weekly by default, but can be customized), but I'd force one to verify. Then either check your SDK method, or the log for those apps and their state.

I guess, given that you have a CAS, it's possible that something didn't get replicated properly, though I would doubt that if everything else is running fine (unless these 25 apps were all created at the same time, and maybe their was a replication issue around that same time).