Software Deployment

We have had the same question before and don't think we came up with a working "convert" solution.
Using Process Monitor or alike to find out the changes made by the WSE-EXE.
If it's a small one maybe open it with notepad may reveal some useful info.

I wouldn't waste my time looking. Just capture the install to a WSI and compile to an MSI. If you need an EXE for deployment, use MSIExec.EXE and pass it the required arguments or use Wise to build a wrapper EXE.

BTW, we'd appreciate posts with no cussing, thanks.

After a while I went looking for that WSE but was so bloody upset that I couldn't find it

You really should try and get these things into context - upsetting yourself over a silly old script is just plain silly.

I think there is a lesson to be learned here! [;)]

http://en.wikipedia.org/wiki/Data_backup

http://www.ontrackdatarecovery.co.uk/

Have to agree with VBScab...

Just for info.... you used to be able to reverse engineer early versions of SMS Installers' compiled executables, but I think Microsoft/Wise closed that loop hole for security reasons.. obvious really!

Thanks packager vets..

The EXE I need to get back into WSE format basically has an internal script I need to find which looks similiar to this one:

item: Install File
Source=.\su.exe
Destination=%TEMP%\su.exe
Flags=0000000010100010
end
item: Install File
Source=.\GTPro_Pro.reg
Destination=%MAINDIR%\GTPro_Pro.reg
Flags=0000000010100010
end
item: Install File
Source=.\GTPro_Dev.reg
Destination=%MAINDIR%\GTPro_Dev.reg
Flags=0000000010100010
end
item: If/While Statement
Variable=GTPRO
Value=A
end
item: Install File
Source=.\GTConfig_pro.ini
Destination=%MAINDIR%\GTConfig.ini
Flags=0000000010100010
end
item: Execute Program
Pathname=%TEMP%\SU.EXE
Command Line=%CNAME% CTC_ITSPRT m$C2?w4wu@7ujamA "regedit /s c:\gtpro\GTPro_Pro.reg"
Flags=00001010
end
item: Else Statement
end
item: Install File
Source=.\GTConfig_dev.ini
Destination=%MAINDIR%\GTConfig.ini
Flags=0000000010100010
end
item: Execute Program
Pathname=%TEMP%\SU.EXE
Command Line=%CNAME% CTC_ITSPRT m$C2?w4wu@7ujamA "regedit /s c:\gtpro\GTPro_Dev.reg"
Flags=00001010
end
item: End Block
end
item: Remark
end
item: Exit Installation
endBut regrettably it has some scripting that is configured differently then above. I tried using WSE's setupcapture to capture the EXE as its run but I don't get any scripting like above. I even tried Wise itself to capture the EXE right to an WSE but that only shows basic system changes. Essentially, the EXE is supposed to copy a file called su.exe to a location on the drive C:\Program Files\IBM\WebSphere MQ\bin then based on security parameters in the WSE, allow for admin access each to the EXE in question runs. Again, its similar to the script example above.

Wise won't create a WSE, but a WSI which can then be compiled into an MSI. WSEs compile into EXEs. They're two, completely different things.

The reason I suggested capturing was because a capture will, er, capture everything which the script does, negating the need to create any script.

Looking at your example, it seems to be importing 2 .REG files with a "super user" account. Is that right? If the requirement is that simple, you don't need to capture anything. Just start a new project, import the .REGs and compile the project into an MSI. You would then use the SU utility to run the MSI, if that's what you need. Most deployment systems run in the System context, meaning even that final stage (i.e. using SU) would be redundant.

Actually Wise can capture to a WSE (you just have to specify the source is a .wse but normally its .wsi). However, what it captured wasn't a useful wse.

The problem with creating the new project as you suggested is that the EXE I was trying to find the WSE for is designed to first copy SU.EXE to a specific location, run it based on some security credentials, to then import some registry settings. The key is this must happen under a locked down environment where the user using the application is a regular domain user, not admin.

Further, I do not know what those registry entries are until I can capture them.

What flavour and version of Wise are we talking about? Wise Package Studio? Wise for Windows Installer? Wise Installation System?

Wise Studio 6.01. We're soon moving to 7.0 (yes we are badly behind).

Any ideas gents? I've tried using UltraEdit to hex-edit the WSE-created exe but the data for what scripts are run are all encrypted. Bah! This is really flooring me here.

Holy cow! Forget trying to get at the script - it's never going to happen! If you need to reproduce what the EXE does in editable form, just capture it.

@VBScab - as I stated: doing a capture does not extract the most critical aspects of what is required: it just captures a bunch of files and registry changes and additions that largely have no bounds to the actual prime function the WSE'ed EXE does.

But.. I finally determined whats going on.. Follow me along to see if you can figure this out..

1) A file "su.exe" (aka. Super User) is copied to the user's \local settings\temp folder
2) From there its supposed to run the command line as follows:

su.exe <domain> <username> <password> <executable>

In this case it should be: su.exe <computername> <our corporate master username> <our corporate master password> <path to a cmd file that is only to be run in a dos box to set up an environment>.

Now the problem is if I use CMD in the above <executable> line it won't do anything nor if I call the .cmd file I need to run directly. So here is what I need the WSE -> EXE to do:

1) Copy su.exe to user's \windows\temp (This part is done!)
2) Then using su.exe and its applied credientials (which do work in our locked down environment) to run a specific .cmd file using the \windows\system32\cmd.exe . This will open up a Dos box which will run this .cmd file called "mqsiprofile.cmd".
3) Then stay in the same folder where that .cmd file was run which is in \program files\ibm\mqsi\6.0\bin -- all still running in a Dos box.

I can get this to work mostly using just the cmd.exe and piping it to the mqsiprofile.cmd in a bat file as a test but once su.exe is involved it doesn't work.

Does anyone have any ideas as this totally revolves around su.exe it seems now.

Have you thought about using another tool, e.g. RunAs? Doesn't SysInternals have a similar tool?

I have but the problem is I need the entire command line to include username and password automatically so noone is prompted for the admin password (thats confidential and we encrypt that for obvious reasons). Su.exe supports this but runas doesn't seem to.

Although it's designed for remote execution, I wonder whether SysInternals' PSExec utility - which takes username and password arguments - could be pressed into service? Worth a try, IMV.

Yep looks like psexec is the winner! Works now and I am now successfully able to duplicate what I lost in the WSE'ed EXE. Finally..

My only minor gripe: why the working directory wants C:\Progra~1 then C:\Program Files? Might be an issue with PSExec as it only seems to work with

Set Variable PROGRAM_FILES to C:\Program Files << set to Remove Trailing Backslashes operation
Set Variable MAINDIR to %PROGRAM_FILES%\IBM\MQSI\6.0\BIN << set to Convert to Short filename

If I set the MAINDIR to "C:\Program Files\IBM\MQSI\6.0\BIN" << set to convert Long Filenames then it still works but the script in PSExec has a " between \BIN and the .cmd I need to run (ie...\BIN"\mqsiprofile.cmd) which makes no sense why the " is there. :(

I haven't tried (because I tend to use WMI methods for remote process execution) but it's a general truism that, if an argument requires quotes and you need to pass, in that argument, a path with spaces, then enclose the whole thing in another set of quotes, like:

....whatever.exe first_arg=""c:\program files\ibm\bin\whatever""

Thanks VBScab.. got it working yesterday after I chatted with you. I just created another variable for the working directory path used in psexec and all is well now. Now its a matter of figuring out why the heck the EXE works in my test environment (both as restricted domain user and admin) but oddly doesn't bring up the dos box on a production machine? Oh the joys of a locked down environment. [X(]

BTW, we'd appreciate posts with no cussing, thanks.


Hi, just curious if the "b***dy" word is what you define as cussing. Now, keep in mind that I was born and raised in the USA. That word does not seem like a cuss word to me, but maybe it is in England. Your avatar contains a word that seems closer to a cuss word that the one thudo used. [:D]

All working gents! I found out why PSExec didn't work for domain users in production.. it was because on first run PSExec, like all Microsoft-controller sysinteral apps now comes with an annoying eula so when I run the custom WSE -> EXE I just include the -accepteula after the PSExec and all is good. Now PSExec quite nicely replaces the older SU.EXE which causes restart issues with one of our development groups using a custom cmd file that is required to run with internal admin rights. Quite happy indeed and perhaps something others in this community should know about when needing the requirement of locked down domain users the option to run a command with admin rights WITHOUT compromising security.

Excellent news. I'd forgotten about that EULA thing...I think I posted somewhere about that, saying what an utterly pointless thing it is and someone responded that it's connected with the convoluted agreement that MS has with the cahps at SysInternals.

ORIGINAL: MicrosoftBob
Your avatar contains a word that seems closer to a cuss word that the one thudo used. [:D]What year is it there, Bob? 1936? :)

I scan all posts and concerned that I should add a new "dirty word" to the filter, I hit up Wikipedia on the term which states...

Bloody is the adjectival form of blood but may also be used as an expletive attributive (intensifier) in Australia, Britain, Ireland, Canada, South East Asia, New Zealand, and Sri Lanka. Nowadays it is considered (by most of the population of these countries) to be a very mild expletive, and unlikely to cause offence in most circles.

So-- I think we are okay here?

Hi, Bob K. I think we were already OK, weren't we, MS Bob? I certainly was/am. Just a bit of banter...

I always hope so, but keep my ear to the ground just in case-- it is hard to read "tone" in an email sometimes. I guess that is why we have these anoying things: [;)]

Im in New Zealand. There is a tv ad that is runs occasionally advertising Australia, and the last words of the advert are "where the bl**dy Hell are you". That advert was taken off tv in britain because of that B word, and changed to "where the hell are you"...conservative poms.
We have another tv advert for drink driving in NZ (plus billboards everywhere), "If you drink and drive, you're a bl**dy idiot". The B word is everyday language in NZ and Australia.
:)

Hi, Bob K. I think we were already OK, weren't we, MS Bob? I certainly was/am. Just a bit of banter...


Hi, sorry for the late reply, but yes, just a bit of banter as you say, thus the smiley icon in my message.[:D]