I am also having the same problem as mentioned here Azure Files - System error 53
Although I'm afraid the answers provided have not helped.
My current setup all in west europe
File Share
VM 1 Windows 2012 - Can connect to File Share
VM 2 Windows 2012 - Cannot connect to File Share
I've run PortQRY which confirms that port 445 is outgoing and working.
Although I am still receiving this error
This error occurred after a random shutdown, before which I could connect fine.
What other troubleshooting steps can I take to find out why this is not working?
According to your description, it seems that no issue is on your network between VM and Azure FileShare.
You could refer to Mine's link, please check Cause 3.
"System Error 53 or System error 87" can also be received if NTLMv1
communication is enabled on the client. Having NTLMv1 enabled creates
a less-secure client. Therefore, communication will be blocked for
Azure Files. To verify whether this is the cause of the error, verify
that the following registry subkey is set to a value of 3:+
HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel.
I also met a similar question with you, you could check the link. The solution is to modify the registry
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.
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 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!!
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.
I have setup FTP within IIS7 on a Windows 2008 Virtual Machine. I enabled Port 21 within the endpoints and Active FTP works just fine. But I am unsure to how to connect through Passive. I followed Microsoft documentation (enabled a range of ports within IIS and allowed the same ports on the local firewall) I also allowed the ports within the endpoints in Azure Management. This didnt work.
I read somewhere on an unofficial MS forum that MS do not allow Passive FTP within Azure. Is this true? If not can someone direct me to the right documentation?
Thanks
SOLUTION
I followed instructions in this article.
The problem I was having was I didn't stop and start the FTP service after doing this. It wont work otherwise.
Passive FTP should work fine in Windows Azure Virtual Machines. However, you may not be able to choose large port range since you can only have up to 25 endpoints in Azure and this could be limitation to have Passive FTP. This Forum discussion talk more about it.
You can find this blog which explains how they configure Passive FTP with IIS on Windows Virtual Machine.
An additional piece of info about the post referenced above (http://www.itq.nl/blogs/post/Walkthrough-Hosting-FTP-on-IIS-75-in-Windows-Azure-VM.aspx) - at the end it says you need to use the following command to add the port range in IIS:
appcmd set config /section:system.ftpServer/firewallSupport \
/lowDataChannelPort:7000 /highDataChannelPort:7014
This failed for me, because the port range is locked so it can only be set on the root IIS node. The error is:
Support (Your site name) /lowDataChannelPort:5000 /highDataChannelPort:6000
ERROR ( message:Can not set attribute "lowDataChannelPort" to value "5000".. Rea
son: This configuration section cannot be used at this path. This happens when t
he section is locked at a parent level. Locking is either by default (overrideMo
deDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny"
or the legacy allowOverride="false".
. )
If you traverse up the IIS nodes to the root server node, choose Features View, then FTP Firewall Support, you can set the Data Channel Port Range there using the text box, without the need for scripting, and avoiding this error. Once this is done, you then need to restart the ftp service (as noted above), and passive FTP works well.
I've added this additional answer here because being unable to run the appcmd command to set the port range had me going around in circles for a number of hours, and this may help others avoid the same problem.
I thought others might run into this. If you get the security message indicating that the parent is locked, just go back into your FTP and turn OFF Require SSL Connections. Then rerun the command. Setup your endpoints, open the firewall, etc. THEN go in and turn back on Require SSL Connections!