I was wondering if it is possible not to have the virtual machine additions installation eject the iso image after installing, maybe an undocumented switch.
I have created a custom OS installation CD and anything to be installed after VMA will be left hanging, or if you have more files in the $OEMO$\$$ or $OEM$\$1 directories they are never copied.
If there is a switch please let me know the full command line.
The switches are all standard, documented commandlines for InstallShield and MSI. I am not certain why you want undocumented switches - I hate undocumented switches from a supportability and maintenance perspective, and why do you want us to get sued? 😉
Anyways, this is the commandline that I use to automate installation of VM Additions into my Virtual Machine as a part of OS installation - all standard and documented switches:
setup.exe /s /v"REBOOT=ReallySupress /qn"
- /s - InstallShield "Silent" install switch
- /v - InstallShield "pass arbitrary values to the internal MSI" switch
- REBOOT - Standard MSI switch controlling reboot behavior (no, I do not use the newer /norestart switch because I do not want to require MSI 3.0 and I want automation that works from NT4/W2K on up)
- /qn - MSI switch which pops up NO user interactive dialog (can use /qb- to get a dialog with cancel button)
As for how I deal with the CD eject problem - I copy the VM Additions CD image to the local disk (or make it available on a remote UNC share) and then launch the VM Additions setup.exe in automation from the respective locations.
Honestly, the VM Additions ISO which ships is very hostile towards automation. I've filed bugs on these things before:
- AutoRun.inf launches setup normally as "setup.exe" and not unattend, so it requires clicking "Next" to install VM Additions
- At end of VM Additions installation, the VM DVD ejects, causing automation to hang waiting for the now-ejected ISO.
- IVMGuestOS.InstallAdditions() loads the ISO, but since AutoRun.inf is not unattend, this API call is useless from automation perspective
As a result, the first thing I do with a new Virtual Server 2005 build is to:
- Take the released VM Additions ISO and extract it
- Perform my "fixes" to the above problems so that VM Additions installation is truly unattend
- Repackage my fixes into a new VM Additions ISO and have all my Virtual Server automation consume that instead
Sorry Ben... probably not what you want to see people do, but I have to get things automated... :-/