MSI does not recognize %random% environment variable
I am trying to create a log file with a unique name and I want to control the location of the file. I know I can add to the MSI log file by specifying /l +v but this will cause the log file to be very large after the installation has been run more than once. There is an environment variable called %random% that I try to use. It will generate a random number but this does not seem to be recognized by msi.
A simple command like
dir > %SystemDrive%log-%random%.log correctly generates a file like C:\log-23342.log
These are the parameters I pass to msiexec and the resulting file
/l*v %SystemDrive%\log-%random%.log -> C:\log-%random%.log
/l*v %random% -> %random%
As you can see MSI expands the SystemDrive variable fine but ignore %random%
Why is this and is there any way to generate a unique file name with a known location?
A simple command like
dir > %SystemDrive%log-%random%.log correctly generates a file like C:\log-23342.log
These are the parameters I pass to msiexec and the resulting file
/l*v %SystemDrive%\log-%random%.log -> C:\log-%random%.log
/l*v %random% -> %random%
As you can see MSI expands the SystemDrive variable fine but ignore %random%
Why is this and is there any way to generate a unique file name with a known location?
0 Comments
[ + ] Show comments
Answers (14)
Please log in to answer
Posted by:
AngelD
13 years ago
Posted by:
frede
13 years ago
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.
Posted by:
pjgeutjens
13 years ago
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
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
Posted by:
AngelD
13 years ago
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.
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.
Posted by:
admaai
13 years ago
Posted by:
frede
13 years ago
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.
set WshShell =
Gives the output
C:\Windows
%random%
so it's definitely not recognized as a "true" env. variable.
Posted by:
frede
13 years ago
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
Any ideas how to solve this is greatly appreciated.
/Fredrik
Posted by:
AngelD
13 years ago
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.
Installing with the system account would produce the log-file in the %windir%\temp folder.
Posted by:
frede
13 years ago
Yes, this work but is definitely not easy and user friendly.
/Fredirk
- The default location of the temp directory is C:\Users\UserName\AppData\Local\Temp. Compare that to C:\.
- 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?
- 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.
- 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.
/Fredirk
Posted by:
AngelD
13 years ago
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."
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."
Posted by:
frede
13 years ago
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
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
Posted by:
AngelD
13 years ago
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)
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)
Posted by:
anonymous_9363
13 years ago
Posted by:
frede
13 years ago
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
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
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.