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
Related
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.
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).
If I want to self host WCF in a Windows Azure Website by spinning up my own ServiceHost can I host end points on 8080 or any other port I want to? Is there any specific usable range of ports I have access to or is port access entirely blocked?
Edit: for absolute clarification this question is NOT about web or worker roles and is only about Azure Websites
This blog post is slightly out dated now as Windows Azure Websites have more features now (like staging and production slots, WebJobs, etc) but the part regarding ports is still true for Azure Websites.
When to use Cloud Services [...] Windows Azure Websites is all IIS, the web server provides the entire platform, there is no room for long running processes or threads that can sit and wait for communication on another port outside of IIS
http://blogs.msdn.com/b/cdndevs/archive/2013/11/21/windows-azure-websites-vs-cloud-services.aspx
Note that now you can have a long running process using webjobs that does back-end work, but you can't listen on anything other than 80
No, WAMS won't let you open ports. If you need that, you should host in a Web Role (Cloud services). Then you can configure your endpoints through windows azure management portal.
How does Windows Azure handle Session is it InProc session or something else?
Also why should one not use Session and instead go for Windows Azure Cache to store transient data?
Session management in Windows Azure depends on how the application is deployed. If your application is deployed in Windows Azure Website, then InProc session will work. However if your application is deployed as Windows Azure Cloud Service, then InProc session will not work. Reason being the load balancer in front of your cloud service. In case of a cloud service, load balance works in a Round Robin manner and thus InProc session management would not work.
If you want, you can still use session in your cloud services however you would need to use a different session provider than default InProc provider. There is a session provider built on top of Windows Azure Cache which can be used (and is actually recommended). You don't have to make any changes in the code as far as session handling is concerned. Only thing that will change is an entry in your web.config file. Please see this link for more details: http://msdn.microsoft.com/en-us/library/windowsazure/gg185668.aspx.
Summary:
Does anybody know if there are known issues or configuration gotchas with an IIS service connecting to an Azure based service?
Scenario:
I currently have a scenario that requires me to host two web-services, one in Azure, and one on a server running IIS. The IIS hosted service (a WCF service) connects to the Azure hosted service (actually the Azure storage API) in order to fetch certain information. This information is manipulated and returned to the client.
Client -> IIS Service -> Azure Storage Service
Issue:
I'm running into issues with the IIS service connecting to the Azure Service. The hostname cannot be resolved. I'm using the Azure Storage client from my code, but have actually tried this using the azure API calls, and they also do not work from IIS. I captured the requests using Fiddler (on a different machine), they match the azure REST API calls, as expected. These requests, when made outside of IIS on the host machine execute properly. It is only when they are issued by the IIS service that they fail.
In my research other people have been running into this issue when there's a firewall problem, but since I can hit the service properly from the machine, that doesn't seem to fit the bill. My hunch is that there's a configuration issue I need to sort out in IIS, but I've failed to find anything useful with my searches.
Does anyone have any information on why this might be occuring (known bugs, gotchas etc)? Any workarounds? From a SOA perspective, this seems fairly critical to understand.
Any assitance anyone has would be helpful. Thank you.
Sounds like a proxy configuration issue. Check how your IIS server connected to Internet. If you are using some sort of proxy to get to Internet, that connection has to be configured correctly.
Specifically, if your proxy servers are Microsoft ISA server, or Microsoft Forefront TMG, then you need to check two things:
ISA server client or Forefront TMG client software is installed on the server
The account used by IIS application pool is domain user. ISA Server/TMG are designed to work only with user account, not service account. Alternative workaround for this limitation is using "defaultProxy" configuration in web.config, however it only wokrs for HTTP/HTTPS.
If you use different proxy server, then other issues might be involved, for example proxy might require authentication.