Using VBS to open Excel spreadsheet with write access

Hi @Rick Crosby ,

Please let me know how the tests suggested by Marcin go, particularly whether the task works with “Run only when user is logged on.”

If the issue persists, please share the workbook’s storage location (local drive, network share) the ReadOnly check result, and any error message from the macro or save operation. These details will help me narrow down the cause.

Thank you.

Considering that Excel successfully opens the correct workbook, you might want to focus on the difference between the interactive session and the Task Scheduler session rather than the file path.

Test by changing the task temporarily from "Run whether user is logged on or not" to "Run only when user is logged on." If the workbook then opens normally and the macros work, that indicates the problem is the noninteractive Task Scheduler session. Excel desktop automation can behave differently when launched without an interactive Windows desktop, particularly with the user's Office profile, HKEY_CURRENT_USER, temporary folders, and file locking.

Also verify that the task is running under exactly the same Windows account that you use when manually running the VBS. On the General tab, enable "Run with highest privileges." This does not automatically grant file permissions, so the account must also have Modify/Write permissions on the folder containing the workbook. Excel needs to create its temporary lock file there.

I would also populate Task Scheduler's "Start in (optional)" field with the folder containing the VBS/workbook, without quotation marks. This eliminates differences in the working directory between manual execution and Task Scheduler.

You can confirm what Excel is actually doing by checking the workbook immediately after opening it:

Set objWorkbook = objExcel.Workbooks.Open(WkbMain, False, False)
WScript.Echo "ReadOnly = " & objWorkbook.ReadOnly

If this reports True only when the task runs, then the VBS is not requesting read-only mode. Excel is choosing read-only because it cannot obtain the required write/lock access in that execution environment.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin