rss.livelink.threads-in-node

Understanding IIS Website Limits: Connection Timeout, Bandwidth, and Connection Limits

meenakshiBalekar — Fri, 12 Jun 2026 17:37:52 GMT

In this blog, I am sharing learnings from multiple real-world issues I have worked on where the root cause came down to just three IIS Website Limit settings. On the surface, these options feel pretty straightforward in the UI but in practice, they can quietly become the reason behind major incidents.

I have seen these settings trigger timeouts, dropped connections, and strange performance issues sometimes even before the request makes it to your application. That’s what makes them tricky everything looks fine at the app level, but the problem is already happening underneath.

The idea here is simple, I want to help you recognize these patterns early. If you understand how these limits behave, you can pinpoint the issue faster and avoid hours of unnecessary troubleshooting.

Let’s break it down.

Introduction

When troubleshooting performance issues or unexpected disconnections in IIS-hosted applications, one commonly overlooked area is Website Limits configuration.

These settings are available under:

IIS Manager → Site → Actions → Configure → Limits

This play a crucial role in controlling how the server handles connections and network usage.

In this article, we focus on the three most commonly used settings :

Connection Timeout
Limit Bandwidth Usage
Limit Number of Connections

1. Connection Time-out (in seconds)

What It Does

This setting defines how long IIS keeps a connection open before terminating it if inactive or incomplete.

Default: 120 seconds (2 minutes)
Applies to:
- Idle connections
- Slow uploads
- Requests waiting too long

When It Becomes Important

You will notice impact in scenarios like:

Long-running API calls
Large file uploads
Slow client networks
High queue wait times under load

Common Issues When Misconfigured

Scenario	Observed Issue
Too Low	Requests fail prematurely
Too High	Connections stay open unnecessarily
Under Load	Intermittent failures, timeouts

Typical errors:

Client: Connection reset / cannot reach site
Proxy: 502 / 504 errors
Uploads: Partial uploads fail

Practical Tuning Guidance

Increase when:

APIs take longer to execute
Users upload large files

Decrease when:

You see many idle connections
Facing slow-client attacks or connection hoarding

Critical Insight:
This works at HTTP.sys level, meaning requests may fail before reaching your application.

2. Limit Bandwidth Usage (in bytes)

What It Does

This setting restricts the maximum outbound bandwidth for the website.

If the checkbox is enabled, IIS throttles the response speed.

When It Is Useful

Multi-tenant servers
Shared infrastructure environments
Preventing a single application from saturating the network

What Happens When Misconfigured

Condition	Impact
Too Low	Slow page loads
Too Restrictive	Downloads take very long
Misaligned with workload	User complaints despite healthy CPU/memory

Typical symptoms:

Pages load slowly
File downloads stall
Streaming buffers frequently
Upstream gateway timeouts (504)

Practical Tuning Guidance

Use it when:

You need fair usage across applications
Running in shared hosting environments

Avoid when:

Dedicated production environments
Performance is a priority

Important Note:
This does not reduce server load — it only slows down responses.

3. Limit Number of Connections

What It Does

Controls the maximum number of concurrent connections allowed to the website.

Enabled via checkbox
When limit is reached → IIS rejects new connections

Why You Would Use This

To prevent resource exhaustion
To isolate noisy applications
To enforce traffic control in shared environments

Common Issues When Too Low

Scenario	Observed Issue
Traffic spike	Requests rejected
High concurrency	API failures
Behind proxy	502 / 503 responses

Typical error patterns:

HTTP 503 (Service Unavailable)
Connection failures before app processing

Critical Insight (Very Important for Production)

Even if this is set to unlimited:

Your system is still limited by CPU, memory, threads, and backend dependencies.

Increasing this value:

Does NOT solve performance issues
Can actually amplify failures under load

Practical Tuning Guidance

Set limits when:

You want controlled back-pressure
Protecting shared systems

Avoid blindly increasing limits during incidents

Always investigate:

CPU utilization
App pool queue
Thread starvation
Dependency slowness

Troubleshooting TIPS

When users report:

Random 502 / 504
Upload failures
Intermittent disconnections

Always check:

Connection Timeout
Bandwidth limit
Connection cap

Because:

These settings can reject or terminate requests before your code runs

Quick Summary

Setting	Controls	Common Issue
Connection Timeout	Idle request duration	Timeouts, disconnects
Bandwidth Limit	Response speed	Slowness
Connection Limit	Concurrent requests	503 errors

Let me take you via some Real-World Scenarios: When IIS Website Limits Cause Production Issues

Understanding configuration is important but real value comes from recognizing patterns during incidents.

Below are real-world scenarios where these IIS Website Limits directly impact production systems.

Scenario 1: Intermittent 502 / 504 Errors (Connection Timeout Misalignment)

Situation

Application hosted behind:
- Azure Application Gateway / Nginx / ARR
Users report:
- Random failures
- API calls failing intermittently

What Was Observed

IIS logs show:
- sc-status = 200 (success) for some requests
But users still getting:
- 502 / 504 from gateway

Root Cause

Connection Timeout in IIS = 120 seconds
Upstream proxy timeout = 60 seconds

Result:

Proxy times out first → returns 504
IIS continues processing → client never receives response

Fix

Align timeouts across layers:

App Gateway / Proxy timeout ≥ IIS Connection Timeout
IIS timeout aligned with actual request processing time

Key Learning

Always treat timeouts as a chain, not in isolation.

Scenario 2: Large File Upload Failures (Connection Timeout Too Low)

Situation

Users uploading large files (100MB+)
Upload fails randomly (especially from slower networks)

What Was Observed

Upload stops mid-way
No clear application exception
Connection closed abruptly

Root Cause

IIS Connection Timeout reached while:
- Client still sending request body slowly

HTTP.sys terminated connection before upload completed

Fix

Increase connection timeout
Validate with slow network simulation

Key Learning

Connection timeout applies not just to idle connections but also to slow request body transmission

Scenario 3: HTTP 503 During Traffic Spike (Connection Limit Too Low)

Situation

Sudden spike in traffic (deployment / marketing event)
APIs start failing

What Was Observed

IIS logs:
- 503 Service Unavailable
Users:
- Random failures
CPU < 50% (system not overloaded)

Root Cause

"Limit number of connections" was enabled
Configured value too low

IIS started rejecting new connections once threshold hit

Fix

Increase connection limit
OR remove limit if not required
Validate actual concurrency vs configured cap

Key Learning

503 does not always mean server overload it can be intentional rejection due to limits

Scenario 4: Site is Slow but No Resource Bottleneck (Bandwidth Limit Enabled)

Situation

Users report:
- Slow page loads
- Slow downloads

What Was Observed

CPU: Normal
Memory: Normal
No thread contention

But:

Response times extremely high

Root Cause

"Limit bandwidth usage" enabled in IIS
Value set very low

IIS throttling response speed intentionally

Fix

Disable bandwidth limit
OR increase to realistic throughput

Key Learning

Bandwidth limit causes artificial slowness, not system bottleneck

Scenario 5: Random Disconnects Under Load (Connection Timeout + Queue Wait)

Situation

High traffic
Some requests succeed, some fail

What Was Observed

Requests spend time in:
- App pool queue
Then fail before execution

Root Cause

Requests waiting too long in queue
Connection timeout reached before execution started

Fix

Increase timeout (short-term)
Fix root cause:

Thread starvation
Slow backend dependencies

Key Learning

Timeouts can occur even before request execution begins

Troubleshooting Patterns to Remember

When analyzing IIS issues, map symptoms quickly:

Symptom	Likely Setting
502 / 504 (intermittent)	Connection Timeout mismatch
Upload failures	Connection Timeout
503 under load	Connection Limit
Everything slow but CPU fine	Bandwidth Limit
Random disconnects	Timeout or queue delay

Some useful Insight

In real production environments, IIS limits rarely act alone, they amplify existing system behaviors.

A well-performing system:

Aligns timeouts across layers
Avoids unnecessary limits
Uses limits for protection, not masking

IIS and CVE-2026-49975

Rene_Gross — Mon, 08 Jun 2026 08:01:40 GMT

Hello IIS Team,

our SOC Team informed us about the CVE-2026-49975 vulnerability in MS IIS.

I could'nt found any patch for this. So my question is - are there any plans for for a patch / hotfix or what can we do to fix this?

Greetings Rene

Source:

https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

UPDATE: IIS no longer serving up one of my websites

gregaryb — Tue, 12 May 2026 11:55:56 GMT

I have two websites on my windows 10 desktop:

https://www.gregsnativelandscapes.com.au: This one is working fine.
https://www.gjb.au This one is not working - all I get is
This site can’t be reached
The connection was reset.

What the hell?

I have checked:

The bindings - https, correct domain name
Both web sites are started.
I have done ISSRESET.
Checked my A records in Webcentral account.
I have gone through the IIS settings of each website and checked that they are all the same - they are.

So what else do I need to check?

Is there a specific IIS troubleshooter available that I can download and run?

IIS on Windows 10 no longer serving my websites

gregaryb — Wed, 06 May 2026 12:45:24 GMT

My websites were working, i.e. I could access them on my mobile phone.

But something has happened abd they are not longer accessible - "NOT FOUND"

I have checked:

The bindings - https, correct domain name
Both web sites are started.
I have done ISSRESET.
Checked my A records in Webcentral account.

So what else do I need to check?

Is there a specific IIS troubleshooter available that I can download and run?

How to Add an Adaptive Card in Microsoft 365 Agent SDK

meenakshiBalekar — Wed, 01 Apr 2026 01:12:58 GMT

One of the most important UI capabilities is Adaptive Cards, which let your agent send structured, interactive content such as forms, inputs, buttons, and layouts.

In this guide, you’ll learn exactly how to:

Create an Agent SDK bot
Send an Adaptive Card when a user joins
Handle Action.Execute submit events
Parse user input from the card
Respond with text

I will walk through the full working code from my project.

You can download complete sample from : M365AgentSDKAdaptiveCard

Step 1: Understanding How Adaptive Cards Work in Agent SDK

Adaptive Cards are sent in the Agent SDK using:

var attachment = new Attachment { ContentType = "application/vnd.microsoft.card.adaptive", Content = <JSON> };

You then send them like this:

await turnContext.SendActivityAsync(MessageFactory.Attachment(attachment));

And to handle submit actions (Action.Execute), the Agent SDK triggers:

ActivityTypes.Invoke Name = "adaptiveCard/action"

Step 2: Use the Adaptive Card Designer

Create or test your card on our new designer here: https://adaptivecards.microsoft.com/designer

Your sample card:

Collects name & age
Uses Action.Execute with verb "personalInfo"

Step 3: The Full Working Agent SDK Code

Below is the complete working implementation showing:

✔ Welcome card using Adaptive Card
✔ Parsing Action.Execute values
✔ Responding back to the user

This is based entirely on your code, cleaned up and rewritten for clarity & correctness.

Complete Agent SDK Bot with Adaptive Card

using Microsoft.Agents.Builder; using Microsoft.Agents.Builder.App; using Microsoft.Agents.Builder.State; using Microsoft.Agents.Core.Models; using Microsoft.Extensions.Hosting; using Microsoft.Extensions.Logging; using System.Text.Json; using System.Text.Json.Nodes; using System.Threading; using System.Threading.Tasks; namespace MyFirstAgentSDK.Bot; public class EchoBot : AgentApplication { public EchoBot(AgentApplicationOptions options, IHostEnvironment env, ILoggerFactory loggerFactory) : base(options) { OnConversationUpdate(ConversationUpdateEvents.MembersAdded, WelcomeMessageAsync); OnActivity(ActivityTypes.Message, OnMessageAsync, rank: RouteRank.Last); OnActivity(ActivityTypes.Invoke, OnInvokeAsync); } private async Task WelcomeMessageAsync(ITurnContext turnContext, ITurnState turnState, CancellationToken cancellationToken) { foreach (ChannelAccount member in turnContext.Activity.MembersAdded) { if (member.Id != turnContext.Activity.Recipient.Id) { var attachment = new Attachment { ContentType = "application/vnd.microsoft.card.adaptive", Content = """ { "type": "AdaptiveCard", "version": "1.4", "schema": "http://adaptivecards.io/schemas/adaptive-card.json", "body": [ { "type": "Container", "items": [ { "type": "TextBlock", "text": "Please enter your personal information", "weight": "Bolder", "size": "Medium", "color": "Accent" }, { "type": "Input.Text", "id": "Name", "label": "What's your name?", "placeholder": "Enter your full name", "maxLength": 50, "isRequired": true, "errorMessage": "Name is required" }, { "type": "Input.Number", "id": "Age", "label": "How old are you?", "placeholder": "Enter your age", "min": 1, "max": 150, "isRequired": true, "errorMessage": "Please enter a valid age between 1 and 150" } ], "style": "emphasis", "spacing": "Medium" } ], "actions": [ { "type": "Action.Execute", "title": "Submit", "verb": "personalInfo", "style": "positive" } ] } """ }; await turnContext.SendActivityAsync(MessageFactory.Attachment(attachment), cancellationToken); } else { await turnContext.SendActivityAsync(MessageFactory.Text("Hello and Welcome!"), cancellationToken); } } } private async Task OnMessageAsync(ITurnContext turnContext, ITurnState turnState, CancellationToken cancellationToken) { await turnContext.SendActivityAsync($"You said: {turnContext.Activity.Text}", cancellationToken: cancellationToken); } private async Task OnInvokeAsync(ITurnContext turnContext, ITurnState turnState, CancellationToken cancellationToken) { if (turnContext.Activity.Name == "adaptiveCard/action") { JsonElement root; if (turnContext.Activity.Value is JsonElement element) { root = element; } else { var json = JsonSerializer.Serialize(turnContext.Activity.Value); root = JsonDocument.Parse(json).RootElement; } if (root.TryGetProperty("action", out var action)) { if (action.TryGetProperty("verb", out var verbElement) && verbElement.GetString() == "personalInfo") { if (action.TryGetProperty("data", out var data)) { var name = data.GetProperty("Name").GetString(); var age = data.GetProperty("Age").ToString(); await turnContext.SendActivityAsync(MessageFactory.Text($"Hello {name}, you are {age} years old!"), cancellationToken); var invokeResponse = new Activity { Type = ActivityTypes.InvokeResponse, Value = new InvokeResponse { Status = 200 } }; await turnContext.SendActivityAsync(invokeResponse, cancellationToken); } } } } } }

Step 4: What This Code Does

1. Sends an Adaptive Card when a new user joins or as per your criteria

The card that I have used includes:

Text
Name input (required)
Age input (required)
A submit button with verb "personalInfo"

2. When the user clicks Submit

Teams / Message Extension sends:

invoke name = adaptiveCard/action

OnInvokeAsync() receives:

{ "action": { "verb": "personalInfo", "data": { "Name": "...", "Age": "..." } } }

3. Bot parses and sends a text response

Example output:

Hello Meenakshi, you are 30 years old! ( P.S I am older than this )

Locally when you run the project on playground it looks like :

This is how it looks on test in webchat

And this how it looks on teams :

4. Responds with 200 status

This is required for Teams & M365:

var invokeResponse = new Activity { Type = ActivityTypes.InvokeResponse, Value = new InvokeResponse { Status = 200 } }; await turnContext.SendActivityAsync(invokeResponse, cancellationToken);

Conclusion

With the Microsoft 365 Agent SDK:

Action.Execute events are handled inside OnInvokeAsync
Inputs are parsed through the Activity.Value JSON payload
The SDK is lightweight and much simpler than the old Azure Bot SDK

Your bot is now fully capable of collecting structured user input using Adaptive Cards.

Drop in any queries or samples that you would like me to explain.

Happy Learning!

Let's Create Our First Microsoft 365 Agent SDK using Python - For Single Tenant

meenakshiBalekar — Wed, 01 Apr 2026 01:12:42 GMT

Step 1: Set Up Your Development Environment

I am using VS Code, so you don’t need to manually install Python on your system (unless you want to).
VS Code can handle Python via extensions which makes it super easy and everything at once place.

You can download complete sample : here

Install These Extensions in VS Code

Open VS Code → Extensions → install:

Python (Microsoft)
Dev Tunnels (optional but helpful)
GitHub Pull Requests & Issues ( Saves a lot of Download time)

These ensure:

You can run Python files directly inside VS Code
IntelliSense / linting works
Dev tunnel commands work in the integrated terminal

Step 2: Download/Clone the Official Sample

I am using this exact sample: Agent SDK Python Cards

Run these commands inside VS Code Terminal:

git clone https://github.com/microsoft/Agents.git cd Agents/samples/python/cards

You now have the complete working Python Agent sample.

Step 3: Install All Required Packages

Inside the cards folder, run:

pip install -r requirements.txt

This installs:

FastAPI
Uvicorn
Agents SDK
dotenv

VS Code will automatically detect and configure a Python interpreter for you. Once done, your requirements.txt file will look like :

Step 4: Add Your M365 Agent Configuration

Inside the folder, you’ll see:

.env.TEMPLATE

Rename it to:

.env

Then open the file and fill in:

CONNECTIONS__SERVICE_CONNECTION__SETTINGS__CLIENTID= CONNECTIONS__SERVICE_CONNECTION__SETTINGS__CLIENTSECRET= CONNECTIONS__SERVICE_CONNECTION__SETTINGS__TENANTID=

Here I am creating a single tenant bot, hence I am suing these settings for MSI it will be different
You can refer the different type of available authentication types here

Python -m src.main

Where do these values come from?
Your Azure portal -> App Registration/ Managed Identity ( Depending on what type of application is created)

Step 5: Run the M365 Agent Locally

Start your Agent:

Python -m src.main

You will see :

But you will not be able to test the bot here locally, so we would need additional tools to help us test locally.

Step 6: Create a Dev Tunnel

You must expose your local bot over HTTPS.
For that we use devtunnel.

Step 6.1 — Authenticate devtunnel

You must authenticate first or you’ll get:

Unauthorized tunnel creation access

So run:

devtunnel user login

A browser pops up -> Sign in with the same Microsoft account used for your M365 Agent.

Step 6.2 — Create the Tunnel

Now run:

devtunnel host -p 3978 --allow-anonymous

You will get a public HTTPS URL like:

Copy this URL and we can test the bot in Azure bot service

Step 7: Update the M365 Agent Endpoint in Portal

Go to your Azure portal → ABS Agent → Settings → Endpoint URL
Paste: <tunnel-url>/api/messages

Click Save.

At this point:

Your Agent is running locally
Your tunnel is publishing it
You will be able to can talk to your Agent

Step 8: Test the Agent (The Fun Part)

Go to your Azure bot service → Test in Web Chat.

Type:

hello

You should get back the card responses from the sample.

If the sample sends Adaptive Cards or text messages, you will see them appear here exactly as coded.

That's It! You Built Your First Python M365 Agent

This guide took you from:
✔ VS Code setup
✔ Python environment extensions
✔ Cloning the sample
✔ Adding env configuration
✔ Running the Agent
✔ Creating a dev tunnel
✔ Testing in Web Chat

Happy Learning!

Resolving Weak SSL Ciphers in .NET Framework 4.5

Goyal_Sandeep — Wed, 01 Apr 2026 01:12:12 GMT

Symptom

Applications built on the .NET Framework 4.5 may fail to establish secure HTTPS connections or may default to outdated and insecure protocols. This can result in connection failures, browser security warnings, or rejection by modern APIs and services that require stronger encryption standards like TLS 1.2 or higher.

Cause

.NET framework 4.5 is out of support and hence it does not use the latest cryptography mechanisms, we strongly recommend building apps in supported frameworks. Add the support lifecycle article there

.NET Framework official support policy | .NET

Resolution

The most robust fix is to upgrade your application to .NET Framework 4.6, 4.7 or later, where TLS 1.2 is enabled by default. This ensures your application uses stronger cipher suites and secure protocols automatically, without requiring additional configuration.

After installing the newer .NET Framework on your development or production environment, update your project’s target framework and recompile. For ASP.NET applications, update your Web.config file to reflect the new framework version. For example, if upgrading to .NET 4.6:

<system.web>

</system.web>

This change, along with rebuilding your application under the updated framework, ensures that IIS and the .NET runtime use the latest libraries. Once deployed, your application will negotiate HTTPS connections using TLS 1.2 by default, resolving issues related to weak or unsupported cipher protocols.

IIS setup a web site to be accessed without a domain name....how?

Gregary — Thu, 08 Jan 2026 10:51:25 GMT

I want to setup a web site for testing without a domain name.
I have 3 web sites with domain name that are working fine.
I am working on a web site for Millhouse and they already have an existing web site with the domain name millhouse.org.au

I want to setup their new web site on my web server for testing purposes and so member of the organisation can view it (as http) to assess it.
I want to be able access it like this: 58.168.225.214:8080
But what I have done so far isn't working:

I have setup port fording in my modem with WAN and LAN ports of 8080.

And 8080 as the port in the web site settings in IIS.

IIS Site Randomly Returns 404 While App Pool Remains Started

captainit — Fri, 26 Dec 2025 21:17:14 GMT

Hello,

We have an IIS site running behind Azure Front Door that becomes unavailable every few days.

Symptoms:

Application Pool remains started

Users see the blue "Not Found" page from Azure Front Door

When accessing the site directly on the server during the failure, we get a 404 from IIS, not Front Door

The site does not recover on its own

Recovery requires an App Pool recycle or IIS restart, and sometimes a full server reboot because recycle or IIS restart does not help

What it is NOT:

No CPU, memory, disk, or network pressure

Event logs do not correlate with the outage

When it happens:

Random and unpredictable

Any insights would be appreciated.

From the server itself:

Please your support.

Azure Bot Identity | Application with identifier 'x' was not found in the directory 'Bot Framework'

manojdixit — Fri, 05 Dec 2025 14:42:50 GMT

TL;DR

Every Azure Bot has a fixed identity (MicrosoftAppId) tied to either an App Registration or a Managed Identity—it cannot be changed or reused.
Azure Bot supports three identity types:
- User-Assigned Managed Identity
- Single-Tenant App Registration
- Multi-Tenant App Registration (deprecated after July 31, 2025)
Bots involve three auth flows:
1. Client → Channel (platform-specific)
2. Channel ↔ Bot (core system auth using OAuth2 + Entra ID)
3. User sign-in (optional; uses Authorization Code Flow)
The error “AADSTS700016: Application with identifier 'xxx' was not found in the directory 'Bot Framework'” happens when the Bot application tries to request tokens from the botframework.com tenant instead of its home tenant while the App registration is set as SingleTenant.
BotFrameworkAdapter Class (Microsoft.Bot.Builder) | Microsoft Learn is hardcoded to the Bot Framework tenant and does not work with Single-Tenant or Managed Identity bots. In Bot-Builder SDK (retires after Dec 2025), CloudAdapter Class (Microsoft.Bot.Builder.Integration.AspNet.Core) | Microsoft Learn supports SingleTenant and UserAssigned-MSI bots and MicrosoftAppType needs to be configured to reflect the correct Bot Identity.
With announcement of the Bot-Builder SDK deprecation, we recommend moving to The M365 Agents SDK which retains many Bot Builder concepts with ability to create next generation Agents with orchestration, observability and more secure options authentication. This also offers flexible and more secure options for token aquisition.

Skip directly to the "Channel (2) ↔ Bot (3) Authorization" section if you want to understand why the error occurs.

Azure Bot Identity

Every Azure Bot Service has a unique Id (also known as MSAAppId or MicrosoftAppId) which you can find in Azure Portal -> Azure Bot Resource -> Configuration if the Bot is created:

This MSAAppId corresponds to either the Client ID of Application Registration in Microsoft Entra ID or Managed Identity in Azure . This is Id is tied to the respective Bot Service from creation until deletion, cannot be modified or reused for a different Bot resource. Closely related to this is the concept of the Azure Bot Identity Type and can be one of the following:

User-assigned managed identity - identity tied to a Managed Identity in Azure
Single-tenant - identity tied to an Application Registration in Microsoft Entra ID with Supported account types = Accounts in this organizational directory only
- Reference - How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn
Multi-Tenant (Deprecated – ends July 31, 2025) - identity tied to an Application Registration in Microsoft Entra ID with Supported account types = Accounts in any organizational directory
- Reference - Microsoft Identity Platform Glossary - Microsoft identity platform | Microsoft Learn

References:

Create an Azure Bot resource in the Azure portal - Bot Service | Microsoft Learn

Identity and Authorization

As described in Navigating Azure Bot Networking: Key Considerations for Privatization, an Azure Bot Solution consists of below components:

Clients (1): User-facing application used to consume/converse with Bot solutions. Examples include Web Chat Widget, Teams, Slack etc.
The Bot Service: This managed SaaS umbrella includes configuration management, channel services and token services. Services are made available with the <service>.botframework.com endpoints.
The Bot Application (2): Using the Bot/Agents SDK or Composer, you create an HTTP-based application that encapsulates your functional and conversational logic, including recognition, processing, and storage. The Bot application operates using the Bot Framework Activity Specification. The Bot application exposes a public messaging endpoint for receiving activities (messaging endpoint).
Channel Connectors (3): While Azure Bot Service provides two native channels—Direct Line and Web Chat—it is designed to be highly extensible and supports integration with additional clients and communication platforms through external channels. These channels are implemented and operated by their respective providers and run within their own managed data centers. The bot’s messaging endpoint is not exposed directly to end users; instead, users interact with the bot via channel connectors, which handle session management, activity routing, and authentication on behalf of the client. Different clients, such as Teams and Slack, represent messages and activities uniquely. Since Bot applications understands and responds with activities as defined in the Bot Framework Activity Specification, channels are responsible for transforming activities and forwarding them to the application.

There are 3 Authentication/Authorization flows in a Bot solution.

Client (1) to Channel (2) Authentication - This flow is platform-specific and is implemented by the channel owner. It governs how an end-user or client application authenticates with the channel before any interaction reaches the bot. For example, the Direct Line channel requires a token or secret to establish trust, as described in Direct Line Authentication in Azure AI Bot Service - Bot Service | Microsoft Learn
Channel (2) <-> Bot (3) Authorization - This flow is channel-independent and is consistent across all Azure Bot channels. Communication between the channel and the bot occurs via bi-directional HTTPS calls secured using OAuth2 JWT Access Tokens issued by Microsoft Entra ID. Both the channel and the bot validate each other by exchanging these tokens. This mechanism is what directly relies on the Azure Bot Identity type (Managed Identity, Single-Tenant App, or legacy Multi-Tenant App) and is the primary focus of this blog.
User Authentication - This is an optional flow enables end users to authenticate within the chat experience so the bot can identify the user, access protected user data or perform actions on the user’s behalf (e.g., schedule meetings, access emails). User authentication is implemented using the "Authorization Code Flow" and supports multiple identity providers, including Microsoft Entra ID. When Entra ID is used, the bot can authenticate users using the same App Registration as the bot identity, or a separate App Registration, depending on security and design requirements. This user sign-in process is independent of the Channel-to-Bot authorization flow and is not affected by the bot’s identity type.

- References:
  - Add authentication to a bot in Bot Framework SDK - Bot Service | Microsoft Learn
  - Flow Diagram - botframework-sdk - In a brief:
    - The Bot application checks whether a user access token already exists in the Azure Bot Token Store.
    - If no token is found, the bot challenges the user to sign in within the chat interface. Some channels, such as Microsoft Teams, also support SSO - Enable SSO with Microsoft Entra ID - Teams | Microsoft Learn
    - The issued token is then securely stored in the Azure Bot Token Store.
    - The user is redirected to the configured Identity Provider (for example, Microsoft Entra ID) and authenticates successfully.
    - The Bot application retrieves the token from the Token Store and uses it to access protected resources or perform actions on the user’s behalf.

Channel (2) <-> Bot (3) Authorization

As we see in the "Outbound Flow: Bot to Channel", the Bot Application typically uses OAuth 2.0 client credentials flow on the Microsoft identity platform - Microsoft identity platform | Microsoft Learn. The token authority (endpoint) used for this flow depends on the Bot Identity Type, as documented in Authenticate requests with the Bot Connector API - Bot Service | Microsoft Learn.

The error "Application with identifier 'xxx' was not found in the directory 'Bot Framework'" happens when:

The Bot’s Application Registration is configured as Single-Tenant
(Supported account types = Accounts in this organizational directory only)
The Bot application requests a token from the Bot Framework tenant:
- https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token
Since the App Registration is Single-Tenant, only the home tenant can issue tokens.
The Bot Framework tenant is not the home tenant → token issuance fails.

All the operations shown in diagram except business logic is automatically handled by the SDK (BotSDK or AgentsSDK) but the Developer gets control correct token endpoint.

Bot SDK automatically infers the token endpoint/Authority based on the configuration:
- If you are using BotFrameworkAdapter Class (Microsoft.Bot.Builder) | Microsoft Learn - it will always make calls to "https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token". Thus, it cannot work with SingleTenant or UserAssigned MSI Bot.
- If you are using CloudAdapter Class (Microsoft.Bot.Builder.Integration.AspNet.Core) | Microsoft Learn, it supports configuring the Bot Identity using the MicrosoftAppType. Review samples to understand how this is configured for different runtimes:
  - BotBuilder-Samples/samples at main · microsoft/BotBuilder-Samples · GitHub
  - BotBuilder-Samples/samples/csharp_dotnetcore/02.echo-bot/appsettings.json at main · microsoft/BotBuilder-Samples · GitHub
M365 Agents SDK - This is a successor of Bot SDK and will be the only supported SDK after December 2025:
- The Identity configuration is flexible and simplified in Agents SDK. The concepts remain same, appropriate token endpoint/authority needs to be used.
  - Configure authentication in a .NET agent | Microsoft Learn
  - Agents/samples at main · microsoft/Agents · GitHub

Migration fromMultiTenant SingleTenant to in the Bot code:

With announcement of the Bot-Builder SDK deprecation, we recommend moving to Agents SDK which retains many Bot Builder concepts with ability to create next generation Agents with orchestration, observability and more secure options authentication.
- GitHub - microsoft/botframework-sdk: Bot Framework provides the most comprehensive experience for building conversation applications.
- Azure Bot Framework SDK to Microsoft 365 Agents SDK migration guidance | Microsoft Learn
For Bot SDK to work with SingleTenant, you must use CloudAdapter Class (Microsoft.Bot.Builder.Integration.AspNet.Core) | Microsoft Learn and configure correct MicrosoftAppType.

I hope it helps.

Addressing .Net EOL installations for Windows Admins

manojdixit — Fri, 28 Nov 2025 13:53:53 GMT

TL; DR:

Installing the latest .NET runtime on a server does not upgrade existing applications that are built on unsupported versions (for example, anything older than .NET 8 as of Nov 2025). Applications must be explicitly upgraded through a full development lifecycle—retargeting the project to a supported framework, updating dependencies, rebuilding, testing, and redeploying.

This is not something a Windows administrator can safely perform alone. However, admins can and should identify which applications are running on EOL .NET versions and coordinate with development teams to ensure they are upgraded to a supported release.

.NET vs .NET Framework: Understanding the Difference

Unlike the classic .NET Framework, modern .NET (formerly .NET Core) is not an integral part of the Windows operating system. It is typically installed on-demand when an application requires it. This means multiple .NET versions can coexist on the same system without automatically affecting each other.

Modern .NET is:

Cross-platform (Windows, Linux, macOS)
Open source
Designed for rapid evolution and cloud-native development

Because of these design goals, modern .NET follows a fixed annual release cadence with defined support timelines.

Official documentation:

End of Life (EOL)

As a .NET version approaches End of Life (EOL), Microsoft recommends upgrading to a supported version and reducing dependency on the expiring runtime. After EOL:

Security updates stop
Bug fixes stop
Microsoft technical support ends
Compliance and audit risks increase

Microsoft strongly discourages continued use of unsupported runtimes:

Using out-of-support .NET versions may expose your applications, data, and environment to security vulnerabilities and operational failures.

EOL is also referred to as End of Support (EOS).

Why Security Tools Flag EOL .NET Installations

Once a .NET runtime reaches EOL, vulnerability scanners and endpoint security software often flag it as a risk and recommend removal. Even if your tools do not explicitly report it, proactive removal and upgrade is still best practice.

Before uninstalling, however, administrators typically ask:

What will break if I remove this version?
Can I just install the latest .NET to replace it?
Which applications are dependent on this runtime?
Can I safely remove it if nothing appears to use it?

Here is a general workflow that can be used to address the above questions:

Step 1 – Identify Applications Using EOL ASP.NET / .NET Runtimes

Important: The steps below identify only the applications actively running at the time of execution. Any dormant services, scheduled tasks, or rarely used applications may still depend on EOL .NET but will not appear until they are executed.

To identify currently running applications that are using the .NET runtime, you can use Sysinternals ListDLLs from Microsoft.
Download ListDLLs - Sysinternals | Microsoft Learn and run the following command from an elevated (Administrator) CMD prompt:

listdlls.exe -d coreclr.dll -accepteula -vSample output of listdll command

This will show all the dotnet processes (with versions 6/7 or 8 or previous) along with version of .Net runtime loaded (coreclr). Make a note of processes that are loading EOL .Net versions - .NET and .NET Core official support policy.

Note - coreclr is the Dotnet runtime dll which will be loaded in a .Net process. The listdll shows a specific version loaded by respective process, that would help identify processes using EOL .Net runtime.

Reference - CoreCLR is now Open Source - .NET Blog

Step 2 - Reach to the developers to upgrade the Application to supported version:

Applications do not automatically upgrade to a newer .NET version simply because a supported runtime is installed on the server. Each application must be rebuilt and retargeted to explicitly use the newer framework version.
The upgrade process typically follows a full software development lifecycle (SDLC), including:
- Retargeting the project to the latest supported .NET version
- Updating NuGet packages and dependencies
- Fixing breaking changes
- Rebuilding the application
- Functional and regression testing
- Deployment to production
This process is not something a Windows administrator can safely perform alone. It requires access to the application source code and ownership from the development or product team. Administrators should focus on identifying incompatible or EOL runtimes and coordinating with application owners to plan upgrades.
Reference:
- Upgrade to a new .NET version - .NET | Microsoft Learn

Step 3 – Confirm No Applications Are Using EOL .NET Runtimes

After application owners have upgraded and deployments are completed, you must verify that no processes are still running on unsupported .NET runtimes.

Repeat the same process from Step 1 to re-scan the system:

Step 4 – Uninstall / Remove EOL .NET Runtimes

Once you confirmed no dependency on the EOL products you can proceed with uninstall.
Note that .Net apps can be self-contained or framework-dependent:
- .NET application publishing overview - .NET | Microsoft Learn
- Publish self-contained
  This mode produces a publishing folder that includes a platform-specific executable used to start the app, a compiled binary containing app code, any app dependencies, and the .NET runtime required to run the app. The environment that runs the app doesn't need to have the .NET runtime preinstalled.
- Publish framework-dependent
  This mode produces a publishing folder that includes an optional platform-specific executable used to start the app, a compiled binary containing app code, and any app dependencies. The environment that runs the app must have a version of the .NET runtime installed that the app can use.
  - Framework dependant apps will use the shared runtimes that you may have installed from Download .NET (Linux, macOS, and Windows) | .NET.
- For self-contained apps, the developer must provide a latest package with supported runtimes.
Of course, to anticipate failure, please have back up/recovery plans and execute the actions during a downtime as per your company policies.

I hope this helps.

HTTPS Reverse Proxy on IIS 10 – External Access Fails (Timeout) Although Local Requests Work

raysefo — Sat, 22 Nov 2025 20:03:22 GMT

Hello everyone,

I’m currently facing an issue with an IIS 10 reverse proxy configuration on Windows Server, and I would really appreciate your guidance.

Environment

Windows Server

IIS 10

Application Request Routing (ARR) + URL Rewrite enabled

Backend application running on:

http://localhost:8080/ http://localhost:8080/login

Public domain:

https://lojistik.abc.com.tr

What I want to achieve

I want users to access the backend web application through the following URL:

https://lojistik.abc.com.tr/LMYS/login

Internally, IIS should proxy this to:

http://localhost:8080/login

What works

The backend application is accessible without issues:

http://localhost:8080/login

From the server itself, reverse proxy works:

Invoke-WebRequest "https://lojistik.abc.com.tr/LMYS/login"

→ StatusCode: 200 (success)

What does NOT work

From any client machine, the following request results in a timeout:

https://lojistik.abc.com.tr/LMYS/login

Browser shows connection timeout.

No entry appears in IIS logs for external requests to /LMYS/....

Tests performed

▪ netstat -ano | findstr :443 on the server → Port 443 is listening ▪ DNS resolves correctly:

lojistik.abc.com.tr → 10.6.130.90

▪ Reverse proxy rule on IIS is correctly configured under the HTTPS binding site:

Pattern: ^LMYS(/.*)?$ Rewrite to: http://localhost:8080{R:1}

▪ ARR Server Proxy is enabled.

Key observation

Requests from the server itself succeed (reverse proxy returns 200), but external clients always time out, which suggests that the HTTPS traffic is not reaching IIS at all (likely blocked or not NAT-forwarded on the network path).

Question

What could cause HTTPS (port 443) traffic to reach IIS locally, but external requests to the same port to hang indefinitely?

Any guidance would be greatly appreciated.

Thank you in advance.

Best regards,

Why Does an Old Certificate Reappear After Reboot in Azure VMs?

Shekhar — Wed, 29 Oct 2025 16:02:22 GMT

Issue Observed

A customer removed an expired SSL certificate from their Azure VM after installing a renewed one. However, after every reboot, the old certificate reappeared, and IIS site bindings automatically started picking it up.

Investigation Steps

1. Identify the Process Bringing Back the Certificate

To trace the root cause, we configured Sysmon following this guide:
Auditing Scenarios for Web Application Hosted in IIS - Part 1 - SSL Binding Modified | Microsoft Community Hub

We asked the customer to remove the certificate and reboot the server to reproduce the issue.
After rebooting, the certificate was reinstalled. Event logs revealed a process named akvvm_service.exe was responsible for bringing the certificate back.

Following is the screenshot from the event log:

I then checked the task manager to check about the process (7964) and see following:

2. What is akvvm_service.exe?

akvvm_service.exe is the service executable for the Azure Key Vault VM extension.
Purpose of this service:
- Monitors certificates stored in Azure Key Vault that the VM is configured to observe.
- Automatically downloads, installs, and refreshes those certificates into the Windows certificate store (e.g., LocalMachine\My) at a defined polling interval:
  - Azure Key Vault VM extension for Windows - Azure Virtual Machines | Microsoft Learn

3. Why Was This Happening?

The customer had multiple certificates in their Key Vault. The VM extension KeyVaultForWindows was pulling all configured certificates back into the server during every reboot.

To check the extensions:
Go to Azure VM -> Search for Extensions -> Select Extensions + applications:

We see all the Extensions + applications configured with the VM and here we see this extension KeyVaultForWindows configured:

Further checks revealed:

Issue was only happening in DEV, TEST and STG environment and not in PROD

DEV, TEST, and STG environments had the KeyVaultForWindows extension installed.
PROD environment did not have this extension, which explained why the issue was isolated to non-PROD environments.

Resolution

We shared the following action plan:

Option 1: Uninstall the Key Vault VM extension to match the PROD setup.
Option 2: Delete or disable certificates that are no longer required in Key Vault.

The customer chose Option 2 and confirmed:

“Disabling expired certificates within Key Vault fixed the issue.”

Key Takeaways

If old certificates reappear after reboot, check for Azure Key Vault VM extension.
This extension automatically syncs certificates from Key Vault to your VM.
To prevent unwanted certificates:
- Remove the extension if not needed.
- Or disable/delete unnecessary certificates in Key Vault.

IIS app pool in-memory cache miss

indrajit — Fri, 03 Oct 2025 16:56:02 GMT

Hi,

Our IIS server runs on windows 2016 servers, recently we are experiencing frequent miss from in-memory cache, and instead of connecting to NCache which is our cache solution, it is sending request to database. After lots of debug we still could not identify the issue here. But as a best practice we are going to change some setting. But, one suggestion is to change max worker count from 4 to 1. Will that impact our performance? How much will it be effective to bring that value to 1 from 4, in terms of single worker cache miss issue occurrences?

Troubleshooting File Upload Error: 413 Request Body Too Large in .NET Core

Goyal_Sandeep — Tue, 02 Sep 2025 16:25:30 GMT

Troubleshooting File Upload Error: 413 Request Body Too Large in .NET Core

When working with file uploads in .NET Core, you might encounter the 413 "Request Body Too Large" error even if the maxAllowedContentLength value in your web.config file is correctly set. This issue can be perplexing, especially when all configurations seem to be in place. In this blog, we will explore a common cause of this error related to the ASPNETCORE_TEMP environment variable and how to resolve it.

Understanding the Issue

The 413 error indicates that the request body size exceeds the server's configured limit. Typically, this is controlled by the maxAllowedContentLength setting in the web.config file. However, if the ASPNETCORE_TEMP environment variable is incorrectly set, it can lead to this error despite having the correct maxAllowedContentLength value.

Scenario

Let's consider a scenario where the maxAllowedContentLength in the web.config file is set to 50 MB, but the application still throws a 413 error for files larger than 10 MB. Upon investigation, it is found that the ASPNETCORE_TEMP environment variable is incorrectly configured in the launchSettings.json file.

Steps to Resolve the Issue

Verify maxAllowedContentLength in web.config: Ensure that the maxAllowedContentLength value in your web.config file is correctly set according to your requirements. For example:

<system.webServer>

</requestFiltering>

</security>

</system.webServer>

Check ASPNETCORE_TEMP Environment Variable: The ASPNETCORE_TEMP environment variable specifies the location where ASP.NET Core stores temporary files, such as those used for buffering large request bodies. If this variable is incorrectly set, it can cause the 413 error.
Update launchSettings.json: Ensure that the ASPNETCORE_TEMP environment variable is correctly configured in the launchSettings.json file. Here is an example of how to set it:

{

"profiles": {

"IIS Express": {

"commandName": "IISExpress",

"launchBrowser": true,

"environmentVariables": {

"ASPNETCORE_ENVIRONMENT": "Development",

"ASPNETCORE_TEMP": "C:\\Temp\\ASPNETCORE"

}

"YourProjectName": {

"commandName": "Project",

"dotnetRunMessages": true,

"launchBrowser": true,

"applicationUrl": "https://localhost:5001;http://localhost:5000",

"environmentVariables": {

"ASPNETCORE_ENVIRONMENT": "Development",

"ASPNETCORE_TEMP": "C:\\Temp\\ASPNETCORE"

}

Verify the Temporary Directory: Ensure that the directory specified in the ASPNETCORE_TEMP environment variable exists and has the necessary permissions for the application to write temporary files.

Example Case

In a recent support case, the maxAllowedContentLength was set to 50 MB in the web.config file, but the application was still throwing a 413 error for files larger than 10 MB. Upon checking, it was found that the ASPNETCORE_TEMP environment variable was set to an incorrect path in the launchSettings.json file. Correcting the path resolved the issue.

Conclusion

By ensuring that the ASPNETCORE_TEMP environment variable is correctly set and the maxAllowedContentLength value in the web.config file is appropriate, you can resolve the 413 "Request Body Too Large" error in your .NET Core application. Proper configuration of these settings ensures smooth handling of large file uploads without encountering size-related errors.

If you have any further questions or need additional assistance, feel free to reach out!

Enabling Client Certificate Authentication for an Application Inside Default Web Site

Goyal_Sandeep — Tue, 02 Sep 2025 16:25:14 GMT

Enabling Client Certificate Authentication for an Application Inside Default Web Site

In this blog, we will explore how to enable client certificate authentication for a specific application hosted inside the Web Site in IIS, while keeping client certificate authentication disabled at the Web Site level. This configuration is useful when you want to secure only a particular application with client certificates, without affecting the entire site.

Understanding the Scenario

Imagine you have a Web Site in IIS that hosts multiple applications. You want to enable client certificate authentication for one specific application, but not for the entire Web Site. This setup ensures that only the designated application requires client certificates for access, while the rest of the site remains accessible without this additional layer of security.

Step-by-Step Configuration

Install IIS Client Certificate Mapping Authentication:

Open Server Manager.
Click on Manage and then Add Roles and Features.
In the Add Roles and Features Wizard, click Next until you reach the Server Roles page.
Expand Web Server (IIS), then Web Server, then Security.
Select IIS Client Certificate Mapping Authentication and click Next.
Complete the wizard and click Install

Configure SSL Settings at the Application Level:

Launch IIS Manager and navigate to your Default Web Site.
Select the specific application for which you want to enable client certificate authentication.
In the Features View, double-click on SSL Settings.
Check Require SSL and Require under Client Certificates

Disable Client Certificate Authentication at the Web Site Level:

In IIS Manager, select the Default Web Site.
Go to SSL Settings.
Ensure that Require SSL and Client Certificates are not checked

Configure Client Certificate Mapping Authentication:

Select the specific application in IIS Manager.
In the Features View, select Configuration Editor under the Management section.
Navigate to system.webServer/security/authentication/iisClientCertificateMappingAuthentication.
Set the enabled field to true.
Set the oneToOneCertificateMappingsEnabled property to true.
Click on Edit Items under the oneToOneMappings property.
Add a new mapping by providing the BLOB of the client certificate

Common Mistakes and Solutions

Configuring at the Sub-Application Level:

A common mistake is configuring client certificate authentication at the sub-application level. This approach does not work as expected and should be avoided. Instead, configure it at the server and site level to ensure proper authentication

Fallback Mechanism Issue:

Ensure that all other authentication methods are disabled for the application that requires client certificate authentication. This prevents fallback mechanisms from allowing access without the correct certificate.

Conclusion

By following these steps, you can successfully enable client certificate authentication for a specific application within the Default Web Site in IIS. This configuration ensures that only the designated application requires client certificates for access, while the rest of the site remains accessible without this additional layer of security. If you encounter any issues or need further assistance, feel free to reach out.

Identifying and Blocking Python-httpx Requests

Goyal_Sandeep — Tue, 02 Sep 2025 16:24:57 GMT

Introduction

In today’s API-driven world, automated scripts—especially those using Python libraries like httpx—can pose a risk if left unchecked. While many of these scripts are legitimate, some are used for scraping, brute-force attacks, or unauthorised data access. This blog explores how to detect and block such requests using IIS features like the URL Rewrite Module and Request Filtering.

Identifying Python-httpx Requests

The first step is detection. We identified Python scripts accessing APIs by analysing IIS logs, particularly the User-Agent field. Suspicious entries like "Python httpx" indicated automated access attempts.

Blocking with URL Rewrite Module

The URL Rewrite Module in IIS allows you to create inbound rules based on request headers. Here's how to block requests from httpx:

Open IIS Manager and navigate to your site.
Open the URL Rewrite module.
Add a new Inbound Rule.
Set the condition:

Input: {HTTP_USER_AGENT}
Check if it Matches the Pattern: .*httpx.*

Set the action to Abort Request or return a custom status code like 404.

This method is flexible—you can customise the response code or redirect the request.

Blocking with Request Filtering

As an alternative, Request Filtering offers a simpler but less flexible approach:

Open Request Filtering in IIS.
Go to the HTTP Verbs or Headers tab.
Add a rule to deny requests where the User-Agent contains httpx.

When tested, this method returned a 400 status code, effectively blocking the script.

Testing the Block

Here’s a simple Python script using httpx to test your rules:

Testing Script

Create a new Python file and give it any name (for example, TestPython.py).
Copy and paste the following content into that file.

import httpx

response = httpx.get('http://localhost/test.htm')

print(response.status_code)

Testing Method

Open the Command Prompt.
Navigate to the directory where the test Python script is located.
Run the following command:

python TestPython.py

When accessed ('http://localhost/test.htm') via a browser: 200 OK
When accessed via script: 403, 404, or 400 depending on your configuration

Choosing Between Methods

Feature	URL Rewrite Module	Request Filtering
Custom Status Codes	✅ Yes	❌ No

Conclusion

Blocking automated httpx requests is essential for protecting your APIs from misuse. IIS provides robust tools to help you do this effectively. Whether you prefer the flexibility of URL Rewrite or the simplicity of Request Filtering, both methods can be tailored to your security needs.

Troubleshooting SSL Certificate Issues in Reverse Proxy

Goyal_Sandeep — Tue, 02 Sep 2025 16:24:40 GMT

Introduction

Reverse proxies are essential in modern web architectures, especially for isolating backend services and enforcing security. However, SSL certificate issues can introduce complex challenges, particularly when dealing with HTTPS-only bindings, self-signed certificates, or organisational constraints. This blog shares practical insights from real-world troubleshooting, lab simulations, and customer scenarios.

Reverse Proxy Configuration: HTTP vs HTTPS Bindings

HTTP Binding Setup

In one scenario, I configured a reverse proxy for a backend site using HTTP binding on a custom port (e.g., 82). This setup is straightforward and avoids SSL complications. The reverse proxy helps prevent direct public access to the backend server, enhancing security.

HTTPS Binding Challenges

When the backend site is configured with only HTTPS binding (e.g., port 49494), the reverse proxy must validate the SSL certificate. This introduces challenges, especially with self-signed or privately issued certificates. In such cases, clients may encounter 502.3 - Bad Gateway errors due to failed certificate validation.

Certificate Issues and Solutions

Certificate Warnings

Accessing the reverse proxy site over HTTPS often led to browser warnings due to untrusted certificates. This is common when the backend uses a self-signed certificate or one issued by a private CA.

Solution 1: Root Certificate Installation

Installing the backend server’s root certificate on the reverse proxy server resolved the warning. This approach is secure and recommended for production environments.

Solution 2: Registry Change (Temporary)

For testing or constrained environments, I used a registry key to bypass certificate validation:

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\IIS Extensions\\Application Request Routing\\Parameters]

"SecureConnectionIgnoreFlags"=dword:00003100

⚠️ This is a temporary workaround and should not be used in production due to security risks.

Troubleshooting Tips

Always verify the backend URL directly from the proxy server.
Use freb logs to identify SSL handshake failures.
Monitor for 502.3 errors and correlate with certificate validation logs.

Lab Setup Guide

Prerequisites

Reverse Proxy Server (Windows Server)
Backend Server (Windows Server)
Client Machine (Windows 10/11)

Backend Server

Create a website with HTTP (e.g. port 82) and HTTPS (e.g. port 49494) bindings.
Use self-signed or test certificates for HTTPS.

Reverse Proxy Server

Configure URL rewrite rules for both HTTP and HTTPS.
Test access to backend URLs from the proxy server.
Import root certificates or apply registry changes as needed.

Client Machine

Access the reverse proxy URL and validate connectivity.
Observe browser behaviour and error messages.

Conclusion

SSL certificate issues in reverse proxy setups can be complex but manageable with the right approach. Whether you're dealing with HTTP/HTTPS bindings, self-signed certificates, or organisational constraints, understanding the root cause and applying targeted solutions is key. Collaboration, testing, and documentation are your best allies.

Troubleshooting IIS Admin Service Termination: “Invalid Signature” Error

Goyal_Sandeep — Tue, 02 Sep 2025 16:23:56 GMT

🔍 Overview

If you've encountered the following error in your Windows Event Viewer:

“The IIS Admin Service service terminated with the following service-specific error: Invalid Signature”

you're likely dealing with a cryptographic issue affecting the IIS metabase. This blog post walks you through the root causes, diagnostics, and step-by-step resolutions to restore service functionality.

🧠 What Causes This Error?

This error typically appears as Event ID 7024 and is often triggered by:

Corruption or deletion of the machine key used by IIS.
Improper SSL certificate updates.
Misconfigured permissions on cryptographic folders.

The IIS Admin Service relies on a secure machine key (usually a file starting with c23) stored in:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

If this key is missing or invalid, IIS cannot decrypt its configuration, resulting in the “Invalid Signature” error.

🧪 Diagnostic Steps

Check Event Viewer
Look for Event ID 7024 under System logs.
Verify Machine Key Presence
Navigate to the MachineKeys folder and check for a file starting with c23.
Audit Permissions
Ensure SYSTEM and Administrators have Full Control on the MachineKeys folder.

🛠️ Resolution Steps

✅ Option 1: Restore from Backup

If you have a backup of the c23* file:

Replace the corrupted file.
Restart the IIS Admin Service.

🔄 Option 2: Reinstall IIS 6 Metabase Compatibility

If no backup is available:

Delete the corrupted c23* file.
Open Server Manager → Manage Optional Features.
Uninstall IIS 6 Metabase Compatibility.
Reboot the server.
Reinstall the feature to regenerate the machine key.

🔐 Option 3: Reset Permissions

Ensure the following permissions on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys:

SYSTEM: Full Control
Administrators: Full Control

💡 Pro Tips

Always back up the MachineKeys folder before making changes.
Consider enabling IIS Configuration Backup for future recovery.

Capture .NET Memory Dump on Linux

meenakshiBalekar — Tue, 02 Sep 2025 16:23:35 GMT

Collecting memory dumps is a crucial part of diagnosing and troubleshooting application issues on Linux machines. Microsoft suggests three primary tools for this purpose: dotnet-dump, procdump, and createdump. In this blog post, we will explore these tools, provide the commands needed to use them, and offer a summary to understand their significance better.

1. Methods to Collect Memory Dumps on Linux

dotnet-dump

The dotnet-dump tool is a part of the .NET SDK and can be used to collect and analyze dumps. It allows you to capture a dump file from a running .NET application without needing to install additional debugging tools.

https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dump

procdump

Procdump is a versatile tool provided by Microsoft that captures dumps based on various triggers, such as high CPU usage or unhandled exceptions. Originally built for Windows, it has been ported to Linux, offering similar functionalities.

https://github.com/microsoft/ProcDump-for-Linux

createdump

The createdump utility is specifically designed for .NET Core applications. It creates core dumps that can be used for post-mortem debugging when an application crashes.

https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/aspnetcore/practice-troubleshoot-linux/lab-1-3-capture-core-crash-dumps#configure-createdump-to-run-at-process-termination

2. Command for dotnet-dump

To collect a memory dump using dotnet-dump, you can execute the following command:

./dotnet-dump collect -p <ProcessID>

In case you want to collect dump on crash you can use below :

./dotnet-dump collect -p <ProcessID> -Crashreport

Here, replace with the ID of the process you want to dump.

3. Command for procdump

To capture a dump with procdump, use the command:

sudo procdump -p <PID> -n 3 - s 10

sudo procdump -C <CPU_Usage> -M <Memory_Usage> <PID> -n 3 - s 10

In this example, the tool will create a dump if the CPU usage exceeds a certain threshold over three consecutive 10-second intervals. Adjust the parameters as needed for your specific scenario.

4. Command for createdump

To generate a dump using createdump, the command is:

sudo createdump --full <PID>

Replace with the appropriate process ID.

Summary

Collecting memory dumps is essential for diagnosing application issues on Linux. Microsoft provides three recommended tools: dotnet-dump, procdump, and createdump. Each of these tools offers unique functionalities to help capture detailed information about your applications' state at the time of issues. By utilizing the respective commands for each tool, you can efficiently collect memory dumps and troubleshoot more effectively.

The commands for capturing memory dumps are straightforward:

dotnet-dump: dotnet-dump collect -p

procdump: procdump -p -s 10 -n 3

createdump: createdump --full <PID>

By following these steps, you can ensure that you have the necessary data to analyze and resolve issues efficiently. Memory dump collection is a valuable skill for any Linux system administrator or developer, and mastering these tools will significantly enhance your troubleshooting capabilities.

rss.livelink.threads-in-node

Understanding IIS Website Limits: Connection Timeout, Bandwidth, and Connection Limits

Introduction

1. Connection Time-out (in seconds)

What It Does

When It Becomes Important

Common Issues When Misconfigured

Practical Tuning Guidance

2. Limit Bandwidth Usage (in bytes)

What It Does

When It Is Useful

What Happens When Misconfigured

Practical Tuning Guidance

3. Limit Number of Connections

What It Does

Why You Would Use This

Common Issues When Too Low

Critical Insight (Very Important for Production)

Practical Tuning Guidance

Troubleshooting TIPS

Quick Summary

Let me take you via some Real-World Scenarios: When IIS Website Limits Cause Production Issues

Scenario 1: Intermittent 502 / 504 Errors (Connection Timeout Misalignment)

Situation

What Was Observed

Root Cause

Fix

Key Learning

Scenario 2: Large File Upload Failures (Connection Timeout Too Low)

Situation

What Was Observed

Root Cause

Fix

Key Learning

Scenario 3: HTTP 503 During Traffic Spike (Connection Limit Too Low)

Situation

What Was Observed

Root Cause

Fix

Key Learning

Scenario 4: Site is Slow but No Resource Bottleneck (Bandwidth Limit Enabled)

Situation

What Was Observed

Root Cause

Fix

Key Learning

Scenario 5: Random Disconnects Under Load (Connection Timeout + Queue Wait)

Situation

What Was Observed

Root Cause

Fix

Key Learning

Troubleshooting Patterns to Remember

Some useful Insight

IIS and CVE-2026-49975

UPDATE: IIS no longer serving up one of my websites

This site can’t be reached

IIS on Windows 10 no longer serving my websites

How to Add an Adaptive Card in Microsoft 365 Agent SDK

Step 1: Understanding How Adaptive Cards Work in Agent SDK

Step 2: Use the Adaptive Card Designer

Step 3: The Full Working Agent SDK Code

Complete Agent SDK Bot with Adaptive Card

Step 4: What This Code Does

1. Sends an Adaptive Card when a new user joins or as per your criteria

2. When the user clicks Submit

3. Bot parses and sends a text response

4. Responds with 200 status

Conclusion

Let's Create Our First Microsoft 365 Agent SDK using Python - For Single Tenant

Step 1: Set Up Your Development Environment

Install These Extensions in VS Code

Step 2: Download/Clone the Official Sample

Step 3: Install All Required Packages

Step 4: Add Your M365 Agent Configuration

Step 5: Run the M365 Agent Locally

Step 6: Create a Dev Tunnel

Step 6.1 — Authenticate devtunnel

Step 6.2 — Create the Tunnel

Step 7: Update the M365 Agent Endpoint in Portal