>>>>It has dependency on VC++ runtime library msvcr71.dll and msvcp71.dll
>>>>
>>>>>Any guesses why I would be getting the following error message?
>>>>>
>>>>>Library file z:\applications\programs 9.0\vfpcompression.fll is invalid.
>>>>>
>>>>>What's interesting here is that when I use Citrix to connect to the server, I can use that fll without any problems; however, the background task running on that server fails with the message above.
>>>>>
>>>>>Thanks
>>>
>>>The fll and both of those dlls are all in the same directory (which is the current directory)
>>
>>Unless z: is a physical drive local to the machine running the scheduled task, try using a UNC instead.
>>
>>Make sure the account under which the scheduled task runs has sufficient privileges.
>>
>>I have seen some weird effects with the working directory setting in scheduled tasks. I just found some related info at http://superuser.com/questions/622507/windows-task-scheduler-wont-run-file-on-non-system-drive .
>
>Most interesting. Using the UNC would be necessary ONLY for the case of using Set Library To?

I was actually thinking about the parameters and settings you use in the scheduled task. But, for best reliability you may need it in your VFP code as well.

The idea is that the scheduled task effectively logs on as another session. Unless drive z: is local and physical or every logon is forced to run a logon script that maps network drive letter z:, then anything in that session that tries to reference z: may fail. It's just good practice to get used to using UNCs for anything that may require being scheduled.

>The scheduled tasks have been running for years with no other problems (and never using UNCs).

On Server 2012? Is it possible you're starting to see these problems because you're running them for the first time on Server 2012?

>I also don't know what "sufficient privileges" means in this case.

Well, for a start try admin privileges for all volumes/folders you need. But based on the above link that may not be enough, you may need to explicitly allow access. I haven't messed around enough with Server 2012 to know for sure, you may need to do some tests.