AutoInstall really isn't suitable for this; honestly, avoid it - amazingly, internally the code is even worse than you'd think from it being such a lame tool, which is why it never got better - like GhostCast, it is what it is and the design is so bad it needed to be rewritten from scratch to do even a small improvment. And of course, if you started from scratch you'd probably aim at a different, rather better concept altogether.
Actually, all file transfers specified in the console via "File and folder actions" are meant to be multicast (folder transfer aren't, because they are a replication system). However, the problem is that due to some bad calls by my manager at the time, it's built on the GhostCast multicast code which is just not fit for purpose; running it in the management client is particularly fraught because its core design faults interact with a *hideous* design fault in Windows XP.
The firewall introduced in Windows XP SP2 is mostly good, but there's a nightmare flaw in it; at boot, there's a mini-firewall built into the TCP/IP stack (the "boot firewall") which just does some simple default things until the real firewall service can start up, load its rule base, and then take over.
Unfortunately, it seems that during the hand-over between the two firewalls, something horrible happens to multicast group membership - a process can be subscribed to a multicast group, receiving multicast traffic, but at some point during the machine boot process up to several minutes later, the listening process just stops receiving all incoming multicast traffic and it's thrown away. And because the GhostCast code is just awful, if multicast stops it just hangs and can't recover anything. I tried dozens of things to work around this over several years after being forced to use multicast for deployment file transfers, and nothing worked.
At the end, the only thing that stopped customers having their file transfers fail after deploying a machine was simply not using multicast within the first few minutes of boot, and so when the management system is setting up a file transfer to the clients, if the client is within a time window (five minutes? something like that) of its last boot then it says "no thanks, that's just not going to work" and forces unicast instead.
Using AutoInstall won't change any of this, since regular file transfer and AI package transfer is exactly the same code in the management system.
Unfortunately I can't suggest what might work better for you, without knowing a whole lot more about your environment and being able to see the process work from end to end in your context.