I want to copy the file to a network drive using build agent (powershell or cmd (Build Steps)).
P:
# or
cd P:\foolder\
# ...
But the commands don't work. Build log: "Disk P not found".
The disk is connected via windows. When running from windows, the commands work.
I assume java/BuildAgent doesn't have rights. But my user has rights. And java, and BuildAgent runs under my user.
Please, do not offer FTP
Open command prompt as Administrator
bind your drive again using below command
net use x: \\10.1.2.3\Share
again do the same in Command prompt without administrator (if its not bounded)
Related
My OS is Windows 10 (x64) and I installed both Powershell 7 and cygwin.
Then, I installed "sshpass" using cygwin.
And, here are the cases I am experiencing right now.
From cmd, if I enter "C:\cygwin64\bin\mintty.exe -", cygwin pops up with initial directory "~". Then, if I type "sshpass -p<password> ssh <username>#<host>", it perfectly works smoothly!
From cmd, if I enter "C:\cygwin64\bin\mintty.exe", cygwin pops up with directory "/cygdrive/c/Users/myname". Then, if I type "sshpass -p<password> ssh <username>#<host>", it asks me to type the password. This means that sshpass is not working correctly here.
From powershell, if I type "C:\cygwin64\bin\sshpass.exe -p<password> C:\cygwin64\bin\ssh <username>#<host>", nothing happens.
My questions are the following:
How do I properly run sshpass command in Powershell?
Let's say my ip address is 1.1.1.1 and I am connecting to a server whose ip is 2.2.2.2, and both computers OS systems are Windows. When I connect to the server through ssh, it shows the "cmd" terminal of the server. How can I change it to show "cygwin" terminal when I connect to the server?
I am having very hard time fixing this out.. Thank you very much in advance..
I am not sure i am getting this, anyway, if i understand correctly you have a hard time launching sshpass from powershell.
Try using Start-Process commandlet: (maybe add the full path to ssh in arguments (?))
start-process -filepath C:\cygwin64\bin\sshpass.exe -ArgumentList '-p<password> ssh <username>#<host>' -Wait -NoNewWindow
Anyway instead of reaching linux commands to windows and run it from powershell, why don't you check powershell modules?
ssh using powerShell script by passing the password along with the Commnad
Also, Powershell Remoting towards linux is a thing nowadays, and it runs over ssh (not bash afaik)
I can open a powershell and type
> Ubuntu
to open a WSL ubuntu shell on windows 10. This will always take me to the WSL home directory. How would I instead open the terminal in the same location that the powershell is currently in?
FYI. I need this for creating a right click "open terminal here" type registery key for windows explorer.
If we look at what running ubuntu.exe actually does:
PS C:\> ubuntu.exe /?
Launches or configures a Linux distribution.
Usage:
<no args>
Launches the user's default shell in the user's home directory.
install [--root]
Install the distribution and do not launch the shell when complete.
--root
Do not create a user account and leave the default user set to root.
run <command line>
Run the provided command line in the current working directory. If no
command line is provided, the default shell is launched.
config [setting [value]]
Configure settings for this distribution.
Settings:
--default-user <username>
Sets the default user to <username>. This must be an existing user.
help
Print usage information.
We can see that it by default launches the WSL shell inside the home directory. If we want run inside it inside the current directory open in PowerShell, we need to specify the run option. So the full command will be ubuntu.exe run.
Another option is to just run wsl.exe or bash.exe. These commands will by default open WSL in the current working directory.
Note: We don't need to specify the .exe after the commands. Running ubuntu, wsl and bash all work as well. PowerShell knows how to run executables without specifying the extension.
method 1:
set Ubuntu to wsl default distribution by wsl --set-default Ubuntu
just type wsl and you are in the current Powershell directory
method 2:
open other folder
wsl.exe --cd $pwd or wsl.exe --cd "path"
I have a .msi file in my remote machine which is in a different domain from my local machine. I am able to connect to the remote machine with powershell but how can I install the msi there. The installation process has a lot of inputs to be given along with pressing 'Next' and then again giving a particular input and radio buttons and many more. Thus it is an interactive installation. In my local I am able to do it with [System.Windows.Forms.SendKeys] to imitate the keyboard inputs but as the process will be running in background in the remote machine I don't think SendKeys will work. And 'psexec' is not an option here because in my remote machine I cannot include PSTools with my Powershell. Is there any way to do it with Invoke-Command and -ArgumentList??
If there is a way then how can I choose sequentially whether to input a text in a particular field or click the next button or click any other button within the application window??
I finally got to solve this puzzle with the help of a automation tool called AutoIt. This tool has its own scripting language and can create .exe files to run a particular application and do the corresponding installation steps based on each successive window the application installer pops. After creating the .exe I copied it to my remote machine using Copy-Item or you can use robocopy, then invoked the .exe remotely with the help of psexec. As I had the misconception previously about psexec, it only needs to be integrated with powershell at the local and thus it automatically creates a session of its own and interacts with the remote machine. This is the command to run the .exe on remote machine:-
psexec -i 2 -s -d \\remote_machine_name -u Username -p Password C:\Path_to_exe\installer.exe
You can actually log on to the remote machine and see in the GUI that it is happening. And yes, obviously you need to have the .msi which will be called to be present there in the remote machine so that the .exe can do its job locally in the remote session.
Background:
I have several registry keys that are saved and used to update/configure remote PCs in my environment. I may not have deployed the device, previously, but I use these registry keys to update the PC as I fix/repair/etc...I am part of a team of 45 managing about 25,000 workstations and peripherals in our region of the enterprise.
if I use this command from my Win 10 PC to a Win 7 PC, it executes without problems.
psexec \remotecomputer -u domain\adminaccount regedit.exe /i /s "\server\share\directory1\directory2\directory3\someregistry.reg"
psexec starts regedit, imports the above registry file and closes.
If I run that exact same command from my Win 10 PC to another Win 10 PC, I get the following error, from CMD as ADMIN,
"PsExec could not start regedit.exe on REMOTEPC_HOSTNAME:
The system cannot find the file specified."
it can't find regedit??? WTF??
I'm curious why Win 10 is blocking me, as an admin, from importing a registry key?
I've tried reg import as a solution, but I keep getting syntax errors and it can't find the file/pathway.
It's almost like the remote PC, doesn't recognize admin input due to UAC settings?
In testing, I've set the group policy editor to enable remote registry tools, no change. I've enabled remote registry services and set to start the service automatically. I can access the PC registry via remote registry...but psexec just won't work on the remote device.
I can RDP to the device and run the command line equivalent:
regedit.exe /i /s "\UNC\pathway...\etc*.*reg" it executes, without issues.
this proves that regedit is working
Can anyone provide some expertise on this?
add -s flag to psexec to run regedit
The old PsExec trick of running RegEdit doesn't always work. This is because psexec depend on a hidden SMB Administrator service. (Which in any security sense should be disabled.)
PsExec allows redirects of the input and output of a remotely started
executable through the use of SMB and the hidden $ADMIN share on the
remote system. With this share, PsExec uses the Windows Service
control Manager API to start the PsExecsvc service on the remote
system which creates a named pipe that PsExec communicates with. This
named pipe is what allows for input/output redirection back to the
system that launched PsExec.
So instead, in order to remove any TrustedInstaller owned registry Keys, you can use a different tool. This worked:
ExecTI - Run as TrustedInstaller
Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe
i have installed fresshd in one of my windows server.now i am connect to the system through putty. It is working fine.
my issue us when i am running from command line
PuTTY.lnk -ssh -2 -P 22 username#XXX -pw pswd -m command.txt
commands given in the command.txt files are not executed it just open the putty console and it is closing.
when Running from Jenkins also same issue.
I am not sure if you are connecting to Windows from a Linux machine, or to Linux from a Windows machine. Or Windows to Windows?
PuTTY.lnk is not an executable. If you try to run that, it should produce an error 'PuTTY.lnk' is not recognized as an internal or external command. I am assuming you are running the command from a Windows machine, since you are referring to windows shortcut file (.lnk)
You need to use PuTTY.exe + the rest of your command line. Please note that unless it is in your $PATH settings, you would have to provide a full path to the .exe, for example C:\LocationOfPuttyInstall\putty.exe -ssh -2 -P 22 username#XXX -pw pswd -m command.txt. For the sake of preventing any other problem, you should also specify a correct full path to the command.txt file.
If you are not sure where your Putty is installed, on the Windows machine, do the following:
Right click your PuTTY shortcut (the PuTTY.lnk file)
Look under "Target"
That would list your full path to PuTTY.exe executable.
This should resolve your problem.
p.s.
Usually Putty is used to connect from a Windows machine to a Linux machine. From your question, it almost looks like you are trying to connect from a Windows machine to another Windows machine.
You should use PsExec windows tool for such purposes:
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx