none
Shared Content Ungültiger URI RRS feed

  • Frage

  • Hallo,

    wir hosten auf einer alten 2008er IIS Webserverfarm einige interne Websites. Diese möchten wir nun auf einen Server 2012 R2 mit IIS 8.5 migrieren. Zusätzlich ist geplant die Features Shared Config / Shared Content einzusetzen, da es sind um 3 Server handelt, die über einen Loadbalancer angesteuert werden.

    Wenn ich nun eine bestehende Seite auf den neuen IIS übernehme und Shared Content "aktiviere" (Komplettes Verzeichniss der Seite von inetpub nach UNC Fileshare kopiere), erhalte ich anschließend auf der Webseite und im Eventviewer immer folgende Fehlermeldung und die Seite öffnet sich nicht

           

    Event code: 3005
    Event message: Es ist eine unbehandelte Ausnahme aufgetreten.
    Event time: 14.11.2014 14:14:59
    Event time (UTC): 14.11.2014 13:14:59
    Event ID: b3922a066f844443aaf81f2ad911a36e
    Event sequence: 4
    Event occurrence: 1
    Event detail code: 0

    Application information:
        Application domain: /LM/W3SVC/2/ROOT-28-130604444972145530
        Trust level: Full
        Application Virtual Path: /
        Application Path: \\servername\xxxx$\WebserverFarm\Produktiv\Farm_A\Content\webseite\
        Machine name: xxxxxx

    Process information:
        Process ID: 4620
        Process name: w3wp.exe
        Account name: NT-AUTORITÄT\Netzwerkdienst

    Exception information:
        Exception type: UriFormatException
        Exception message: Ungültiger URI: Autorität/Host konnte nicht analysiert werden.
       bei System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
       bei Gmos.Foundation.CommonResourceController..ctor(String rootLocalPath, String rootRemotePath, Boolean useLocalSource)
       bei Gmos.Foundation.CommonResourceController..ctor(Boolean useLocalSource)
       bei Gmos.Foundation.CommonResourceController..ctor()
       bei Gmos.Foundation.Web.CommonResourceHandler..ctor()
       bei Gmos.ServiceUser.Client.WebGui.SiteMaster.Page_Load(Object sender, EventArgs e)
       bei System.Web.UI.Control.LoadRecursive()
       bei System.Web.UI.Control.LoadRecursive()
       bei System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)



    Request information:
        Request URL: http://xxxx.com/default.aspx
        Request path: /default.aspx
        User host address: 143.180.42.34
        User: xxxxxx
        Is authenticated: True
        Authentication Type: Negotiate
        Thread account name: xxxx\Administrator

    Thread information:
        Thread ID: 21
        Thread account name: xxxx\Administrator
        Is impersonating: False
        Stack trace:    bei System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
       bei Gmos.Foundation.CommonResourceController..ctor(String rootLocalPath, String rootRemotePath, Boolean useLocalSource)
       bei Gmos.Foundation.CommonResourceController..ctor(Boolean useLocalSource)
       bei Gmos.Foundation.CommonResourceController..ctor()
       bei Gmos.Foundation.Web.CommonResourceHandler..ctor()
       bei Gmos.ServiceUser.Client.WebGui.SiteMaster.Page_Load(Object sender, EventArgs e)
       bei System.Web.UI.Control.LoadRecursive()
       bei System.Web.UI.Control.LoadRecursive()
       bei System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

    Ich habe nun schon 2 unterschiedliche Seiten probiert, doch keine der beiden funktioniert. Als Authentifizierung ist Anonym und Windows angegeben (was auch funktioniert, wenn die Seite lokal liegt). Der Folder auf dem UNC Pfad hat mittlerweile Everyone Full Control aktiviert, damit ich Berechtigungsprobleme ausschließen kann. Hat hier vielleicht jemand eine Idee? Viele Grüße

    Freitag, 14. November 2014 14:00

Antworten

  • Hallo Stefan,

    wir sind heute auf den Fehler gestoßen. Auf der Homepage war ein Bild eingebunden, auf das über einen RequestHandler zugegriffen wird. Genau dabei scheint es die mitgegebenen Authentifizierungsdaten einfach zu verwerfen und den Zugriff natürlich zu blockieren....

    Doofer kleiner Fehler, der echt nicht leicht zu finden war, da der IIS keine ordentliche Fehlermeldung zurückgegeben hat und die Programmierer leider auch erst sehr spät daran gedacht haben.

    Aber wenigstens ist das Problem behoben!

    Danke und Gruss

    • Als Antwort markiert Marc Hunziker Montag, 24. November 2014 14:58
    Montag, 24. November 2014 14:58

Alle Antworten

  • Hallo Marc,

    ohne jetzt zu wissen, ob da ggfs. noch andere Sachen nicht funktionieren:

    $ Freigaben sind meines Wissens nach administrative Freigaben und sollten tunlichst nicht für sowas verwendet werden.

    Zudem solltest Du IMHO nicht mit Administratorkonten für die Dienste arbeiten.

    Zur Konfiguration des IIS und des Fileservers schau bitte auch mal hier:

      http://www.iis.net/learn/web-hosting/scenario-build-a-web-farm-with-iis-servers/configuring-step-2-configure-iis-web-farm-servers#21

    Da wird das eigentlich recht gut erklärt.

    Everyone schließt nicht Netzwerkdienst bzw. NETWORK SERVICE ein. Daher bringt es nichts, Everyone Rechte zu geben.

    Falls ihr kein AD einsetzt, solltest Du auf beiden Servern (IIS und Fileserver) einen Benutzer mit gleichem Benutzernamen und gleichem Passwort anlegen, den auf dem IIS in die IIS_IUSRS Gruppe stecken und den Anwendungspool dann mit diesem Benutzer laufen lassen.

    Wenn die Berechtigungen auf die Freigabe dann stimmen, sollte das eigentlich funktionieren.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community


    Freitag, 14. November 2014 15:56
    Moderator
  • Hallo Stefan,

    Das mit der $ Freigabe wird noch geändert. Ist jetzt nur für den Anfang und für die erste Seite zum testen.

    Das Administratorkonto habe ich ebenfalls nur eingetragen, da ich einfach jegliches Rechteproblem ausschließen wollte. Ich habe ein extra dafür angelegtes AD Konto, welches ich (sobald die Seite generell mal läuft) dann eintragen werde.

    Ich habe außerdem am Netzwerkshare nicht nur Everyone eingetragen, sondern auch den Network Service. Hatte aber ebenfalls keine Änderung zur Folge :-(

    Zum Test habe ich bereits eine 2e Seite zum Testen mal auf den neuen Server verschoben. Diese rennt genau in den selben Fehler wie die erste....

    Das Problem ist auch, das es sich bei dem Netzwerkshare um ein eingebundenes Linux System handelt. Ich werde den Share mal auf einen Windows Server verschieben und es dann da nochmal probieren. Ansonsten bin ich langsam mit meinem Wissen am Ende. Die Seite von dir hatte ich nämlich schon rauf und runter gerattert und auch sonst jegliche Seite dazu gelesen... allerdings habe ich eben nicht mehr gefunden und darum wende ich mich ans Forum ;-)

    Ich melde mich nach dem Verschieben des Shares auf einen anderen Server nochmal.

    Gruss, Marc

    Montag, 17. November 2014 07:10
  • Hallo nochmal,

    ich habe jetzt das ganze Verzeichnis auf einen anderen Server (windows Server) verschoben und einen Share dafür eingerichtet.

    Der Application Pool läuft unter dem Network Service. im Windows Share habe ich den Network Service, den Computerhost und Jeder mit Voller berechtigung eingetragen....

    Trotzdem rennt die Seite gegen die Wand... Selbe Fehlermeldung bezüglich

    Exception information:
        Exception type: UriFormatException
        Exception message: Ungültiger URI: Autorität/Host konnte nicht analysiert werden.

    Ich werd noch wahnsinnig :-(

    Dienstag, 18. November 2014 10:25
  • Mittlerweile habe ich den kompletten Server nochmal neu aufgesetzt.

    Neuen IIS erstellt und nur die Notwendigsten Features aktiviert. Dann die Seite erstellt und mal die Seite ins Lokale inetpub kopiert .... Seite geöffnet --> funktioniert einwandfrei.

    Dann die Seite gestoppt und Content aufs Netzlaufwerk. Anschließend Pfad für die Seite und User mit Berechtigung eingetragen --> Seite Starten --> Fehler!  Ungültiger URI..

    Hat sonst jemand noch eine Idee?

    Freitag, 21. November 2014 08:24
  • Hallo Marc,

    das Szenario an sich wird, eben wegen vielfältiger möglicher Probleme, nicht oft verwendet.

    Aber schau dich mal hier um, evtl. findest Du dort den Hinweis, den Du brauchst.

      http://www.chrisdanielson.com/tag/caspol-exe/

      http://terrid.me/configuring-iis-to-use-a-unc-share-as-the-root-of-a-website-or-application/

    Vom letzten Link ist evtl. das hier interessant:

    I then remembered reading about the changes that were implemented with the AppPoolIdentity in IIS7; specifically that the Application Pool identity uses the machine account to access network resources. Even though we were using a domain based user account for the application pool, we decided to add the computer account with read permissions to the share. Voila, we were then able to browse the site successfully from either web node. I can not explain why this was necessary but it resolved the error we were encountering.

    Aber letztendlich ist folgendes eigentlich das, was in so gut wie allen mir bekannten Fällen zum Erfolg geführt hat (von http://serverfault.com/questions/279414/permissions-issue-with-virtual-directory-to-unc-path):

    I resolved our issue by creating matching accounts on both the web server and the unc server. I then modified the Application pool to run using that matching account not network service. This gave me the flexibility to sync the password on both servers without affecting other network service dependent functions.

    Wenn Du das so gemacht hast und die obigen Links nicht helfen, kann ich mir da auch keinen Reim drauf machen.

    Kleiner Nachtrag: Der Inhalt darf natürlich nicht über ein Netzlaufwerk angesprochen werden. Hier wird immer der UNC Pfad benötigt. Zudem solltest Du mal eine neue Freigabe erzeugen und es damit probieren. Die bitte dann aber nicht ...$ benennen, das ist, wie schon erwähnt, schlecht und kann die Ursache sein.

    Der 2012 R2 Server ist kein DC, oder?


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community



    Freitag, 21. November 2014 18:42
    Moderator
  • Hallo Stefan,

    wir sind heute auf den Fehler gestoßen. Auf der Homepage war ein Bild eingebunden, auf das über einen RequestHandler zugegriffen wird. Genau dabei scheint es die mitgegebenen Authentifizierungsdaten einfach zu verwerfen und den Zugriff natürlich zu blockieren....

    Doofer kleiner Fehler, der echt nicht leicht zu finden war, da der IIS keine ordentliche Fehlermeldung zurückgegeben hat und die Programmierer leider auch erst sehr spät daran gedacht haben.

    Aber wenigstens ist das Problem behoben!

    Danke und Gruss

    • Als Antwort markiert Marc Hunziker Montag, 24. November 2014 14:58
    Montag, 24. November 2014 14:58