During the installation that I made I run in custom action file called ConfigurationUtility.exe witch should create a SQL database with some parameters. It should run some scripts in directory \scripts where the utility is copied. But I have this error in event log: "Action ConfigurationUtility.exe, location: C:\Windows\Installer\MSI4724.tmp, command: -dbname NewDB -username sa -password .....
I think it's happens because the installer trying to run it from C:\Windows\Installer\MSI4724.tmp but not from the Installation folder.
Setup package is built with Advanced Installer.
How can I fix it?
Thanks.
You have not configured the custom action correctly.
If you want it to run some scripts from the installation folder where it is placed you should call the EXE using the custom action "Launch installed file". You should not launch it as an attached file custom action (only this type of custom actions get extracted as temp files and launched as in your example)
Also, since this is an EXE I recommend you give it full admin rights to run, otherwise the system might stop it from running. To do this configure the custom action to "When the system is being modified" and "Run under the LocalSystem account with full privileges", and make sure it is scheduled to run after "Add Resources" group (where Advanced Installer ads it by default)
Related
I use dtexec to run ssis packages and I use the dtexec...>e:\log.txt command to write console messages to a txt file. It works fine if I run it manually, but it is not working if I put it in task schedule. It seems no permission to create the log.txt file. I checked the "Run with highest Privileges" option. But I use the same account as I do this manually.
I have a custom Java app and an IzPack installer. For years, in my izpack build file I had the following:
<run-privileged condition="izpack.windowsinstall.vista|izpack.windowsinstall.7"/>
The problem is that some of the users do not have admin privilege on their PCs, but they still want to be able to install the package. If I remove the above, they can run the installer but then it complains "This directory cannot be written!", when they try to install in the default location, which is C:\OPENDCS.
Yet the same user can create this directory either from a CMD or an Explorer window.
Is there a way to allow the izpack installer to create a directory directly under C:\ without running as an administrator?
Please check the behavior with izpack v5.0.7. The problem you mentioned should be fixed with this issue: https://izpack.atlassian.net/browse/IZPACK-1355
You could package your directory create operations in a create-dirs.bat batch file, which you would mark <executable> and execute stage="postinstall". This way the directory creation will be executed with the given user's permissions, which (according to your post) should work just fine.
EDIT 29/02/2016: You would put this file into a first "dummy" <pack>, mark it <executable> and execute stage="postinstall" as stated above, which would execute it after this first dummy pack was installed. At the installation of the next pack (i.e. your first useful pack) you will already have the folder created.
Note that postinstall will not run the batch file after the installation, but after the <pack>'s installation.
I'm trying to use the Microsoft User State Migration tool with Powershell; the way the program "loadstate.exe" works is that it needs to be called locally so that it will load up a remotely saved state of the user's profile and then restore it to the local computer.
I am seeking to automate this with Powershell; in order to do this, I have written a script that will elevate the user to run Powershell in Executive/Administrative mode and then execute the following command, against the USMT program that is installed on all of our computers:
c:\usmt\loadstate.exe /i:$configfile $storepath
Where $configfile is the name of the configuration file and the store path is the name of where the files are stored at. This all works, except that when run from remote, it seems to try to execute it from the System context - the desktop files are instead restored with the ACL permissions of CREATOR OWNER, SYSTEM, and Administrators - rather than giving it to the actually logged on user.
So if I have it set as a logon script, and try to have it execute when the user GuineaPig logs in, it will seek to restore the files and it will actually restore it - but all desktop items will be invisible to GuineaPig because she doesn't have any rights to see them.
If I just have the script locally, say on the user's C:\ DRIVE, and then right-click and "Run as Powershell Script", it works fine.
How do I execute this remote powershell script(located on our domain controller) so that it will actually run it in the context of the local user?
Alternately, how do I just tell the Group Policy of a logon script to just run something from the user's computer? I can also just set the script to be copied to the C:\ of every local computer, I just need the logon policy to actually run it from the C:\ of every local computer as the locally logged on user.
Thanks in advance.
I prepared an MSI project of my app and added a custom action in the commit stage to run the exe of the app after finishing the install. After finishing the setup , it try to run the exe by it failed . I debugged the problem , it was because the execute directory is system32 and not the setup folder . if I run the exe normally from the setup folder , it run normally.
Any suggestion what is the cause.
Thanks
Wasim ...
If you want to launch the installed application after installation completes, you should do it after InstallFinalize action. Look at WiX tutorial to see how to add this feature.
Update: To add checkbox to the Completion page and run the installed application, look at this question. There's a link to an article which describes how to do it with a script to do it. Then you will have to add the condition, the steps can be found in my answer there.
You can try using a type 34 custom action (EXE with working directory).
I'm using Windows Server 2003 to try and execute a PHP script every day at 9AM. Here's the command inside of run:
"C:\Program Files\Zend\ZendServer\bin\php.exe" C:\Program Files\Zend\Apache2\htdocs\signout\teachernotify.php
It's supposed to execute the PHP script above which is supposed to e-mail me, but it doesn't work. Accessing the script above through a browser works, but not through Scheduled Tasks.
When I run it through the task scheduler, it goes through like something happened, but it doesn't appear to work.
Any advice?
Thanks
It sounds like it could be a permissions problem. When run through Apache via a web browser, the permissions would be based on whatever permissions Apache is running under. As a scheduled task, the permissions are based on the user specified for the task.
Make sure that the user specified in the "Run as" field in the task settings dialog has permissions to send an email.
Based on your most recent comment, it seems the problem is that the filename needs double quotes around it. I failed to notice that in the original question.
"C:\Program Files\Zend\ZendServer\bin\php.exe" "C:\Program Files\Zend\Apache2\htdocs\signout\teachernotify.php"