When I group select to console into multiple Eve-NG Telnet nodes within a lab and then select ">_Console To Selected Nodes", Super Putty opens, however, it will only open a tab for a single Telnet node.
I have created a lab in Eve-NG with two vSRX Telnet nodes that are connected via ge-0/0/1 and ge-0/0/2. This lab also has an Eve-NG cloud image where the vSRX nodes are connected to it via ge-0/0/3. I added two GUI enabled Linux VNC hosts which are also connected to the afore mentioned cloud image and each via e0.
I set up Super PuTTY in the Windows 11 registry and then set it as the default Telnet application with the "only allow single instance" mode enabled.
Ideally, Super PuTTY should open both vSRX nodes within a single instance and each within a separate tab.
I discovered through troubleshooting that if a Super PuTTY session is already opened on the desktop, then both vSRX's will be opened in separate tabs. Or if the "only allow single instance" mode is disabled in Super Putty, then the vSRX's are both opened but in separate Super PuTTY instances. This behavior is not desirable.
Would anyone be able to offer any tips that I could try at solving the above issue?
Related
I am having architecture where my BOT server is on Cloud VM. To access that VM, I do RDP. I scheduled all the BP jobs on that BOT on VM. Now when I am connected to VM using RDP and keep the Blue Prism window in foreground, my BP jobs are running fine, means in Attended mode, they are fine. But if I minimize that BP window or if I dont do RDP to VM machine, I am getting error 'failed to navigate'. That means in unattended mode on my Cloud based VM BOT server, jobs are not running.
NOTE: My BP VM machine is always up and running also its not getting locked also, as I disabled windows screen lock (alt+ctrl+del).
In this scenario, will logon agent help or any other suggestions?
Utilizing an environment relying on RDP is not supported or recommended by Blue Prism, as it causes issues with automated processes (as you describe). Please refer to page 4 of the Blue Prism Data Sheet - Remote Access Tools (available in the Documents tab of the Blue Prism client portal):
The following tools have been deemed to be specifically unsuitable for providing remote access to Blue Prism environments:
Remote Desktop Connection (RDP)
The way that this Windows tool (and other tools that use the RDP protocol) handle session management is not compatible with Blue Prism:
The underlying operating system is aware as a connection is
established which can, subject to the automation techniques being
applied, result in the executing automation being interupted.
It requires the remote access credentials to be aligned with the
credentials used to authenticate the target system against the
network which presents a potential security risk.
As a user authenticates any previously connected users are locked out.
Each connection creates a separate desktop session.
The connection is not maintained throughout a system reboot.
It does not matter whether the VM is in cloud or within your own infrastructure, they both have same issue. Blueprism needs "screen" to be able to interact with applications. VM of course does not have a physical screen, but there is still a virtual one (I don't mean the RDP one by this) as the virtualization layer provides virtual GPU and monitor.
Imagine a non-virtual pc left unlocked. This is the same. Even if you don't see it (you have to look for "console", some clouds provide access to it), it exists.
There are more possibilities how to solve it, two of them are:
1) use Blueprism Login Agent
This will unlock the physical/virtual screen of the machine with given AD/Windows credentials, like a human user would before he starts working with the pc.
Please search internet for more infor about it or look up videos on youtube, like this one: https://www.youtube.com/watch?v=Eeeeu_iHjzk&list=PL4SEtvjUqihFh-iFvb_s0VAhPCX1tzg2A&index=43
(I am not the author of this video nor affiliated with the author)
2) modify Windows registry setting to log in automatically
More info: https://support.microsoft.com/en-us/help/324737/how-to-turn-on-automatic-logon-in-windows
I've encountered this problem before.
Try using the BluePrism's "Login Agent"'s "Login" process with the BOT's credentials.
If you continue to get this error, try using a "Dynamic" Spy mode for a particular attribute.
Good luck.
Fairly new to cloud computing, so bear with me if question is obvious or silly. With tons of information available on internet, I was able to successfully create an ec2 linux instance and installed R and Rstudio on it. Ran my scripts on it which went really well but took too long (16 hrs) and very expensive as well since I require instances with high memory and vCPUs .
In my programs, I am essentially running the same scripts for different datasets.
My question is, is there any way I can run multiple similar instances of ec2 (with exactly same software installed and my scripts). So, this way, I will be able to run my scripts on every dataset on a separate instance simultaneously in less amount of time.
So what I have tried so far. I have created an AMI image of my existing instance and launched it. But I couldn't SSH it because of its weird username and ip address, something like "root#10.0.0.1". I can see both instances are running (original and the AMI image instance), I can SSH into original but not into the other one. I am able to login to the RStudio for original instance on port 8787.
Another question is how to launch this AMI imaged instance using SSH (Putty) in parallel with original instance. What problem will it cause if I use both of them in the browser (RStudio in this case) simultaneously?
Please help me with this!Thanks!
Problem: For a school project, I was running several machine learning algorithms on pretty large size data which happened to requre 30-35GB of memory and my PC couldn't handle it. I was using R/RStudio. So, I resorted to AWS for my memory limitation problem.
What I did initially: I created an ec2-instance, installed R/RStudio. Everything worked out perfectly and I was able to run my programs on RStudio through browser. I actually, ran my scripts on a very small dataset on this AWS instance to see how things are going. To much of my surprise it took very long for the whole script to run even with this small dataset. Soon enough, I realized that all these algorithms in my programs could be run independently for the same set of features with a little tweak in the scripts.
So, I decided to play with AWS little bit. I recreated the programs such that everything stayed the same except the learning algorithms in each script. In other words, I wanted to simultaneously run a copy of these programs with different algorithms so that I could get everything running simultaneously and produce the results in a smaller amount of time.
Now, my goal was to run multiple copies of this instance (original instance). And I should be able to run RStudio on my browser for each of these instances e.g. 5 ec2 instances will have 5 RStudio running concurrently on browser's different tabs. With that, I would be able to run all RStudio for each instance on my browser.
Then, I created an image (AMI) of this instance and then I created multiple instances from the AMI but I was missing out few points while creating those new instances from AMI which caused the problem I asked in the question above.
I initially suspected that it has something to do with port 8787 and I might not be able to run multiple RStudio for each ec2 instance in the browser. However, that was not the problem at all.
There are few very important things to take care of while you create the new instances from an AMI.
Mistake: While CREATING new instances from this AMI, I was NOT selecting two important things correctly i.e. VPC and Security Group.
Correct method is:
VPC -- On the "Configuration Instance Details" page:
a. Click the "Network" dropdown and select the VPC which was created for the original instance. (Original instance is the one which is used to create the AMI (image))
b. Click the "Auto-assign Public IP" dropdown and select Enable
Security Group -- On the "Configure Security Group" page:
a. for "Assign a security group" option, tick the "Select an existing security group" options
b. If there are more than one security groups in the list then select the one which was created for the original instance (OR create a new Security Group and make sure that it has the same kind of inbound and outbound port accesses)
Once I set this up, as Marc B mentioned in the comments, each instance gets its own IP address, and a local subnet address is assigned as well
IP address of instance looks like : ec2-33-444-22-111.us-west-1.compute.amazonaws.com
subnet looks like: 127.0.0.35
Now, after learning this, I recreated 5 instances from my AMI. So, now I had 5 instances with RStudio on each of them. All of them were running perfectly fine because I was able to SSH into each of them.
Now I thought I should be able to work with these instances in different tabs of the browser and run my scripts in them. But I wasn't able to login to all the RStudio instances in my browser tabs. Only one of them was working fine and the others were just not working in the browser. However, I was able to SSH into all of them from PuTTY. I could have ran my scripts from Linux (SSH) as well but I wanted to run them using RStudio.
After spending a good number of hours on this, I figured out the problem that the RStudio server needs to be started manually for each ec2 instance in the linux except the very first instance.
For one of the ec2-instance (besides the one which was working fine on browser), I did the following to start the RStudio server manually as below:
SSH using PuTTY
Become root: sudo su
Go to this path where RStudio was installed on my Linux instance: cd /usr/lib/rstudio-server/bin
start RServer with this command : rstudio-server start
Now go back to the browser, open another tab and use your ec2-instance address and port number (http://ec2-33-444-22-111.us-west-1.compute.amazonaws.com:8787). And now you should get the login page of RStudio for this instance as well.
Now, with a similar process, I had to manually run RStudio-servers for all other instance in order to be able to access them through the browser. Then I thought, if there is a way to start the RStudio server when Linux starts up every time. Then came up with a solution. To do this, I made a change in one of the configuration files of Linux as follows:
Become root: sudo su
go to this path: cd /etc/rc.d
vi the file rc.local and add the following command:
/usr/lib/rstudio-server/bin/rstudio-server start
save the changes you made.
close the SSH connection
Then, I went back to the AWS console, stopped this instance and created an AMI (image) of it. Now the above changes will be effective for each instance that I create from this AMI i.e. now RStudio server will be started as soon as the instance boots and will be accessible through the browser.
Now I can use multiple RStudio instances using different tabs of my browser. Make sure you are using the correct instance address in the browser. Port number stays same for all i.e. 8787
I'm looking for a way to login into multiple remote servers using SSH on multiple tabs while using screen. Now I have set multiple tabs when running my screen and bash on each of it and I have to manually connect to each remote server using SSH and enter the password for my key. Now I'm looking for a way to enter that password once and login to all of servers automatically. All of them are possible to login using same ssh key. Any ideas?
I think what you are looking for is a way to - do the same thing on X servers. If you are on ubuntu you can achieve the same using terminator. Open up terminator, split the screen X times and then start the broadcast mode in the left top corner of the screen. This will allow you to work like a jedi!
I have an XenServer setup with multiple VM's running on it. I want to be able to interact with one of those VM's from the XenServer console. For example, if I have a windows VM I would like to interact with it from the XenServer host console all while the other VM's are running. Is that possible?
This is my first question and hopefully I posted it right. Sorry if I did something wrong. I searched for an answer but I was unable to find an answer.
By interact with it, do you mean login to it? If so, you're at the wrong place. You should login to your VMs from the XenCenter app, which you'll install on your windows machine by going to http://ipOfYourZenserver (ie. http://192.168.1.75 or whatever).
The only thing you might be able to do from you Xenserver is ssh to one of the machines running.
Install XenCenter from http://yourXenServerIp/
Connect to your XenServer, via Server -> Add
Click the VM in question in the left tree
On the right pane click the Console tab, which should display the output from your VM. If it's running and Windows has started you should see the Windows GUI.
Ideally you should install XenTools on your VM's to improve performance (this includes better console interaction).
We've found it best to enable remote desktop on our Windows VM's and connect using the Windows RDP client (Start -> Run -> mstsc).
It is possible to interact with VMs that are in XenServer, but you need XenCenter app to do that (make sure to get a compatible version of XenCenter eg if you are using XenServer 7 you must use XenCenter 7 or 8 etc).
After installing XenServer, connect it to your XenCenter and then all the VMs will appear in a list at the left side. Then, you can select any VM you want and from the "console" tab you can have interact in it like any other hypervisor (eg virtualbox).
If this isn't clear enough let me know.
I followed this
http://blogs.technet.com/b/keithmayer/archive/2013/04/17/step-by-step-build-a-free-sharepoint-2013-lab-in-the-cloud-with-windows-azure-31-days-of-servers-in-the-cloud-part-7-of-31.aspx#.UX_iF7XvvQI
I created a VM using the datacentre Image it created successfully and the status shows Its running. I am trying to RDP It says
Remote Desktop cant connect to the remote computer for one of these reasons:
1) Remote access to the server is not enabled
2) The remote computer is turned off
3) The remote computer is not available on the network
make sure the remote computer is turned on and conencted to the network and that remote access is enabled.
I did check the endpoints the public port is open and also 3389 private port is open too. I did try with different release one with latest patch and the other with the second latest OS patch but I am still not able to RDP.
Thanks
Yeah I already figured out firewall in my organization is blocking it. I did update the answer but it did not show up I am trying again :)
Make sure your VM has reached the "Running" status. If it's still in one of its pre-running statuses (such as Provisioning), you won't be able to RDP.
Also: Be sure you don't try logging in with 'Administrator' (the default in the rdp login box). Choose localhost\yourusername.
I had a similar problem the other day. It was solved by going to the Azure Portal, selecting the VM Dashboard, then clicking "Connect" in the grey toolbar at the bottom. This will download an RDP file that contains the correct connection settings. You can then send that rdp file to others who you would like to give access to.
I just opened one of the files used to connect, and it looks like the only real difference is the port used.
full address:s:[vm name].cloudapp.net:62808
username:s:Administrator
prompt for credentials:i:1
I am not sure if all Azure VM's use 62808, but the default RDP port is 3389 so just copying the DNS from the Dashboard into the RDP address will NOT work without adding the correct port.
One more thing folks should check when having trouble connecting is password length.
I thought I would be all secure by using a guid for a password. RDP worked fine from home (on older XP RDP client), but not from office. At first I thought it was a firewall issue. After verifying with the IT guys that I had full outbound access, I looked a little closer at the RDP error message.
It was saying my credentials were rejected. Finally, I created a second account on the VM and gave it RDP access. I was able to log in fine. The only difference between the two users was this time I didn't bother with a long password.
So I shortened the password on my main account and got in with no problem. I'm not sure what the limit is, but it seems to be less than 32.