An include collection query would look like this: Select * From SMS_CM_Res_Coll_COLLECTIONID
That should grab all computers in the collection On Thu, Dec 4, 2014 at 10:57 AM, Miller, Todd <[email protected]> wrote: > Maintenance windows shift the schedule of deployment to be client > dependent, where my current workflow puts the schedule on the package and > advertisement. I am not sure I can operate with the time the software gets > installed to be dependent on the settings on the client. > > > > > > Thanks for the suggestion on the collection query. I will investigate to > see if I can make collection membership of another collection be part of > the criteria in a collection query. Do you happen to know off hand what > attribute class contains collection memberships? I can’t find it. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Ryan > *Sent:* Thursday, December 04, 2014 9:40 AM > *To:* [email protected] > *Subject:* Re: [mssms] Question about Limiting Collections > > > > Why aren't you using maintenance windows to schedule deployments? That's > what they are there for. > > In my experience, collection refresh schedules only really apply to > queries. Include and Exclude collection rules happen immediately when one > collection changes. If you want your old system to work still, use a query > rule to add all computers in Collection X to Collection Y instead of an > include rule. > > > > On Thu, Dec 4, 2014 at 9:26 AM, Miller, Todd <[email protected]> > wrote: > > I have a question about the function of limiting collections. In SCCM > 2012, they are having a undesirable effect where when a limiting collection > is changed, the collections that are limited by that collection seem to > reevaluate immediately. I have a workflow in 2007 that this new function > disrupts. Sorry this is kind of long. > > > > > > Here is my workflow in SCCM 2007. > > > > I create a collection with query rules to determine what clients are > eligible for the installation. This collection we will call “Deploy - App > A” and I set the collection to refresh daily at 3:30AM. I create another > collection named “Limiter –App A” which is initially empty. The Deploy - > App A collection is set to be limited by Limiter –App A. > > > > Then I advertise an package to deploy to “Deploy – App A” and set it to > run at some time in the past- I could also set it to run “as soon as > possible.” Nothing happens immediately because Deploy – App A and Limiter > – App A are empty. > > > > Now when I want to deploy Application A to a client, I add Computer X to > the Limiter – App A collection. At 3:30AM (and not before), when the > Deploy –App A collection is refreshed, the client is added to Deploy – App > A and the next time the client checks in AFTER 3:30AM, the software is > installed. > > > > Basically, I can drop clients or lists of clients into the Limiter > collection in the middle of the day knowing that they won’t get added to > the actual deployment collection until the collection is scheduled to > refresh in the middle of the night. > > > > That’s how this functions in SCCM 2007. > > > > > > SCCM 2013 messes up this beautiful arrangement I have. Now the deployment > collection ignores the collection schedule entirely. I am not even sure > what that collection refresh schedule is good for anymore. > > > > As soon as I add a client to Limiter – App A, the Deploy – App A > collection seems to refresh and Computer X that I just added to Limiter – > App A gets added to Deploy – App A. Since the advertisement is in the > past, itkicks off the installation. My ability to pre-stage installations > during the day knowing the deployment collection won’t update until the > middle of the night is lost. I do not have the Deployment collection set > to do incremental updates, so why is it not respecting the collection > update frequency? > > > > Is there a way to predictably (at a particular time) add clients to a > collection where I could stage them during the day and have the collection > update at a set time? There doesn’t seem to be a way for me to ensure that > collections are updated only on a strict schedule anymore. > > > > > ------------------------------ > > Notice: This UI Health Care e-mail (including attachments) is covered by > the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is > confidential and may be legally privileged. If you are not the intended > recipient, you are hereby notified that any retention, dissemination, > distribution, or copying of this communication is strictly prohibited. > Please reply to the sender that you have received the message in error, > then delete it. Thank you. > ------------------------------ > > > > > > > > > ------------------------------ > Notice: This UI Health Care e-mail (including attachments) is covered by > the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is > confidential and may be legally privileged. If you are not the intended > recipient, you are hereby notified that any retention, dissemination, > distribution, or copying of this communication is strictly prohibited. > Please reply to the sender that you have received the message in error, > then delete it. Thank you. > ------------------------------ > >
