Have you ever wondered why a ConfigMgr client takes a long time to run the advertised programs after you deploy this client using ConfigMgr OSD? Well, this is because as soon as the machine is imaged, it gets added to the ‘All Systems’ collection and gets the advertisements/policies that are targeted to the All Systems collection. But what if your advertisements are not targeted to the default All Systems collection, and instead are targeted to a custom query based collection? In that case, the newly imaged machine doesn’t get added to the custom collection until it sends the inventory AND the collection updates based on its schedule and finds the machines that fulfill the query condition to add the machine(s) to the collection, and in turn triggering the creation of policies for these clients. Until this happens, there are no Advertisements for this newly imaged client to run(unless of course, they were targeted to the All Systems collection). This is why you may notice a delay of up to 24 hours or more until you see the newly imaged clients processing all the Advertisements that you expect them to execute.
One way to workaround this delay is to add the machine to the desired collection(s) manually, and give it about an hour to request for new policies. However, this is a tedious task. Another way is to somehow add the computer to the desired collection during the OSD Task Sequence run-time. This would result in the computer pulling all the policies targeted to the desired collection immediately after it is imaged. I wrote a script that can be used to do just that. All you need to do is to add a ‘Run Command Line’ task to the Task Sequence and specify the following Command line:
cscript AddMeToCollection.vbs <SiteServerName> <CollectionID> %_SMSTSClientIdentity%
In the above command line, <SiteServerName> needs to be replaced with the SMS Site Server Name <CollectionID> needs to be replaced with the desired Collection ID
Thats all that you need to edit in the above command line. However, you need to make sure that you run this command line as an account which has rights to connect to the SMS Provider. If the account running this command does not have the required rights, then the script will fail to execute. Regardless of the Success/Failure, you would see the return code in the SMSTS.log, which may be useful during troubleshooting.
You can find this script attached here. I hope you find this post useful.
IMPORTANT: Using the example above works in my lab, however information in this post is provided "AS IS" with NO Warranties, or Support.
Vinay Pamnani | Support Engineer
Awesome!! That's a fantabulous piece of info .. :)
How about a script that queries SCCM for all collections a computer belongs to, save that to a variable and then post, add the computer back into all those collections?
Just a little tweak: you are creating a direct membership rule using "oCollection.AddMembershipRule oDirectRule". So there's no need to trigger an update of the collection membership (oCollection.RequestRefresh False) afterwards if I am not mistaken (because direct membership clients are inserted directly into the corresponding table without the need for collection evaluator to run).
Good but AS soon the computer is newly imaged(member in AD) and discoverd by SCCM,it will be added to SCCM Database and based on the collection membership updatation,the newly computer will be added to all the collections where the collection query matches to the computer if i am not worng. Is there any necessity to send the hardware information before getting the computer policies ?
Excellent!Thank you so much for that information, I wanted to try this in our lab before we implement in one of our customer place ,kindly let me know is there any specific part of the TS where we should put this in or can we just add it somewhere after Setup Windows and ConfigMgr task during the PostInstall Phase.
Thanks once again!
@Simon: That's a good thought. I'll see what I can come up with, given i get enough time to do this stuff.
@Torsten: You are absolutely correct Sir. I will change that shortly.
@Koneti: It really depends on the Collection Query. If the query is based on a condition that relies on Hardware/Software Inventory then the Collection will update only after that information is sent. However, even if the Collection Query is independent of Hardware/Software Inventory, the Collection Update can take upto 24 hours (which is the default update schedule).
@Sagar: In all my testing, I placed the Run Command Line task right after Setup Windows and ConfigMgr task.
Hi have a question, I am trying to use that script and I have an error message telling me "Could not find the Resource ID for the computer. Exiting!". I did the test on another test lab and the script worked.
The only difference is:
LAB A: my SQL server is on another server, the script is not working
LAB B: My SQL server is on the same server as my SMS provier.
Is there a way to make it work in LAB A wihtout many changes?
@Mathieu: The script does not connect to SQL, but instead gets the Resource ID from SMS Provider. As long as you provide the Site Server name in the command line, it should work fine. However, if it's not able to find the Resource ID, it would either be a problem identifying the SMS Provider Namespace, or connecting to the SMS Provider Namespace. You would see the error right after the line in SMSTS.log that says, Exiting!
You may want to connect to the root\sms namespace on the Site Server, and see if you have the correct SMS Provider Location listed there, and also make sure the account you're using to Run the Command Line has rights to connect to the namespace.
My bad, thank you for the information I was with the idea that it was getting the info right from the database. I did made some more test and find out that the account I was using was the real problem, everything else was working but again there was some permission missing.
Sorry for my other post :)
Hi, Thanks for your script. I m working on a SCCM deployment scenario and I've found some month ago a script named collad.vbs (google it to find it) which is doing the same thing (I think).
I would like to use this script to install sofware update during workstation installation. But to do that there are 4 steps to accomplish :
- Add to a static collection (your script)
- Refresh policy
- trigger schedule (or software update deployment)
- remove from collection.
I need to work on the last 3 steps, if someone know how to do that ?
What security rights does the "Run As" account require to perform this action in SCCM?
Great now how do you remove it from the collection AFTER the machine is built?
Nice Post Vinay, but this may not work in scnerios where machine should be added to multiple collections for software packages, Since we have seperate collection for each package/advertisement and its not practical to include all those collection in script.
You are absolutely correct Sir! I know this would not be a good solution in a scenario where multiple collections are involved, however I provided this as an example, and it's fairly easy to modify the script to read from a text file containing the collection ID's of all the collections, and then add the machine to them. However, this is where R3 comes in the picture, and with features like Delta AD Discovery and Dynamic Collection Updates, we hopefully would never need to use any such scripts/workarounds anymore.
Thank you very much! Exactly what we need for our deployment. Great work, keep it up!