// Fragen an Claude

Auf die Frage kommt es an

Juni 2026 · im Original-Wortlaut, unbearbeitet

Das Experiment

Ein kleines Experiment: Stellt Claude von sich aus die entscheidende Rückfrage? Ich habe dieselbe Aufgabe — eine Wartungsseite für den IIS — zweimal gestellt, jeweils im frischen Chat: einmal knapp, einmal mit genauer Beschreibung meines Szenarios. Es geht nicht darum, die KI vorzuführen, sondern um einen Befund. (Beide Verläufe stehen unten vollständig — achte auf den Unterschied.)

Ich

Ich brauche eine Wartungsseite, die ich auf einem neuen Windows Server mit IIS hoste, während auf einem anderen Windows Server mit IIS eine Web-App läuft. Gib mir alles, was ich brauche.

Claude (Browser-Chat)

Hier ist ein komplettes Paket für deine Wartungsseite. Es besteht aus einer responsiven, professionellen HTML-Seite, einer web.config-Datei (damit der IIS die Seite direkt richtig ausliefert) und einer Schritt-für-Schritt-Anleitung.

1. Die Wartungsseite (HTML & CSS)

Das CSS ist direkt in der HTML-Datei eingebunden, damit du nur eine einzige Datei verwalten musst. Erstelle eine Datei namens index.html:

<!DOCTYPE html>
<html lang="de">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Wartungsarbeiten</title>
    <style>
        body { text-align: center; padding: 50px 20px; font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; background-color: #f4f7f6; color: #333; }
        h1 { font-size: 40px; margin-bottom: 10px; }
        article { text-align: left; max-width: 600px; margin: 0 auto; background: #ffffff; padding: 40px; border-radius: 10px; box-shadow: 0 4px 15px rgba(0,0,0,0.05); }
        .icon { font-size: 50px; margin-bottom: 20px; text-align: center; }
        a { color: #0078D7; text-decoration: none; }
    </style>
</head>
<body>
    <article>
        <div class="icon">🛠️</div>
        <h1>Wir sind gleich wieder da!</h1>
        <p>Entschuldige die Unannehmlichkeiten. Wir führen derzeit wichtige Wartungsarbeiten durch, um das System für dich zu verbessern.</p>
        <p>Bei dringenden Fragen erreichst du unseren <a href="mailto:support@deinedomain.de">Support</a>.</p>
        <p class="signature">&mdash; Dein IT-Team</p>
    </article>
</body>
</html>

2. Die IIS-Konfiguration (web.config)

Damit der IIS die index.html sofort als Startseite erkennt, erstellst du im selben Ordner eine web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <defaultDocument>
            <files>
                <clear />
                <add value="index.html" />
            </files>
        </defaultDocument>
        <httpProtocol>
            <customHeaders>
                <add name="Retry-After" value="3600" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

3. Einrichtung auf dem neuen IIS-Server

  1. Ordner erstellen, z. B. C:\inetpub\wwwroot\Wartungsseite.
  2. index.html und web.config hineinkopieren.
  3. IIS-Manager öffnen (Windows-Taste + R, inetmgr).
  4. Rechtsklick auf „Sites" → „Website hinzufügen…"; physischer Pfad = der Ordner; Hostname = der Domainname.
  5. Mit OK starten — die Seite läuft.

4. Traffic umleiten (Der Switch)

Option A — DNS ändern (sauber für längere Wartungen): A-Record der Domain auf die IP des neuen Servers umstellen. Wegen DNS-TTL dauert das; TTL vorher niedrig setzen (z. B. 300 Sekunden).

Option B — HTTP-Umleitung im IIS des alten Servers (schnell): solange die alte App noch erreichbar ist, dort temporär eine HTTP-Umleitung auf den neuen Server einrichten.

Meine Anmerkung

Sieht vollständig aus — und reicht für den einfachen Fall. Aber diese Lösung liefert die Wartungsseite nur unter der Standard-URL aus. Ruft jemand eine Unterseite auf oder drückt F5 auf einem tieferen Pfad, kommt ein 404. Genau dieser Punkt fehlt — und Claude weist von sich aus nicht darauf hin. Bei einem Menschen würde ich Unfehlbarkeit nicht voraussetzen; einer Maschine unterstelle ich sie zu leicht.

Ich (neuer Chat)

In einem Projekt haben wir mehrere Web-Applikationen im IIS, die zu einem Zeitpunkt für eine Wartung abgeschaltet werden. Per Load Balancer soll auf eine andere IIS-Website auf einem anderen Server umgeschaltet werden. Die Mitarbeiter sollen dann nur die Wartungsseite sehen. Schreibe mir alles, was ich für diese Wartungsseite auf dem neuen IIS brauche.

Claude (Browser-Chat)

Das ist ein klassisches Setup für geplante Wartungsarbeiten. Damit die Umleitung über den Load Balancer reibungslos läuft und niemand Fehlermeldungen (404 oder Zertifikatswarnungen) erhält, bereitest du auf dem neuen IIS einiges vor.

1. SSL/TLS-Zertifikate (sehr wichtig!)

  • SSL-Offloading am Load Balancer: Hält der Load Balancer die Zertifikate und reicht HTTP an den IIS weiter, brauchst du auf dem IIS keine.
  • SSL-Passthrough: Reicht er HTTPS nur durch, brauchst du im IIS ein Wildcard- (*.euredomain.de) oder SAN-Zertifikat mit allen Hostnamen (Binding: https, Port 443, Hostname leer bzw. per SNI).

2. IIS-Modul

Du brauchst ein Modul, um jede beliebige Anfrage (z. B. domain.de/app1/login.aspx) abzufangen und auf die Wartungsseite umzuschreiben: das IIS URL Rewrite Module (nicht standardmäßig installiert).

3. Website-Einrichtung

  1. Neue Website anlegen (z. B. MaintenanceSite), leeres Verzeichnis (z. B. C:\inetpub\maintenance).
  2. Bindings: HTTP (80) und ggf. HTTPS (443). Hostnamen leer lassen, damit die Site als „Catch-All" für jeden Traffic vom Load Balancer fungiert.

4. Die web.config (das Herzstück)

Damit nicht jede Anfrage auf einen Unterpfad (z. B. /api/v1/data) einen 404 wirft, schreibst du alles auf die index.html um — und gibst statt 200 OK den Status 503 (Service Unavailable) zurück (Best Practice für SEO und APIs):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="CatchAllForMaintenance" stopProcessing="true">
                    <match url=".*" />
                    <conditions logicalGrouping="MatchAll">
                        <add input="{REQUEST_URI}" pattern="^/index\.html$" negate="true" />
                        <add input="{REQUEST_URI}" pattern="^/assets/.*$" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="/index.html" />
                </rule>
            </rules>
            <outboundRules>
                <rule name="Set 503 Status Code" preCondition="IsHTML">
                    <match serverVariable="RESPONSE_STATUS" pattern=".*" />
                    <action type="Rewrite" value="503" />
                </rule>
                <preConditions>
                    <preCondition name="IsHTML">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
        <httpErrors existingResponse="PassThrough" />
    </system.webServer>
</configuration>

(Für die outboundRules muss im IIS oft „Application Request Routing" aktiv sein, sonst den 503er per Custom Error setzen.)

5. Load-Balancer-Health-Checks

Stelle sicher, dass der Health-Check entweder ein 200 OK auf eine ausgenommene Test-Datei (z. B. health.txt) erwartet — oder den 503 dieser Wartungs-Site als „healthy" akzeptiert.

Meine Anmerkung

Erst die genauere Beschreibung — mehr Kontext, ohne die Lösung vorzugeben — bringt die Antwort, die mein Szenario wirklich braucht: alle Pfade abgedeckt, kein 404. Die Lehre ist nicht „die KI ist schlecht", sondern: Auf die Frage kommt es an. Wie genau weiß ich selbst, was ich will? Und sehe ich die Lücke in einer Antwort, die vollständig aussieht? Den fehlenden, entscheidenden Punkt erkennt man nur mit Erfahrung.