Creating an MSI or Script to deploy an EXE through AD - windows

First:
I know there are other questions that ask similar/the same thing, I have looked at them tried all of them but no solution has helped.
The problem:
We use Epson Iprojection (downloaded from here: https://www.epson.co.nz/products/projectors/software/) However I can not find a way to get an MSI out of it (I am starting to think there is no MSI bundled in the .exe), and I can not seem to install it through CMD on computer start using AD. Any help will be greatly appreciated.

Vague Answer: Let me try to formulate an answer out of those messy comments above. I only briefly tested this software, it might not deploy as badly as expressed. Remember that this is a generic answer for whoever would find this in the future, and not for OP per-se (there is no real answer in here).
Due Diligence: I always try to consult package tip databases if I have problems with a package. Somebody, somewhere will have seen the same problem (eventually).
Silent Installation: Silent installation of legacy setups is usually possible (not always), but never really reliable. For Installshield it involves recording answer files (setup.iss) that record dialog answers. However, unknown dialogs can show up suddenly on some systems (low disk space, reboot prompts, unexpected lock or application in-use warnings, unexpected service running warnings,etc...) and hence halt the install unexpectedly as the response file has no recorded value for the dialog in question. This particular Epson setup also has an unfortunate reboot requirement on uninstall that is hard to deal with for large scale deployment (spontaneous reboot likely - without warning).
Repackaging: Personally I would try to capture the install using a repackaging tool. Most of these are expensive, but can output MSI, MSIX or other deployment package types. Repackaging fails when the package contains complex, custom logic that - for example - create dynamic content (ciphers, unique GUIDs, etc...) and in a number of very specific technical cases.
Contact Vendor: If you capture an MSI that doesn't work, why not try to send it back to the vendor with some comments on how hard this software is to deploy and maybe mention the major benefits of MSI? I would tell them you have to ditch the whole software from your network if they can't deliver a deployment solution that works. Time is of the essence. "Some solutions are only free if your time is worthless" (quote from Joel Spolsky himself - slightly out of context, but the same issue: we need solutions that work in a timely fashion).
Note: I once had to compile a special setup to deal with a client's
deployment problem that was our fault. Deployment problems need fixing at a standardization level. Standards!

Buried within the single-exe download is iProjection_inst.exe, some sort of wrapper that prompts for language selection, and doesn't seem to have a standard "non-interactive" mode.
Inside this is instData\Setup.exe, a vintage "full screen" InstallShield installer with external ini / cab files.
Running this with Setup.exe /? doesn't give any command line arguments, as it would for a modern InstallShield setup.exe.
Although it supports recording an answer file via Setup.exe /r, when I try to replay the answer file with Setup.exe /s it seems to still prompt for EULA, and then fails to install.
So this is really a design flaw in the innermost installer to do with the dialog sequence.
Assuming Epson won't fix it and repackaging is too hard, a hacky alternative is to use Powershell to automate the UI of instData\Setup.exe once the "Welcome" screen is showing, but I don't think this will work running as an AD script.
$wshell = New-Object -ComObject wscript.shell
$aName = "Epson iProjection Setup"
function Next() {
if ($wshell.AppActivate($aName)) {
$wshell.SendKeys(' ');
start-sleep 1;
}
}
function AcceptEula() {
if ($wshell.AppActivate($aName)) {
$wshell.SendKeys("{TAB}");
$wshell.SendKeys("{TAB}");
$wshell.SendKeys(' ');
start-sleep 1;
}
}
Next; AcceptEula; AcceptEula; start-sleep 20; Next;

I know this is an old thread but it looks like it may be easy now. The latest 2.41 from here
http://www.downloads.epson.com.au/DownloadFile.asp?filename=iProV2411Win%5FWEB%2Eexe&path=Drivers
seems to have an MSI in it. Just jump into the %temp% folder and organize by date so you can see the latest files. Run the installer and a new folder named with a GUID should show up, in my case {27CDEEE8-B6F2-45a7-A48E-696862573D9B}.
Under this folder there is a series of InstData folders like InstDataX64 where you can find an MSI.

Related

ZeroMQ Windows Installer NSIS Error

I want to install ZeroMQ for Ratchet/PHP and I downloaded the installer from http://zeromq.org/distro:microsoft-windows. But I keep getting "NSIS error" whenever I try to install it.
It immediately shows after I run the installer. Different versions, x64 or x86 ones, none of them works. This problem only shows up with ZeroMQ installers.
Does anyone have any idea why does this happen?
P.S. I use Windows 8.1. (Up to date)
This question does not belong here on Stackoverflow but since you posted it here anyway I will give you the technical answer: NSIS needs to open a file handle to itself so it can read the compressed data, it does this by calling GetModuleFileName to get the path and CreateFile to open the file. If this step fails it displays the _LANG_CANTOPENSELF message ("Error launching installer", the text in your screenshot).
A) GetModuleFileName can return a "incorrect" path when filesystem redirection is involved, this is most commonly seen when psexec is used to execute the program from the Windows directory on a remote 64-bit computer and this is probably not the case here?
B) The call to CreateFile can fail, this is most often caused by Anti-Virus software holding a lock/denying access to the file. Try to disable/uninstall any 3rd-party Anti-Virus software...

install on windows 7 troubleshoot compatibility PCA - "This program might not have installed correctly”

Well, I'm using Visual C++ 2010 Express and ResEdit
for my midi sequencer's SETUP app.
Win32 API, no MFC, some custom window and control classes and such.
Now that I got Windows 7, my dang SETUP program is broke.
Windows gives me the ole "Did this app install correctly??" thingy.
Which implies that SOMEthing is wrong with my installer.
I'm tryin' to figure out what that might be...
I've seen these 2 SO threads:
"This program might not have installed correctly"
"This program might not have installed correctly" message in Windows 7 RC
Which have lead me to these places:
http://msdn.microsoft.com/en-us/library/dd371711(VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb756937.aspx
http://msdn.microsoft.com/en-us/library/aa905330.aspx#wvduac_topic3
http://blogs.msdn.com/b/cjacks/archive/2009/06/18/pca-changes-for-windows-7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the-rules-on-you.aspx
http://community.flexerasoftware.com/archive/index.php?t-189007.html
Only registry entries I use are the standard uninstall spot and
associations for filetypes.
SETUP writes a dat.cfg file in program files\pianocheater dir
that points to where all the app's data is. (just a text file with a path in it)
(And an etc.cfg for a temp dir within that data dir to use.)
So I'm only READING from programfiles\pianocheater post SETUP.
Can anybody think of why Windows wouldn't like the install?
Source code is at http://shazware.com/_etc/SETUP_PIANOCHEATER.cpp
It uses my library of window, control classes similar in spirit to mfc.
I could send useful parts of it, too.
It's not toooo bad for a setup app.
Should be pretty ledgible for a win32 guy/gal.
I could uuuuuse some he'p...:/
Oh yeah, I should point out that Go() is the entry point instead of main().
The DBG()s just do OutputDebugString() and seem to all run just fine.
TStr is just a big char[MAX_PATH] (and I don't do unicode)
And the trick PROBably is that I'm on win7 64 bit, but this is a 32 bit app.
I'm pretty sure I'm using the registry correctly for assoc's and uninstall spot, though.
So is THE thing I SHOULD do the manifest xml thing?
Or is there a more correct way to do things?
thanks much,
...Steve
First off, check whether that message is a false positive or not. The message you're seeing is designed to use heuristics (which can be wrong!) to determine if an installer failed due to Windows Vista/7 compatibility issues. If your installer is in fact compatible with Windows 7/Vista, then all you need to do is add a manifest declaring itself compatible. You'll also want to add a requestedExecutionLevel entry to your manifest as well to request elevation.
If your installer is in fact failing, of course, then you ought to fix that first.
Finally, if the error is showing up because a launcher executable exits early or something like that, consider suppressing installer detection by adding the appropriate manifest entries to the launcher as well (you may be able to use a requestedExecutionLevel of asInvoker if the launcher doesn't need administrative access; the presence of a requestedExecutionLevel manifest entry should suppress installer detection). Note that you should make sure you use ShellExecute to invoke your main installer process, not CreateProcess, or UAC may not elevate the child process.

MSI Package hangs-up when calculating disk space

In my team we prepared an msi installer package for our application. Package is made in WIX contains custom UI, call custom actions from C# library and almost everything works fine except one thing: calculating required disk space. On this stage whole installer hangs up from time to time, especially when client testing it :( We have the same problems on developing machine, but restarting installer helps, so this error is quite random.
I was googling a little bit and found two workarounds, all based on command line parameters:
msiexec /i filename.msi (change state messages handling)
and
msiexec /package /qr (starting package with limited UI)
unfortunately its not a solution for me, because installer has to working without passing extra parameters to it when user want to install application :(
I'll be appreciate for any clue in my investigation :)
You'll want to read this blog post:
It’s time to experiment
The exact cause is unknown but the workaround is to opt out of WiX's WaitForCostingDlg dialog.

I have a delphi 7 program running on windows 2008 and I get "folder does not exist" error

I've asked the very same question here :
Why does my program say "folder does not exist" when run on Windows 2008?
but none of the answers were satisfying and my problem still exists , so I decide to ask it in another way with more detail cause this problem really irritate me and we need to solve this , otherwise we have to write the similar application in another language which means waste of our time.
program written in delphi 7(32 bit)
environment running this program is : windows 2008 r2 64-bit
the task program try to do : creating 3 folders then copy an sound file and compress it using lame commmand line (lame.exe) and save changes into database
error I get : "THE 'folder' does not exist . the file might have been moved or deleted , Do you want to create it?" and it cause the program become halted
things I have done :
1- try to run the program as an administrator
2- check eventlog but no clue
3- triple check the required folder and all of them was correct
4- read this KB: http://support.microsoft.com/kb/927387
BUT still I am seeing this bloody error.
I have uploaded the picture of the error here as you see it clearly :
http://i28.tinypic.com/9to6qr.jpg
The folder name is C:\Upload_ABC\\2010\07\27\:
please notice I haven't written that unwanted dialog-box inside my program I believe windows 2008 attach it or bring it on my application.
please please please give me some idea or let me know what should I do ?
best regards.
C:\Upload_ABC\\2010\07\27\
You have two backslashes in your path. Use debugger to see why.
Have you checked the access rights for that folder structure with regard to the account the Delphi program is running from? Windows Server systems tend to be more restrictive in what a user is allowed to do than Windows on workstations are.
In addition I suggest to strip down a copy of the program to the relevant functionality to show the error. With this you get at least a chance that anyone around may test it on another system.
Furthermore you can try to compile it with D2010 and see wether the error persists. If it does, you might have a chance to find the problem running the D2010 debugger. If you don't have D2010 at hand, you might install the trial just for this purpose.
What is between the two consecutive backslashes in your path? Is there really nothing between them or have some characters been removed because they are Unicode and D7 doesn't support Unicode?
As there is nothing in between the two consecutive backslashes...
It does sound like Windows is getting its grubby little fingers in between your program and your access of the files. Either the folders have not been created, or you are being denied access once they have. And as the changes you are trying to store in your database involve compressed files, virtualization seems to be the culprit as explained by the link you yourself provided.
A couple of avenues to try:
Remove any compatibility settings on your exe (right click|properties|Compatibility tab) that could trigger Windows to butt in. Also don't forget this can be triggered by things like "setup" or "update" as part of the executable name.
"Save your application's data in a folder under your user profile."
Such as c:\users\\documents or some such (better not hardcode it in actual production code, but ok for debugging). That after all is exactly the advice the linked msdn article is giving for scenario 2 "you cannot find the files or folders you just created"
If you can't debug on the machine where it is running, go back to old school debugging: add trace messages to your code to show where in the code you are (and have been) and show them in a memo on a separate form or some such.
Make sure you don't "eat" any exceptions that could give you extra information about what is going on.

Strange, possible “shadow copy” issue where two editors show different contents

I have some code that is reading a config file, but when I open the file in TextPad, I see different values than my application does. I checked it with Notepad. Notepad agrees with my application, TextPad shows something else.
This is on Vista x64 Business.
Any idea what could be causing this? I've looked in the Context Menu->Properties->Previous Versions details, but it says "There are no previous versions available".
Here's the steps to replicate (I can't make it happen reliably):
Installed .NET app in Program files.
That app reads the config file, but is falling over.
I manually edit that config file in Textpad.
The change doesn't take effect.
I open the config file in Notepad, and see something different.
Try making the change in Notepad and saving, and get this error message:
Notepad
Cannot create the C:\Program Files (x86)\Daniel Schaffer\WorkingOn for FogBugz\FogBugz > WorkingOn.exe.config file.
Make sure that the path and file name are correct.
I can't put the content here as it's XML and is being encoded by Superuser.com, but here's a link to a screencast: http://screencast.com/t/zhERl7mocp4.
Sounds like a case of you don't have administrator privs, when you installed your app. Sometimes when you install an app with no admin privs, it behave really strangely because of vista security model. I had a similar problem to this last year. It wasn't the exactly, but it was strange behaviour, until I figured out it was vista's security model. It elevates it into application/user security context, from what I know, as my brain froze when I was reading about it, as it was pure muck and virtually useless from what I can see.
Try opening Textpad (excellent app) with Run as Administrator, and then edit the config. See what happens. If it stays then same then its a prives problem. If that doesn't work, deinstall you app, and then install it as an administrator. That will give the app the write admin privs to work. Then when you edit the config. See if that works.
Take a look at this. You can elevate an app to run as administrator, Using the techniques found here. How to elevate an application.. Try all these before you do a reinstall.
If that doesn't work, post your question to server fault. Also post it to a suitable MSDN forum.
Hope that help.
Bob.
This is interesting. My guess is that a Vista Feature called UAC Virtualization (aka Data Redirection) is at work here. It basically redirects legacy applications to %USERPROFILE%\AppData\VirtualStore\Program Files\... so they can write files in the program's directory.
Maybe Textpad tries to open the file in read-write mode while both your application and Notepad use it read-only?
You can fire up Process Monitor to see the exact magic, and please let me know ;-)
Try just to strip that whitespace character from application name; my guess is something related to canonical path building
try to copy file to another path and reopen it. see if it changes the result.
One thing you can do is observe what exact file each of those methods ends up opening. To do this,
launch Process Monitor from the sysinternal suite.
look only for file operations (deselect registry operations on the right of the toolbar)
select only your own process (filter out all the processes that you don't care about, or just include your own process name in the filter list)
You can also simply use the search function for your file name, this might be the faster route.
Process monitor has helped me find so many issues it's amazing.

Resources