I am trying to use Azure Files and I am getting the following System error 53. Any ideas?
There are two possible reasons for getting this error if you are trying to mount your Azure file shares from outside of Azure Datacenter via SMB 3.0.
Your client OS needs support SMB 3.0, for example use Windows 8, Windows 10, Windows Server 2012.
The port 445 (TCP Outbound) needs to be opened by your ISP or firewall. The SMB protocol is dependent on this port if you mount from outside of Azure Datacenter, and I do notice some ISP blocked this port (e.g. Comcast).
You can refer to the links below to do a self-check on the port by yourself.
http://poshcode.org/2514
http://powershell.com/cs/media/p/4063.aspx
There is another explanation for this error.
If you try to connect to that network share from your machine as opposed to connecting from an Azure VM (or role).
The network share is only visible to Azure VMs. There may even be one more restriction - the share and the VM must live in the same Azure region.
Sources:
My experience, hitting this problem on my laptop (and seeing it work, using the same cmd, in an Azure VM).
Also, this: https://blogs.msdn.microsoft.com/windowsazurestorage/2014/05/12/introducing-microsoft-azure-file-service/ :
Once your share is created, it can be accessed via the SMB or REST
protocol from any Azure node (VM/Worker/Web role) hosted in the same
region as the storage account hosting the share.
This is the only thing that worked for me:
Change this registry key to a value of 3
HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel
For more information, see the LmCompatibilityLevel topic on TechNet.
Got this solution from this MS docs
Related
I have used Azure Cloud Services in the past and enabled RDP when I needed access to the machine for some troubleshooting. Today I needed access again, but I cannot access any cloud service anymore. I enabled RDP with my normal certificate and the same user and password as always, but I just cannot connect.
Adding the RDP connection works fine, but when logging in it just times out. It feels like a port that is blocked. Anyone knows if something has changed?
Your issue looks similar to the thread posted here.
Azure classic cloud service cannot RDP
Here is a document on enabling remote desktop connection for a role in Azure cloud services:
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-role-enable-remote-desktop-new-portal
The problem I have is that we're trying to use our WebApp in Microsoft Azure to connect to an external SQL-database (not our own) through a VPN. The SQL-database is only allowing connections from our local IP-addresses that we put up as a Network (for example 176.0.0.0/24).
We are now connected to the same virtual private network, and through our Azure-VM we can now connect to the SQL-Server through SQL Server Management Studio.
Now we want to do the same with a WebApp, but we're not getting through to the server. It gets "Not authenticated" before reaching the SQL-Server (probably the server isn't accepting our IP from the WebApp).
The different problems I have tried to look through is:
Do we only try to connect through our Outbound IPs?
Is the WebApp not connected to the VPN?
I have unfortunatley not found any real answers, and neither any solutions to my problem. If you have any ideas of how to solve our problem, or maybe know how I could tunnel all of the SQL-calls through the VM, the help would be very much appreciated!
Hybrid connection is one option. What you can also do is enable point-to-site in your VPN. Once you do that, you can directly integrate your web app to the vnet and your connections will work. (Go to your web app -> Settings -> Networking -> VNet Integration)
If your Vnet is V1(older way of creating VNs) then enabling point to site is very straightforward. You can do it through portal. For V2 Vnets you have to do it through powershell commands.
Here is a link for the documentation which explains both the options.
https://azure.microsoft.com/en-in/documentation/articles/web-sites-integrate-with-vnet/
There's a way to "tunnel all of the SQL-calls through the VM". You may want to use hybrid connections (cf https://azure.microsoft.com/en-us/documentation/articles/integration-hybrid-connection-overview/).
The principle is to have an agent installed on the VM that can access the database with the correct IP address.
Suppose you can access the SQL DB as mysqldbsrv from the VM. You add an hybrid connection associated to your web app, you install the agent on the VM. Then, when you connect to mysqldbsrv from the Web App, you go through the VM.
In Azure, I created a virtual network and then associated an Ubuntu Server virtual machine, created with Azure Resource Manager Deployment method, with the network. I then updated the associated Network Security Group and added an inbound security rule for port 80 (Source:Any, Destination:Any, Service:TCP/80). After installing Apache on the VM, I tried to access the server from my browser, but have run into a wall. I can SSH into the VM just fine, but web is a no-go, and I cannot figure out why. Any help would be appreciated.
It sometimes happen to me too because I forgot to RESTART the VM, yes just restart it. At least this works for me. and also dont forget to add outbound rule too
It worked for me with this inbound rule.
Note that when a VM is created from the portal (in ARM model), it gets automatically associated to a virtual network (vnet), a specific subnet within the vnet and a network security group.
When creating the inbound security rule, make sure to:
identify the correct network security group associated to the VM
use a priority number lower than 65500
set the source port range as *
You also need open port 80 on the VM to allow web access.
I dont think that creating your Network Security Group opens the desired port on the VM automatically.
By default in Azure Resource Manager (ARM), all ports are open; there is no need to make Network Security Groups (NSGs) to open ports, only to close them. Here is an example of an ARM template that deploys an ubuntu VM with apache:
https://github.com/Azure/azure-quickstart-templates/tree/master/apache2-on-ubuntu-vm
Alternatively, if you want an auto-scaling LAP stack using VM Scale Sets (in public preview), you can find the ARM template for that here:
https://github.com/Azure/azure-quickstart-templates/tree/master/201-vmss-lapstack-autoscale
Hope this helps! :)
This is my Azure configuration:
I have a Virtual Network with a couple of subnets and a gateway
configured to allow point-to-site.
There is one Virtual Machine with SQL Server (2014) installed. There
are some databases in there already. SQL Server is set up to allow
SQL Server and Windows Authentication mode. This VM is in the Virtual Network
I have an empty Azure Web App
I deployed my main MVC WebApp to the empty Azure Web App and looks good, except when it tries to retrieve information from the database.
Is it a connection string error? or there can be something else...
My connection string looks like this:
<add name="MyEntities" connectionString="metadata=res://*/Data.MyModel.csdl| res://*/Data.MyModel.ssdl| res://*/Data.MyModel.msl;provider=System.Data.SqlClient;
provider connection string="
data source=tcp:10.0.1.4;
initial catalog=MyDataBase;
persist security info=False;
user id=MySystemAdmin;
password=SystemAdminPassword;
multipleactiveresultsets=True;
App=EntityFramework""
providerName="System.Data.EntityClient" />
Here is the error thrown by the azure web app...
So it seems to be related to either the way I'm providing the connection string or the end-points/firewall configuration.
Check your connection string against this connection string for Entity Framework designer files (https://msdn.microsoft.com/en-us/data/jj556606.aspx#Connection)
Just from a quick glance I see two possible errors:
Semicolon missing added after provider=System.Data.SqlClient (the example on the page I provided the link to doesn't have one)
The IP address you specify to connect to is a local one (10.0.0.1) and should be the IP/DNS name of your database in Azure.
Not sure if this is the issue or if StackOverflow just clobbered your markup. In addition you talk about a lot of gateways so I would check to make sure you can talk between your systems. Finally posting error messages and capturing exceptions about what's actually going on will help diagnose the error because at this point it's all guesswork.
Hope that helps.
What the guys said above plus:
The Web App needs to have a hybrid connection to the VNET the VM is if you want to use the local IP address, otherwise you have to use the PIP.
Check the firewall on the VM if the proper ports are open. This has to be both on the VM firewall and the endpoints. Also, if there are any ACLs on the VM, you have to check those too.
The other answers gave me the guidelines to find out the solution.
I'll try to describe the steps I followed:
Using the new azure portal (portal.azure.com currently in preview) I
established a connection between the Azure Web App and the Virtual
network:
Home > Browse > Click on Azure Web App name
In the Azure Web App blade click on Networking tile
In Virtual Network blade, click on the Virtual Network where the database is located (it's important to mention that the Virtual Network ought to have a gateway previously configured)
My intention was to provide certain level of security to the VM with
the databases by placing it inside a Virtual Network, so I had not
considered opening ports. Turns out that it's necessary, so, in the VM:
I enabled the TCP/IP protocol for SQL Server using the Sql Server Configuration Manager (How to? here)
Then I created a new Inbound Rule opening the 1433 port, but only for private connections (very nice).
It was not necessary to create an endpoint in the VM for this port (very happy with this).
Finally, I published the the app to the Azure Web App using the connection strings as shown in the question (with internal database IP)
Final touch: in the new Azure Portal > Azure Web App > Settings, I was able to enter Connection Strings. Settings created in the portal are not overwritten; so now I'm sure this Azure Web App will always use the correct connection string.
Final note: in theory (not tested yet) the internal IP will not change as long as the VM is not Stopped (Deallocated).
I've created literally dozens and dozens of web servers in my day, but this is my first attempt with Windows Azure and I'm running into some problems. I just started migrating from AWS recently.
First of all, I'm running Ubuntu 13.04. Firewall disabled (for debugging), Apache2 installed correctly (using apt). SSH works fine as do many other services with both the DNS hostname and public IP. Virtual host is set up correctly and validated. However, I cannot access the HTTP website either through the Azure provided subdomain or the virtual IP. It just times out.
This is also my first time using Ubuntu 13.04 as well. So, through the powers of deduction, I'm assuming there is something I'm missing either with this new version of Ubuntu or some quirk in Azure. Does anyone have any suggestions?
SOLUTION
These steps to create "endpoint" works fine for all VPS:
open "virtual machine > endpoint > add endpoint"
choose "next"
set "name:http, protocol:tcp, public port:80, private port:80"
choose "complete"
and then must wait for activation and then for some time.
If you are using Azure Resource Groups along with your VMs (which is available on the new portal) you cannot use endpoints because it's not available there, so you should follow the following to open up the HTTP port or ANY other port:
1- Select the VM that you want to manage ports on.
2- In settings, click on Network Interfaces and select your network.
3- Go to Network Security Group and select your group.
4- Add Inbound or Outbound security rules depending on what you need.