ApplicationPoolIdentity is a built-in virtual account in IIS that runs application pools with minimal privileges. Unlike traditional user accounts, it doesn't appear in the Windows User Manager, making environment variable configuration non-trivial.

The conventional ways to set environment variables (System Properties or setx command) won't work because:

• Virtual accounts don't have user profiles
• System-wide variables affect all processes
• There's no traditional registry hive for these accounts

Method 1: Using applicationHost.config

Edit IIS's configuration file directly:

<applicationPools>
    <add name="MyAppPool">
        <environmentVariables>
            <add name="MY_VAR" value="MyValue" />
        </environmentVariables>
    </add>
</applicationPools>

Method 2: Programmatic Approach via C#

For dynamic configuration:

using (ServerManager serverManager = new ServerManager())
{
    ApplicationPool appPool = serverManager.ApplicationPools["MyAppPool"];
    appPool.ProcessModel.EnvironmentVariables.Add("DB_CONNECTION", "Server=...");
    serverManager.CommitChanges();
}

Method 3: PowerShell Scripting

For automated deployments:

Import-Module WebAdministration
$appPool = Get-Item "IIS:\AppPools\MyAppPool"
$appPool.processModel.environmentVariables.Add("FEATURE_FLAG", "true")
$appPool | Set-Item

• Recycle after changes: Environment variables are read at worker process startup
• Permissions: Ensure the account editing applicationHost.config has sufficient rights
• Variables scope: These settings only affect the specific application pool

To verify variables are properly set:

// In your ASP.NET application:
Response.Write(Environment.GetEnvironmentVariable("MY_VAR"));

Or use Process Explorer to inspect the worker process's environment block.

While virtual accounts are secure, consider creating a dedicated service account if you need:

• Cross-machine environment consistency
• Complex credential requirements
• Integration with legacy systems

Working with IIS ApplicationPoolIdentity accounts presents unique challenges when trying to set process-specific environment variables. Unlike traditional user accounts where you can set environment variables in the user profile, virtual accounts don't have this capability out of the box.

There are three main approaches to consider when setting environment variables for ApplicationPoolIdentity:

1. Machine-wide variables (affects all processes)
2. User-specific variables (not applicable to virtual accounts)
3. Process-specific injection (our target solution)

The most reliable method is to use IIS's built-in configuration tool. Here's the command syntax:

appcmd.exe set config -section:system.applicationHost/applicationPools 
/+"[name='YourAppPoolName'].environmentVariables.[name='VAR_NAME',value='VAR_VALUE']" /commit:apphost

Example for setting a database connection string:

appcmd.exe set config -section:system.applicationHost/applicationPools 
/+"[name='ECommerceAppPool'].environmentVariables.[name='DB_CONNECTION',value='Server=prod-db;Database=ecom;']" /commit:apphost

For developers who prefer a code-based solution, you can use C# to modify the IIS configuration:

using Microsoft.Web.Administration;

void SetAppPoolEnvironmentVariable(string appPoolName, string varName, string varValue)
{
    using (ServerManager serverManager = new ServerManager())
    {
        var appPool = serverManager.ApplicationPools[appPoolName];
        if (appPool != null)
        {
            var envVars = appPool.GetCollection("environmentVariables");
            var envVar = envVars.CreateElement();
            envVar["name"] = varName;
            envVar["value"] = varValue;
            envVars.Add(envVar);
            serverManager.CommitChanges();
        }
    }
}

After setting the variables, verify they're working with this PowerShell command:

Get-Process -IncludeUserName | Where-Object { $_.UserName -like "*ApplicationPoolIdentity*" } | 
Select-Object ProcessName, Id, @{Name="Environment";Expression={$_.GetEnvironmentVariables()}}

• Environment variables are stored in plaintext in applicationHost.config
• Restrict access to this file (typically at %windir%\system32\inetsrv\config)
• Consider using managed identities for Azure-hosted applications instead

While this solution works well for most scenarios, you might want to consider alternatives when:

• Working with containers (use container environment variables instead)
• Deploying to Azure App Services (use application settings)
• Requiring frequent variable changes (consider a configuration service)