Remote Desktop Is Not Available

Typically, when we are deploying an app or troubleshooting application problems, you would tend to remote into the server to look at log files, review IIS settings, look at event viewer, etc. When you first start using Azure Web Apps, you have to get used to this and learn about the other ways of doing most of these functions. Deploying code is done via Visual Studio, git, a build server, or FTP. Viewing App Service log files, event viewer, running processes, and other tasks can be accomplished via the kudu console, Stackify, and/or Azure portal.

Limits on Installing 3rd Party Software and Management Tools

One of the biggest benefits of Azure App Services is also a big limitation. You don’t have to manage Windows Server at all and Microsoft is completely responsible for everything. But, you also have no access to install virtually all 3rd party software. This can be a negative if your corporate IT uses traditional monitoring tools like Nagios, SolarWinds, Dynatrace, Splunk and many others.

There are some vendors who have adapted their products to work with Azure App Services but there are very few. You can check the Azure marketplace to look for potential solutions. Do note that some of the listed products may only work for virtual machines and not Azure Web Apps.

Performance Counters Are Not Available

Performance counters can be a pain to work with. But they are critical to understanding key metrics about IIS, applications, and the .NET CLR. Without performance counters there is no way to monitor things like garbage collection, IIS queuing and a lot of other data that can be critical to troubleshooting weird performance problems.

The modern threat landscape for cloud environments is extremely dynamic, the solution is built on the same anti-malware platform as Microsoft Anti-malware for Azure. It is a single-agent solution for applications and tenant environments, designed to run in the background without human intervention. You can deploy protection based on the needs of your application workloads, with either basic secure-by-default or advanced custom configuration, including anti-malware monitoring.

When you deploy and enable Microsoft Antimalware for Azure for your applications, the following core features are available:

• Real-time protectio
• Scheduled scanning
• Malware remediation 
• Signature updates 
• Anti-malware Engine updates 
• Anti-malware Platform updates 
• Active protection 
• Samples reporting 
• Exclusions 
• Anti-malware event collection 

Types of Logs in Azure

Cloud applications are complex with many moving parts. Logs provide data to ensure that your application stays up and running in a healthy state. It also helps you to stave off potential problems or troubleshoot past ones. In addition, you can use logging data to gain deep insights about your application. That knowledge can help you to improve application performance or maintainability, or automate actions that would otherwise require manual intervention.

Azure produces extensive logging for every Azure service. These logs are categorized by these main types:

Control/management logs give visibility into the Azure Resource Manager CREATE, UPDATE, and DELETE operations. Azure Activity Logs is an example of this type of log.

Data plane logs give visibility into the events raised as part of the usage of an Azure resource. Examples of this type of log are the Windows event System, Security, and Application logs in a virtual machine and the Diagnostics Logs configured through Azure Monitor

Processed events give information about analyzed events/alerts that have been processed on your behalf. Examples of this type are Azure Security Center Alerts where Azure Security Center has processed and analyzed your subscription and provides concise security alerts.

Activity Log

The Azure Activity Log, provides insight into the operations that were performed on resources in your subscription. The Activity Log was previously known as “Audit Logs” or “Operational Logs,” since it reports control-plane events for your subscriptions. Using the Activity Log, you can determine the “what, who, and when” for any write operations (PUT, POST, DELETE) taken on the resources in your subscription. You can also understand the status of the operation and other relevant properties. The Activity Log does not include read (GET) operations.

Here PUT, POST, DELETE refers to all the write operations activity log contains on the resources. For example, you can use the activity logs to find an error when troubleshooting or to monitor how a user in your organization modified a resource.

Azure Diagnostic Logs

Azure Diagnostic Logs are emitted by a resource that provide rich, frequent data about the operation of that resource. The content of these logs varies by resource type (for example, Windows event system logsare one category of Diagnostic Log for VMs and blob, table, and queue logs are categories of Diagnostic Logs for storage accounts) and differ from the Activity Log, which provides insight into the operations that were performed on resources in your subscription.

Protect your assets

With API Management, you can protect your enterprises’ APIs by providing security solutions including SSL, API authentication, API Keys management and other runtime policies such as API quota and rate limit.

Monitor and analyze

Get thorough insight in the performance, health and quality of your APIs. API Management provides an in-depth look into your APIs trough a diverse set of metrics about the API usage. You will be able to discover the trends that are most impacting your business.

Embrace the API economy

Exposes business assets and services to unlock additional business and generate new revenue and opportunities. API Management allows enterprises to successfully share core services across the organization and across boundaries. The lightweight virtualization layer of Azure API Management enables modern and restful APIs to integrate data and resources with today’s mobile devices, without any security sacrifice.

Drive API adoption

Provides comprehensive documentation to drive API adoption and reduce the learning curve of performing the API intake in the first place. The developer portal helps developers to easy understand and promote the use of the API and prevent misuse.

Cross-Origin Resource Sharing (CORS) defines a policy-driven approach for controlling how web applications make cross-domain requests. This is in contrast to the long-established single-origin policy (SOP), which says that URLs in JavaScript (and elsewhere) can only refer to the origin URL of the page. The advantage of CORS is that it allows a web app to pull resources (e.g., data and other features) from multiple websites onto one page without having to construct proxies or use other workarounds. CORS defines a contract between the client-side browser and the server application as well as an algorithm that is followed to enable server applications to opt in to allowing cross-origin requests.

Finding Your Origin

A typical web application consists of a rich browser-based client (using HTML5, JavaScript, and CSS3), served up from a web server application (such as with ASP.NET or MVC 3 in an Azure Web role) and integrating data from various Representational State Transfer (REST) services. From the perspective of the browser, there are two scenarios for how the web app gets its data from the services: same-origin and cross-origin (aka cross-domain).

In the same-origin scenario, the services are hosted within the same web server application that delivered the web page, or they may exist externally and be called from the web server application logic with their resultant data integrated in the web server application’s response. In either case, from the browser’s perspective they are being reached from the same server — the same origin. When services are accessed with different hostnames, protocols, or ports, the request is considered cross-origin. This is very common for websites that use third-party services for their data, where the browser-based client calls the service directly and the domain used to access the service is different from the domain that delivered the web page. The subtle issue here is that browsers enforce an SOP whereby such cross-domain requests are not allowed, in order to protect the browser from malicious code loaded from the external domain.

This is not an issue specific to web applications hosted on Azure, but if you are doing any amount of web application development on Azure you will undoubtedly encounter the SOP. In fact, Azure introduces additional scenarios where cross-origin resource access is required. Naturally it is best to architect your Azure-hosted solution with the SOP in mind, rather than encounter SOP and have to make drastic changes to your web application when you least expect it.