So i have a Batch Script which i got trough a task at work, there is an error inside the script which i lokated at the following position of the code
REM Install service
echo register Service...
%INSTALL_PATH%<name_of_exe>.exe //IS//%SERVICE_NAME% #error here
echo successfully installed %SERVICE_NAME%.
So as squashman told after starting of an .exe there follow parameters. So to this point it is clear,
//IS//%SERVICE_NAME% #is parameter
So i want to know if //IS// is some kind of "batch-magic". So it is not some kind of crazy Windows Path since there are "/" not "\". So my it is some kind of character-escaping?
So i found it out.
There is a Programm called Procrun from ApacheCommons with the following description
Procrun is a set of applications that allow Windows users to wrap (mostly) Java applications (e.g. Tomcat) as a Windows service.
The service can be set to automatically start when the machine boots and will continue to run with no user logged onto the machine.
So now the Problem line was easy to understand since the .exe belongs to procrun.
<name>.exe //IS//%SERVICE_NAME% # //IS - install service
# //%SERVICE_NAME% - the name
Related
I have Teamcity currently setup to run a batch file, this batch file executes a fortify scan. It seems the environment variable 'PATH' had loaded correctly on one attempt and started to perform the scan. On the next build attempt the batch file couldn't locate one of the executable(sourceanalyzer.exe). When looking into the user defined parameters it seems different environment variables were loaded than the previous build attempt. It looks like the system environment variables load on the successful attempt and then a users environment variable loaded on the failed attempt. Is there a way to permanently set the environment variable PATH in the agent to load only the system environment variables?
UPDATE:
I have tried several things, to include passing in a Fortify environment variable, which does allow TeamCity to start running the scan. However, it looks like I hit another snag with Fortify's plugin for vs2015. The new error states it cannot find the plugin. I assume this is because pathways are hard coded? Seeing as TeamCity doesn't use the System environment variables and I have to pass them in for TeamCity to find these directories. Is there an easier way to use the batch file to load the system environment variables to avoid hard coding pathways? Would setlocal in the batch file help load these system environment variables, so I can just call sourceanalyzer with out creating environment variables or hard coding pathways?
IIRC, Teamcity will ask you if you want to install the build agent on the System account or the user account. By default it selects the System account and as long as you aren't running any GUI apps, you won't notice the difference... until something like this happens. If Fortify is GUI based, then reinstall your build agent on the user account and ignore the following. Otherwise...
When you set your PATH variables using the System(Control Panel) advanced settings, there are two panes, one for user and one for system. Here you can inspect the System variables to make sure they are correct.
What I will generally do is create a new key, say FORTIFY_PATHand prepend %FORTIFY_PATH% to the System PATH variable. THEN RESTART YOUR MACHINE. The path won't get updated correctly until you do.
Next, login to the system account using PSExec: https://superuser.com/a/596395 and try to run your tools from that command prompt to verify that they are working in the build agent's environment. I once had trouble getting an SVN script to upload until I logged into the System account and provided my SVN password. Some settings are stored in %APPDATA% which is different from the user account.
If you can't get Fortify to run from the System command prompt, then you should probably reinstall your build agent to your user account. Or install Fortify to the System account (if possible).
When configuring TeamCity build agents, check the agent system and environment variables By going to Agents->Agent->Agent Parameters, or the /agentDetails.html?id=1&tab=agentParameters&kind=envpath on your server.
After changing the parameters, restart the agent or restart the agent's machine.
How do i do this?
i've tried all i can think of.
Browsing for my .exe file i want to run.
run a bat file
writing forcedos.exe in program textbox and path to my bat file in command line parameters textbox
Why cant it just work with an normal exe?
and i know it should run a program because it can restart the service correctly.
EDIT
Application: test.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Exception
This is my latest try to make it work.
the script has the code
Dim objShell
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.Run("iexplore")
Set objShell = Nothing
Now the script opens internet explorer if i run the cmd command
wscript.exe "C:\asfh.vbs"
The "run a program" recovery option for when a service crashes runs the specified executable in the same way as the service, i.e., it runs in session 0 (and so is affected by session 0 isolation, see also related questions) and it runs with the same security context as the service.
This means that it can't interact directly with the user (you can display a GUI, but nobody will see it) but it also restricts what the executable or script can do. For example, some shell API functions will not work properly unless the user account has been interactively logged in at some point. In the example script you posted, the script itself is probably running, but is unable to launch Internet Explorer because IE is only designed to run in an interactive session.
Provided you restrict yourself to basic functionality, it should all work as expected. (There is no master list that I know of describing what functionality is safe to use in a service context, but it is usually easy to guess. You can resort to trial and error if necessary!)
Also note that as far as I know forcedos.exe is no longer present in modern versions of Windows. If you want to run a batch file, you can specify cmd.exe as the application and /c myscript.bat as the command line parameters.
I created a new free-style software project and under "Configure", I added a "Execute Windows batch command" under the section "Build".
My command in the text-box is as follows:
call \\ukvc-miu29-12\c$\Testing1\testing.bat
My console output when I try to run my build is as follows:
Started by user anonymous
Building in workspace C:\Program Files (x86)\Jenkins\jobs\Run comparison script\workspace
[workspace] $ cmd /c call C:\Windows\TEMP\hudson1649447975658279345.bat
C:\Program Files (x86)\Jenkins\jobs\Run comparison script\workspace>call \\ukvc-miu29-12\c$\Testing1\testing.bat
Access is denied.
C:\Program Files (x86)\Jenkins\jobs\Run comparison script\workspace>exit 1
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
Have spent close to two hours looking for a solution online, but I am unable to find one.
New to Jenkins, so any suggestion/s is/are appreciated, thanks!
I guess Jenkins runs as another user than the one you're logged in with. So that user probably isn't allowed to access that network share (or doesn't have the login credentials cached).
The easiest way of making sure it will work, would probably be to add the same user with the same password that Jenkins runs under to \\ukvc-miu29-12.
(As for the call, I'm not sure you really need it and I have a vague suspicion that you end up failing the build every time if you use call here. The temporary batch Jenkins executes there looks like it relies on the fact that control won't return if the batch file was executed successfully. But that's just a guess on my part.)
I have a batch file which uses gpresult /v and saves the output in a text file and copy that text file to a shared folder. This batch when i run on my local machine works perfectly fine but once i deploy it through SCCM it says can not open file with error code 4. I dont know what is wrong in the file.
the code is Like this:
#echo off
gpresult /v >%computername%.txt
xcopy %computername%.txt \some path
Error 4 is "The system cannot open the file.", as if the path is invalid or the open() fails for some other reason.
Do you know what directory the program is running in (CWD)?
That's where the results of gpresult are going (if the output redirection succeeds).
gpresult is not going to produce meaningful user-level data for the SYSTEM user.
Perhaps you should use gpresult /v scope computer.
Why are you using xcopy when you're only copying one file? xcopy really only has added value (over copy) if you are copying directories.
xcopy's behavior changes depending on how you specify the target. If the target ends with the directory separator (backslash), xcopy treats it like it's a directory. If it doesn't and the target doesn't exist, xcopy asks you what to do, which causes automated processes to pause indefinitely waiting for user input.
SCCM Programs Run as 'NT Authority\SYSTEM'
When SCCM (2007) runs a program, the program doesn't run as a regular user. It runs as the highest privilege user (sort of), SYSTEM.
This account is not a regular account, and many settings and environment variables that exist and are predictable for a regular user are different or do not exist for SYSTEM.
One particularly frustrating "feature" of the SYSTEM account's profile is that it is nestled away under %WINDIR%\System32, and so it is subject to filesystem redirection whenever you refer to anything relative to the profile.
Try this: use psexec -s (sysinternals) to get shell access as the SYSTEM account and run the command in that environment to see how it behaves. This is as close as we can get to an environment like the one SCCM programs run under.
When SCCM runs the command, the CWD will probably be somewhere under %WINDIR%\SysWOW64\CCM\ and may be invoked with the 32-bit version of CMD.EXE.
I have a question in regards to something similar to this. So I have an uninstall bat that runs. Due to the vendors uninstall it causes a force close of the windows explorer UI. So in haste to solve that issue I added a call to open explorer.exe. There is a problem with this as someone pointed out to me. Actually as soon as he said I knew exactly what he was saying and where he was going with his statement. Calling explorer.exe would be fine except that the bat is running under the system context not the user so when explorer is restarted it will start under the guise of the system desktop profile not the user's. I know there is way to still run under the guise of system but to restart explorer under the currently logged in user's profile.
I'll try to keep this short, without all the details of this batch file procedure.
OS: Windows XP
Action: Scheduled Task (background, I can't find a way to run it in the foreground)
Problem: files not created on mapped drive. When the batch file is ran directly, it works.
It does the following (or at least tries to):
clean a directory: works
create executables based on a substituted location
We use the following to map a local folder to the K: drive:
subst K: /D
subst K: D:\Development\SVN
The executables are built from source code that is located on (for example) K:\Sources to K:\Executables.
This fails, for a reason I did not yet discover. As mentioned above, if the batch file is ran directly it doesn't fail. If I substitute K:\ by C:\Development\SVN the issues seem to be resolved but still, this doesn't solve the fact that I can't run it when using K:.
I hope anyone here has an idea, I tried Googling for a long time + scanning SO but to no avail.
Thanks in advance!
substed drives are local to session, and your scheduled task is run in another session then your login session.
It seems to be possible to schedule task for user login session with schtasks.exe command line, but then the task runs only if the user is logged in. It might not be what you want, so using a full non-substed path might be the best solution after all.