InstallAware

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.

Hi, Craig!

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

Thanks in advance!

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.

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.

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!

Craig Daniel wrote: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