Software Deployment

I've never heard of this "random" environment variable, sounds to me it's only a user variable which is not provided for the account you are installing with

The variable has been available since Windows 2000 so it's generally available on the Windows platform. The random number is generated by cmd.exe which may be why it's not available to Windows installer. I doubt it has anything to do with the account running the installer. Typing Set at the command prompt will not show the random variable which may bew why e.g. SystemDrive does work but not random.

Fredrik,

I'm not sure if this is a pure environment variable. I did a little test on my machine and while a command of echo %random% gives me random numbers in the command shell, the VBS code oSh.ExpandEnvironmentStrings("%random%") does not recognise it as an environment variable.

Some further research seems to indicate that these are what's called discrete value variables, and while these do look like env. variables, not all of them really are (%cd% is another example of this) -source-

PJ

wow, you really learn something new every day :) thanks
So the question: do you really need to store the log-file in the root of the systemdrive?
The size of the log-file will depend on the "size" (amount of entries) of the package (msi) and the type of detailed logging.
ORIGINAL: frede

The variable has been available since Windows 2000 so it's generally available on the Windows platform. The random number is generated by cmd.exe which may be why it's not available to Windows installer. I doubt it has anything to do with the account running the installer. Typing Set at the command prompt will not show the random variable which may bew why e.g. SystemDrive does work but not random.

Possibly due to %RANDOM% is dos only. Open a cmd box and it works (tested on xp), you can also use "cmd /c" in the beginning instead.

pjgeutjens: I think you're right. The following vbs code
set WshShell = CreateObject("WScript.Shell")
WScript.Echo WshShell.ExpandEnvironmentStrings("%SystemRoot%")
WScript.Echo WshShell.ExpandEnvironmentStrings("%random%")

Gives the output

C:\Windows
%random%

so it's definitely not recognized as a "true" env. variable.

AngelD: The directory is not important but it must be a well-known directory so it's easy for anyone to find it. Most of our users would never be able to locate a random log file stored in the temp. folder which is why we force the log to be created in the root with a set name. I also want to log everything about the installation cause it really helps when something goes wrong. We used to have the /L*v option to log everything but the problem is that if the installation fails and the user re-runs the installation the log file is rewritten and we cannot determine the initial cause for an error since the second time the installation is run it might not give the same error. When using /L +v to add to the same log file the log file is huge after the installation has run a few times which is really inconvenient when sending via email. This is why I'd like to create a unique file name for every installation. I could then just ask the users to sort by date to get the most recent file. I cannot use the %time% or %date% variables since they contain illegal file name characters.

Any ideas how to solve this is greatly appreciated.
/Fredrik

It sounds like the easiest way would be to turn on the Windows Installer Logging policy and let the service generate the log, it will be located in the %temp% folder of the user whom executed the msi with a random name starting with MSIxxxxx.LOG.
Installing with the system account would produce the log-file in the %windir%\temp folder.

Yes, this work but is definitely not easy and user friendly.

1. The default location of the temp directory is C:\Users\UserName\AppData\Local\Temp. Compare that to C:\.
   
2. The AppData folder is by default hidden so it's not even visible in the Explorer window. Sure you can type just %temp% in the Explorer location and hit enter but how many novice users know that?
   
3. The folder name will also be different on different versions of Windows. On Vista it's C:\Users but on XP it's C:\Documents and Settings.
4. There can and likely will be numerous files called MSIxxx.log in the temp folder so the user must know exactly which file to pick. Compare that to a known file name.

The automatic log generation definitely needs improvement if you ask me.
/Fredirk

You're picky ;)

I can't see any problems with this
2-3:
The folder is easy accessible by quickly typing "%temp%" in START -> RUN...it's not a very long typing either.
However; the log-file will mosly be located in the system temp folder (depending on deployment method).

4:
as you said it "I could then just ask the users to sort by date to get the most recent file."

Yes I AM picky, cause I know that even the smallest hurdle can make novice users fail completely 8-)
Also, if users have tried to install several times and maybe over several days the likelihood of them sending the correct first log file is remote. If I could just be allowed to specify a prefix to the log file that would be fine but no, it has to be called MSIxxx.log which makes it easy to mix them up. If I set the filename myself I cannot generate unique file names...

[X(]

/Fredrik

Then use a vbscript or alike to provide the exact commandline you want which should solve your problem(s).

Do you really have that much "installation" problems that you need to generate a log-file each time?
(In that case you should prevent the errors from happen before hitting the production.)

How about accessing the temp folder yourself? then you don't have to involve the user at all (if you know the computername and can access it remotely)

When generating log file names for my utilities, I use the tool name plus the date and time in ISO format (YYYMMMDDHHMMSS) e.g. DeleteAllExpiredUserAccounts.HTA_20110413123604.LOG. I do that in VBSscript.

Maybe you could build a command line-building script to do that.?

I am actually calling the MSI from within installshield which creates a setup.exe stub that calls the MSI file with the correct parameters, i.e no way to use a vb script. This always creates a script but it's of course only needed if something goes wrong with the installation.
Compared to the number of installations I wouldn't say that there are many problems but they do occurr (as for ANY software vendor I would say)
Every computer is unique so there is no way to cover all possible things that may go wrong with an installation. In the case where an error do occur I need it the process of sending an install log file to be as near fool-proof as possible.
Connecting remotely is an option that we use when all else fails but it's not the first choice.
/Fredrik