we converted 1500 task sequences to applications. worked like a charm. we have zero packages except mdt toolkit and zero task sequences except 1 os deploy.
On Thu, Aug 22, 2013 at 1:47 AM, Craig Andrew (OIZ) <[email protected] > wrote: > Ah the use of task sequences is a very long, and political story that > involves software packaging teams and complexities in the software catalog. > I’d rather not go into it just now but I do have a blog post in draft which > kinda covers it in the background part. It’s more about how to set > detection methods so that you can run an uninstall application step in a > task sequence (which at the moment is not possible).**** > > ** ** > > *Von:* [email protected] [mailto: > [email protected]] *Im Auftrag von *Jason Sandys > *Gesendet:* Mittwoch, 21. August 2013 16:17 > *An:* [email protected] > *Betreff:* RE: [mssms] client policy processing limits**** > > ** ** > > So, not evaluating at all, simply still just curious, what are you doing > that requires the TSes? I understand there’s no way to make a dependency on > a package from an App, so what is in the package that is introducing this > dependency.**** > > ** ** > > J**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Craig Andrew (OIZ) > *Sent:* Wednesday, August 21, 2013 9:07 AM > *To:* [email protected] > *Subject:* AW: [mssms] client policy processing limits**** > > ** ** > > Hi, **** > > ** ** > > I am advertising just over 300 Task Sequences*, which along with Updates > and Configurations equates to over 1600 Policy files. In 2012 there are two > files, the Assignment part and the body part, of a Policy. What I am seeing > is that somewhere around 300 Deployments the amount of policy files that > the policy agent has to process at machine policy retrieval is “at least” > 1600. And once it is finished the wmi seems to stop responding. The client > certainly stops responding, it cannot actually install any software.**** > > ** ** > > The TS are used to deploy applications so they contain one package step > and one application step. (I reckon that’s about 3 policies per deployment, > possibly 6 or 7 policy files per deployment) x 300 = anywhere between 1800 > and 2100**** > > ** ** > > Although it could be I have missed the updates policies as well. If I > don’t advertise all the to a client, then it just gets standard policies > like updates and configs, and I never see any lag in policy processing.*** > * > > ** ** > > I will have a look at the wmi buffer. One thing is, if I repair wmi > repository and repair client then the client starts responding but starts > processing the policies again so it’s not long before it falls over again. > **** > > ** ** > > *Von:* [email protected] [ > mailto:[email protected] <[email protected]>] *Im > Auftrag von *Daniel Ratliff > *Gesendet:* Mittwoch, 21. August 2013 15:39 > *An:* [email protected] > *Betreff:* RE: [mssms] client policy processing limits**** > > ** ** > > One thing that comes to mind is that if you are sure its WMI that’s > failing, you can increase the memory buffers for WMI. I had to do this > recently for a PowerShell script running a WMI query against our CAS. **** > > ** ** > > > http://social.technet.microsoft.com/wiki/contents/articles/6563.configmgr-sccm-how-to-increase-wmi-default-memory-allocation.aspx > **** > > ** ** > > *Daniel Ratliff* > > ** ** > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jason Sandys > *Sent:* Wednesday, August 21, 2013 9:34 AM > *To:* [email protected] > *Subject:* RE: [mssms] client policy processing limits**** > > ** ** > > I’m curious how one gets to 1600 deployments for a single system? Are you > deploying every possible update to it?**** > > ** ** > > J**** > > ** ** > > *From:* [email protected] > [mailto:[email protected]] *On Behalf Of *Trevor Sullivan > *Sent:* Wednesday, August 21, 2013 8:19 AM > *To:* [email protected] > *Subject:* RE: [mssms] client policy processing limits**** > > ** ** > > Hello Andy,**** > > ** ** > > That’s an interesting problem you’re describing. Just to make sure I > understand it correctly, are you saying that if you deploy too many > ConfigMgr Applications, Package/Programs, Desired Configuration Management > Rules, Software Updates Deployments, etc. to a single ConfigMgr 2012 SP1 > CU2 client, that it quits processing them at some point?**** > > ** ** > > Cheers,**** > > *Trevor Sullivan* > > [image: WordPress Logo 32px] <http://trevorsullivan.net/> [image: > Twitter Logo 32px] <http://twitter.com/pcgeek86> [image: Facebook Logo > 32px] <http://facebook.com/trevor.sullivan> [image: Google+ Icon > 32px]<https://plus.google.com/106658223083457664096> > **** > > ** ** > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Craig Andrew (OIZ) > *Sent:* Wednesday, August 21, 2013 1:45 AM > *To:* [email protected] > *Subject:* [mssms] client policy processing limits**** > > ** ** > > Hi All,**** > > ** ** > > Does anyone know if there are specific limits on how many deployments a > client can receive before dying? (ConfigMgr 2012 SP1 CU2)**** > > ** ** > > What I am seeing in tests just now is if I deploy enough stuff to a > client, I can make it generate about 1600 policy files and the wmi goes > kaput. Then I need to rebuild the repository and perform a client repair. > Basically the client just doesn’t do anything, but it also doesn’t report > any errors. After the repair, it processes the policy files and eventually > falls over again, during which time if I am lucky I can install a couple of > apps.**** > > ** ** > > What I really need to do is write some guidelines for software deployment > best practice, and wondering if anyone has seen this already or has a link > to MS documentation that specifies a limit on deployments/received policy > per client…**** > > ** ** > > Thanks for any help**** > > ** ** > > Andy**** > > ** ** > > ** ** > > ** ** > > > The information transmitted is intended only for the person or entity to > which it is addressed > and may contain CONFIDENTIAL material. If you receive this > material/information in error, > please contact the sender and delete or destroy the material/information.* > *** > > ** ** > > ** ** > > ** ** > >
<<image001.gif>>
<<image004.gif>>
<<image002.gif>>
<<image003.gif>>
