> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/da/config/hosting/hosting-iis.md).

# IIS

Vær vært for PowerShell Universal i IIS ved at konfigurere programpuljen, webstedsbindinger, web.config-indstillinger og Windows-godkendelse for jobs.

## Hosting i IIS

PowerShell Universal understøtter at blive hostet i IIS (Internet Information Services (IIS) for Windows® Server). Bemærk, at der kræves en række værtsforudsætninger og specifikke konfigurationstrin for at køre PowerShell Universal på IIS. Gennemgå hvert afsnit omhyggeligt, da IIS kræver mange specifikke konfigurationsindstillinger for at fungere med moderne .NET Core-programmer som PowerShell Universal.

## Trin 1 : forberedelse af IIS-værten

Følgende komponenter er påkrævede for at hoste PowerShell Universal på IIS.

* [Internet Information Services (IIS) version 10.0](https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/new-features-introduced-in-iis-10-1709)
  * Inklusive: WebSocket-protokol
* [ASP.NET Core Hosting Bundle 10.0](https://dotnet.microsoft.com/en-us/download/dotnet/9.0)

Følgende Windows Server IIS-funktioner skal også være aktiveret på IIS-værten:

| Visningsnavn for funktion | Krav                                      | Installationsscript                       |
| ------------------------- | ----------------------------------------- | ----------------------------------------- |
| WebSocket-protokol        | Påkrævet for at køre PowerShell Universal | `Install-WindowsFeature Web-WebSockets`   |
| Windows-godkendelse       | Påkrævet for at bruge Windows-godkendelse | `Install-WindowsFeature Web-Windows-Auth` |

Sørg først for at aktivere IIS-funktionen på Windows Server, og installér derefter ASP.NET Core-hostingpakken.

**BEMÆRK**: IIS kræver ofte en genstart af værten efter installation af .NET Core Hosting bundle! Det anbefales kraftigt, at De GENSTARTER IIS-værten efter installation af .NET Core Hosting bundle.

Når disse forudsætninger er opfyldt, er De klar til at begynde konfigurationen af PowerShell Universal på IIS.

{% hint style="warning" %}
Aktivering af IIS-funktionen WebDav Publishing vil forårsage problemer med Universal. WebDav Publishing filtrerer HTTP-anmodninger og forhindrer verberne PUT og DELETE som standard. Hvis De har aktiveret WebDav Publishing, skal De sørge for, at det er konfigureret korrekt, så disse verber tillades.
{% endhint %}

## Trin 2 : Download PowerShell Universal

Download den seneste kopi af PowerShell Universal. De skal downloade **ZIP**-arkivversionen af PowerShell Universal. Dette arkiv er specifikt bygget til personer, der ønsker at konfigurere PowerShell Universal til IIS eller andre tredjepartswebservere. Udpak indholdet af ZIP-filen til den tilsigtede placering for webværtsmappen på Deres IIS-vært.

De skal sikre, at PowerShell Universal-programfilerne ikke er blokeret, efter at De har pakket dem ud. De kan fjerne blokeringen af dem med cmdletten `Unblock-File`.

```
Get-ChildItem C:\inetpub\wwwroot -Recurse | Unblock-File
```

{% hint style="warning" %}
Denne placering er meget vigtig og vil blive refereret til i hele dette dokument. Vigtigst af alt skal denne placering være tilgængelig for den identitet, der bruges af IIS-programpuljen.
{% endhint %}

## Trin 3 : konfiguration af IIS-programpuljen

Nu hvor vores vært er klar, og vi har downloadet PowerShell Universal, kan vi begynde at konfigurere IIS.

Det første trin i IIS-konfigurationsprocessen er at oprette en ny programpulje i IIS. Før vi begynder konfigurationen, bør vi sikre, at vi vælger en gyldig identitet til IIS-programpuljen.

### 3.1 : Valg af en programpuljeidentitet

Programpuljeidentiteten er afgørende for PowerShell Universal, da den vil være den "standardbruger", som job og apps (tidligere kendt som dashboards) kører som. Den vil også være den bruger, der udfører læse-/skrivehandlinger i databasen for Universal-automatisering, og den vil blive brugt af IIS til at læse webindholdskataloget og køre programmet.

Det foreslås at bruge "**LocalSystem"** eller en **tjenestekonto** efter Deres valg.

På grund af begrænsninger i IIS har indstillingerne for programpuljeidentiteten **VÆSENTLIGE** konsekvenser for funktionsmåden for "**Run As**"-indstillinger, når Universal-automatisering bruges.

{% hint style="danger" %}
**IIS-begrænsninger med Universal-automatisering**

* **App Service konfigureret som Local System** - Scripts køres som standard som System Account, og en *Run as Accounts **KAN*** angives, når et script køres i Universal-automatisering
* **App Service konfigureret som en tjenestekonto** - Scripts kan **KUN** køres med tjenestekontoen, og en **\*\******Run as Account*** \_\*\*\_KAN IKKE\*\* angives, når scripts køres.
  {% endhint %}

**Krav til tjenestekontoens identitet**

* [ ] Fuld læse-/skriveadgang til den PowerShell Universal-programmappe, vi udpakkede i **Trin 2**
* [ ] Fuld læse-/skriveadgang til PowerShell Universal-databasen : Standard: *C:\ProgramData\Universal Automation*
* [ ] *Log på som et batchjob* rettigheder (f.eks. fra secpol.msc > Lokale politikker > Tildeling af brugerrettigheder

{% hint style="info" %}
Placeringen af standarddatabasen kan tilpasses via filen `appsettings.json` i PowerShell Universal, hvis det ønskes.
{% endhint %}

Når vi har valgt en gyldig identitet, er vi klar til at oprette programpuljen i IIS.

### 3.2 : Oprettelse af den nye IIS-programpulje

Nu hvor vi har valgt en programpuljeidentitet, der har læse-/skriveadgang til mapperne for PowerShell Universal-programmet og databasen, kan vi oprette programpuljen i IIS.

* I IIS Manager skal De vælge indstillingen **Add Application Pool...**
  * **Name:** Brug et vilkårligt navn, som De ønsker, til programpuljen
  * **.NET CLR Version**: No managed code
  * Klik på **OK** for at oprette programpuljen.

### 3.3 : Konfigurer "Advanced Settings" for IIS-programpuljen

Nu hvor programpuljen er oprettet, skal vi konfigurere **Advanced Settings**

* Åbn "**Advanced Settings"** for programpuljen, og anvend følgende konfigurationer:
  * **General / Enable 32-Bit Applications**: False
  * **Process Model / Identity**: Brug den identitet, vi valgte til vores programpulje, i afsnittet "Valg af en programpuljeidentitet" ovenfor.
  * **Process Model / Load User Profile**: True

Når Advanced Settings er anvendt, er vores programpulje klar, og vores næste trin bliver at konfigurere det IIS-websted, der skal bruge denne programpulje.

## Trin 4 : konfiguration af IIS-webstedet

### 4.1 : Klargøring af web.config til vores websted

Nu hvor vi har en gyldig programpulje, skal vi oprette et IIS-websted for at eksponere programmet. Før vi gør det, bør vi gennemgå PowerShell Universal-filen `web.config` for vores websted. I den udpakkede mappe til PowerShell Universal-programmet finder vi en web.config-fil. Denne konfigurationsfil er specifikt udformet til IIS og har en række konfigurationer, vi skal gennemgå, før vi opretter IIS-webstedet.

Vigtigst af alt skal vi opdatere argumentværdien "**processPath**" i denne konfigurationsfil. Denne værdi giver IIS den nøjagtige sti til programmets binære fil, så programmet kan startes korrekt.

* Åbn filen web.config i PowerShell Universal-programmappen
  * Find sektionen **\<aspNetCore** **processPath** i konfigurationsfilen
  * Ændr argumentet processPath fra ".\Universal.Server.exe" til den nøjagtige placering af stien til Universal.Server.exe (se figuren nedenfor for et eksempel)
  * Gem filen for at anvende konfigurationen

```markup
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="C:\Program Files (x86)\Universal\Universal.Server.exe" arguments="" forwardWindowsAuthToken="false" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="InProcess"/>
  </system.webServer>
</configuration>
```

{% hint style="info" %}
Der findes en række yderligere konfigurationer i denne fil. Vi gennemgår dem mere detaljeret i afsnittet "Avanceret konfiguration", men De kan se "**Yderligere web.config-konfigurationer**" på denne side for at få flere oplysninger
{% endhint %}

### 4.2 : Oprettelse af IIS-webstedet til IIS

Nu hvor der er oprettet en programpulje til PowerShell Universal med en gyldig identitet, og vi har konfigureret filen web.config, er vi endelig klar til at oprette IIS-webstedet. Webstedskomponenten i IIS indlæser programartefakterne og eksponerer programmet på det konfigurerede webslutpunkt.

1. I IIS Manager: Klik på "Add Website.."
2. Konfigurer valgmulighederne for det nye websted :
   * **Site Name**: Brug et hvilket som helst navn, De ønsker, f.eks.: `PowerShell Universal.`
   * **Programpulje**: **BRUG IKKE** *DefaultAppPool* - **Vælg** den programpulje, vi oprettede i vores forrige trin.
   * **Physical Path**: Dette skal være den fysiske sti til det PowerShell Universal-indhold, vi udpakkede fra vores downloadede .zip-fil. **BEMÆRK**: AppPool-identiteten skal have adgang til placeringen.
   * **Binding Settings**: Bemærk, til den indledende konfiguration anbefales det at bruge de grundlæggende standardværdier, vi opdaterer disse senere i vores avancerede konfiguration
     * Type http - til den indledende konfiguration
     * IP-adresse: Alle ikke-tildelte
     * Port: 80
     * Host Name: navn på værten

## Trin 5 : start af websted

På dette tidspunkt bør alle de påkrævede konfigurationer være på plads, og det IIS-websted, der er vært for PowerShell Universal, bør være oppe at køre. Med en webbrowser - gå til den konfigurerede placering af webstedet for at validere, at PowerShell Universal er startet. Herfra kan De følge guiden "Kom godt i gang" for at validere den grundlæggende funktionalitet. Når De er sikker på, at programmet fungerer korrekt med en grundlæggende IIS-konfiguration, kan De gå videre til "Avanceret konfiguration" for at sikre og færdiggøre Deres ønskede IIS-konfiguration.

{% hint style="info" %}
Hvis De stadig oplever problemer med den grundlæggende IIS-konfiguration, kan De prøve at kontrollere stien "Logs", der er angivet i web.config, for almindelige problemer. Hvis De stadig oplever problemer, kan De henvende Dem på foraene eller til support for at få hjælp.
{% endhint %}

## Indlejrede IIS-programmer

Det er muligt at indlejre flere PowerShell Universal-instanser under en enkelt programpulje og et enkelt websted, men det kræver noget yderligere konfiguration.

De skal have to mapper til Deres programfiler: én til hvert program. De skal også opsætte to datamapper: én til hvert program.

Når De har opsat og konfigureret Deres mappestruktur, skal De oprette to appsettings.json-filer og opdatere Deres web.config-filer for hvert program.

I filerne appsettings.json skal De angive de korrekte stier til datafilerne for hver instans. De skal også konfigurere den korrekte basis-URL for det indlejrede websted.

```json
{
  "Kestrel": {
    "BasePath": "/psu1"
  },
  "Logging": {
    "Path": "C:\\src\\psu\\data1\\log.txt",
  },
  "Data": {
    "RepositoryPath": "C:\\src\\psu\\data1\\Repository",
    "ConnectionString": "filename=C:\\src\\psu\\data1\\database.db;upgrade=true",
  }
}
```

Dernæst skal De opdatere web.config-filerne for hvert websted, så de bruger den korrekte appsettings.json-fil og bruger OutOfProcess-hosting.

```markup
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\Universal.Server.exe" arguments="--appsettings C:\src\psu\appsettings.psu1.json" forwardWindowsAuthToken="false" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="OutOfProcess" />
  </system.webServer>
</configuration>
<!--ProjectGuid: 588ACF2E-9AE5-4DF1-BC42-BCE16A4C4EDE-->
```

Højreklik nu i IIS Manager på mapperne psu1 og psu2 for at konvertere dem til programmer.

De burde nu kunne få adgang til PowerShell Universal admin console på begge de følgende URL'er.

```
http://localhost/psu1/admin
http://localhost/psu2/admin
```

## Konfiguration til jobs

{% hint style="warning" %}
Forkert konfigurerede indstillinger for programpuljen kan medføre, at jobs ikke kører. Den primære årsag er genbrug af programpuljen eller en fejl ved start af webappen, når serveren startes. Dette er ikke et problem for funktioner som API'er eller Apps (tidligere kendt som Dashboards), men på grund af baggrundsbehandlingen af jobs skal De sikre, at serveren starter webstedet og holder det kørende. De kan [få mere at vide her](https://docs.hangfire.io/en/latest/deployment-to-production/making-aspnet-app-always-running.html#making-asp-net-core-application-always-running-on-iis).
{% endhint %}

Hvis De skal køre planlagte jobs i Deres PowerShell Universal-instans, der er hostet i IIS, skal De sørge for at konfigurere IIS korrekt. Der er flere indstillinger, der skal valideres, når De konfigurerer Deres programpulje.

### Programinitialisering

Installer funktionen Application Initialization i serverrollen Web Server.

### Indstillinger for programpulje

De bør konfigurere følgende indstillinger:

* **General**: .NET CLR version = [No Managed Code](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/advanced?view=aspnetcore-7.0#sub-applications).
* **General**: Start Mode = AlwaysRunning
* **Process Model**: Idle Time-out-indstilling = 0 (deaktiveret)
* **Recycling**: Regular Time Interval = 0.

### Webstedsindstillinger

I det IIS-websted, der hoster Universal, skal De sikre, at Preload er aktiveret.

### Miljøvariabler

Selv om vi forsøger at registrere, at PSU kører i IIS, kan De støde på problemer med, at Negotiate-godkendelseshandleren er aktiveret, når den ikke understøttes i IIS. For at sikre at dette ikke er et problem, kan De deaktivere den helt ved at oprette nedenstående miljøvariabel på Deres IIS-maskine.

```powershell
$Env:PSU_DISABLE_WIN_AUTH = true
```

### Fejlfinding af problemer med IIS og jobs

Hvis De stadig har problemer med IIS og jobs, bør De overveje at slå[ logføring af IIS-genbrug](https://blogs.iis.net/ganekar/iis-7-0-application-pool-recycles-log-a-event-in-windows-event-log) til for at sikre, at IIS holder Deres websted kørende.

Fra og med PowerShell Universal 3.3 kan De (via systemets oppetid på startsiden i admin console) få en god indikation af, hvornår tjenesten sidst blev startet.

Før version 3.3 kan De se serverens oppetid ved at besøge [Hangfire](/powershell-universal/da/udvikling/hangfire.md)-dashboardet og klikke på fanen Servers.

## Godkendelse

PowerShell Universal kan bruge anonym godkendelse og Windows-godkendelse i IIS.

### Windows-godkendelse

Hvis De vil aktivere Windows Authentication, skal De først aktivere den for Deres webserver og derefter for Deres websted. De finder godkendelsesindstillingerne under sektionen Authentication i IIS Manager.

Angiv de samme indstillinger for webstedet.

Når godkendelse er aktiveret i IIS, skal De sikre, at Windows-godkendelse er aktiveret for PowerShell Universal.

Juster først filen `web.config` for at videresende Windows-godkendelsestokenet.

```markup
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\Universal.Server.exe" arguments="" forwardWindowsAuthToken="true" stdoutLogEnabled="true" stdoutLogFile=".\logs\log" hostingModel="OutOfProcess" />
  </system.webServer>
</configuration>
<!--ProjectGuid: 588ACF2E-9AE5-4DF1-BC42-BCE16A4C4EDE-->
```

Aktivér derefter Windows-godkendelse i filen `appsettings.json` for PowerShell Universal.

```javascript
    "Authentication" : {
    "Windows": {
      "Enabled": "true"
    },
  }
```

Genstart Deres programpulje, og nu bør De kunne logge på med Windows-legitimationsoplysninger.

{% hint style="warning" %}
Når De aktiverer Windows-godkendelse, men ikke anonym godkendelse, kan De ikke længere bruge PowerShell Universal AppTokens. De skal aktivere begge godkendelsesmetoder for at understøtte Windows-legitimationsoplysninger samt App Tokens.
{% endhint %}

### Anonym godkendelse

Anonymous Authentication kan aktiveres, så app-tokens og andre anmodninger kan sendes gennem IIS-proxyen. De skal aktivere Anonymous Authentication på både Server- og Web site-niveau. Der er ingen yderligere konfiguration at foretage i PowerShell Universal.

## Yderligere web.config-konfigurationer

Indstillingerne i Universal web.config kan justeres, som De finder det passende. Nedenfor finder De en beskrivelse af hver indstilling.

### ForwardWindowsAuthToken

Denne indstilling bruges til Windows-godkendelse. Hvis De ønsker at bruge Windows-godkendelse med IIS, skal De sørge for at deaktivere anonym godkendelse og aktivere Windows-godkendelse på Deres IIS-websted og derefter sætte denne indstilling til true.

### StdoutLogEnabled og StdoutLogFile

Denne indstilling bruges til fejlfinding af opstartsproblemer med Deres Universal-opsætning. Det anbefales at aktivere den, første gang De konfigurerer IIS-integrationen. De kan deaktivere den, når alt er konfigureret. De skal sikre, at Deres AppPool-identitet har skriveadgang til placeringen for StdOutLogFile.

### HostingModel

Hostingmodellen angiver, hvordan Universal-serveren kører. Når den er angivet til InProcess, kører Universal Server inde fra IIS-agenten. Det giver bedre ydeevne end OutOfProcess-hosting. InProcess-hosting fungerer ikke sammen med StdOutLogEnabled. Det anbefales kun at bruge OutOfProcess-hosting, mens De konfigurerer Universal, og InProcess, når Deres konfigurationstrin er fuldført.

## Opgradering

Ved opgradering skal De sikre, at De ikke kopierer (overskriver) filer oven på Deres eksisterende installation. I stedet skal De (med undtagelse af web.config og \*.json-filer) slette alle de nuværende programfiler og kopiere de nye ind i kataloget. **Hvis De kopierer oven på programfilerne, kan det medføre, at der findes binære filer i installationskataloget, som ikke forventes, og det kan forårsage problemer med PowerShell Universal.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.devolutions.net/powershell-universal/da/config/hosting/hosting-iis.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
