TS, COM and environment variable corruption

I am launching a batch script that sets a load of environment variables, and then starts a java process, and this uses COM to start an instance of excel. The environment variables in my excel instance are clipped and some are missing altogether. At first I thought I was hitting some windows limit, but it turns out that running this same script logged directly into the server (ie with a keyboard and monitor) works perfectly

It appears terminal services is somehow interfering with COM in a strange way... Is there a solution to this? (I am using win 2000 sp4
Thanks
Tony

What program are you using to set the environment variables? I'm assuming you know that the normal SET command only works for the current instance of cmd.exe when run on an NT based OS

There's a resource kit utility to facilitate this

Patrick Rous
Microsoft MVP - Terminal Serve
http://www.workthin.co

----- TonyP wrote: ----

I am launching a batch script that sets a load of environment variables, and then starts a java process, and this uses COM to start an instance of excel. The environment variables in my excel instance are clipped and some are missing altogether. At first I thought I was hitting some windows limit, but it turns out that running this same script logged directly into the server (ie with a keyboard and monitor) works perfectly

It appears terminal services is somehow interfering with COM in a strange way... Is there a solution to this? (I am using win 2000 sp4
Thanks
Tony

Yes I am using the SET command, and am deliberately exploiting the fact that the environment can be changed in one instance of cmd.exe. The whole script works fine on my normal desktop, and on the server when logged directly into it. It just doesn't work when logged in via Terminal Services

I am invoking an instance of excel via COM, and excel (excel 2000) is recieving a corrupted environment. This issue only arrises when using TS. A modified script that launches excel directly still manages to run my program (the needs the environment to get dlls and files), so I am guessing the issue is to do with TS and COM

My current workaround is to use Daimeware instead of TS, but TS is a lot smoother so it would be nice to be able to log in via TS

A minimal test case of the bug is to log into a machine with TS, and run a script that sets some dummy variable. Then launch excel (preferably via COM - I have noticed some corruption of a long PATH variable without COM although it doesn't stop my program from working). Then in excel, go into the visual basic editor and open the immediate window, and type shell "cmd.exe". Then in that window type SET to print out all the environment. There may be an easier way to get the environment from within VB, but in any case that should show the corruption. Please tell me if you manage to reproduce this..
Tony