Yesterday I came across a really strange issue with one of our clients.

An automated routine is generating reports in Excel format and sends those out via email. The job queue entry is now reporting an error when executing the job.

“This message is for C/AL programmers: The call to member SaveAs failed. Microsoft Excel returned the following message: SaveAs method of Workbook class failed”

Background:

They migrated to new server environment and the Dynamics NAV Application Server (NAS) is now running on a Windows Server 2008 R2 (x64). One of the job queue entries that are executed via the NAS is creating Excel files that will be sent as an Email attachment. The Excel version is Excel 2013.

The generation of the Excel file is based on the Excel Buffer in NAV. To use it as an automation without user interaction a function was added to the Excel Buffer table to assist. This is also the place where the last interaction with Excel happens before the error is generated.

CloseBook(WorkBookPath : Text[250])
//+++JIG1.10
IF NOT EXISTS(WorkBookPath) THEN BEGIN
  XlWrkBk.SaveAs(WorkBookPath);
  XlWrkBk.Close(FALSE);
  XlApp.Quit;
END;
CLEAR(XlApp);
//---JIG1.10

Before the migration the job was running fine. Even executing the job manually is working as expected on the new server. The problem occurs only if the NAS comes into play and executes the Job Queue entry.

This Issue is not related to permissions on the server or in NAV itself. I compared the details with the user I was using for routine the job manually and tested it out.

After a while of research I came across a change in the folder structure of windows server operating system. It seems that Excel is looking for specific folder when it is executed without a User Interface.

The folder name is simply ‘Desktop’.

For 64 bit environments the folder path is:

C:\Windows\SysWOW64\config\systemprofile\Desktop

For 32 bit it is:

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

Creating this empty folder prevents NAS/Excel from generating the error.