TM1 Forum

I have a simple VB script that, among other things, starts Excel, opens a spreadsheet and runs a macro within it. It works fine when I run it on the server manually, either by simply double clicking on it or invoking with either cmd /c or cscript.exe from the command line. However when called from a TI process with ExecuteCommand, the call to the Application.Run method throws a 424 Object Required runtime error. Everything else in the script works fine including several other method calls on the Excel application object.

I can run it fine as the user the TM1 service runs as so doesn't appear to be a permissions issue. I'm sure I'm missing something fundamental but don't understand why it fails when called from TI when my ad hoc testing works and would appreciate any suggestions. The server in question is running win 2008 R2, 64 bit 9.5.2 and Excel 2010.

OK, I was rather stupidly looking at the wrong problem.

The underlying issue is really that my script is failing to open the spreadsheet containing the macro when running from TI.
The file does exist. The file isn't being used by another program nor are there any workbooks open as far as I can tell. I've tried using a unc path (grasping at straws) but that doesn't work either. I know this is really a VB issue but I'm just trying to understand how the runtime environment changes when I run my script from TI rather than manually.

Might be seeing a Windows thing? Is that a mapped drive ( or fileshare)? TM1 services running under an account that would have access to the UNC (mapped drive won't work with a service account)?

dkleist wrote:Might be seeing a Windows thing? Is that a mapped drive ( or fileshare)? TM1 services running under an account that would have access to the UNC (mapped drive won't work with a service account)?

Thanks but that is the real drive on the server, not a mapped one. My ExecuteCommand call uses exactly the same path to run the script and does work.

The only difference -- that I can think of, at least -- between opening an Excel sheet from TI and doing it manually is the Windows user context.

TI runs as the user under which the TM1 Windows service is set up to run. If this is not you, that user might have different rights.

For instance, there are limitations on what interactions the SYSTEM account can have with the desktop. If you were running your TM1 service as SYSTEM, it probably could not open an Excel file.

It's hard to suggest anything further without more information, but I'd look at security first.

Lazarus wrote:The only difference -- that I can think of, at least -- between opening an Excel sheet from TI and doing it manually is the Windows user context.

TI runs as the user under which the TM1 Windows service is set up to run. If this is not you, that user might have different rights.

For instance, there are limitations on what interactions the SYSTEM account can have with the desktop. If you were running your TM1 service as SYSTEM, it probably could not open an Excel file.

It's hard to suggest anything further without more information, but I'd look at security first.

Thanks for the suggestion but the account under which the TM1 service was running did have necessary rights.

I've managed to resolve this finally. The solution was to create the folder C:\Windows\SysWOW64\config\systemprofile\desktop as mentioned here:

http://forums.techarena.in/windows-security/1297117.htm

I confess, I'm not entirely sure why this works but I haven't had any problems since.