Windows Directory wrong on Terminal Server

[Craig Daniel]

I thought I would post this in case it can help someone else, or perhaps the folks at IA will make a change.

In a script, if you call Get Common Folder Location System->Windows Directory, I think most people would except C:\\WINDOWS or C:\\WINNT, or whatever it happens to be. On Server 2003 running Terminal Services, WINDIR will come out wrong. What you actually get is C:\\Documents and Settings\\username\\WINDOWS. This is decidedly unhelpful in an installer when we're trying to look in, for example, the WinSxS folder.

Previously I was told here that IA uses the windows API function GetWindowsDirectory. The Microsoft documentation says very clearly that this is what will happen on a terminal server. It also refers us to the function GetSystemWindowsDirectory which will always return the real windows directory (not the per-user one).

I respectfully suggest that InstallAware should be using GetSystemWindowsDirectory if one specifies the "Get for all users" option so that we always get the right folder even on a terminal server. As it is, the work-around is annoying because we have to require the user to go into Add/Remove programs and run our installer via Add New Programs. That puts the terminal server in "install mode", and the GetWindowsDirectory function works as expected.

[ALive]

Hi, Craig!

Good suggestion! Agree with your request.
Michael, is it possible to implement this?

Thanks in advance!

[MichaelNesmith]

Interesting discussion. First, I'll quote MSDN:

Windows NT 4.0 Terminal Server Edition: To retrieve the shared Windows directory, call GetSystemDirectory and trim the "System32" element from the end of the returned path.
Windows Me/98/95: Although GetSystemWindowsDirectory is not implemented in Windows Me/98/95, GetSystemWindowsDirectoryW is supported by the Microsoft Layer for Unicode.

Next, per Microsoft spec, it is necessary to actually put terminal server in installation mode before running a setup. This is by design per Microsoft.

So:

1. Since the API is not available in down-level platforms,
2. Since TS design requires entry into installation mode a priori,
3. And since a workaround is already available ($WINSYSDIR$),

R&D will probably be not honoring this request.

[Craig Daniel]

Good points all, Michael.

Unfortunately, the work-around of trimming the System32 part off the path is not helpful because scripts we include (like the one that checks for the VC++ runtime) do not use that work-around and hence they will have the wrong path if I don't put the TS in install mode.

So the lesson here is, always put your Terminal Server in install mode even though it may appear to work without doing so.

[MichaelNesmith]

Remember, you have the source of all your runtime installer scripts with InstallAware, so you could adapt them too!

That said, I just remembered there's also a free terminal server plug-in. I think it lets you programmatically swap in and out of TS modes. Check the plug-ins forum, that could come in very handy!

[JonRobertson2]

require the user to go into Add/Remove programs and run our installer via Add New Programs. That puts the terminal server in "install mode", and the GetWindowsDirectory function works as expected.

Craig,
As I recall, this has always been a requirement when installing in Terminal Services or Citrix (which sits on top of Terminal Services). Our application has been TS/Citrix compatible for ten years, and that was a requirement back then.

However, I'm going to check out the plug-in that Michael mentioned. Best case, we can write MSICode that will put the server in "install" mode automatically. At a minimum, it would be nice to detect TS, determine the server is not in "install" mode, and halt the install, informing the user that the install must be done via Add/Remove Programs.

Citrix had a command-line utility that let you change the user mode. I don't know if TS has this or not, as I've just used Add/Remove Programs.

Jon