I was recently working on a PowerShell Script that used Excel COM objects to pull data from remote computers put it into a spreadsheet. I finished up the script and tested it under my own account and got the result I was looking for—the data was pulled from the remote computers, an Excel spreadsheet was created and saved to a network share, and an email was sent out with the spreadsheet as an attachment.
Pleased with the script, I set it up as a Scheduled Task and set it to run under the credentials of an existing service account. When I manually ran the scheduled task, however, the script would not run. I tried using my own account for the scheduled task and it still would not run. I was using some formatting in Excel that would have been lost if I went with a CSV file and having to remember to manually run the task at the scheduled interval while I was logged in would not have been the best solution, so I decided to look for a solution rather than re-write the code.
After some digging, I discovered PowerShell scripts that use Excel COM objects—and presumably other COM objects—that run while a user is not logged in require the SystemProfile have a Desktop folder in order to run as scheduled tasks. The folder, however, does not exist under the C:\Users directory as you might expect. Instead, it is located at:
C:\Windows\System32\config\systemprofile\Desktop
*AND*
C:\Windows\SysWOW64\config\systemprofile\Desktop
The empty “Desktop” directory itself needs to be created and nothing more—no special permissions or registry hacks. In the case of a 32-bit OS, only the first directory needs to be created. In the case of a 64-bit OS, *both* directories need to be created. In my case, I was on a 64-bit OS and the directory in System32 existed but the directory in SysWOW64 did not. Once I created the missing directory I was able to use the original service account to successfully run the scheduled task whether or not it was logged in to the system.