This content has been marked as final. Show 2 replies
When you create the MA policy for each site, make sure you push the local target repository to the top and disable the others. You should put ePO as the second item in line.
Now depending on when your clients check in and get a new sitelist.xml, if they haven't received it, they will continue to go to the ePO server for updates. No matter what, they will always go to the ePO server for new tasks and policies.
RDP into a distant workstation and checkout the sitelist.xml and start to fix it from there. BTW, you may want to consider applying some randomization to your deployment task, the SADR cannot handle all those inbound connections at the same time..which reminds me, perhaps that's the reason your clients are hitting your ePO server - Overflow.
I was not under the impression that the deploy task could figure out which clients do or do not have the software module. So, I assume that your clients are ALL trying to install VSE every day at the specified time. During install it realizes that it doesn't require and stops. But before it realizes that, it'll try. Once MA moves to P3, I believe that the SADR will queue up the clients, up to 250'ish before denying them.
I suggest that you make a task to deploy your module with a schedule of run immediately or once at a given time and a randomization of x hours.
Heck, create the task at the top level in disabled mode and turn it on per site until the site is adequately rolled and then move to the next site. Just don't make it run everyday. Use your reports/dashboards to figure out where you need to concentrate your one-off touch efforts.
Just a quick point - the tasks do have this ability. Basically tasks are driven by a pair of scripts: a detection script that works out if the product is installed, and an install script that actually does the installation (or removal.)
When the task runs the detection script is run first - if the product is is already installed then the process doesn't go any further.