I think, I may be wrong because I've never tested this; but if you wanted to prevent anyone from installing something interactively/manually from Software Center, create a Custom Client Agent Setting, and under "Computer Agent", change Install Permissions to "No Users". Assign that custom client agent setting to the same collection you've sent this Software Distribution & App Deployment Disabling baseline, and I *think* you've covered the bases for preventing clients in the particular collection from getting Software.
Sherry Kissinger On Tuesday, August 26, 2014 3:25 PM, Todd Hemsell <[email protected]> wrote: FYI, I think it is called "Fast Deploy" in policy and the DB. On Tue, Aug 26, 2014 at 3:21 PM, Todd Hemsell <[email protected]> wrote: You will notice that there is an entire addition section. go to the software catalog and request an application, it will install even when all that is disabled. >You can disable that in policy though. > > > >On Tue, Aug 26, 2014 at 1:43 PM, Niall Brady <[email protected]> wrote: > >nice analysis Sherry ! >> >> >> >> >>On Tue, Aug 26, 2014 at 8:31 PM, Sherry Kissinger <[email protected]> >>wrote: >> >>I did a little more testing today. >>> >>> >>>Setup: 1) Target currently deserves RichCopy as an App Deployment. >>> 2) Uninstalled RichCopy, App Deployment Re-eval cycle, and it >>>reinstalled. >>> >>>Testing App Deployment Disabling: >>> 1) Sent the Baseline to disable both App Deployments and legacy >>>Software Distribution. >>> 2) policy refreshes; confirmed the baseline ran. Waited a few >>>minutes. >>> 3) From Zanders' ClientCenter, confirmed I didn't "see" any >>>applications available. >>> 4) Uninstalled RichCopy, then a bunch of App Deployment re-eval >>>cycles--and it did NOT reinstall. >>> >>> >>>Remember, the target is still in the collection where it deserves >>>RichCopy--it's just refusing to install it anymore. >>> >>> >>>Testing re-enabling: >>> 1) Removed the deployment of the baseline for disabling, and >>>deployed the baseline to remove the local policy. >>> 2) a bunch of policy refreshes, and from the applet, forced >>>an immediate evaluation. Within about 3 minutes, RichCopy reinstalled. >>> >>> >>> >>> >>>So I think it does what *I* want it to do anyway. :) >>> >>> >>>As a small reminder, if; 2 years from now you are wondering... "OK, who >>>actually has these local policies? how do I figure that out?" -- >>>http://myitforum.com/cs2/blogs/skissinger/archive/2009/07/06/hardware-inventory-mof-edit-for-local-policies.aspx >>> >>> >>>I'm planning on blogging these baselines within the next day or so (other >>>priorities permitting). >>> >>> >>>Sherry Kissinger >>> >>> >>> >>> >>>On Tuesday, August 26, 2014 12:17 AM, Eswar Koneti <[email protected]> >>>wrote: >>> >>> >>> >>>OK,i did some testing for legacy packages,it seems to be working for me too. >>>after the compliance,i tried deploying the legacy app ,policyagent.log >>>receives the info about the deployment and execmgr.log generating yellow >>>messages saying 'Can not find client site settings' . >>>but the deployments which are already made available in software center do >>>not affect with this change.users can run the apps from software center >>>without any problem. >>>Regards, >>>Eswar Koneti http://www.eskonr.com/ >>> >>> >>>Date: Mon, 25 Aug 2014 15:56:30 -0700 >>>From: [email protected] >>>Subject: Re: [mssms] Is it possible to have a Maitenance Window that >>>prevents any deployments? >>>To: [email protected] >>> >>> >>>Niall kindly forwarded me his Word Document, and using that, I made up two >>>Baselines (and 4 configItems) >>> >>> >>>Attached are the baselines which "should" have 2 CIs each; if you were to >>>import them into your environment. >>> >>> >>>I've only tested these quickly in a lab, against 1 client. But that client >>>did refuse to do any application deployment or traditional >>>package/program/advert deployment when it had the two things Disabled; and >>>when I took that baseline away and instead assigned the "remove the local >>>policies" one, that client seemed to want to do apps and adverts again. >>> >>> >>>You would only deploy 1 baseline (not both); primarily you'd deploy the one >>>to Disable SWDist and AppDeployments. The other baseline would be for >>>"oops, I didn't really mean to target "All Systems"... now how do I undo >>>that?" You'd stop the Baseline deployment of the Disable, and instead >>>target the Removal of the local policies one. >>> >>> >>>But it would be great if someone on this list would test the baselines in >>>their lab (or "when you test, you test in production" -- whichever works for >>>you!) . Once it seems to work for more than just me, Niall or I can blog >>>it out there. >>> >>> >>> >>> >>>Sherry Kissinger >>> >>> >>> >>> >>>On Monday, August 25, 2014 9:11 AM, Niall Brady <[email protected]> wrote: >>> >>> >>> >>>I've got a word doc, never blogged it and never finished it, to stop ALL software deployments you'll want to configure something to stop applications from installaing also, this only disables SWD >>>the list stopped me from sending it as it's too big, email me if you want a >>>copy. >>> >>> >>> >>> >>>On Mon, Aug 25, 2014 at 4:07 PM, Niall Brady <[email protected]> wrote: >>> >>>here's what i did, never blogged it and never finished it, to stop ALL >>>software deployments you'll want to configure something to stop applications >>>from installaing also, this only disables SWD >>>> >>>> >>>> >>>> >>>>On Mon, Aug 25, 2014 at 3:31 PM, Niall Brady <[email protected]> wrote: >>>> >>>>i started blogging about disabling SWD and other functionality via CI/CB >>>>and got great success with that, however it only disabled that >>>>functionality (other functionality could still work) however the same >>>>ideaology could be used for disabling the other functionality... >>>>> >>>>>I never completed it but happy to share if anyone wants it >>>>> >>>>> >>>>> >>>>> >>>>>On Mon, Aug 25, 2014 at 3:18 PM, Daniel Ratliff <[email protected]> >>>>>wrote: >>>>> >>>>>Also note that if you have any deployments set to Ignore Maintenance >>>>>Windows, adding Trevor’s suggestion below will not help. You will still >>>>>need to stop CCMexec, etc. >>>>>> >>>>>>You could setup a client policy to disable what you need? But I know >>>>>>there are some limitations there as well. >>>>>> >>>>>>Daniel Ratliff >>>>>> >>>>>>From:[email protected] >>>>>>[mailto:[email protected]] On Behalf Of Trevor Sullivan >>>>>>Sent: Monday, August 25, 2014 9:13 AM >>>>>>To: [email protected] >>>>>>Subject: RE: [mssms] Is it possible to have a Maitenance Window that >>>>>>prevents any deployments? >>>>>> >>>>>>Sure, just create an All Deployments Maintenance Window that is 40 years >>>>>>in the future, and apply it to those machines. If you’re especially >>>>>>worried about these systems, then you could always consider disabling the >>>>>>ccmexec service, or removing the ConfigMgr client altogether, but then >>>>>>you’d lose other ConfigMgr features like Compliance Settings rules, >>>>>>Inventory reports, and so on. It all depends on how critical these >>>>>>systems are during that period. >>>>>> >>>>>>Cheers, >>>>>>Trevor Sullivan >>>>>>Microsoft PowerShell MVP >>>>>> >>>>>>From:[email protected] >>>>>>[mailto:[email protected]] On Behalf Of >>>>>>[email protected] >>>>>>Sent: Monday, August 25, 2014 8:02 AM >>>>>>To: [email protected] >>>>>>Subject: [mssms] Is it possible to have a Maitenance Window that prevents >>>>>>any deployments? >>>>>> >>>>>>Crazy question but I need to lock down a specific set of machines for a >>>>>>30 day window. Is it possible to prevent deployments entirely? Anyone >>>>>>have a suggestion? >>>>>> >>>>>>Appreciate the help >>>>>> >>>>>>Thanks >>>>>> >>>>>> >>>>>>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. >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >
