I have a Wix installer which should be allowed to run on Windows Server 2008 but not on Vista. According to Microsoft's Operating System Properties page, this is not possible using the parameters they provide for this purpose (VersionNT and WindowsBuild).
Has anyone solved this problem or know how to solve it?
Thanks!
Try
<Condition Message="This application is only supported on Windows Server 2008, or higher.">
<![CDATA[Installed OR (VersionNT >= 600 AND MsiNTProductType > 1)]]>
</Condition>
Note that such a check can be easily bypassed by someone simply editing the MSI with Orca, so unless there are technical limitations (e.g. even if they get it installed, certain services will only be present on the Server OS) I wouldn't advise it.
Related
Does anyone know if AppFabric can be installed through WIX (windows installer xml)
We have an enterprise application we deploy to clients through installer using WIX (windows installer xml) and this application use AppFabric 1.1 and we need to make our installer to be able to also install the AppFabric on the client server..
I have ve spent 2 days getting familiar with all the stuff about AppFabric but I can find solid information whether it is possible or not..
Does anyone knows if it is feasible ?
Thank you so much and blessings.
Hernán
If AppFabric is normal installer, you can download it from internet using Custom Action (normal way - for example using WebClient) and then start installation
var process = Process.Start(filePath);
process.WaitForExit();
You just have to remember to start it in InstallUISequence! Sample:
<Custom Action="ConfigurEwsFilter" After="ExecuteAction" >
<![CDATA[NOT Installed]]>
</Custom>
I heard that bootstrapper can download (or add to installer) and fire file too, but i have never test it :) That's why Check this tutorial!
Im installing windows server 2008 on my Windows 7.
It seems like I will need to reinstall all programs after installing MS windows server 2008. I dont really want to do that, is there another way around it?
And how can i find out whether I already have Windows Server installed on my computer? Thanks.
The two operating systems do not support an upgrade path. You could do some unsupported things, IE exporting registry entries and importing them manually, but you're not likely to get things working the same way. Further, some of your applications may not actually be supported on 2008.
http://technet.microsoft.com/en-us/library/dd979563(WS.10).aspx
I am using Visual Studio 2010 setup project
I don't think you are allowed to redistribute PowerShell. And at any rate, it is built in to Windows 7 and Server 2008 R2. All the other platforms have separate installers as well. I think it would be best to just notify your customers that they need PowerShell 2.0.
I had a similar problem in the StudioShell installer - wanted to make sure PoSh 2.0 is installed. I did a cursory check for the executable with a minimum version number, and added a launch condition that notified the user of the missing prerequisite and offered to open a web page to the PowerShell download. Seemed like the most legally helpful approach.
There is a way, albiet requiring you to build some MSI thing manually that will get it from MS and install it for you. I know the exchange install used that technique. You can also get a license/permission from MS to redistribute the official installers.
I have a tool that I want to install on my main development box (Windows Server 2008). The installer tells me that it requires Vista. Of course I'm not saying Server 2008 is Vista, but I figure something that installs on Vista should be able to install on Server 2008.
Is there some way (perhaps via a temporary registry change) to get a server 2008 system to appear as Vista for the purpose of installing software?
Thanks!
Win2008Workstation has an example guide of how to use Orca to patch an MSI file.
Have you tried the emulator for running the install, when right clicking and going in to the properties of the installer?
right click > properties > compatiblity > and change the compatibility mode to Windows XP or Windows Server 2003
A few ideas:
If it's an MSI installer, download orca and delete the custom action that does the check
Use a tool such as process monitor to watch what registry keys the installer reads and tweak them to match vista's.
I've been working on a project that accesses the WMI to get information about the software installed on a user's machine. We've been querying Win32_Product only to find that it doesn't exist in 64-bit versions of Windows because it's an "optional component".
I know there are a lot of really good alternatives to querying the WMI for this information, but I've got a bit of a vested interest in finding out how well this is going to work out.
What I want to know is if there's some kind of redistributable that can be packaged with our software to allow 64-bit users to get the WMI Installer Provider put onto their machines? Right now, they have to install it manually and the installation requires they have their Windows disc handy.
Edit:
You didn't mention for what OS, but the WMI Redistributable Components version 1.0 definitely exists.
For Operation System, we've been using .NET 3.5 so we need packages that will work on XP64 and 64bit versions of Windows Vista.
You didn't mention for what OS, but the WMI Redistributable Components version 1.0 definitely exists.
For Windows Server 2003, the WMI SDK and redistributables are part of the Server SDK
I believe that the same is true for the Server 2008 SDK
Wouldn't the normal approach for a Windows component be that the administrators of a set of servers use whatever their local software push technology (i.e. SMS) to ensure that component is installed? This is not that uncommon of a requirement for the remote management of servers via WMI.
By the way, the WMI Installer Provider is not provided in the Standard Edition of the server products, but it is in the Enterprise Edition. So, Windows 2003 Server will not have this installed by default, but Windows 2003 Server Enterprise (and DataCenter) will.
This answer does imply that you are putting the burden of installation back on your user base, but for Windows administrators this should not be any issue.