I'm attempting to use MsDeploy runCommand provider to uninstall and reinstall a Windows service during an automated deployment.
So far, I've been somewhat successful when following the advice in this question and this blog post.
To perform the actual install/uninstall operations, I'm calling a batch file on the remote host. The batch file works as expected when I log into the host directly and use the 'Run as Administrator' option from the shell. When simply running the batch file by double-clicking (or when running the batch file with the MsDeploy runCommand provider), the batch file doesn't have sufficient permissions to perform the install or uninstall operation. In all cases, I'm running the batch file with a user account that is a local administrator on the host.
I've confirmed that runCommand is using an administrator account through the Management Service Delegation tool, and restarted the Management Service just for the heck of it.
My questions know are:
1) How can I emulate the 'Run As Administrator' with the runCommand provider?
2) If I use a Powershell script instead of a batch file, would this still be a problem?
3) Is there something basic I'm missing here?
I would really not have to write real software to perform this action on the remote host!
Any advice would be appreciated.
Have you tried the runas MSDOS command?
runas /user:mycomputer\myusername somecommand
I want to scan the files that are uploaded to my Azure blob. It looks like ClamAV (www.clamav.net) is probably the way to go. I see instructions on how to install on a Windows server, but what would my procedure be for a site hosted on Azure? I am using ASP.NET MVC.
Disclaimer: I haven't used ClamAV. Having said that...
You should be able to install it during a startup task (with elevated privileges). I looked at the ClamAV wiki, and it appears that the msi has a silent-install:
msiexec /i clamAV.msi /qr
You'll need to change that last parameter to /qn to force "no user interface."
The challenge will be scanning blobs. You'll need to copy files from their blobs to a local directory in your VM instance, and then run clamdscan on that file (basing off the wiki).
I haven't tried this, but the basic premise should hold up: Install anything requiring an MSI as a startup task (probably needs elevated mode).
Frequenlty my work involves to VNC to a remote system and work on it. SInce i run command line apps on this remote system most of the time, i was wondering if there's an alternative software to command prompt which i could install on my local machine. Using this i should be able to create a session with the remote system and from then on all commands issued in command prompt should run in remote system.
localHost>dir --> should list the directory contents in remotehost active directory
localhost>app.exe should run app.exe in remote host and display its contents in localhost command prompt
I browsed a little and read about cmdlets in powershell. But it looks like i need to write a cmdlet for each app in the path (dir, mkdir, app.exe in the path). Correct me if am wrong. Once session is established, i simply need the commands invoked in local host to be run in the remote host and return the console output to local host. Please let me know if powershell + cmdlets are the only way
THanks
Just use PowerShell Remoting if it can be set up (requires a little preparation).
I'm not quite sure why you think of writing own cmdlets for stuff that's already there. dir is an alias to Get-ChildItem which does return the items in the current path (and—depending on options—some other stuff as well). And since PowerShell is a shell it has no problems running external programs too.
SSH is what you're looking for. Cygwin has a SSH server and client.
Unix people do this all the time with SSH. You can install the sshd server on your remote machine through Cygwin, then use PuTTY to connect to it.
As a bonus, PuTTY does not use the clunky Windows cmd.exe program; it's got a much nicer terminal of its own.
You could maybe even run PowerShell on the remote end, so you don't have to learn bash.
Depending upon on how you actuall access the machines PSExec may be an alternative that wont require you to install anything on the remote system.
I followed these instructions while trying to get remote debugging working with Delphi 2007. After completing all the steps, the remote debugger is half working.
It is able to launch and halt the application but the break points I set do not work. The automatic break point (at line Application.Initialize;) is working but it goes right to the CPU window. The debugging information appears to be missing.
I triple checked, both 'Include TD32 debug info' and 'Include remote debug symbols' are checked, a clean build was performed, and the correct files have been moved to the remote machine.
What am I missing?
Any help would be greatly appreciated.
You might like to go through my own checkist for this, which is as follows. I hope its not too patronising, but there may be a step you've omitted. I also seem to recall that it was improtant to use IP addresses, not names. Also note that these instructions are for D7, howver I'm not aware that the principle has changed.
=======
In this description, TARGET refers to the machine being debugged (i.e the remote machine) and HOST refers to the machine being used fro debugging (i.e the local machine).
If necessary, install the remote debugger on the target by copying the RDEBUG folder to the target and running SETUP.
Run the remote debugger locally on the target using Start | Borland Remote Debugger | Remote debugger. A ‘spider’ icon should appear in the task bar. (It can be useful to double-click on this icon to obtain a connection status dialog – this shows how the local IDE is connecting to the remote in later steps here).
On the host machine, explode the project to be debugged. Check that this compiles locally and runs offline.
By convention, copy the SOFTWARE ROOT folder from the host to the target. This will be the working folder for the application when debugged. By copying the folder in its entirety, all support files will be found locally as needed. (This also fits nicely with using SecondCopy to duplicate the entire ART software tree on a remote machine and then to explode the required project – this will create the remote folder for you).
In the Delphi IDE on the local machine, use Run | Parameters | Remote to set the Remote Path to the remote exe file in the folder you have just copied, as it will be visible on the target machine. If you’ve copied it as instructed in ‘4’, this path will be identical to the file that the local IDE would create and debug, eg “C:\Art_Soft\RT290\Bench\Dev4all\RT290w.exe”
In the Delphi IDE on the local machine, use Run | Parameters | Remote to set Remote Host to the IP address of the target (you should use IPCONFIG on the target to find out what the IP address is). Before leaving the dialog, select ‘Debug Project On Remote Machine’.
Enable “Include remote debug symbols” on the “EXE and DLL options” pane under Project|Options|Linker
Compile and run the file from the IDE. The remote connection status should show connection progress and a the remote screen should show the application running.
What are the correct files? I assume both the .exe and .rsm file?
(disclaimer: I only know remote debugging in D2009)
I'm currently running Vista and I would like to manually complete the same operations as my Windows Service. Since the Windows Service is running under the Local System Account, I would like to emulate this same behavior. Basically, I would like to run CMD.EXE under the Local System Account.
I found information online which suggests lauching the CMD.exe using the DOS Task Scheduler AT command, but I received a Vista warning that "due to security enhancements, this task will run at the time excepted but not interactively." Here's a sample command:
AT 12:00 /interactive cmd.exe
Another solution suggested creating a secondary Windows Service via the Service Control (sc.exe) which merely launches CMD.exe.
C:\sc create RunCMDAsLSA binpath= "cmd" type=own type=interact
C:\sc start RunCMDAsLSA
In this case the service fails to start and results it the following error message:
FAILED 1053: The service did not respond to the start or control request in a timely fashion.
The third suggestion was to launch CMD.exe via a Scheduled Task. Though you may run scheduled tasks under various accounts, I don't believe the Local System Account is one of them.
I've tried using the Runas as well, but think I'm running into the same restriction as found when running a scheduled task.
Thus far, each of my attempts have ended in failure. Any suggestions?
Though I haven't personally tested, I have good reason to believe that the above stated AT COMMAND solution will work for XP, 2000 and Server 2003. Per my and Bryant's testing, we've identified that the same approach does not work with Vista or Windows Server 2008 -- most probably due to added security and the /interactive switch being deprecated.
However, I came across this article which demonstrates the use of PSTools from SysInternals (which was acquired by Microsoft in July, 2006.) I launched the command line via the following and suddenly I was running under the Local Admin Account like magic:
psexec -i -s cmd.exe
PSTools works well. It's a lightweight, well-documented set of tools which provides an appropriate solution to my problem.
Many thanks to those who offered help.
Download psexec.exe from Sysinternals.
Place it in your C:\ drive.
Logon as a standard or admin user and use the following command: cd \. This places you in the root directory of your drive, where psexec is located.
Use the following command: psexec -i -s cmd.exe where -i is for interactive and -s is for system account.
When the command completes, a cmd shell will be launched. Type whoami; it will say 'system"
Open taskmanager. Kill explorer.exe.
From an elevated command shell type start explorer.exe.
When explorer is launched notice the name "system" in start menu bar. Now you can delete some files in system32 directory which as admin you can't delete or as admin you would have to try hard to change permissions to delete those files.
Users who try to rename or deleate System files in any protected directory of windows should know that all windows files are protected by DACLS while renaming a file you have to change the owner and replace TrustedInstaller which owns the file and make any user like a user who belongs to administrator group as owner of file then try to rename it after changing the permission, it will work and while you are running windows explorer with kernel privilages you are somewhat limited in terms of Network access for security reasons and it is still a research topic for me to get access back
Found an answer here which seems to solve the problem by adding /k start to the binPath parameter. So that would give you:
sc create testsvc binpath= "cmd /K start" type= own type= interact
However, Ben said that didn't work for him and when I tried it on Windows Server 2008 it did create the cmd.exe process under local system, but it wasn't interactive (I couldn't see the window).
I don't think there is an easy way to do what you ask, but I'm wondering why you're doing it at all? Are you just trying to see what is happening when you run your service? Seems like you could just use logging to determine what is happening instead of having to run the exe as local system...
Using Secure Desktop to run cmd.exe as system
We can get kernel access through CMD in Windows XP/Vista/7/8.1 easily by attaching a debugger:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"
Run CMD as Administrator
Then use this command in Elevated:
CMD REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"
Then run osk (onscreenkeyboard). It still does not run with system Integrity level if you check through process explorer, but if you can use OSK in service session, it will run as NT Authority\SYSTEM
so I had the idea you have to run it on Secure Desktop.
Start any file as Administrator. When UAC prompts appear, just press Win+U and start OSK and it will start CMD instead. Then in the elevated prompt, type whoami and you will get NT Authority\System. After that, you can start Explorer from the system command shell and use the System profile, but you are somewhat limited what you can do on the network through SYSTEM privileges for security reasons. I will add more explanation later as I discovered it a year ago.
A Brief Explanation of how this happens
Running Cmd.exe Under Local System Account Without Using PsExec. This method runs Debugger Trap technique that was discovered earlier, well this technique has its own benefits it can be used to trap some crafty/malicious worm or malware in the debugger and run some other exe instead to stop the spread or damage temporary. here this registry key traps onscreen keyboard in windows native debugger and runs cmd.exe instead but cmd will still run with Logged on users privileges, however if we run cmd in session0 we can get system shell. so we add here another idea we span the cmd on secure desktop remember secure desktop runs in session 0 under system account and we get system shell. So whenever you run anything as elevated, you have to answer the UAC prompt and UAC prompts on dark, non interactive desktop and once you see it you have to press Win+U and then select OSK you will get CMD.exe running under Local system privileges. There are even more ways to get local system access with CMD
an alternative to this is Process hacker if you go into run as... (Interactive doesnt work for people with the security enhancments but that wont matter) and when box opens put Service into
the box type and put SYSTEM into user box and put C:\Users\Windows\system32\cmd.exe leave the rest click ok and boch you have got a window with cmd on it and run as system now do the other steps for yourself because im suggesting you know them
There is another way. There is a program called PowerRun which allows for elevated cmd to be run. Even with TrustedInstaller rights. It allows for both console and GUI commands.
(Comment)
I can't comment yet, so posting here... I just tried the above OSK.EXE debug trick but regedit instantly closes when I save the filled "C:\windows\system32\cmd.exe" into the already created Debugger key so Microsoft is actively working to block native ways to do this. It is really weird because other things do not trigger this.
Using task scheduler does create a SYSTEM CMD but it is in the system environment and not displayed within a human user profile so this is also now defunct (though it is logical).
Currently on Microsoft Windows [Version 10.0.20201.1000]
So, at this point it has to be third party software that mediates this and further tricks are being more actively sealed by Microsoft these days.
if you can write a batch file that does not need to be interactive, try running that batch file as a service, to do what needs to be done.
I use the RunAsTi utility to run as TrustedInstaller (high privilege). The utility can be used even in recovery mode of Windows (the mode you enter by doing Shift+Restart), the psexec utility doesn't work there. But you need to add your C:\Windows and C:\Windows\System32 (not X:\Windows and X:\Windows\System32) paths to the PATH environment variable, otherwise RunAsTi won't work in recovery mode, it will just print: AdjustTokenPrivileges for SeImpersonateName: Not all privileges or groups referenced are assigned to the caller.
Using task scheduler, schedule a run of CMDKEY running under SYSTEM with the appropriate arguments of /add: /user: and /pass:
No need to install anything.
i used Paul Harris recommendation and created a batch file .cmd or .bat with what ever command i needed to run under system and used the schedule task run one time.
than trigger it as needed. and updated the batch as needed. so any command i need to run under system i just update the batch.