I followed the instructions listed here to capture an image of my Azure VM:
Now I am unable to RDP to the VM - I get the generic message "Remote Desktop can't connect to the remote computer for one of these reasons:1,2,3 etc"
The VM I'm trying to connect to is: teamsitepoc.cloudapp.net:59207
Here's what I've tried:
I have checked that it's started.
Tried re-sizing to extra small then back to small.
Attached the disk that was captured, giving the following:
Could anyone please advise what else I can try to troubleshoot
It is entirely possible that you encountered the shutdown bug listed at the top of the page you link to.
Unfortunately rather than updating the documentation all they did was add a warning to the top of the page and left the incorrect instructions in the actual steps so likely many other people will encounter the same issue.
The workaround is available here: Image capture issue / VM unexpectedly started after guest-initiated shutdown
I also had this problem, pings went through from the VMs but no RDP port open.
Then I realized that windows was still updating!!
Related
I am unable to ssh into a gcp vm. When i try troubleshooting- it is not showing any issue.
I was able to ssh into other VMs.
FYI i have a Github instance installed into that vm.
this is the firewall config, i tried allowing both http and https- but it did not work.-
How do i proceed to troubleshoot further?
From GCP doc
After an SSH connection fails, you have the option to Retry the connection, or Troubleshoot the connection using the SSH-in-browser troubleshooting tool.
i did troubleshoot but all steps were green.
As #John Hanley suggested on troubleshooting using the serial console to check and view the error messages for authentication failure.
In addition to that from the Compute Engine VM serial logs you can check also for a UFW block error warning then if you have seen this error message follow this steps for troubleshooting:
Go to VM instances page > Click the name of your VM instance
Click the EDIT button at the top of the page
Scroll down to "Custom metadata" section
For the box Key, please input "startup-script"
On the Value box, input "sudo ufw allow 22"
Save your changes.
Once saved, please click on the RESET button at the top of the page.
Check also whether or not the VM boot disk is full see this documentation on Inaccessible VM due to full boot disk for general Troubleshooting SSH errors see this documentation.
I have a VM host in Azure, created using Resource Manager. I've come to use it today and can't RDP to the machine. When I view the Boot Diagnostics it has Please Wait. after a period of time it will go to the logon screen. When I view the CPU usage you can see it drop which assume is the VM restarting.
I've tried the following :
Reset Password
Reset Configuration
Redeploy
I've also looked at the network interfaces and tried adding it to a network security group with RDP rule but still nothing.
Is there anything else I can check?
EDIT
When I first start the VM up and look at the Boot diagnostics I can see the login screen. When I try and RDP to the machine it says it can't connect.
The CPU drops where I assume its restarting, I've tried RDP to the machine from another machine on the same VPN
I raised a ticket regarding the following. Support noticed the following in the logs "Rebooting VM to apply DSC configuration." The "DSC extension" was causing the machine to reboot.
They advised me to go to VM in the control panel and then extensions and uninstall the Powershell extension. Not sure what caused this ie I did not knowingly install this. But once I uninstalled it I was able to RDP. Support have asked me to try and install it again and see if the same happens again but at the moment not had a chance to do this.
We've got a classic VM on azure. All it's doing is running SQL server on it with a lot of DB's (we've got another VM which is a web server which is the web facing side which accesses the sql classic VM for data).
The problem we have that since yesterday morning we are now experiencing outages every 2-3 hours. There doesnt seem to be any reason for it. We've been working with Azure support but they seem to be still struggling to work out what the issue is. There doesnt seem to be anything in the event logs that give's us any information.
All that happens is that we receive a pingdom alert saying the box is out, we then can't remote into it as it times out and all database calls to it fail. 5 minutes later it will come back up. It doesnt seem to fully reboot or anything it just haults.
Any ideas on what this could be caused by? Or any places that we could look for better info? Or ways to patch this from happening?
The only thing that seems to be in the event logs that occurs around the same time is a DNS Client Event "Name resolution for the name [DNSName] timed out after none of the configured DNS servers responded."
Smartest or Quick Recovery:
Did you check SQL Server by connecting inside VM(internal) using localhost or 127.0.0.1/Instance name. If you can able connect SQL Server without any Issue internally and then Capture or Snapshot SQL Server VM and Create new VM using Capture VM(i.e without lose any data).
This issue may be occurred by following criteria:
Azure Network Firewall
Windows Server Update
This ended up being a fault with the node/sector that our VM was on. I fixed this by enlarging the size of our VM instance (4 core to 8 core), this forced azure to move it to another node/sector and this rectified the issue.
I've just installed Neo4j 1.8.2 onto Azure by following this step-by-step process...
http://de.slideshare.net/neo4j/neo4j-on-azure-step-by-step-22598695
Unfortunately, when I browse to http://:7474/webadmin Fiddler says Error 10061 - No connection could be made because the target machine actively refused it.
I've followed the instructions exactly and haven't received any errors.
Any help much appreciated.
So, I think I got to the bottom of this. I think it was due to the size of compute / VM I was creating. It looks like the problem is caused when running on Extra Small instances. I created a new installation using a Small instance and everything now works :).
Try setting the server to accept connections form all hosts, and maybe use a newer Neo4j, say 1.9.4
http://docs.neo4j.org/chunked/stable/security-server.html#_secure_the_port_and_remote_client_connection_accepts
The way the VM Depot image is set up, it's pre-configured to allow all hosts to connect, and the Neo4j server will auto-start. The only thing you need to take care of, when constructing your VM, is to open an Input Endpoint, with any public port you want (preferably 7474 to stay true to Neo4j) and internal port 7474.
Note that the UI changed a bit since the how-to was published: You can specify the endpoint as the last step before creating your virtual machine. Other than that, the instructions should be the same. And... once the VM is up and running (it'll take about 5-10 minutes), you just visit http://yourservicename.cloudapp.net:7474 and you should see the web admin. Note: this is not the same as your vm name. If you named your VM something like 'neo' then you do not want http://neo:7474 or http://neo.cloudapp.net:7474. You need to use your cloud service name (you had to create a name for the service when you deployed the VM.
I've deployed that image several times in demos, and just tried again right now to make sure nothing wonky happened. Worked perfectly.
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.