I want to make a simple program to help connect to a Remote Desktop, this is what I got till now:
#echo off
echo Connect Program
echo Enter IP of computer:
set /p ip=
echo Enter Username
set /p user=
echo Enter Pass
set /p pass=
Now I just want the code where I fill the variables %ip%, %user%, %pass%.
Any easy way to do this?
Here is what I derived from this post. First, an entry for the login credentials is created. Second, the RDP connection is established. Third, the entry containing the credentials is deleted. I've been using this on Win7 and Win10 so far.
I call this script from the KeePass password manager which passes the parameters to the script.
Usage example:
rdp.bat "my.host.name.de" "port" "username" "password"
rdp.bat
:: RDP connection without password prompt ------------
:: %1 = hostname
:: %2 = port
:: %3 = username
:: %4 = password
:: ---------------------------------------------------
cmdkey /add:"%~1" /user:"%~3" /pass:"%~4"
start /wait mstsc /v:"%~1:%~2"
cmdkey /delete:"%~1"
Note:
If the script running in the background is closed before the RDP session has ended, the entry containing the login credentials will not be deleted. Only use this approach if you know what you are doing. Do not use this e.g. on a public computer, as your login information might be exposed!!
Remote Desktop Connection (mstsc.exe) doesn't allow you to provide the credentials from the command line. Running mstsc /? from a command prompt shows the available switches:
MSTSC [] [/v:] [/admin] [/f[ullscreen]] [/w: /h:] [/public] | [/span] [/multimon] [/edit "connection file"] [/restrictedAdmin] [/prompt] [/shadow: [/control] [/noConsentPrompt]]
"connection file" -- Specifies the name of an .RDP file for the connection.
/v: -- Specifies the remote computer to which you want to connect.
/admin -- Connects you to the session for administering a server.
/f -- Starts Remote Desktop in full-screen mode.
/w: -- Specifies the width of the Remote Desktop window.
/h: -- Specifies the height of the Remote Desktop window.
/public -- Runs Remote Desktop in public mode.
/span -- Matches the remote desktop width and height with the local virtual desktop, spanning across multiple monitors, if necessary. To span across monitors, the monitors must be arranged to form a rectangle.
/multimon -- Configures the Remote Desktop Services session monitor layout to be identical to the current client-side configuration.
/edit -- Opens the specified .RDP connection file for editing.
/restrictedAdmin -- Connects you to the remote PC or server in Restricted Administration mode. In this mode, credentials won’t be sent to the remote PC or server, which can protect you if you connect to a PC that has been compromised. However, connections made from the remote PC might not be authenticated by other PCs and servers, which might impact app functionality and compatibility. Implies /admin.
/prompt -- Prompts you for your credentials when you connect to the remote PC or server.
/shadow: -- Specifies the sessionID you wish to view.
/control -- Allows control of the session.
/noConsentPrompt -- Allows shadowing without user consent.
This indicates that the only way to ask for the user credentials when launching is to either have them stored in the .RDP file in advance or to prompt the user at run time using /prompt.
I have a simple batch file which needs to be run weekly to upload some files via Core FTP.
I'm using the free version of Core FTP LE.
MySavedProfile is the Site Name of the saved profile I created using Core FTP's site Manager. The profile contains the URL / credentials / etc of the site to connect to.
Here are the contents of the batch file:
SET logf=confirm.log
echo test-start >> %logf%
"C:\Progra~1\CoreFTP\coreftp.exe" -B -s -pasv -O -site MySavedProfile -u "C:\Progra~2\PathToFiles\FileToUpload.txt"
echo test-finish >> %logf%
For the Windows Server 2012 r2 Task Scheduler, I have created a basic, weekly scheduled task on the Task Scheduler Library root which runs the batch file. For this scheduled task I have:
(Under the General tab)
"Run whether user is logged on or not" is selected
"Run with highest privileges" is checked
Configure for = Windows Server 2012 R2
(Under Actions)
Action = Start a program
Program / Script = "C:\Progra~2\PathToFiles\batch.bat"
Start in = C:\Progra~2\PathToFiles\
Here is the weird behavior I am getting:
If I double click on the batch file directly, it works fine and uploads the text file via Core FTP just fine.
However, if I try to let the Windows Task Scheduler run it, it runs everything except the Core FTP line. That is, I get the usual:
test-start
test-finish
in the confirm.log file, but the FileToUpload.txt has not been uploaded to the remote server, and there are no errors from CoreFTP that I can detect.
I have tried this with a service account that has permissions to run batch files, as well as my own account for this scheduled task. I get the same result: it doesn't seem to run that CoreFTP line. At least not via Task Scheduler. I need this upload to be automated.
I've searched Core FTP's documentation, Google, etc. No one seems to have run into this exact issue. I've applied recommendations from distantly related issues, but none of them have worked.
Any help would be greatly appreciated. Thank you.
The only way to do this is to use the full version of Core FTP (that is Core FTP Pro). If you use the LE version you have to check the "Run only when user is logged on" option.
This happens because of the splash screen at the beginning.
If you can't be logged on forever you could create a user that will always be logged on just for these tasks.
Remember to use the -Log option on CoreFTP to check if it is actually doing something.
I have a simple batch file that uses Robocopy to transfer data from one of our servers to a NAS device. I have tried using both a mapped drive as well as a UNC path.
It works when I run the batch file manually (using both mapped drive and UNC) but when I use Scheduled Tasks the command window does not come up and although the task is shown as Running it just sits there and does absolutely nothing at all.
I have set up the scheduled task from the Administrator account, have "Run whether user is logged in or not" with the admin password stored.
Is also set with Run with highest privileges and under actions I have set "Start in" to the root of the D:\ drive which is where the batch file is located.
I have also checked local security policy & everything seems fine in there.
I've got this script in a batch file:
cmdkey /generic:"servername" /user:"user id" /pass:"password"
mstsc /v:"servername"
...which logs me into a remote server (remote desktop session). It works great, but doesn't actually log me in all of the way because this server is configured with an interactive logon, meaning there is a message that comes up that I have to click OK to when I first connect before it actually signs in all of the way.
We have a problem with our admins shutting down this server at night to apply updates and thus logging us out - causing our scheduled tasks to not refresh. I want to assign this batch file to a scheduled task on my local PC to ensure that every morning, before my scripts run, I'm logged back into the server.
Is there a way to get this batch file to bypass/acknoweldge this message so it finishes signing me in?
I want to copy some files from a network shared drive (mounted at my local machine as drive Z). I have written a Batch file to copy the contents of Z drive into my local drive. This batch file runs successfully on cmd, but i am having issue when i trigger it through Jenkins. The Jenkins gives the following error:
"The system cannot find the specified drive"
Any help regarding this, will be greatly appreciated.
Thanks,
Nouman.
If you don't want to use Jenkins-plugins or schedule-Tasks here is a "groovy" way:
By Hand:
You can use the Groovy Script-Console provided by Jenkins>Manage Jenkins>Script Console and execute the command to map the network-drive within the Jenkins-service. (Must be repeated, once the Jenkins-service is stopped)
Automation:
Write your Groovy commands to a file named "init.groovy" and place it in your JENKINS_HOME-directory. So the network-drive gets mapped on Jenkins-startup.
Groovy Commands - Windows:
Check available network drives using the Script-Console:
println "net use".execute().getText()
Your init.groovy would look like this:
def mapdrive = "net use z: \\\\YOUR_REMOTE_MACHINE\\SHARED_FOLDERNAME"
mapdrive.execute()
Yes Jenkins uses different login credentials. To map a drives through Jenkins use below command in Jenkins command prompt:
Subst U: \drive\folder
then after that your queries.
You might run into permission issues. Jenkins might be executed with different user credentials; so it does not know the configured drive for the windows share. Instead of using shell scripts I suggest to use a plugin. There is a set of Publish-over plugins that allow deployments to remote systems via a couple of protocols (ssh, cfis etc). Have a look at the CFIS plugin that allows to send artifacts to a windows share. Once the plugin is configured (ie the host is specified in the Manage Jenkins section) you can add to the post build steps Send files to a windows share where you can specify which file(s) shall be sent to which location.
Had this issue where my jenkins job was unable to read files present on the network drive.
I resolved it by adding "net use" command in your pre-build step. i.e.
Open your job.
Go to Pre Steps
From the drop down, select Execute Windows Batch Command
Enter the following command:
net use E: \[server name][Folder name] "[password]" /user:"[userid]"
Click Save
Execute the job
I was able to read files from my network drive by following the steps mentioned above.
It seemed to be a one time activity as after the initial run, I had removed the batch command from my job and it seemed to remember the mapped drive command.
Try adding debugging commands to that bat file, or as separate build step, such as net use, set (pay attention to vars like like HOMEPATH and USERNAME) and plain dir Z:\.
As said in another answer, most likely reason is that Jenkins runs as SYSTEM user, which has different permissions. One way around that is, go to services (for example open Task Manager, go to Services tab in it, click the Services button at the lower right corner of that tab), find Jenkins service, open it's properties, go to "Log on" tab and set your normal user account as one that runs Jenkins.
Basically you can access your network shared drive (Z) using by servername or IP from jenkins command. Write \\192.168.x.xxx\Your_Folder instead of z:\Your_Folder.
For example:
mkdir \\192.168.x.xxx\Your_Folder
I was trying to copy files from one remote computer to other, the easy solution which worked for me is COPY iphone.exe \192.xx.xx.xx\dev(dev is the folder name on c drive in that ip address)
A similar issue showed up for us on Jenkins slaves set up on Windows Server 2008 following this documentation. The Jenkins agent failed to access the mounted network drives even after configuring the agent service with the correct user credentials.
Troubleshooting:
Jenkins could access the mounted network drives by their drive letters when connected via the JNLP agent (Launch agent via Java Web Start).
It stops recognizing the drive letters soon after we install the agent as a Windows service. Configuring the correct user credentials and restarting the agent does not help.
We could still access the drives via the command line while logged in to the machine with the above user.
Stop the agent service from services.msc and then uninstall it by running the command jenkins-slave.exe uninstall. The slave is disconnected at this point.
Reconnect the slave by launching the JNLP agent via Java Web Start. The agent can now access the network drives again.
Synopsis:
Do not install the slave agent as a Windows service to keep accessing your mounted network drives using drive letters. But this is highly unreliable as the agent might fail to restart after a machine reboot. Alternatively, see if Jenkins can access them via \\<ip_address\of\network\drive>.
In order to access your remote drive
just use the command in cmd prompt
pushd "\sharedDrive\Folder1\DestinationFolder"
mkdir FolderName
popd
pushd >> It navigates to the shared drive by creating a virtual drive..
popd >> Gets you back to the local directory