In my installer i need a number of launchers, to install them as services, based on the user input. Those Launchers are all the same except for an index in their name.
I dont want to create all those launchers manually because that would be impossible to maintain.
Is there a way to copy and modify launchers at installer runtime and then install them as a service?
There is no reason to duplicate a service launcher at runtime. You can use an "Install service" action to install several services with different service names. To do that select "Other service executable" in the "Service" property of that action, then you can select and executable and a (variable) service name as well as variable arguments.
I have a Usecase too, where i want to have this Possibility of Renaming the Launcher an Runtime.
Assume you want to have a Testinfrastructure, where you want not only to test one Instance of your Programm, but several. And you want to use the Launchers from Install4J to start your Application.
Assume you have 5 Services that need to be started to provide the desired Functionality. Now think of having 10 Instances for 10 Customers, you want to test. Further you want to test it not on 10 different Machines, Docker, VM's, or what ever but on one single Machine.
This isn't possible, since you can't rename the Services at Runtime.
Wolfgang, i understand your Problem. Mine is similar.
I played a bit around with the Launcher.exe.
Perhaps there's a Solution for your Case.
Assuming your desired Launchernames are all off the same Length, like:
- Launcher_01.exe
- Launcher_02.exe
- Launcher_03.exe
- Launcher_04.exe
- Launcher_05.exe
You can then generate a Launcher once, with the Name "Launcher_xy.exe".
It's now possible to open up your favorite Hex-Editor an search for "Launcher_xy", rename it to "Launcher_01" and save the Data back to the exe-File. But be aware of not changing the Length of the Name. It won't work, if you'll change the Length.
So if you've changed the Name and afterwards execute
Launcher_xy.exe -install non-interactive
you will get a new Service called "Launcher_01.exe" under Windows-Services.
Related
I want to create a script that will launch an application and configure it completely with provided input values.
ex: Launch outlook-> enter default address-> choose connect ->proceed with next options and finish
How can this be achieved using powershell script?
I am able to launch the applications but not sure how to input values to it.
Ths is a very broad topic, and the answer will depend on the specifics of any given application.
Here is a technet article that dscusses various ways to launch an application, with the benefits and drawbacks of each: https://social.technet.microsoft.com/wiki/contents/articles/7703.powershell-running-executables.aspx
There are sevaral approaches depending on the app & installer but the basic key is that you must be able to configure the app manually using nothing but command line tools.
If you can do it manually, e.g., one command at a time then scripting the full install becomes easy.
Most/many installers have switches for "silent install" though Outlook is a complicated setup, start there.
Many installers will show there options when you type: InstallerName /?
Usually the options you need are /silent or /q or /quiet and perhaps.
Office has the concept of creating .MST files (t=transform) to provide additional configuration so search for "creating an officer transform" file.
For some apps, you can monitor the registry with a "registry watcher" app and then write a script to make the same/similar settings for each install.
With Outlook, I would first pursue the MST/transform route and ask this question in places where Office and Outlook are discussed.
I'm considering using shims to get around a game demanding Admin privileges (I tried editing the embedded "requestedExecutionLevel" tag with Resource Hacker and using .manifest files, but discovered the launcher software always downloads a new version of itself before running, thereby overwriting "asInvoker" with "requireAdministrator"). If I write protect the exe it exits with an error.
I understand that the shim required to spoof Admin privileges will probably add no appreciable overhead in itself; but MicroSoft's Application Compatibility Toolkit (ACT) that you need to install to enable shims uses a database to keep track of which application requires which shim. I'm sure this could be done with little overhead; but having seen MS' (and other corporates') past bloatware, I'm concerned my entire system will be slowed down if I install it.
Does anyone have DIRECT experience of installing ACT and KNOWS whether it slows the system down generally?
I've discovered you can add RUNASINVOKER as the value of a STRING key given the name of the application's full path here:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
and it will do the job without you having to install Microsoft's ACT package.
Example: if you had an application called Smeagol.exe in the directory c:\LordOfTheRings, then create a STRING key called:
c:\LordOfTheRings\Smeagol.exe
in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
and give it the value of
^ RUNASINVOKER
and it will run without requesting Admin privileges.
So basically what I'm trying to do is to have a number of additional parameters (namely SERVICENAME and SERVICEDISPLAYNAME) in the installer of my application (which runs a service) instead of hard-coding them in the installer. The installation runs fine with this change. However the problem I have is when I run a silent uninstall. It appears that the Service Control does not stop the service before removing it from the machine and I get a dialog box telling me that the service is still running and asking me if I want the service to be stopped before uninstalling it. What should I do to make it work (i.e. make the service control to stop the service automatically before removing it)?
The ServiceControl Element is just an abstraction for the underlying ServiceControl Table. Neither "do" anything. Instead, they merely express what needs to be done. The stopping of services is performed by the StopServices Action which gets it's orders from the aforementioned table.
In Windows Installer, properties are not persisted automatically after an installation is complete. If you log the installer you will likely find that your SERVICENAME property is null and the StopServices action doesn't know what to do with that.
Take a look at the following:
The WiX toolset's "Remember Property" pattern
If you implement this pattern, the data for SERVICENAME should be restored during the uninstall and the
As I've explained in my other question, I'm busy setting up a PowerShell module repository in my enterprise.
My plan is to have a master repository (r/w access to a limited group of people) and slave repositories (read only access to everyone). I need multiple repositories because clients are located in different security zones and I can't have a central location reachable by all clients.
For this reason, I need to configure the PowerShell profile of the clients so that they can point to the correct repository to find the modules. I would like to define a $PowerShellRepositoryPath environment variable for this purpose.
Also, the profile needs to be customized in order for it to execute a script located in the repository (thus where $PowerShellRepositoryPath points to) when PowerShell starts (my goal here is to automatically add the latest module versions to the PSModulePath of the clients on startup).
We have a mixed environment with domain members and stand-alone servers in different network zones.
How would you proceed? Is it possible to push that variable and the profile via a GPO for domain members? Would customizing the $Profile variable via GPO be an option?
What about the standalone servers?
Edit:
I think that for creating the environment variable, I'll just use a GPO to create it and use it in PowerShell via $env:variableName. For non-domain situations, I'll probably have to use a script though..
I am not sure about pushing $profile via GPO. But, I'd simply put a logon script that copies the profile script from a network location based on the user's group/security membership.
Well if you're going to change the path to the modules, I'd have a file in the repository (say current.txt) that has the name for the current module (or current file path, whichever you are changing) in it. Then have the $profile script read the content of that file, and set the variable based on the contents. This way you don't have to screw around with updating the profile scripts, just update the central repository current.txt file with the path (or partial path, the part that changes, or filename or whatever), and when it replicates to the client repositories, all powershell profiles get updated with the latest modules when the profile script is executed.
Out of curiosity, why not just overwrite the module files in the client repositories with the latest version? If you did it that way, all clients would always have the latest versions, and you wouldn't have to update the $profile scripts.
Alternately you could always write another script to replace the $profile script on all machines. I think the first route I suggested would be the cleanest way of doing what you are after.
As far as the GPO thing goes, I don't believe you can do this. There is no GPO defined to control what is in the profile script. I would say you could maybe do it with a custom ADM file, but the profile script path is not controlled by the registry, so no go there.
Calling the JBoss command line tool Twiddle, located in $JBOSS_HOME\bin directory, can give us the port number on which JBoss is listening for HTTP requests (see Q2366489). That's smashing :)
However, we can't rely on the fact that the system administrator has set the JBOSS_HOME path variable, and it would be useful to know if we can obtain this directory programatically from within the JBoss environment. In my case the project is deployed as a WAR file.
TIA
This, and various other path-related values, are set by JBoss as system properties, which you should use to obtain them.
For example, the system property jboss.home.dir will be set to the equivalent of $JBOSS_HOME, regardless of how the server is actually started.
The various system properties are defined in org.jboss.system.server.ServerConfig.
So:
String jbossHomeDir = System.getProperty("jboss.home.dir");