biztalk-iis-environment-inventory/Dokumentation.md

Technische Dokumentation

1. Ziel und Abgrenzung

Das Tool dokumentiert den für den Frankfurt-Aufbau relevanten IIS-/BizTalk-Bestand auf den BEW-Systemen ACC und PROD. Es ersetzt eine fehleranfällige manuelle Aufnahme und benötigt trotz eingeschränkter PowerShell-Umgebung keine PowerShell-Ausführung.

Die Anwendung ist:

• lokal und read-only
• auf .NET Framework 4.7.2 ausgelegt
• ohne BizTalk-ExplorerOM-/OperationsOM-Buildabhängigkeit
• ohne Microsoft.Web.Administration-Deploymentabhängigkeit
• fehlertolerant je Datenquelle
• für Gitea-Build und Artefaktbereitstellung strukturiert

Die Anwendung ist kein Backup-Werkzeug. Sie dokumentiert, was für einen kontrollierten Transfer vorhanden sein muss. Webinhalte, Zertifikate, private Schlüssel und IIS-Konfigurationsschlüssel müssen über freigegebene Backup-/Exportprozesse übertragen werden.

2. Architektur

Administrative cmd.exe auf ACC oder PROD
  |
  +-- run-inventory.cmd
        |
        +-- BizTalkIisEnvironmentInventory.exe
              |
              +-- SystemCollector
              |     +-- Win32_OperatingSystem
              |     +-- Win32_ServerFeature
              |     +-- Registry (.NET Framework)
              |
              +-- IisCollector
              |     +-- applicationHost.config (XML, read-only)
              |     +-- Webverzeichnisse und Dateimetadaten
              |     +-- NTFS-ACL der Web-Stämme
              |
              +-- CertificateCollector
              |     +-- LocalMachine\My
              |     +-- CAPI/CNG-Metadaten und Key-Datei-ACL
              |
              +-- SecurityCollector
              |     +-- Win32_Service
              |     +-- secedit.exe /export
              |
              +-- BizTalkCollector
              |     +-- Registry/Uninstall
              |     +-- Dateiversionen
              |     +-- root\MicrosoftBizTalkServer
              |
              +-- DocxReportWriter
                    +-- Office Open XML (DOCX/ZIP)
                    +-- atomarer Dateiwechsel

Alle Collector-Abschnitte laufen nacheinander, weil sie lokale I/O- und WMI-Ressourcen verwenden und teilweise voneinander abhängen. Zertifikate werden beispielsweise gegen die vorher gelesenen IIS-Bindings markiert. Eine Exception beendet nur den betroffenen Abschnitt. Die übrigen Collectoren laufen weiter.

3. Datenquellen

3.1 Windows und Rollen

Win32_ServerFeature liefert installierte Rollen/Features. Der Report beschränkt die Ausgabe auf IIS-, Web-, HTTP-, WAS-, ASP.NET-, .NET-, MSMQ- und COM+-relevante Einträge. Betriebssystemdaten stammen aus Win32_OperatingSystem.

Auf Client-Windows oder Systemen ohne Win32_ServerFeature wird der Abschnitt als teilweise markiert. Das ist kein falscher leerer Bestand.

3.2 IIS

Standardpfad:

%WINDIR%\System32\inetsrv\config\applicationHost.config

Die XML-Datei wird mit FileShare.ReadWrite | FileShare.Delete geöffnet, damit eine laufende IIS-Verwaltung die Aufnahme nicht unnötig blockiert. Es werden erfasst:

• Section-Deklarationen und globale Belegung
• Protected-Configuration-Provider
• Application Pools und ProcessModel-Identitäten
• Sites, Bindings, SSL-Thumbprints
• Anwendungen und virtuelle Verzeichnisse
• physische Pfade

Der SHA-256-Wert im Report gehört zu einer bereinigten logischen Konfiguration. Vor dem Hashing werden sensible Attribute und verschlüsselte XML-Nutzdaten ersetzt. Er dient dem Vergleich ACC/PROD oder Vorher/Nachher, nicht als Hash der Originaldatei.

3.3 Webinhalte

Jeder physische Web-Stamm wird iterativ begangen. Dadurch entsteht keine tiefe Methodenrekursion. Schutzgrenzen:

Einstellung	Default	Wirkung
MaxFilesPerApplication	10000	Maximale Zahl im Word-Dateimanifest; Gesamtzahl und Gesamtgröße werden weiter gezählt.
MaxContentDepth	30	Maximale Verzeichnistiefe.
IncludeFileHashes	false	SHA-256 nur bei ausdrücklicher Aktivierung.

Reparse Points/Junctions werden nicht verfolgt. Das verhindert Schleifen und ein unbemerktes Verlassen des Web-Stamms. Sie erscheinen als Hinweis. Zugriffsfehler einzelner Dateien oder Verzeichnisse machen das Manifest sichtbar unvollständig, stoppen aber nicht die Site-Aufnahme.

Empfehlung für die erste ACC-/PROD-Aufnahme:

run-inventory.cmd ACC C:\IIS-Doku\ACC
run-inventory.cmd PROD C:\IIS-Doku\PROD

SHA-256 für jede Webdatei erst in einem zweiten Lauf aktivieren, wenn ein genauer Inhaltsvergleich benötigt wird:

BizTalkIisEnvironmentInventory.exe --environment ACC --output C:\IIS-Doku\ACC-Hash --include-file-hashes

3.4 Zertifikate und private Schlüssel

Der Collector öffnet LocalMachine\My read-only. Für jedes Zertifikat werden unter anderem Thumbprint, Gültigkeit, Issuer, Algorithmus, Key Usage und IIS-Nutzung dokumentiert.

Bei privatem Schlüssel werden – soweit die ACL es zulässt – nur folgende Informationen gelesen:

• CAPI-/CNG-Provider
• eindeutiger Containername
• Provider-Exportpolicy
• Pfad der Containerdatei
• NTFS-ACL der Containerdatei

Der Code ruft weder X509Certificate2.Export noch CngKey.Export auf. Es gelangt kein Schlüsselmaterial in Log oder DOCX. Exportierbar = Ja bedeutet lediglich, dass ein separater, autorisierter Export technisch möglich sein sollte.

3.5 Dienstkonten und lokale Sicherheit

Anwendungspoolkonten stammen aus der IIS-Konfiguration. Relevante BizTalk-/IIS-/SSO-/MSMQ-Windows-Dienste werden über Win32_Service gelesen.

Für lokale User Rights und grundlegende Security-/Audit-Policy startet die .NET-Anwendung:

secedit.exe /export /areas USER_RIGHTS SECURITYPOLICY

Das ist ein signiertes Windows-Bordmittel und keine PowerShell-Ausführung. Der Prozess hat einen Timeout von 60 Sekunden. Die temporäre INF-Datei wird nach dem Parsen gelöscht. Scheitert secedit, bleibt der Rest des Reports verwendbar.

3.6 BizTalk

Der Collector benötigt keine BizTalk-Assembly. Er verwendet:

• HKLM\SOFTWARE\Microsoft\BizTalk Server\3.0 in 32-/64-Bit-Registry-View
• Windows-Uninstall-Einträge
• Dateiversionen zentraler BizTalk-Programme und Assemblies
• WMI-Namespace root\MicrosoftBizTalkServer

Geprüfte Klassen:

• MSBTS_GroupSetting
• MSBTS_Host
• MSBTS_HostInstance
• MSBTS_ReceivePort
• MSBTS_ReceiveLocation
• MSBTS_SendPort
• MSBTS_Orchestration
• MSBTS_Server

Je Klasse wird die Instanzzahl dokumentiert. Klassenfehler erscheinen einzeln als Finding und nicht als irreführende Null.

4. Secret-Bereinigung

XML-Attribute mit typischen Fragmenten wie password, secret, token, connectionString, privateKey, validationKey oder decryptionKey werden durch [ENTFERNT] ersetzt. Inhalte von EncryptedData, CipherData und CipherValue werden ebenfalls nicht übernommen.

Zusätzlich gelten:

• Logmeldungen enthalten keine XML-Dumps.
• Registrywerte mit sensitiven Namen werden nicht ausgegeben.
• Alle Berichtswerte werden über einen sicheren XML-Writer in WordprocessingML geschrieben.
• Das DOCX enthält keine Makros, externen Links, Skripte, Fonts oder Tracking-Ressourcen.

Der Report enthält dennoch Infrastrukturinformationen und ACLs und muss entsprechend der internen Schutzklasse gespeichert werden.

5. Berechtigungen

Für eine möglichst vollständige Aufnahme ist eine lokale administrative cmd.exe empfohlen.

Ohne Erhöhung funktionieren häufig:

• IIS-XML-Topologie
• öffentlich lesbare Webinhalte
• Zertifikatsmetadaten
• Registry-Grunddaten

Erhöhte Rechte können erforderlich sein für:

• ACL geschützter Webverzeichnisse
• private Key-Container/ACLs
• secedit /export
• einzelne BizTalk-WMI-Klassen
• Dateien unter geschützten Installationspfaden

Fehlende Rechte werden im Log und DOCX ausgewiesen. Das Tool verändert keine ACL und fordert keine zusätzlichen Rechte an.

6. Resilienz und Betriebsverhalten

• WMI-Timeout je Query, Default 30 Sekunden
• Collector-Isolation durch zentralen Safe-Runner
• iterative Dateibegehung mit Maximalgrenzen
• Reparse-Point-Schutz
• geteiltes Lesen aktiver Konfigurations-/Webdateien
• Fehlerisolation je Datei, Verzeichnis, Zertifikat und WMI-Klasse
• atomare DOCX-Ausgabe über temporäre Datei und Replace/Move
• eindeutige Zeitstempel in Report- und Logdateien
• sichtbarer Fortschritt auf der Konsole
• Exitcode 1 bei verwertbarem Teilreport

Bei sehr großen Webverzeichnissen kann --skip-content-manifest verwendet werden. Bei produktiver Last sollten Datei-Hashes außerhalb der Hauptbetriebszeit berechnet werden.

7. Vergleich ACC und PROD

Empfohlenes Vorgehen:

1. Deployment unverändert nach ACC und PROD kopieren.
2. Auf beiden Systemen als lokaler Administrator ausführen.
3. Prüfen, dass Exitcode 0 erreicht oder jeder Teilfehler begründet ist.
4. DOCX-Berichte sicher auf den Dokumentationsarbeitsplatz übertragen.
5. Vergleichen:
   • acht erwartete Anwendungen vorhanden
   • App-Pool-Modus, 32-Bit und Dienstidentitäten
   • Bindings und Zertifikatsablauf
   • Webpfade, Dateizahlen und Änderungsstände
   • NTFS-/Private-Key-ACLs
   • User Rights der Dienstkonten
   • BizTalk-Produkte, Binärversionen und WMI-Komponenten
6. Abweichungen fachlich als beabsichtigt oder als Migrationslücke klassifizieren.

Die DOCX-Dateien können mit Word-Bordmitteln durchsucht und verglichen werden. Für einen maschinellen Diff kann optional in einer Folgestufe ein JSON-Export ergänzt werden; die aktuelle Übergabe ist bewusst auf die gewünschte Word-Dokumentation beschränkt.

8. Build, Test und Gitea

scripts\build-release.cmd

Das Skript:

1. findet MSBuild über vswhere.exe oder PATH
2. baut Solution und Tests in Release
3. führt den abhängigen Konsolen-Testläufer aus
4. führt den eingebauten --self-test aus

Tests decken ab:

• Optionsnormalisierung
• Secret-Bereinigung
• IIS-XML-/Content-Parsing
• secedit-INF-Parsing
• DOCX-Paketstruktur und XML-Injection-Schutz

Auf Nicht-Windows-Buildsystemen wird zusätzlich ein .NET-10-Testziel für die plattformneutralen Tests (Optionsparser, Secret-Bereinigung und DOCX-Paketvalidierung) angeboten. Die Windows-spezifischen IIS- und secedit-Parsertests werden im normalen net472-Lauf auf dem Windows-Runner ausgeführt.

Die Gitea-Workflowdatei .gitea/workflows/build.yml erwartet einen Windows-Runner mit Visual Studio Build Tools und .NET Framework 4.7.2 Developer Pack.

9. Bekannte Grenzen

• Das Tool exportiert keine Websites, Dateien, Zertifikate oder Keys.
• Windows Feature-Namen kommen lokalisiert aus WMI.
• Effektive delegierte IIS-Konfiguration aus jeder einzelnen web.config wird nicht vollständig aufgelöst; die Dateien stehen im Inhaltsmanifest.
• ACLs werden am Web-Stamm und an Key-Dateien dokumentiert, nicht an jeder Webdatei.
• Gruppenverschachtelungen in Active Directory werden nicht aufgelöst.
• Private Keys in HSM/KSP können keinen Dateipfad besitzen.
• WMI-Komponentenzahlen sind eine Bestandsaufnahme, kein Laufzeitmonitoring.
• Der Report ist eine Momentaufnahme; aktive Deployments können sich während des Laufs ändern.

10. Wiederholbarkeit

Für vergleichbare Ergebnisse auf ACC und PROD:

• dieselbe EXE-/Config-Version verwenden
• denselben Berechtigungskontext verwenden
• Dateihashes auf beiden Systemen gleich aktivieren oder deaktivieren
• Aufnahme nicht während eines Deployments ausführen
• DOCX und Log gemeinsam archivieren
• Datum, Umgebung und Servername im generierten Dateinamen unverändert lassen