Opening Excel Workbook Fails when run from Scheduled Task on Windows Server 2008 Rw RRS feed

  • Question

  • Hi,

    I have a little vbs script that instantiates the Excel.Application object and then opens a work book to perform some tasks on it. The script runs fine when run from the command line. When I attempt to run it as a scheduled task (it is supposed to update data that is pulled from a SQL Server at regular intervals), it fails with the following error:

    Microsoft Office Excel cannot access the file 'c:\test\SampleWorkbook.xlsm'. There are several possible reasons: .....

    The file does exist. The path reported in the error is correct. The account under which the task is running is the same account I use to run it from the command line. User Account Control is not enabled, and the task is set up to run with highest privileges. When I run the same script through the Task Scheduler from a Windows Server 2003 machine, it works without issue.

    I was just wondering if somebody on this forum has run into a similar issue in connection with Windows Server 2008 R2 and figured out what the magic trick is to make it work. I'm sure it is rights related, but I haven't quite figured out what which rights are missing.

    Thanks in advance for any advice you may have.


    Tuesday, December 7, 2010 6:35 PM

All replies

  • Are you running the the command line from a "SERVER" or from your PC?  The server will have a c:\ drive as well as a local PC.  I would like to see the complete command line that you are using.  I wouldn't think you have Excel installed on the Server.  So I suspect that the command line is actaully using the excel program on a local PC in the c:\Program File" folder.  Somehow the server is referencing a PC drive (not on the server) on a client PC.  The C:\ drive also must be referenced on the Client PC or the XLS file must be located on the server c:\ drive.
    • Marked as answer by Bessie Zhao Wednesday, December 15, 2010 7:48 AM
    • Unmarked as answer by Gerhardo Friday, January 7, 2011 4:23 PM
    Tuesday, December 7, 2010 7:43 PM
  • No. This particular server does have Excel installed and it wasn't referencing some file on a different machine. Below is a simple way to dupe it. Create an excel spreadsheet, and put a macro in it. Save it and then run the macro through the script on Windows Server 2008 R2. It works fine. As soon as you try to run a scheduled task that basically calls the vbscript, it fails when opening the work book.

    When I run the same script on Windows Server 2003 through a scheduled task, it works fine.



    contents of vbscript file


    set xlapp = CreateObject("Excel.Application")
    set xlBook = xlapp.Application.Workbooks.Open(fileName) 

    xlapp.Run "UpdateDataSources"


    Friday, January 7, 2011 4:31 PM
  • I wondering if the problem is with the file extension (XLS vs XLSM).  Do you get any errors.  I would check on the server the Event Viewer for any error message at the time you scheduled the task.


    You also can indlude the servername in the createobject

    Set xlApp = CreateObject("Excel.Application", "MyServer")

    You may be having problems with the version of excel because your file is an XLS.  Creatobject defaults to the version of excel installed on the PC.  Try specifying Version 11 which supports XLS files.

    set xlapp = CreateObject("Excel.Application.11")



    Friday, January 7, 2011 5:26 PM
  • I'm finding this same issue happen to me too. I'm not too familiar with Excel Macros. Is there a workaround to get my Script task, which accesses an Excel spreadsheet, to work, while i'm executing the SSIS package through Task Scheduler?
    Wednesday, April 6, 2011 4:52 PM
  • You probably would have to build your application using  visual Studio (C++, C#, VBnet) using the Office Interop APIs.  This will allow you to read office appliations without having the licenses running on the server.  The other method would be to run your from a client PC with office installed and login as an administrator to the server.
    Wednesday, April 6, 2011 6:35 PM
  • My server has Excel installed in it and am running the Task as under a System Admin login. I just found that if i choose the Platform as Windows Server 2003, the task does not fail and executes successfully. I'm seeing the problem when the task runs on Windows Server 2008 R2 platform
    Wednesday, April 6, 2011 11:16 PM
  • For what it's worth, I ran into this same issue just now but do not currently have the time to look into it further.

    i find that with Windows Server 2008, there have been some additional restrictions created when binding to objects when running a scheduled task (in this case, Excel.Application). If you play around with the DCOM config / WMI security / local security policy, you may be able to find the exact permission setting to open up for the Service Batch Account that you are using.


    Does the script run successfully when you run the scheduled task as an Administrator?

    Thursday, April 14, 2011 2:18 PM
  • Hi,

    Have anyone found a solution to this? I have the same symptom on a Windows 2008 R2 server where the program works as expected but when run from a schedule task the following code (last line) fails:

        Dim xlApp As New Excel.Application
        Dim xlWrkbook As Excel.Workbook
        Dim xlWrksheet As Excel.Worksheet
        Dim objCurrentCulture As System.Globalization.CultureInfo
        'ställ om kulturen
        objCurrentCulture = System.Threading.Thread.CurrentThread.CurrentCulture
          System.Threading.Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.CreateSpecificCulture("en-US")
          xlApp.Visible = False
          xlApp.DisplayAlerts = False
          xlWrkbook = xlApp.Workbooks.Add(strInputFilePath)

     I do not understand what is causing this. The schedule task runs with highest privileges and the error message.

    Thanks in advance!
    Best regards

    Thursday, April 21, 2011 2:09 PM
  • Hi Gregory,

    I ran the task when i was logged in as the administrator. When i set the task as Window 2003 setting, it works, but inconistently. It is just not reliable and i'm unable to figure out why!

    Thursday, April 28, 2011 9:50 PM
  • Hi, I've also run into this issue on Windows 2008 R2 using Excel 2010 (x64).  Never had this problem before with Windows Server 2003.

    It appears to start Excel, but then the task just hangs (never ends).  I've confirmed that it's not a problem with the script (it runs successfully) and not a related to permissions.

    Like VloveSushi, when I set the task type to Windows 2003, it works inconsistently (I haven't been able to find a pattern).

    Any insight would be greatly appreciated.  Thanks.

    Friday, May 13, 2011 6:27 PM
  • Can you try using the OLEDB? See this  blog http://dougfinke.com/blog/?p=221


    Wednesday, May 18, 2011 3:40 PM
  • Even I have the same problem. when i try to open excel from the schedule task, it shows the status as running. The process is created in the taskmanager but the excel UI never shows up. Any clues?
    Friday, July 22, 2011 3:32 PM
  • Any news from the comunity on this? I'm suffering excatly from the same problem :-(

    Tuesday, September 13, 2011 7:42 PM
  • Googled arouond and found here the solution.



    Incredible, as I added the following directory c:\windows\syswow64\config\systemprofile\desktop it WORKED. Don't ask my why, seems to be something related to COM calls that faill if this directory is not existing.

    Thanks to gregarican for this solution

    • Proposed as answer by Swiss Scripter Tuesday, September 13, 2011 7:58 PM
    Tuesday, September 13, 2011 7:58 PM
  • Thanks for posting this solution, it also worked for me.

    I'm running a Powershell V2 script that does COM calls into an excel.application object, it was failing when invoked via a Scheduled Task on a Windows 2008 R2 x64 server until I created the directory 'c:\windows\syswow64\config\systemprofile\desktop'.

    Thanks again.

    Tuesday, November 8, 2011 7:14 AM
  • I worked for me also! Amazing!
    Monday, April 9, 2012 1:02 PM
  • Fixed the issue for me as well 


    Friday, June 29, 2012 8:16 PM
  • Me too,


    Thursday, August 16, 2012 3:43 PM
  • Damn!!!!!

    Fixed for me too........


    Friday, October 26, 2012 4:42 AM
  • Thank You!  Shocked.. adding a that folder and everything works now!
    Friday, December 14, 2012 8:53 PM
  • Also worked for me, thanks!
    Friday, January 25, 2013 11:58 PM
  • Hi Guys,
    I believe I have been struggling with the same, basic issue that is described in these posts.  However, the solution which seems to be working for everyone else is not working for me.  Perhaps, I am misunderstanding or incorrectly implementing it.  Can someone confirm, if I am correctly or incorrectly implementing the solution (aka the addition of the "c:\windows\syswow64\config\systemprofile\desktop" directory)??  thanks.
    More detail on my specific situation:
    1) I am attempting to schedule tasks in Task Scheduler which opens an excel spreadsheet at specific times each day on a Windows-based server.  Upon opening, the excel spreadsheet should automatically run a series of VBA macros (all of this works on my home PC).
    2) My server OS is Windows Server 2012.
    3) Once I have configured a task in the server Task Scheduler, it fails to launch excel at the time specified in the "trigger" tab. (I am using task configurations/settings identical to those in tasks I have created in the Task Scheduler on my home PC that run flawlessly).

    The "history" tab (on the server task) claims, after the specified trigger time, that "Task triggered on scheduler," "Task Engine recieved message to start task," "Task Started," "Created Task Process," "Action Started."    However, excel has not actually started and nothing else happens going forward.  
    4) Additionally, in a given new task, on the "general" tab, I am given 4 options:

       1.Windows Server 2012
       2.Windows 7, Windows Server 2008 R2
       3.Windows Vista, Windows Server 2008
       4.Windows Server 2003, Windows XP, Windows 2000
    As "VLoveSushi" mentioned, the task in question will launch excel (et al) succesfully according to my settings, if I configure the task with option 4 (Windows Server 2003).  However, If I configure the task with one of the first three options, the task fails to launch excel as I described above in detail #3.
    5)  After reading all the posts here, I decided to try the "c:\windows\syswow64\config\systemprofile\desktop" solution, which many of you said has worked for you.  To me, implementing that solution meant simply creating an empty folder called "desktop" with path "c:\windows\syswow64\config\systemprofile\" on my server.  Doing so hasn't appeared to solve anything, as I am still unable to configure tasks using option 1-3.  To this end,  was adding that directory, as I did, all I needed to do?  Was I supposed to associate that new directory to my server's Task Scheulder in some way?  
    Also, please keep in mind, while I am fairly savvy at writing VBA (and a little SQL) for Excel and Access, this is my first experience on a server.
    Thanks in advance for you help!

    Wednesday, January 30, 2013 4:59 AM
  • Hi,

    I am struggling with an issue similar to this post.

    I have create an windows application using C# code which uses Microsoft.Interop.Excel to create export data from database to excel. I have created a schedule task in Windows Server 2008 R2 to execute the same every morning at 6:30 AM.

    When I run the task manually, it works fine and creates the excel file, but the task fails at 6:30 AM every morning. 

    It seems like, I have to manually execute the task every day, after I manually execute the task, it works fine for the day, either I run manually or set some other time in the schedule task.

    Please let me know if you have came across any such issue.


    Abhijit Sil

    Wednesday, July 10, 2013 2:37 PM
  • Hi,

    i have the same problem. When i run a C# program which uses the Microsoft.Interop.Office.Excel manually on a Windows Server 2012 then it runs without errors. As scheduled task it creates at following code:

    catch (Exception ex)

    following error:

    Microsoft Office Excel cannot open or save any more documents because there is not enough available memory or disk space.

     • To make more memory available, close workbooks or programs you no longer need.

     • To free disk space, delete files you no longer need from the disk you are saving to

    I added also in the C# program a memory counter to see, how many memory is available at the time, when this error happens. Here the added code:

    ramCounter = new System.Diagnostics.PerformanceCounter("Memory", "Available MBytes");

    Here the result: Available Memory: 1128 MB

    So i think it should be enough to add a new empty Excel-Workbook.
    Strange, that Microsoft takes so long to solve that problem or at least to tell us normal users, what the workaround could be. Is Microsoft not looking in such forums? Where we have to put such problems?



    Friday, July 19, 2013 8:33 AM
  • The issue has to do with the way the default environmental settings are configured on the PC.  Did you try the fix that everybody else used?  I suspect the TEMP foler that windows is using for swap space isn't configured properly.  Try emptying the folder c:\windows\temp


    Friday, July 19, 2013 12:07 PM
  • Hi jdweng,

    i cleared the folder c:\windows\temp. The issue is still there.

    I suppose even if i start the program manually(and then is running correctly) windows server 2012 is using the same swap space.

    • Edited by elu Friday, July 19, 2013 1:55 PM addition
    Friday, July 19, 2013 1:51 PM
  • When you schedule th etask make sure you set the crendentials to a user account.  You may want to try as an administrator to see if that helps.  the problem has nothing to do with Excel, it has to do with the environmental settings that the task is running under.

    You may want to look at the website below to see if anything on the webpage helps.  I would look at the tuning issues that are related to the user accounts, environmental variables, and running tasks.



    Friday, July 19, 2013 5:22 PM
  • Same issue here.  One more variable in the equation, this scheduled task worked fine until we upgraded from Office 2007 to 2013.  The vbs script works fine if I run it manually but as a scheduled task, the job fails because it is unable to open the excel file only when run as a scheduled task.  I have everything set to run with elevated privs and run as an administrator account id.  As I said, this task worked fine until we upgraded to office 2013 on that system.
    Wednesday, July 24, 2013 3:15 PM
  • i found some other detail to my issue above:

    when i start the program an event is created in the event logger under "Microsoft Office Sessions":

    ID: 1, Application Name: Microsoft Office Excel, Application Version: 12.0.6665.5003, Microsoft Office Version: 12.0.6612.1000. This session lasted 26 seconds with 0 seconds of active time.  This session ended normally.

    So it seems, that the rights are enought to start Excel, but something is preventing to create a new Excel-workbook.

    Does someone know, how it is possible to inform a Microsoft Windows Server 2012 developer, to have an official statement about that problem?


    Monday, August 5, 2013 11:24 AM
  • Thanks!!!
    • Proposed as answer by JasonDWilson77 Monday, October 7, 2013 5:40 PM
    Tuesday, September 17, 2013 4:25 PM
  • Circling back to this after sometime as I see this is not marked as Answered.  I had to create this folder "c:\windows\syswow64\config\systemprofile\desktop " in both the syswow64 directory and the non-syswow64 directory to fix this issue.  Not sure both were necessary, but after the syswow64 was created my issue still existed, so I created the other one and the issue was resolved.  Thanks to everyone who posted on this!

    • Proposed as answer by FosterHardie Monday, December 9, 2013 7:19 PM
    Monday, October 7, 2013 5:40 PM
  • Go to Trust center settings in EXCEL (as the needed user) and deaktivate the standard settings, allow access through deactivation of all checkmarks.

    (and choose the first point of three available options below, and confirm witk OK.)

    • Edited by drapoel Tuesday, November 12, 2013 4:21 PM
    Tuesday, November 12, 2013 3:14 PM
  • Can I ask more about you program?  Are you writng macros in an excel workbook or are you writing a VS application.  It is easier for a VS application to pull data directly from the database than to use an intermediate excel file.

    I would first check the Event in Start - Administarative tools - Event viewer to see what error messages are bing generated.  Can you open the excel file manually to verify the excel file being generated is good.  This posting originally was started due to problems open an excel file in a service.  Your problem seems to be in generating an excel file in a service.  I would first make sure there is an excel license on the server and that a good excel file can be opened on the server.  Are you accessing the excel file on the server PC or through a network drive?

    Normally an excel file will not have an extension shown if excel insn't installed n the PC.  without excel installed the PC (or server) will not recognize the excel extensions.  I also suspect that the window explorer you are using has the setting "Hide extnesions for known file types" set so you aren't seen the xls extension.


    Tuesday, November 12, 2013 4:35 PM
  • To clarify, the "non-syswow64" is at C:\Windows\System32\config\systemprofile. Like Jason, c:\windows\syswow64\config\systemprofile\desktop did not do it, but adding a desktop to the System32 path did for Server 2008 R2 64bit and Office 2013 64bit.
    Monday, December 9, 2013 7:24 PM
  • i already have folder

    folder "c:\windows\syswow64\config\systemprofile\desktop "

    but still its not working


    Tuesday, December 10, 2013 5:52 AM
  • creating a folder inside c:\windows\syswow64\config\systemprofile\desktop  works fine..

    Great solution!

    Wednesday, May 21, 2014 3:49 PM
  • I've found same issue in Windows Server 2012 and the same strange solution (creating folder %windir%\syswow64\config\systemprofile\desktop) works for me too. Thanks.
    Saturday, May 24, 2014 10:59 PM
  • This is truly killing me ... trying to get it working on Windows Server 2012 without success.

    I desperately need to automate running Excel macros in a "headless" environment, that is non-interactive, non-GUI, etc.

    I can get it to work using Excel.Application COM, either via VBScript or Powershell, successfully on many other Windows systems  in our environment - Windows Server 2008 R2, Windows 7 (32-bit), etc.,  -BUT-

    The two servers we built out for running our automation process are Windows Server 2012 (SE) - and it just refuses to run on the 2012 servers - it gives the messages below from VBScript and PowerShell, respectively- 

    I have tried uninstalling and re-installing several different versions of Microsoft Excel (2007 Standard, 2010 Standard, 2010 Professional Plus, 32-bit vs. 64-bit, etc.), but it makes no difference.

    Would be extremely grateful if any one out there has had any success in running Excel automation on Server 2012 in a non-interactive environment that they could share.

    ( I have tried adding the "%windir%\syswow64\config\systemprofile\desktop" folder, which did fix the issue for me when testing on Windows Server 2008 R2, but sadly did not resolve it on Windows Server 2012 )


    [VBScript error msg]

    Z:\TestExcelMacro.vbs(35, 1) Microsoft Office Excel: Microsoft Office Excel cannot
    access the file 'Z:\TestExcelMacro.xlsm'. There are several possible reasons:

    • The file name or path does not exist.
    • The file is being used by another program.
    • The workbook you are trying to save has the same name as a currently open work

    [Powershell error msg]

    Exception calling "Add" with "0" argument(s): "Microsoft Office Excel cannot open or save any more documents because th
    ere is not enough available memory or disk space.
     To make more memory available, close workbooks or programs you no longer need.
     To free disk space, delete files you no longer need from the disk you are saving to."
        + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
        + FullyQualifiedErrorId : ComMethodTargetInvocation

    You cannot call a method on a null-valued expression.
        + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
        + FullyQualifiedErrorId : InvokeMethodOnNull

    Wednesday, July 23, 2014 5:28 PM
  • Googled arouond and found here the solution.



    Incredible, as I added the following directory c:\windows\syswow64\config\systemprofile\desktop it WORKED. Don't ask my why, seems to be something related to COM calls that faill if this directory is not existing.

    Thanks to gregarican for this solution

    Worked great, solved the problem
    Friday, August 15, 2014 7:47 PM
  • Same issue here.

    Old server, Server 2003/Office 2003.  Scheduled task worked great.  No issues.


    Server 2008 R2/Office 2010.  Scheduled task fails.  Lots of pissed off people

    I created the folder for both the System32 and SysWow64 directories and it doesnt work

    They want to know why it worked before and it doesnt work now and I have no answers for them except Microsoft changed something

    This is really frustrating 

    Warm Fuzzies!

    Wednesday, September 3, 2014 6:42 PM
  • Googled arouond and found here the solution.



    Incredible, as I added the following directory c:\windows\syswow64\config\systemprofile\desktop it WORKED. Don't ask my why, seems to be something related to COM calls that faill if this directory is not existing.

    Thanks to gregarican for this solution

    Worked great, solved the problem

    In this article, what exactly does he mean "You must allow it to run through console. You can reschedule the task and it would give you option to work on the same.?


    Warm Fuzzies!

    Wednesday, September 3, 2014 6:45 PM
  • Thanks FosterHardie !!!!

    After adding the folder "C:\Windows\System32\config\systemprofile\desktop", it worked fine.

    Tuesday, September 23, 2014 6:57 PM
  • Were you able to solve this issue? I'm having the exact same problem, after creating the 2 folders, it still did not work! Thanks in advance!
    Friday, February 6, 2015 11:06 PM
  • Just install office and use powershell to create an new COM object. Works great. If you don't want to install the full version I think the dev tools work the same. You can use powershell to manipulate the data however you want and it runs under a scheduled task just fine . Been using it to process new users from a export

    Warm Fuzzies!

    Saturday, February 7, 2015 1:05 AM
  • Can somebody please share the solution for this issue?

    I am facing similar issue with Windows 2012 R2 OS and Excel 2007 combination.

    I tried couple of things like Excel is able to Open an existing workbook on my system but fails to create a new Workbook as done by invoking the "Add" command. It fails with Error 800a03ec.

    I tried creating the two folders i.e. C:\Windows\SysWOW64\config\systemprofile\Desktop & C:\Windows\system32\config\systemprofile\Desktop, but could not get it working.

    Tuesday, April 7, 2015 7:46 AM
  • I am having a similar issue:  I have a c# application that builds an Excel (.xlsx) file.  I use Microsoft.Office.Interop.Excel to accompish this.  I used to run the application from scheduled Tasks on a Windows Server 2003.  No problems.  My company recently upgraded the server to Windows Server 2008.  In my case, Excel is installed on the server.  Now the application will work fine from a comand prompt on the new server, but it fails when run from the Task Scheduler.  Specifically, I have observed the following statements failng (throwing an exception):

    xl.SheetsInNewWorkbook = 1;  [ where xl is the name of my Application instance]

    workbook.Save(true, "path_to_save.xlsx", Type.Missing.Value); 

    I also noticed that xl.Visible=true fails.  This is not a big deal.  I turn this off when running from scheduled tasks anyway. I just forgot to do this.  I mention it only because our old Windows Server 2003 does not balk at this.

    I have set up the Task Scheduler to run this application from a Domain user account that is a member of the Server's Administrators group, have cecked Run whether user is logged on or not (with Do not store password unchecked).  I have also checked Run with highest privleges.

    • Edited by Mark9638 Friday, May 22, 2015 4:06 PM
    Friday, May 22, 2015 3:29 PM
  • Hi Mark9638,

    try to enter with the Domain user account with which the scheduled task runs and start it manually. Probably you see more. Could be that it has to do with the missing right to save the workbook on a specific path, which you have to change in the excel under the excel options for trustworthy places to save.




    Tuesday, May 26, 2015 6:37 AM
  • This worked for me: 

    Create these two directories:




    Wednesday, May 27, 2015 5:19 PM
  • After some searching I found this article and at first didn't believe it would work. Just creating an empty folder!! But I did and the scheduled tasks run smoothly. If this is so important for running scheduled tasks why didn't Microsoft already create this folder "desktop" or at least show some intelligent error message to point you in the right direction like "You are missing folder desktop on location ..."

    Thanks for finding this

    Wednesday, June 17, 2015 9:48 AM
  • I have had a same issue on my Server 2012. It worked on Server 2008 after adding a desktop top folder but not in 2012. Has anyone found a solution, please post it here or email at hungtdao@yahoo.com. Thanks in advance.
    Wednesday, July 1, 2015 7:32 PM
  • I managed to solve my issue by following the methods outlined in below link :

    In additions to these 2 folders :

    C:\Windows\System32\config\systemprofile\Desktop & C:\Windows\sysWOW64\config\systemprofile\Desktop

    Add 2 more folders  :



    • Proposed as answer by M.Henning Monday, March 7, 2016 12:09 PM
    Friday, July 3, 2015 4:53 AM
  • I have had a same issue on my Server 2012. It worked on Server 2008 after adding a desktop top folder but not in 2012. Has anyone found a solution, please post it here or email at....Thanks in advance.

    It is amazing that this issue has been around for five years and still no solution that works for everyone. I have this same issue- just upgraded to Server 2012 and the program we ran as a scheduled task in Server 2003 fails. I can run it fine if I run it manually. The program I have problems with calls an Excel spreadsheet, then merges it with others and uses Adobe Distiller to create a PDF. I get the "filename or path does not exist" error. Adding the two new desktop folders in syswow64 and system 32 just changed the error from filename does not exist to "no printers installed". Even though the Adobe PDF printer is installed. I just can't believe it's this difficult to identify the security change from Server 2003 to 2012 that causes this. I'm pulling what little hair I have left out!
    Tuesday, September 1, 2015 7:59 PM
  • With Windows Server 2012 R2 and Excel 2010 32bit THIS helped me. Thanks a lot!!!!
    Thursday, November 5, 2015 12:31 PM
  • Creating the folders described above isn't enough. You have to give your account (the account the task is running under) permissions to them.

    Here are detailed instructions of all the permissions needed. This worked for me in Windows 2012:


    • Edited by cybersaga Friday, April 22, 2016 3:14 PM
    Friday, April 22, 2016 3:13 PM
  • Did you find the solution ?
    Thursday, May 5, 2016 9:32 PM
  • Did you find the solution ? i'm having the same issue.
    Thursday, May 5, 2016 9:33 PM
  • Please tell me how did you resolve it.
    Thursday, May 5, 2016 9:36 PM
  • Please don't post the same thing over and over. Everyone subscribed to this thread gets an email after every post. I got three emails.

    In the post just before yours, I explained how I solved it.

    Thursday, May 5, 2016 9:41 PM
  • cybersaga,

    Sorry you keep getting emails but this is still not resolved. I have tried everything up to this point that was stated above and it is not working. I agree with a previous statement that it have been since 2011 and this is still not resolved. 

    Any help?

    Monday, May 16, 2016 8:23 PM
  • Follow the instructions at http://troyvssharepoint.blogspot.ca/2012/07/stumbled-upon-interesting-one-today.html

    You need to:

    Give permissions in Component Services

    Create the Desktop folder

    Grant permissions on 3 folders

    Tuesday, May 17, 2016 12:53 PM
  • Awesome solution worked for me on Server 2012.

    Thank you,

    Thursday, June 23, 2016 8:57 PM
  • Hi Swiss Scripter,

    Creating a desktop folder under below location worked for me:


    Thank you so much for posting..:-)



    Wednesday, August 24, 2016 6:14 PM
  • Excellent! This worked for 2012.


    Wednesday, September 28, 2016 3:57 PM
  • Oh my.... 7 years after Swiss scripter has posted the solution and this sill happens (and works).

    Thank you,


    Tuesday, December 20, 2016 10:00 PM
  • I created the folders as well and it did not solve my problem.  I also had to edit the scheduled task and check the "Run with highest privileges" box.  The script successfully ran after that in the Windows 2012 Task Scheduler.
    Wednesday, January 11, 2017 4:57 PM
  • Wow. This is incredible that it still works after all these years. The link in this article doesn't work anymore.  I had to write about it:


    Monday, March 27, 2017 7:49 PM
  • Great ! This saved me! Almost six years and still relevant! Thanks a lot!

    -- emnavarro02

    Monday, May 15, 2017 1:17 PM
  • I have the same problem with server 2012r2 and I never manage to get it to work. Instead, I try to work on windows 10. By adding these four folders, scheduled task creates excel and saves excel file on windows 10. But then the creators edition update (or some other monthly updates, these updates always remove your changes, very annoying) erases it all and I have to add the four folders back for it to work again. Hopefully this helps others too.

    • Edited by George_2011 Thursday, July 27, 2017 4:42 PM
    Thursday, July 27, 2017 4:41 PM
  • Thanks!!!! 

    Also using server 2012 and adding these two additional folders worked

    Friday, September 15, 2017 7:10 PM
  • 10th-Dec-2017 and this solution still works :)

    Saturday, December 9, 2017 9:15 PM
  • These two folders are still needed in Windows 10 in February 2018 and works a treat! Too bad I spent 3 hours yesterday debugging my powershell code, only to find a missing system folder fixes the problem!

    The first one (below) existed in Windows 10 but NOT the second folder. Once that was created, my powershell script now opens Excel files when called from a scheduled task.


    • Edited by gpf nz Monday, February 26, 2018 6:12 PM
    Monday, February 26, 2018 6:08 PM
  • On Windows Server 2016 Standard (64bit), the problem still exists. Creating the Folder C:\Windows\sysWOW64\config\systemprofile\Desktop still fixes the problem. Was a long journey till i found this page, thank you!

    Thursday, March 1, 2018 9:51 AM
  • Follow below steps

    Go to --> Control Panel --> Administrative Tools --> Component Services --> Computer --> My Computer --> DCOM Config --> Microsoft Excel Application --> Properties --> Identity and select "The interactive user" option.

    Friday, July 20, 2018 7:00 AM
  • Sloved problem for myself.


    • Windows Server 2012 R2 & Excel 2016;
    • Run .vbs script that uses Excel.Application COM and opens network (shared) file.
    • This needs to be done as a scheduled task running under unprivileged user while user is not logged on.


    • Install 32-bit Excel
    • Create a security group for 'scheduled task' users (we use separate server for running scheduled jobs, so we have one) - Let's name it 'SchTskUsers'
    • Grant SchTskUsers 'logon as batch job' permission: GPEDIT.MSC -> Computer > Windows > Security > Local > User > Logon as batch job;
    • Grant SchTskUsers run components permission : c:\windows\syswow64\dcomcnfg.exe, right click [My Computer], select tab [COM Security], in [Launch and activation permissions] group press [Edit default] and add SchTskUsers with [Local launch, Local Activation] permissions.
      NOTE: In this example I am granting this permission for all applications. That is not too secure, so it is better to grant it per-application, possibly!
    • On this step, we can run Excel from unprivileged batch user, but we can not open files if Excel was run from scheduled task :-( . I think It's a bug: in this way, Excel.exe tries to write to %WINDIR%\SysWOW64\Config\systemprofile\AppData\Local istead of %USERPROFILE%, and, because user who runs Excel does not have any permissions for this folder (He is not Administrator), this fails.
    • Make 'Desktop' folders in System profile. I am not sure it is required in Excel 2016, but, as Internet says, Excel 2007 made an error because of this folder was missing.
    mkdir "%WINDIR%\SysWOW64\Config\systemprofile\desktop"
    mkdir "%WINDIR%\System32\Config\systemprofile\desktop"
    • Grant full control permissions on System profile for Scheduled Task group:

    icacls "%WINDIR%\SysWOW64\Config\systemprofile" /grant SchTskUsers:(OI)(CI)F icacls "%WINDIR%\System32\Config\systemprofile" /grant SchTskUsers:(OI)(CI)F

    NOTE Possibly there is more granular way to grant permissions, or there is a way to make Excel not use system profile. I do not know it.

    • Edited by FilimoniC Monday, August 13, 2018 1:39 PM
    Monday, August 13, 2018 1:27 PM
  • This is the one!! I cannot tell you how many different solutions I have seen on the web today, asking me to do all sorts of strange things! This was the one which finally fixed it for me!
    Thursday, September 6, 2018 3:08 PM
  • Wow, this worked for me too. Thanks to gregarican for sharing his knowledge about it!
    Sunday, October 14, 2018 1:33 PM
  • I have a MS Access application that could be manually run without issue, but when scheduled in Task Scheduler it would return the error: Object variable or With block variable not set.  I was so relieved to find Swiss Scripter's solution, all I had to do was add a "desktop" folder to this existing path on our 2016 server: c:\windows\syswow64\config\systemprofile\desktop.  No more problem! : )

    David Rowland

    Friday, October 19, 2018 1:11 PM
  • 1297117.htm isn't working anymore.

    Anyway, adding the desktop folder solved my problem and made my day !

    Thanks for sharing.

    Best Regards

    Wednesday, May 1, 2019 8:07 PM
  • Yes, adding BOTH of these listed paths worked perfectly for me as well, Thanks to all!!!

    Oracle DBA

    Tuesday, May 14, 2019 5:53 PM
  • this worked for me.thanks


    Friday, December 13, 2019 6:15 AM
  • Hi..

    Creating Desktop folder in system32 and syswow64 worked for me on windows 10 when the UAC level is low. But as soon as when i turn on my UAC to high again it started failing.. 

    Did any one really tried by turning UAC to high?



    Wednesday, June 10, 2020 1:23 PM