Hyper-V and Script Failure.
Updated: 25 Jan 2012 | 12 comments
This issue has been solved. See solution.
We want to support the hyper-v platforms also for the product we are building.
The issue in the installer is just as below but I cannot find a solution a way through to look into this.
the VB-Script is somewhat as following -> it is being run as Call VB Script from embeded code
Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set objSWbemServices = objSWbemLocator.ConnectServer(".", "root\cimv2")
Set osObjList = objSWbemServices.ExecQuery("Select * From Win32_OperatingSystem")
# following three steps do the job
Do some work with OSVersion.
Set properties.
Come out
The Script at Line 2 only in hyper-v and only if run through installer.
If i run script seperately it all goes fine. (Other than set properties part.)
Any pointers?
Discussion Filed Under:
Comments
The implementation of
The implementation of VBScript within Windows Installer is not the same as that implemented in wscript.exe so some methods may not work.
One way to test this would be to install the vbscript on the target workstation then run it by calling wscript.exe and passing the location of the vbscript as argument.
If you are doing nothing more than getting the operating system version, then perhaps it would be simpler to read this from the registry rather than using SQL, or write a Wisescript custom action which uses the "Get System Information" command to retrieve O/S version, etc.
Remember also that a 32 bit installer can only access the 32 bit area of the registry on the target machine, real or virtual, so if you are running on a 64 bit platform, you may need to think up a different approach.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Wscript -
Wscript filename.vbs runs completely fine on Hyper-V
Well we are not only using Operating system but Computer System class as well to get the manufacturer and other details of the box so can not avoid it.
If you are using WMI then you
If you are using WMI then you need wscript.exe as the internal VBScript handling in Windows Installer does not work with WMI calls.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
So change in CA
And how do i do that ?
1. Install or create the
1. Install or create the VBscript on the target system
2. Use the custom action "Call EXE from destination" to call wscript.exe and pass the name and path of your vbscript to it.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Pre Install
the requirement is actually a pre install thing. So installing the file and then running it is not feasible. I may need to create the file and run it.
Other thing is I need to set some properties which are useful for setting which features can be installed. so I believe I cannot do that as well in the CA.
Do you have the option of
Do you have the option of compiling your MSI to an EXE format? If so, you can do all of this in the Wisescript stub that forms the basis of the EXE which installs the MSI, and return the result as property values.
Or you could write a custom action script which generates the vbscript, runs it, then reads the result from a file or registry key and passes the result back in the form of public property values.
Frankly, storing the results of the WMI calls that get the computer details in the registry would be a good move as this information would be present for diagnostic purposes if anything goes wrong.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
I cannot do it in EXE, but
I cannot do it in EXE, but surely the second option works. Thanks ..
>Windows Installer does not work with WMI calls.
>Windows Installer does not work with WMI calls.
Are you sure about that, Ed? At my last client, I had a raft of ready-rolled script templates which all accessed the registry via the WMI route.
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
One thing I have learned over
One thing I have learned over the years is that whenever I am "sure" of anything then someone will prove me wrong!
The information I have gathered like barnacles since 2001 is that the support for VBScript within windows installer is not as comprehensive as that provided by cscript.exe or wscript.exe, and that you can get further complications depending on whether you are running the CA in system or user context and what security model is in force on the workstation.
From an academic perspective, it can be great fun to experiment with the different solutions if you are not under pressure to get something finished, but often, it is quickest and most reliable to follow a course which may not be the most elegant but is robust and reliable.
Having a raft of ready rolled script templates does suggest that you had some time to generate and test these solutions, and no doubt it is something that you carry with you so that you can reinvent the wheel at your future clients - as we all do. Should you wish to create an article for the benefit of other users and share your skills, it can get you a couple of hundred Connect points....
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
I had thought about an article a while ago...
...but fought shy because the class alone takes up nearly 5K and embedded script CAs are restricted in size (256 characters, is it? LOL)
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
Well we both know that the
Well we both know that the custom action table schema has a 256 character limit on the target column, but so far it has not been "enforced" by Microsoft in their windows installer engines, so packagers are getting away with exceeding the limits.
You could surely place the script in the binary table and run it from there instead???
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Would you like to reply?
Login or Register to post your comment.