# Deployment Configuration

## Dedicated defaults

The deployment controller and host installer use the same isolated defaults:

| Parameter | Default |
| --- | --- |
| `SiteName` | `AspClassicUnifiedFramework` |
| `AppPoolName` | `AspClassicUnifiedFramework` |
| `DeployRoot` | `D:\Deployments\AspClassicUnifiedFramework` |
| `BindingIpAddress` | `100.97.39.23` |
| `BindingPort` | `8085` |
| `HostHeader` | empty |
| `ExpectedBranch` | `master` (controller) |

Every value can be explicitly overridden. Site and pool names, deployment root, and host header containing `Schedulicious` are rejected as an additional safety boundary. The scripts do not enumerate another site as a configuration source and provide no adoption switch.

## Configuration ownership

Repository `public\web.config` is the default template for first deployment. After the package is safely extracted and validated, the host installer initializes:

```text
<DeployRoot>\shared\public.web.config
```

from the staged package's `public\web.config`. If `InitialWebConfigPath` is supplied on that first deployment, the validated host-local file at that path is used instead. The parameter does not replace an existing shared configuration. Configuration is never copied from another IIS site.

Every staged release receives the shared file before promotion. Change the shared file only through normal host configuration/change control and validate its XML. Keep secrets and production database paths out of source control.

## IIS state owned by the pipeline

The pipeline owns only the named dedicated site and app pool. It may:

1. create them, only when both are absent and only after a staged release validates;
2. point the dedicated site at `<DeployRoot>\releases\<release-id>\public`;
3. set `system.webServer/asp enableParentPaths=true` at that site's location;
4. start/recycle the dedicated app pool and start a newly created site.

It does not alter unrelated sites, app pools, bindings, authentication, identities, ACLs, Windows features, or IIS modules. It does not add bindings to an existing site.

When the target already exists, the site and pool must both exist and exactly match the requested app pool, sole HTTP binding, and pipeline-owned release-public path. Any mismatch fails closed.

## Controller parameters

`scripts/deploy-iis-git.ps1` supports:

- `SiteName`, `AppPoolName`, `DeployRoot`, `BindingIpAddress`, `BindingPort`, `HostHeader`: dedicated target identity and binding.
- `InitialWebConfigPath`: optional host-local first-deployment seed.
- `RemoteTarget`, `RemotePort`: OpenSSH transport.
- `SourcePath`: standalone checkout to validate/package.
- `ExpectedBranch`: remains `master` by default.
- `ReleaseId`: optional immutable release identifier.
- `BaseUrl`: explicit host-side smoke-test URL.
- `KeepReleases`: reporting threshold only; no deletion.
- `LocalPreflightOnly`: local source/XML/package/safety validation; no network.
- `PreflightOnly` (`HostPreflightOnly` and `RemotePreflightOnly` aliases): run local/package checks, then stream the installer over SSH for host validation without writing remote files or changing IIS/deployment state.
- `DryRun`: local package validation plus remote command preview; no network.
- `AllowAnyBranch`, `AllowDirty`: reviewed provenance exceptions.
- `RunMigrations`: explicit database migration opt-in.
- `SkipSmokeTest`: explicit smoke-test exception.
- `Rollback` and `RollbackTo`: switch the dedicated target to a validated prior release.

## Host installer parameters

`scripts/install-iis-release.ps1` accepts the same target/configuration parameters plus:

- `PackagePath`, `ReleaseId`, `ExpectedSha256`: deployment artifact inputs.
- `PreflightOnly` or `DryRun`: read-only host checks; the target may be absent.
- `RollbackTo`: validated release ID for rollback.

Host preflight requires elevation and verifies WebAdministration, Classic ASP feature and `AspModule`, URL Rewrite, requested binding conflicts (including wildcard overlap), shared-pool conflicts, deployment drive/path accessibility, names, and exact existing-target state. It makes no IIS or deployment-root changes.

## Failure scope

If creation or smoke testing fails, the installer removes only a site or app pool whose creation flags were set by that invocation. For an existing valid target, it restores the captured physical path and parent-path value. Unrelated IIS resources are never cleanup candidates.

Package staging/release files can remain as diagnostic evidence. Database migrations and external writes are outside IIS rollback.

## Secrets, identity, and writable data

Use OpenSSH configuration, an SSH agent, or a CI secret store. Do not commit passwords, private keys, production connection strings, or database files. Put production databases and logs outside release directories. App-pool identity and filesystem ACL provisioning are explicit host-administration tasks, not inferred from another site.