I have an application which needs to run with different user name.
I am trying to call "runas.exe" to call the batch file which calls my application.
When I tried this in command prompt it worked fine. One drawback is I have to provide password
I am wondering if this is possible as this runs on build sever without anyone intervention
Here http://blogs.msdn.com/b/oldnewthing/archive/2004/11/29/271551.aspx Microsoft explains why we cannot give password as command line parameter
I don't know what could be the better approach. Can anyone suggest any good alternative
I use Windows 2008 R2 64 bit
You can't do this, unless you write a small program which does this for you. Batch won't cut it for obvious security reasons.
A sample program that will work in windows xp can be found here.
Related
Can PowerShell be automated? I.e. is there a COM interface to PowerShell that can be imported into Delphi as a type-library interface to automate it, and if so, what is the relevant file name(s)?
Googling, etc, I've found numerous references to automating things from within a PowerShell script, but I haven't been able to find anything to say whether or not I could control PowerShell itself via COM as I could it it were MS Word or whatever, and maybe receive events from it. What I'm wanting to do is to hand it a command from within a Delphi app to execute some arbitrary CmdLet and get status information back from it while it's executing the script (otherwise I'd make do with doing a ShellExecute on it).
I'm not sure whether the fact that I have been able to find anything is because PowerShell is by design not automatable or because I haven't managed to frame an effective query that filters out all the automation that can be done using PowerShell as a script host.
This is using XE8 on Win7 64-bit or its Win10 upgrade, btw.
Elaborating on RaelB's suggestion of http://delphidabbler.com/software/consoleapp:
This worked for me since Powershell itself can be run as a console app. If you wanted to run CmdLet "abc -param", then you would call the Execute method of a TPJConsoleApp instance:
app.Execute ('powershell -command abc -param')
Peter Johnson (delphiDabbler) provides several examples for interacting with the console app via pipes, files, etc. to get your status information back from the Cmdlet's stdOut (stdIn and stdErr are also available). Working code can be quickly derived from the most appropriate example.
Optionally you may want to provide additional parameters for powershell:
https://msdn.microsoft.com/en-us/powershell/scripting/core-powershell/console/powershell.exe-command-line-help
I was starting Windows Azure using WebSites, now I'm facing with the situation where I need Crystal Reports in my site, so I'm looking for a way to install the Redistribute Files to use it in my web page to generate reports.
I follow this page:
http://dotnetspeak.com/2012/07/running-crystal-reports-on-windows-azure
So instead of having a simple website, I'm gonna use a cloud app. Unfortunately, I'm updating frequently my website (role in Windows Azure project).
Do I need to redeploy all the time my cloud app each time I update my MVC project? Because it takes so long (like an hour, because I included a msi installer)
Thank you
Unless you build some custom extensibility into your application with some very robust dependency injection, yes, you have to redeploy.
EDIT: After re-reading your question again, I realised that you're using Windows Azure Websites.
The correct way to accomplish this is to use a webrole rather than the Websites
What you need to do is to store the installer as a blob in Cloud Storage.
Then part of a Azure Startup Task you can download from the blob and execute the installer.
If possible, you can also use the WebPICmdline (i.e the Web Platform Installer Commandline) to download and install for you from the Startup Task.
Steve Marx has done a few posts on using Azure Startup tasks. Here is one of them http://blog.smarx.com/posts/windows-azure-startup-tasks-tips-tricks-and-gotchas
Adding a bit to #Robert's answer: If the actual execution of the MSI is taking an hour, then this is not a very good use case for web/worker roles. Anything that takes more than a few minutes doesn't really fit well with the stateless scalable model. If that's the case, you should consider running a Virtual Machine for running Crystal Reports. Then you can use your web role for everything else.
If, on the other hand, the one-hour time is mostly consumed by the uploading of the MSI, then I'm completely in alignment with Robert: Store the MSI in a blob, and then download it to your role instances upon startup.
I would suggest to split your single Cloud project into two - one for Crystal Reports only. This way you can deploy it separately from MVC site. You could also build extra smarts into start up task, maybe checking if Crystal is already installed. However, I think splitting them up should be good enough for you
Normally the update process does not lead to an complete re-image of your webrole, only the approot gets destroyed! Here you can find a very detailed information about what is happening on update and deployment: http://msdn.microsoft.com/en-us/library/windowsazure/hh472157.aspx
What does that mean to your problem? Code deployment is an "in-place update" process. If you install Crystal Reports in Drive C: or D: it wont get destroyed on each deployment.
In your Start-Up Task you have to check, whether the software is already installed, or not. In case it is not installed, just install it, as mentioned above on Drive C: or D:
Edit: I got the Point: Does your update Process takes so long, because of the file-size of your MSI? If so, i also suggest to upload the MSI into Blob-Storage.
I found interesting problem with Win7/X64 machine.
For this time I haven't got problem with Delphi 6 and UAC.
The exes are working in their's place, so I can use Delphi debugger with them.
But today I got error on run the project: "Unable to create process. For this operation you need higher user level".
How can I prevent this side-effect?
What causes this?
I don't understand why the older projects are running fine, but this new isn't...
Thanks for every idea, link, information!
Additional info:
Normally I using the Delphi 6 IDE with normal starting (without SysAdmin rigths).
So it is never asking me with "really?" kind UAC questions.
And every of the older projects are usable with Delphi 6 - I can build, run, debug everything.
This problem happened with only this project, so I try to find the differences if possible to solve the problem.
I using normal directory ("c:\dev\anyproject"), others are using "c:\dev\otherproject1..2..n").
Does your application request elevation when started from Windows Explorer?
Does it have a manifest?
The name of the exe, like setup.exe, could also trigger elevation. See an outline of the Installer detection technology.
Non-elevated process can't debug elevated process.
If your application requires elevation at the start, then you would need to run the IDE elevated to be able to debug it.
Starting your IDE as an administrator should solve the problem (option in the context menu).
If not, you could always disable UAC while developing.
There is a number of limitations that needs administrator's rights.
For example: you cannot write data directly into program files directory.
i have an application which call another console application and pass to it some parameters (console app is a video/audio coverter app) ... is there a way to programmatically "spy" or catch the passed paramters other than hooking/monitoring shellexecute/CreateThread etc ?
Create an executable yourself that just calls the original and passes all parameters on to it. Then move the original somewhere else and replace it with your exe. Your program can then log all calls to it, including all parameters.
Yes, there is - as you write Process Explorer is able to do it, and you could employ the same technique. But AFAIK there's no Delphi translation of the winternl.h file from the Platform SDK, so it is even more tedious and difficult. Also this is extremely version-specific, and there are chances it will break with the next Windows version. It's also not quite clear whether this works for 64 bit processes (from a 32 bit process).
If you really want to do it you will find the necessary information in this blog posting by Matt Pietrek, and in the CodeProject article "Read Environment Strings of Remote process".
If you do not plan to use it for closed source commercial programs then a look into the (GPL licensed) annotated version of the winternl.h file from the ReactOS project would probably also help.
It's a Win32 FAQ since 1992 : just read the PEB.
See on Win32 experts group.
My problem is to create an ant target for automating our installer running in console mode.
The installer is created using InstallAnywhere 2008, which UniversalExtractor recognizes as a 7-zip archive. Once I have the archive unpacked, it appears that the task can use an input file to drive the console (at the very least, it appears that emitting a quit shuts everything down correctly, and output is captured).
So it looks to me as though I have all of the pieces I need for proving out this idea except a clean way to perform-self-extraction-then-stop. Searching for a command-line argument to stop the auto execution has not produced a likely candidate, and the only suitable ant task I've found ( http://www.pharmasoft.be/7z/ ) isn't so clearly documented that I have a lot of confidence in it.
The completed completed is expected to work in Windows, Linux, and a small handful of other Unix environments.
What's the best practice to use here?
Since you control the installer creation, can you run the self-extraction step on your machine, package the results before the installer is launched in a ZIP file, etc. and use that instead of the single file executable? Not very elegant but it may work.
Also, I am a bit hesitant to blatantly promote my project :) but since it has been a while since you asked the question and nobody has answered, have you considered an alternative? Our project InstallBuilder allows you to install in unattended mode directly, without having to autoextract the contents. Just invoke the executable with --mode unattended, pass any additional options you may need from the command line or an external file and you are good to go. We have a lot of ex-InstallAnywhere customers :)