That's a good question, and since I have it, too, sort of, and I see no reply - here's a bump.
I'm new to ePO 4.5 (but a longtime McAfee Enterprise customer), and I created a Task for a subgroup and thought I could merely move it, copy it, assign it, etc. to another group. I don't see how, nor do I see anything like that in any documentation.
It seems like a really basic function - if you create a Task, why shouldn't you be able to do those things?
Which means the answer to your question would be to assign everything at a very high level...but then there are other concerns.
I have to say (and I was mentioning this to the McAfee account rep and sales engineer who demo'd ePO for me last week) that ePO is much better than it was when I last looked at it a few years back, but compared to some other security consoles (Webroot's, for instance, which is very MMC like, and dragging and dropping or assigning policies (and to them - policies and tasks are one) to any group, sub group, etc. is easy. And the groups can all be OU's, since it integrates with AD inherently and easily (if you wish). You get to focus on creating the policy/task and worry about where to place it later, and if you make a mistake (and you find out that it doesn't work well for a particular OU), assigning a new one is SO easy.
Even if you look at AD GPOs - where you can link GPOs back to any OU even if it was created in a sub OU - it's a basic feature.
Am I missing something?
I have found the best way to handle tasks is creating each task at the highest level in your organization and set it to disabled. At this point you can go to the appropriate sub-folder and break inheritance, allowing you to enable the task where you want.
For example, we wanted to test McAfee agent 4.5 but didn't want to install it manually on a subset of machines or import it to the current branch so it would deploy to everyone. Instead we created a task to deploy the 4.5 agent at the top root at set it to disabled. I could then drill down to either an organizational unit or single system and break inheritance and enable this task.
Now this will be a lot of work to get set up at first, but when you are done the management side will be much easier. If you go back to your root level you can see exactly what systems/OU's have inheritance broken, you won't have to search thru your OU's to see who has what task running. If you no longer want an OU or client to have that task you simply reset inheritance from the root and you are all set.
Hopefully this helps some people out. It took me a while to get going, but now that I have it up and going I have much more control over what is deployed in my environement.
Thanks very much for the post - that was very helpful.