I am getting below exception when I access Azure cache from my dev azure application.
ErrorCode:SubStatus:There is a temporary failure.
Please retry later. (One or more specified cache servers are
unavailable, which could be caused by busy network or servers. For
on-premises cache clusters, also verify the following conditions.
Ensure that security permission has been granted for this client
account, and check that the AppFabric Caching Service is allowed
through the firewall on all cache hosts. Also the MaxBufferSize on the
server must be greater than or equal to the serialized object size
sent from the client.)
Is there any restriction that the Azure cache can only be accessed from hosted Azure application?
You should have no issue accessing AppFabric Cache from the emulator. Just note that the cache is only in Windows Azure itself; there's no emulated cache running locally.
Do you have any further detail on the error message? Also, are you accessing it directly in code? Using it as a session state provider?
Yes we can access Azure AppFabric cache from emulators. Just want to configure correctly and there should be no firewall blocking
Related
I'm responding to Microsoft's Security Advisory ADV200005 | Microsoft Guidance for Disabling SMBv3 Compression. The advice is to Disable SMBv3 compression.
I'm running an Azure Web App which does not use SMBv3 or access files from other servers. So I would like to Disable SMBv3 completely (not just SMBv3 compression).
How would I be able to do that from Azure Portal? Am I even allowed to do that?
All Azure Web Apps (as well as Mobile App/Services, WebJobs and Functions) run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available.
On Azure WebApps, regardless of address, applications cannot connect to anywhere using ports 445, 137, 138, and 139. In other words, even if connecting to a non-private IP address or the address of a virtual network, connections to ports 445, 137, 138, and 139 are not permitted.
As far as Azure App service WebApps - Update, security & patching is concerned - App Service is a Platform-as-a-Service, which means that the OS and application stack are managed for you by Azure; you only manage your application and its data.
You may wish to know about how and when OS updates are applied:
Azure manages OS patching on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly, which aligns to the monthly Patch Tuesday schedule. These updates are applied automatically, in a way that guarantees the high-availability SLA of Azure services.
Additionally, just to highlight - when severe vulnerabilities require immediate patching, such as zero-day vulnerabilities, the high-priority updates are handled on a case-by-case basis. Stay current with critical security announcements in Azure by visiting Azure Security Blog -https://azure.microsoft.com/blog/topics/security/
Kindly checkout this document -https://azure.github.io/AppService/2018/01/18/Demystifying-the-magic-behind-App-Service-OS-updates.html for more details on Azure App Service OS patching.
We recommend that you do not disable SMBv2 or SMBv3. Disable SMBv2 or SMBv3 only as a temporary troubleshooting measure. Do not leave SMBv2 or SMBv3 disabled.
Disable in windows:
Set-SmbServerConfiguration -EnableSMB3Protocol $false
For more details, you could refer to this article.
In Azure, I turned on IP restrictions for:
Web App (Networking > Access Restrictions)
SQL server (Firewalls and virtual networks > Add client IP)
SQL database (Set server settings)
The solution still builds locally and in DevOps (aka Team Foundation Server).
However, Azure App Service Deploy now fails:
##[error]Failed to deploy App Service.
##[error]Error Code: ERROR_COULD_NOT_CONNECT_TO_REMOTESVC
More Information: Could not connect to the remote computer
("MYSITENAME.scm.azurewebsites.net") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer.
Error: The remote server returned an error: (403) Forbidden.
Error count: 1.
How can I deploy through the firewall?
Do I need a Virtual Network to hide Azure resources behind my whitelisted IP?
The REST site scm.azurewebsites.net must have Allow All, i.e. no restriction. Also, Same restrictions as ***.azurewebsites.net should be unchecked.
It does not need additional restriction because url access already requires Microsoft credentials. If restrictions are added, deploy will fail the firewall, hence the many complications I encountered.
I think the answer is incorrect as you might face data ex-filtration and that's the reason Microsoft provide the feature to lock down SCM portal (Kudu console)
There is also a security issue on Kudu portal as it can display the secret of your keyvault (if you use keyvault) and you don't want someone in your organisation to access the Kudu portal for example.
You have to follow this link
https://learn.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops
It will provide you Azure DevOPS IP range that you need to allow on the SCM Access restriction.
Update: To make it works as expected and to use App Service Access Restriction (same for an Azure Function), you need to use the Service Tags "AzureCloud" and not the Azure DevOPS IP range as it's not enough. on the Azure Pipeline logs, you can see the IP blocked so you can see that it's within the ServiceTags "AzureCloud" in the Service Tags JSON file
It's not really clear on the MS Doc but the reason is that they struggled to define a proper IP range for Azure DevOPS Pipeline so they use IPs from AzureCloud Service Tag.
https://www.microsoft.com/en-us/download/details.aspx?id=56519
In my case I was deploying using Azure DevOps and got the error. It turned out the app service where my API was being deployed to, had the box checked "Same restrictions as xxxx.azurewebsites.net", under access restrictions or IP restrictions. you need to allow scm.azurewebsites.net.
Try adding the application setting WEBSITE_WEBDEPLOY_USE_SCM with a value of false to your Azure App Service. This was able to solve my issues deploying to a private endpoint.
In my case it was because the daily quota was overpassed.
So the solution in this case is either wait or pay more (scale up) the app service
In my case this was because the wrong agent (Windows Hosting) was being used when I should have been using a self hosted internal agent... so I needed to change it at the following location
I'm using the Azure Dedicated cache to store my session state in and I've recently been getting connection failures which then take my application down. The only way to fix it is to restart the app.
Does anyone know of a way to catch this type of exception and then refresh the cache connection on the fly?
I am using azure caching library 2.3 and I following this article to setup the sessionstate in the cache.
http://azure.microsoft.com/en-us/documentation/articles/cache-dotnet-how-to-use-service/#store-session
Here is the exception I am getting.
"ClassName": "Microsoft.ApplicationServer.Caching.DataCacheException",
"Message": "There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.)",
"Data": {
"The client was trying to communicate with the server: net.tcp://xxxxx.cache.windows.net:23233.": null
},
Thanks!
I was directed to this post which gives some details on how to refresh the Azure DataCacheFactory.
http://blogs.msdn.com/b/cie/archive/2014/04/29/cache-retry-fails-what-next.aspx
I'm only using the built in SessionProvider so I think this was a bit much and I couldn't understand everything that was going on. So instead I'm catching the exception and then restarting the role so that a new connection can be established on app startup.
Here is the root cause of problem from that post..
Reasons in general can be in case of High Availability the underlying
cache service is load balancing the partitions and the secondary node
is transitioning to primary and the client still is sending request to
old primary node OR for some reason the cache service got moved to a
different VM as part of service healing process but cache client still
is having the old IP address of cache service VM.
Though its good to have a retry policy in place but in extreme cases
where retry is not helping then you could use below approach in your
application to mitigate the errors by refreshing the cache client when
an exception is thrown.
Is it possible to use Azure shared cache service from load-balanced IaaS VMs? Does it exists at all? I can't seem to find caching service in management portal.
You should also take a look at the Windows Azure Cache Service (Preview) that has just been launched. It supports distributed caching from IaaS VMs. Read more here to find out if you need this.
If you're using IaaS with Windows Server, you may want to explore using Server AppFabric Caching. This gives you dedicated resources, co-hosted in your Azure VM's at a lower latency and without the quota's imposed by the shared caching service.
I have an MVC 4 website using a WCF service. When I deploy to Windows Azure using the VS 2012 publish wizard, I get this error:
10:13:19 AM - The HTTP request to 'https://management.core.windows.net/42d4257b-5f38-400d-aac5-2e7acee9597d/services/hostedservices/myapp?embed-detail=true' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout.
After cleaning the project and publishing a few times, the error goes away. What am I doing wrong?
Whenever you start publish process from VS machine, a SSL tunnel is established first and once the tunnel is created, the package is transferred from your machine to Windows Azure Portal first. After the upload is completed, you will see the result notifications are posted back to Publish result windows and that is how it happens.
In your case, the time to build the SSL tunnel doe secure package transfer is longer then normal, this could be because of network latency between your machine and the Windows Azure Management Portal. For security reason the time to create the tunnel smaller windows and if the connection is not created, the retry cycle starts the process again and even if that fails you are greeted with the failure message. This could be caused by excessive traffic on either side or both sides. So this is mainly a networking related issue rather then specific to Windows Azure as after some time successive tries, you could upload your package.
In such failure/situation, you can run network capture utilities i.e netmon, wireshark, and see the time taken during failure and success to see the different in various transfer. This will help you to understand the underlying delaying issues.
Try to update your roles diagnostics
like below
then update your storage credentials because it may be expired.