Das Ändern des physischen Pfads in IIS über appcmd ist nicht aktiviert

In IIS 7.5 ist ein Problem aufgetreten, bei dem wir ein einfaches Bereitstellungssystem haben, das Folgendes umfasst:

Erstellen Sie eine Zip-Datei mit neuer Webroot, die aus drei Ordnern besteht:

Api
Site
Manager

Dies wird in einen neuen Ordner entpackt (sagen wir, wir nennen ihn "SITE_REV1") und enthält ein Skript, das Folgendes aufruft (eines für jede Webroot):

C:\Windows\system32\inetsrv\appcmd set vdir "www.site.com/" -physicalPath:"SITE_REV1\Site"

Dies funktioniert normalerweise 9/10 Mal. In einigen Fällen scheint die Webroot korrekt aktualisiert zu sein (wenn ich die Grundeinstellungen in IIS Manager überprüfe, sieht der Pfad korrekt aus), aber die betreffende laufende Site zeigt tatsächlich auf den alten Speicherort. Die einzige Möglichkeit, dies zu beheben, besteht darin, einen IIS-Reset auszuführen. Es reicht nicht aus, den betreffenden Anwendungspool zu recyceln.

Manchmal scheint es sogar notwendig zu sein, einen Neustart durchzuführen, aber ich bin nicht 100% sicher, dass dies korrekt ist (es war nicht immer ich selbst, der das Problem behoben hat).

Ich habe das Skript mit Powershell und dem Webadministrationsmodul neu geschrieben, in der Hoffnung, dass es einen Fehler in appcmd gibt, aber das gleiche Problem tritt auf.

Set-ItemProperty "IIS:\Sites\www.site.com" -Name physicalPath -Value "SITE_REV1\Site"

Hat jemand so etwas erlebt? Hat jemand eine Ahnung, was los ist und was ich versuchen kann, um dieses Problem zu verhindern? Ein IIS-Reset ist für uns keine gute Option, da dies alle Sites auf dem Server jedes Mal betrifft, wenn wir versuchen, Änderungen an einer einzelnen Site bereitzustellen.

BEARBEITEN: Wir haben festgestellt, dass ein Start / Stopp der Site (NICHT des Anwendungspools) in IIS Manager den fehlerhaften physischen Pfad behebt. Wenn ich die Site jedoch mit appcmd stoppe, den physischen Pfad ändere und dann starte, leide ich immer noch darunter die gleichen Probleme. Ich bin leer ...

— Jishi
quelle

Ist es in Zeiten, in denen dies nicht funktioniert, möglich, dass die Anforderungen bereits vom alten App-Pool über überlappende Rotation bearbeitet wurden ? Sie sind sich der Verfügbarkeitsanforderungen Ihrer Site nicht sicher, können jedoch versuchen, überlappende Rotationen zu deaktivieren und einen App Pool Recycle-Befehl in Ihr Bereitstellungsskript aufzunehmen.

— explunit

Nein, alle nachfolgenden Anforderungen werden vom alten Webroot bedient. Selbst ein Anwendungsrecycling lädt die Anwendung vom alten Stamm neu. Ein IIS-Reset ist die einzige Möglichkeit, ihn wiederherzustellen. Es ist, als ob die applicationHost.config aktualisiert wird (da der IIS-Manager den richtigen Pfad anzeigt), aber der IIS-Server selbst funktioniert von der vorherigen Konfiguration ...

— jishi

Ich kann es in applicationHost.config nicht erwähnen, also gehe ich davon aus, dass es die Standardeinstellung "false" ist.

— Jishi

OK, dachte, wenn disallowOverlappingRotation = true ist, wird der alte App-Pool möglicherweise aufgrund eines lang laufenden Threads oder Ähnlichem nicht heruntergefahren. Aus diesem Grund müsste IIS Reset vollständig gelöscht werden. Interessante Frage - werde gespannt sein, welche Antworten auftauchen.

— explunit

Beachten Sie, dass ein App-Pool-Recycling nicht mit Stop / Start identisch ist. Haben Sie diese Methode ausprobiert? Beachten Sie, dass dadurch alle aktuellen Verbindungen unterbrochen werden und die Site nicht verfügbar ist (Fehler 500), bis der App-Pool neu gestartet wird.

— John Homer

Funktioniert das Ändern des physischen Pfads von IIS Manager korrekt und sofort?

Möglicherweise möchten Sie den folgenden Befehl ausprobieren. Anders Syntax, sollte das gleiche Ergebnis haben, aber vielleicht funktioniert es intern etwas anders, was dazu führt, dass IIS die Änderungen aufnimmt (besser):

C:\Windows\System32\inetsrv\appcmd.exe set app "www.site.com/" -[path='/'].physicalPath:"SITE_REV1\Site"

— Marco Miltenburg
quelle

AFAIK Wir hatten nie ein Problem, wenn wir es manuell im IIS-Manager ändern, nur programmgesteuert.

— Jishi

Ein App-Pool-Recycling sollte pro Site-Basis ausreichend sein. Dies sind unabhängige Prozesse. Zu oft fördern Artikel und Prozesse die Verwendung von iisreset. Ist das Stoppen / Starten des App-Pools für die eine Site eine Option? Handelt es sich um eine Einzelserverlösung, und versuchen Sie, Ausfallzeiten für die Site zu minimieren? Es gibt eine Option zum Deaktivieren des Recyclings bei Konfigurationsänderungen. Dann können Sie manuell recyceln. Was ist in der applicationHost.config aufgeführt, wenn das Problem auftritt?

— Steve Schofield
quelle

Ich bin nicht 100% sicher, aber da der IIS-Manager den neuen Pfad auflistet, gehe ich davon aus, dass applicationHost.config auf dem neuesten Stand ist. Wenn der Prozess jedoch recycelt wird, scheinen die neu konfigurierten Werte nicht verwendet zu werden. Da dies nur gelegentlich vorkommt, ist es schwierig, Fehler rechtzeitig zu beheben.

— Jishi