If you are using Windows Vista or newer, then it may be due to the new security implemented by Microsoft. This issue affects all applications and is not a bug.
If your profile uses a network drive mapped/assigned to a drive letter (a drive on another computer that is available over the network and you've assigned it to a drive letter on your computer) then you may receive an error saying the drive does not exist when the profile is run in a schedule. This happens because such mapped drive letters are not re-assigned automatically (assuming you used the option to Reconnect On Login or equivalent) until you log in to Windows via the console (manually).
'Logging in as a batch job' (which is how Windows Scheduled Tasks work) does not re-create network drive mappings, even for the same user. If the Scheduled Task runs when the user is also logged-in via the console, it may work via Schedule also (reports vary...), but is virtually certain not to work via Schedule if that same user is not also logged-in via the console.
To avoid this, either login to Windows on reboot or use a UNC path instead of a drive letter, e.g. \\server\share\folder\. UNC stands for Universal Naming convention, and it lets you use server and folder names instead of drive letters to access the destination drive. For example, setting the destination to \\2brightsparks_corp\backups\franks_backup\ would eliminate the problem associated with referring to that destination as drive "M:". Of course, the destination folder must be defined as "shared".