In this blog post How to Prepare Legacy IIS VMs for Azure SRE Agent Operations we will explain how to make older Windows web applications ready for faster, safer AI-assisted support.

If your business still relies on applications running on Internet Information Services, or IIS, a Microsoft web server hosted on Windows virtual machines, incidents may depend heavily on one or two experienced people. When the application slows down or stops responding, someone must search through logs, check Windows services, inspect recent changes and decide whether restarting something will make matters better or worse.

Azure SRE Agent is designed to reduce that manual investigation. SRE stands for site reliability engineering, the practice of keeping important systems available, stable and recoverable. The agent uses AI to examine monitoring data, identify likely causes and recommend or perform approved recovery actions.

However, connecting an AI agent to an old IIS server does not immediately create reliable automation. If the application produces poor logs, has undocumented dependencies or can only be repaired by granting broad administrator access, the agent will face the same problems as your support team.

Need help with Azure AI?

CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.

Visit CPI Consulting

What Azure SRE Agent actually does

Azure SRE Agent connects information that normally sits in separate places. This can include Azure Monitor performance data, Application Insights application data, Log Analytics records, configuration changes, alerts, source code and operational runbooks.

In practical terms, it can investigate questions such as:

  • Did error rates increase after the latest deployment?
  • Is high CPU usage causing the website to slow down?
  • Has an IIS application pool stopped or started consuming unusual amounts of memory?
  • Is the problem inside the application, the Windows server, the network or a database dependency?
  • Has this incident happened before, and what fixed it last time?

The agent can then suggest an action, such as collecting diagnostics, restarting a service or following an approved recovery procedure. It can work in review mode, where a person approves each action, or with greater autonomy after the organisation has established sufficient trust and controls.

This makes Azure SRE Agent different from a simple monitoring alert. An alert tells your team that something is wrong. The agent helps investigate why it happened, what changed and what should happen next.

Why legacy IIS workloads need preparation

Many IIS applications were built when monitoring meant checking whether the server was running. Azure may show that the virtual machine is online while customers are receiving errors, payments are failing or employees cannot complete a business process.

Older applications may also write critical information to local text files, use local user sessions, depend on scheduled tasks or connect to databases through undocumented settings. These hidden dependencies make automated recovery risky.

You do not necessarily need to rebuild the application before using Azure SRE Agent. You do need to give the agent clear operational evidence and safe boundaries.

1. Collect useful information from inside the VM

Azure can collect basic information about a virtual machine without installing anything inside it. That provides visibility into areas such as processor load, disk activity and network traffic, but it does not explain what IIS or the application is doing.

For deeper visibility, install Azure Monitor Agent, which collects information from inside Windows, and configure data collection rules. These rules specify which information should be collected and where it should be stored.

For an IIS workload, the useful starting point normally includes:

  • IIS access logs showing requests, response times and errors.
  • Windows Application and System event logs.
  • Processor, memory, disk and network performance.
  • IIS application pool and worker process behaviour.
  • Application exceptions and database dependencies through Application Insights, which monitors what happens inside an application.
  • Azure Activity Logs showing configuration and infrastructure changes.

A simple Log Analytics query can help identify a sudden rise in server errors:

W3CIISLog
| where TimeGenerated > ago(30m)
| summarize
 Requests = count(),
 ServerErrors = countif(scStatus >= 500),
 AverageResponseTime = avg(TimeTaken)
 by Computer, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

The objective is not to collect every possible event. Excessive logging increases storage costs and creates noise. Start with information that helps answer a business question, such as why customers cannot place orders or why a line-of-business application becomes slow each afternoon.

2. Document how the application really works

An AI agent needs operational context, not just server data. Before introducing automated actions, document the application owner, business importance, support contacts, maintenance windows and acceptable recovery time.

You should also record dependencies such as databases, file shares, certificates, service accounts, firewall rules, scheduled tasks and third-party services. If restarting an application pool interrupts a financial batch process, that exception needs to be written down.

Turn existing support knowledge into short runbooks. A useful runbook explains the symptoms, checks to perform, safe actions, conditions that require escalation and how to confirm recovery.

Azure SRE Agent can use these documents as operational guidance. This reduces dependence on the one engineer who remembers how the application was configured eight years ago.

3. Start with limited permissions and human approval

Azure SRE Agent uses a managed identity, which is an Azure-controlled digital identity that avoids storing passwords in scripts. Permissions can be limited using role-based access control, meaning the identity receives only the access required for its job.

For a first deployment, give the agent read-only access to the relevant resource group, monitoring workspace and application data. Keep it in review mode so it can investigate and recommend actions without making production changes independently.

Avoid granting administrator or subscription-wide contributor access simply because it is quicker. Separate production and test environments, restrict the agent to named resources and require approval for actions such as restarting a VM, changing network rules or scaling infrastructure.

Our guide to secure Azure SRE Agent operations for Australian organisations explores these controls in more detail. For broader identity and network planning, see designing secure AI agent infrastructure on Azure.

4. Remove the risks that make recovery unpredictable

Before allowing repeatable recovery actions, check whether the IIS application stores important information locally. Local sessions, uploaded files, temporary transaction data and hard-coded connection details can make a restart or replacement VM disruptive.

Confirm that backups are working, operating systems and applications are patched, certificates are monitored and recovery procedures have been tested. These measures also support the Essential Eight, the Australian Government’s cybersecurity framework that many organisations use to reduce common security risks.

Azure SRE Agent does not make an organisation Essential Eight compliant by itself. It can, however, help teams detect operational issues, follow approved processes and maintain a clearer record of investigations and changes.

Logs may contain usernames, IP addresses or customer information, so access and retention should also be reviewed against Australian privacy requirements. More data is not automatically better data.

5. Pilot one repeatable incident first

Do not begin with the most complex application in the business. Choose one IIS workload with a known, recurring incident and a recovery procedure your team already trusts.

Consider an illustrative 200-person distributor whose ordering portal occasionally produces HTTP 500 errors, meaning the web server cannot complete customer requests. Today, an engineer signs into the server, searches IIS and Windows logs, checks memory usage and manually recycles the application pool.

After preparation, Azure SRE Agent could correlate the increase in errors with memory growth and a recent deployment. It could then propose the approved application-pool recovery action, wait for authorisation, perform the change and verify that error rates return to normal.

The business outcome is not simply “using AI.” It is reducing the time customers are unable to place orders, giving the support team a consistent investigation process and lowering reliance on after-hours manual work.

Measure the pilot using business-focused indicators such as incident duration, support hours, repeat incidents, false alarms and the number of actions that required human correction. Only expand autonomy when the evidence supports it.

AI-assisted operations should make legacy systems safer

Azure SRE Agent can extend the useful life of important IIS workloads while your organisation decides what should be modernised, replaced or retained. But the value comes from preparation: reliable monitoring, documented dependencies, limited permissions, tested runbooks and clear human oversight.

CloudProInc combines more than 20 years of enterprise IT experience with practical Azure, Microsoft 365 and cybersecurity expertise. As a Microsoft Partner and Wiz Security Integrator based in Melbourne, we help organisations introduce AI-assisted operations without losing control of production access, costs or security.

Before scaling beyond a pilot, our production-ready AI agent checklist can help your team review permissions, monitoring, resilience and governance.

If you are unsure whether your IIS virtual machines are ready for Azure SRE Agent, CloudProInc can assess the monitoring, dependencies and operational controls around one workload first — no large migration project required.