6
WEB-Ordner als lokales Laufwerk mappen : IIS 7 mit WEBdav
Hallo Leute,
vielleicht schaffen wir es zusammen, die Ecke "sichere Datenübertragung via ssl" über das Internet für Kunden und gelegentliche interne Zwecke, also relativ flexibel in der Anmeldung und leicht handhabbar und mit Bordmittteln von MS endlich einmal aufzuräumen und zwar in der Weise, dass nicht bei jedem Installationsversuch ein anderes Ergebnis herauskommt ?
Sicher benutze ich für den scharfen Einsatz etwa der LAN zu LAN-Kopplung direkt verbundene Firewalls, aber für mobile Zwecke muss es in den Zeiten der Cloudspeicher ja auch anders gehen. Nachdem die FileZilla-Lösung sich bei mehreren Versuchen als Zufallsnummer herausstellte (entweder es funktioniert oder eben nicht) stieß ich vor Jahren bei der Recherche auf die "webdav"-Lösung von MS. Zum Hintergrund: ich verwalte LAN's in drei Standort-Domänen mit zusammen ca. 35 MS-Servern der Reihe 2008 / 2008R2; die Arbeitsmaschinen sowie die Remoteclients sind entweder noch XP prof oder WIN 8 / 8.1. Aufgrund der Lage der Standorte haben wir immer noch ein Bandbreitenproblem, wenn es um die Datenübertragung zwischen den Standorten geht. So hat das gelegentlich zu übertragende Sicherungsfile einer Betriebsdatenbank MSSQL-Server mittlerweile eine Größe von 15 GB.
Zu meinen Feststellungen:
Auf einigen Servern und meinem Notebook unter WIN 8.1 läuft IIS 7.0 und zwar problemlos. Zwei IIS sind scharf, der Rest dient zu Testzwecken, so daß mir genügend Spielwiese diesbezüglich zur Verfügung steht.
Auf IIS 7 ssl zu aktivieren ist kein Problem und völlig unabhängig (!!) von webdav: man baut zusätzlich zur "Default-WEB-Site" eine "SSL-WEB-Site" und wählt beim Anlegen eben den https-Port aus. Der physikalische Pfad kann dabei parallel zu wwwroot angelegt werden z.B. als sslroot. In den "SSL-Einstellungen" erzwingt man ssl und -sehr wichtig, wenn man Dateien sehen will- aktiviert die Servereigenschaft "Verzeichnisse durchsuchen".
Danach hat man das Ergebnis, daß im Browser sich unter https://localhost sich genau diese WEB-Site meldet. Kopiert man eine Datei "iisstart.html" nach sslroot, meldet sich diese Startseite. Kopiert man andere Dateien in dieses Verzeichnis hinein, etwa eine Handvoll PDF's, so erhält man diese Dateien gelistet und kann sie downloaden. Zunächst darf das JEDER.
Wenn die Windows-Authentifizierung installiert wurde (Rollen-Features bei Servern, Windows-Features bei WIN 8, danach booten!) kann im IIS-Manager die anonyme Authentifizierung deaktiviert und die Windows-Authentifizierung unter "Authentifizierung" als Eigenschaft der ssl-Site bzw. als Ordnereigenschaft aktiviert werden. Danach verlangt der Brwoser die Eingabe von Anmelde-Credentials. An dieser Stelle kommen ganz normale NTFS-Rechte zum Einsatz, also die Benutzer bzw. Gruppen des Servers bzw. der Domäne.
nota: Mit irgendwelchen "WEBdav-Erstellungsregeln", die einen Zugriff regeln sollen, hat das an dieser Stelle schon deswegen nichts zu tun, weil ich in diesem Beispiel webdav ja noch gar nicht aktiviert habe und es demzufolge diese Einstellungen noch gar nicht gibt.)
Da man im normalen Browser nur lesen und downloaden, aber nicht schreiben bzw. hochladen kann, greifen natürlich nur Leserechte.
--
So, und jetzt installiert man die Zauberbüchse "webdav" (von der ich bisher keine Stelle gefunden habe, die sagt, was genau dieses Modul eigentlich macht) und hofft natürlich auf den entscheidenden Fortschritt etwa in der Form, dass ein ein WEB-Ordner (etwa https://[ssl-site]/[ordner]) auf dem Server lokal als Laufwerk x: gemappt werden kann, denn nur so ist auf die Dauer sinnvolles Arbeiten auch etwa mit Einsatz von xcopy / robocopy möglich.
Um Port-Schwierigkeiten mit der Firewall zu vermeiden, probiert man das zunächst aus unter https://localhost/[ordner]: man erteilt -da ja nur eine Freigabe gemappt werden kann- dem Ordner "ordner" etwa die Freigabe "sslordner" und versucht dann, den Pfad https://localhost/sslordner unter der Verwendung passender Anmelde-Credentials zu verbinden.
nota: alle bisherigen Versuche, sich über den vorgesehenen Weg "Computer / neue Netzwerkverbinung herstellen / usw." zu verbinden, schlugen mit ein oder zwei Ausnahmen fehl und zwar auch (!!) bei Zielen, die unter Verwendung eines einfachen net use-Befehls der Struktur
net use x: https://webdav.office.1und1.de/ /user:[Emailadresse bei 1und1] [PASSWORT] /persistent:no
mühelos (!!) zu erreichen waren. => Statt sich mit der formulargeführten Einrichterei herumzuärgern, schreibt man sich diesen Befehl in ein CMD-File, macht einen Doppelklick und ist verbunden und das funktioniert auf jedem Rechner, an dem man gerade sitzt; äußerst praktisch. Man hat ein echtes Laufwerk x: mit (fast) allen normalen Möglichkeiten.
Man möchte sich auf diese Weise natürlich auch mit dem eigenen Server bzw. mit dem "freigegebenen WEB-Ordner" verbinden und versucht das nun analog zum funktionierenden 1und1-Beispiel (genauso geht es mit Strato) lokal mit
net use x: https://localhost/sslordner/ /user:[Windows-Benutzer] [PASSWORT] /persistent:no bzw.
net use x: https://localhost/[Freigabe]/ /user:[Windows-Benutzer] [PASSWORT] /persistent:no
...wobei man natürlich auf passende Ordnerechte UND Rechte auf die Freigabe geachtet hat; hier "Jeder hat Vollzugriff".
Meine Frage: was habe ich übersehen, denn es funktioniert nicht: grundsätzlch -egal was ich mache- erhalte ich den "Fehler 67 : Ordner nicht gefunden" ?
--
Nochmal zurück zum Browser-Zugriff: dort funktioniert alles ...und zwar unverändert, wie es VOR der Aktivierung des webdav-Moduls auch war. => was uns zu der Frage bringt, was dieses webdav-Modul eigentlich überhaupt macht ...ausser, daß die Option "WEBdav-Einstellungen" -die aber lediglich eine Art Vorfilter für sichtbare Dateien zu sein scheinen- im IIS-Manager sichtbar sind.
Tatsache ist: bei 1und1-Zielen geht es, genauso bei Strato und anderen. Benutze ich z.B. ein Tool wie Carot (andere Tools scheitern bei ssl-Verwendung an der Problematik wegen des selbstsignierten ssl-Zertifikats) habe ich unter der Carot-Oberfläche Zugriff auf den eigenen Ordner, bloss leider nicht den gewünschten Laufwerksbuchstaben.
Um etwaigen Zertifikatsschwierigkeite aus dem Weg zu gehen, veranstaltet man das Ganze nochmals unter http:
net use x: http://localhost/[Freigabe]/ /user:[Windows-Benutzer] [PASSWORT] /persistent:no
Auch das klappt nicht.
--
Gesamtergebnis: Mappen zu den großen Providern ist erfolgreich mir dem net use-Befehl; Mappen auf die eigenen Server klappt nicht; wohl aber kann das Tool Carot eine webdav-Verbindung zum eigenen Server etablieren.
Sicherlich ist https://webdav.office.1und1.de/ kein speziell für mich freigegebender Ordner, so daß 1und1 aufgrund der Anmeldung da irgendwas hinterher schiebt. Aber es muß doch möglich sein, unter IIS mit diesem webdav einen "WEB-Ordner" so freizugeben, daß man sich anschließend damit verbinden kann.
Was mache ich falsch, was habe ich übersehen ?
Mein Gott Walter ...
PS: meine Freunde dürfen mich gerne auch "Walter" nennen ! .-)
vielleicht schaffen wir es zusammen, die Ecke "sichere Datenübertragung via ssl" über das Internet für Kunden und gelegentliche interne Zwecke, also relativ flexibel in der Anmeldung und leicht handhabbar und mit Bordmittteln von MS endlich einmal aufzuräumen und zwar in der Weise, dass nicht bei jedem Installationsversuch ein anderes Ergebnis herauskommt ?
Sicher benutze ich für den scharfen Einsatz etwa der LAN zu LAN-Kopplung direkt verbundene Firewalls, aber für mobile Zwecke muss es in den Zeiten der Cloudspeicher ja auch anders gehen. Nachdem die FileZilla-Lösung sich bei mehreren Versuchen als Zufallsnummer herausstellte (entweder es funktioniert oder eben nicht) stieß ich vor Jahren bei der Recherche auf die "webdav"-Lösung von MS. Zum Hintergrund: ich verwalte LAN's in drei Standort-Domänen mit zusammen ca. 35 MS-Servern der Reihe 2008 / 2008R2; die Arbeitsmaschinen sowie die Remoteclients sind entweder noch XP prof oder WIN 8 / 8.1. Aufgrund der Lage der Standorte haben wir immer noch ein Bandbreitenproblem, wenn es um die Datenübertragung zwischen den Standorten geht. So hat das gelegentlich zu übertragende Sicherungsfile einer Betriebsdatenbank MSSQL-Server mittlerweile eine Größe von 15 GB.
Zu meinen Feststellungen:
Auf einigen Servern und meinem Notebook unter WIN 8.1 läuft IIS 7.0 und zwar problemlos. Zwei IIS sind scharf, der Rest dient zu Testzwecken, so daß mir genügend Spielwiese diesbezüglich zur Verfügung steht.
Auf IIS 7 ssl zu aktivieren ist kein Problem und völlig unabhängig (!!) von webdav: man baut zusätzlich zur "Default-WEB-Site" eine "SSL-WEB-Site" und wählt beim Anlegen eben den https-Port aus. Der physikalische Pfad kann dabei parallel zu wwwroot angelegt werden z.B. als sslroot. In den "SSL-Einstellungen" erzwingt man ssl und -sehr wichtig, wenn man Dateien sehen will- aktiviert die Servereigenschaft "Verzeichnisse durchsuchen".
Danach hat man das Ergebnis, daß im Browser sich unter https://localhost sich genau diese WEB-Site meldet. Kopiert man eine Datei "iisstart.html" nach sslroot, meldet sich diese Startseite. Kopiert man andere Dateien in dieses Verzeichnis hinein, etwa eine Handvoll PDF's, so erhält man diese Dateien gelistet und kann sie downloaden. Zunächst darf das JEDER.
Wenn die Windows-Authentifizierung installiert wurde (Rollen-Features bei Servern, Windows-Features bei WIN 8, danach booten!) kann im IIS-Manager die anonyme Authentifizierung deaktiviert und die Windows-Authentifizierung unter "Authentifizierung" als Eigenschaft der ssl-Site bzw. als Ordnereigenschaft aktiviert werden. Danach verlangt der Brwoser die Eingabe von Anmelde-Credentials. An dieser Stelle kommen ganz normale NTFS-Rechte zum Einsatz, also die Benutzer bzw. Gruppen des Servers bzw. der Domäne.
nota: Mit irgendwelchen "WEBdav-Erstellungsregeln", die einen Zugriff regeln sollen, hat das an dieser Stelle schon deswegen nichts zu tun, weil ich in diesem Beispiel webdav ja noch gar nicht aktiviert habe und es demzufolge diese Einstellungen noch gar nicht gibt.)
Da man im normalen Browser nur lesen und downloaden, aber nicht schreiben bzw. hochladen kann, greifen natürlich nur Leserechte.
--
So, und jetzt installiert man die Zauberbüchse "webdav" (von der ich bisher keine Stelle gefunden habe, die sagt, was genau dieses Modul eigentlich macht) und hofft natürlich auf den entscheidenden Fortschritt etwa in der Form, dass ein ein WEB-Ordner (etwa https://[ssl-site]/[ordner]) auf dem Server lokal als Laufwerk x: gemappt werden kann, denn nur so ist auf die Dauer sinnvolles Arbeiten auch etwa mit Einsatz von xcopy / robocopy möglich.
Um Port-Schwierigkeiten mit der Firewall zu vermeiden, probiert man das zunächst aus unter https://localhost/[ordner]: man erteilt -da ja nur eine Freigabe gemappt werden kann- dem Ordner "ordner" etwa die Freigabe "sslordner" und versucht dann, den Pfad https://localhost/sslordner unter der Verwendung passender Anmelde-Credentials zu verbinden.
nota: alle bisherigen Versuche, sich über den vorgesehenen Weg "Computer / neue Netzwerkverbinung herstellen / usw." zu verbinden, schlugen mit ein oder zwei Ausnahmen fehl und zwar auch (!!) bei Zielen, die unter Verwendung eines einfachen net use-Befehls der Struktur
net use x: https://webdav.office.1und1.de/ /user:[Emailadresse bei 1und1] [PASSWORT] /persistent:no
mühelos (!!) zu erreichen waren. => Statt sich mit der formulargeführten Einrichterei herumzuärgern, schreibt man sich diesen Befehl in ein CMD-File, macht einen Doppelklick und ist verbunden und das funktioniert auf jedem Rechner, an dem man gerade sitzt; äußerst praktisch. Man hat ein echtes Laufwerk x: mit (fast) allen normalen Möglichkeiten.
Man möchte sich auf diese Weise natürlich auch mit dem eigenen Server bzw. mit dem "freigegebenen WEB-Ordner" verbinden und versucht das nun analog zum funktionierenden 1und1-Beispiel (genauso geht es mit Strato) lokal mit
net use x: https://localhost/sslordner/ /user:[Windows-Benutzer] [PASSWORT] /persistent:no bzw.
net use x: https://localhost/[Freigabe]/ /user:[Windows-Benutzer] [PASSWORT] /persistent:no
...wobei man natürlich auf passende Ordnerechte UND Rechte auf die Freigabe geachtet hat; hier "Jeder hat Vollzugriff".
Meine Frage: was habe ich übersehen, denn es funktioniert nicht: grundsätzlch -egal was ich mache- erhalte ich den "Fehler 67 : Ordner nicht gefunden" ?
--
Nochmal zurück zum Browser-Zugriff: dort funktioniert alles ...und zwar unverändert, wie es VOR der Aktivierung des webdav-Moduls auch war. => was uns zu der Frage bringt, was dieses webdav-Modul eigentlich überhaupt macht ...ausser, daß die Option "WEBdav-Einstellungen" -die aber lediglich eine Art Vorfilter für sichtbare Dateien zu sein scheinen- im IIS-Manager sichtbar sind.
Tatsache ist: bei 1und1-Zielen geht es, genauso bei Strato und anderen. Benutze ich z.B. ein Tool wie Carot (andere Tools scheitern bei ssl-Verwendung an der Problematik wegen des selbstsignierten ssl-Zertifikats) habe ich unter der Carot-Oberfläche Zugriff auf den eigenen Ordner, bloss leider nicht den gewünschten Laufwerksbuchstaben.
Um etwaigen Zertifikatsschwierigkeite aus dem Weg zu gehen, veranstaltet man das Ganze nochmals unter http:
net use x: http://localhost/[Freigabe]/ /user:[Windows-Benutzer] [PASSWORT] /persistent:no
Auch das klappt nicht.
--
Gesamtergebnis: Mappen zu den großen Providern ist erfolgreich mir dem net use-Befehl; Mappen auf die eigenen Server klappt nicht; wohl aber kann das Tool Carot eine webdav-Verbindung zum eigenen Server etablieren.
Sicherlich ist https://webdav.office.1und1.de/ kein speziell für mich freigegebender Ordner, so daß 1und1 aufgrund der Anmeldung da irgendwas hinterher schiebt. Aber es muß doch möglich sein, unter IIS mit diesem webdav einen "WEB-Ordner" so freizugeben, daß man sich anschließend damit verbinden kann.
Was mache ich falsch, was habe ich übersehen ?
Mein Gott Walter ...
PS: meine Freunde dürfen mich gerne auch "Walter" nennen ! .-)
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 332070
Url: https://administrator.de/contentid/332070
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo P.;
veilen Dank für den Link. Im Prinzip hatte ich dies alles beachtet, habe aber festgestellt, dass ich sowohl unter
http://localhost/ als auch unter
https://localhost/
jeweils einen Ordner "webdav" angelegt hatte. Das Hinzufügen des zweiten Eintrags sorgte wohl dafür, dass es in der Datei applicationHost.config zu einem Doppeleintrag kam, der verhinderte, dass ich für
https://localhost/webdav
die "WEBdav-Einstellungen" überhaupt vornehmen konnte: beim Öffnen des Features erschien eine Fehlermeldung. Löschen des Ordners "webdav" unter https://localhost/ und Anlegen eines neuen Ordners mit anderem Namen löste das Problem. Nachdem ich "jeder darf alles" in den WEBdav-Einstellungen für diesen Ordner angelet hatte funktionierte auch das Mapping mit
net use x: https://localhost:56000/webdavssl/ /user:webdav #User#webdav /persistent:no
unter Verwendung des Users "webdav" auf dem lokalen Rechner. Auf meinem Test-Notebook klappt es also. Konsequenz: die WEBdav-Einstellungen sind also doch wichtig. Ordnerfreigaben hat es nicht gebraucht. Das kann natürlich auf daran liegen, dass es lokale Ordner sind, auf die ich automatisch Rechte habe.
--
Soweit so gut. Natürlich habe ist dasselbe Spiel nun auf einem seit eninger Zeit laufenden Produktionsserver ausprobiert. Unter
net use x: https://localhost/webdav/ /user:[Name] [Passwort] /persistent:no
also LOKAL erhalte ich wieder den Fehler 67 "Ordner nicht gefunden, während ich im Fernzugriff über das Internet mit
net use x: https://[website]/webdav/ /user:[Name] [Passwort] /persistent:no
den Systemfehler 1244 "Benutzer wurde nicht authentifiziert" erhalte. => der Ordner wird also gefunden, nur die Authentifizierung klappt nicht. Mit denselben Credentials bin ich im Browserfenster jedoch erfolgreich.
Bei genauerem Hinsehen stellte ich jedoch fest, daß auch dort die Situation vorlag, daß es sowohl unter der Default-WEB-Site (http) als auch unter der SSL-WEB-Site (https) einen gleichnamigen Unterordner namens webdav (Name könnte auch anders lauten) gibt.
Man kommt auf gleichlautende Namensvergabe natürlich, wenn man versucht, für http und https symetrisch zu administrieren. Aber auch auf dem Server erhalte ich Ärger mit der Datei applicationHost.config wegen Doppeleintrags, was man allerdings nicht sofort bemerkt und vor allem nur asymetrisch bemerkt wird: bei einem der beiden Einträge nämlich gibt es Gemecker, beim anderen nicht.
Kurz und gut: das ist eine blöde Falle, in die man hineintappen kann, wobei man im Grunde alles richtig gemacht hat. Ich werde jetzt auf dem genannten Server das ganze Arrangement enetsprechend umbauen und ich denke, daß es dann funktioniert.
Dennoch Dank für den Hinweis !
Walter
veilen Dank für den Link. Im Prinzip hatte ich dies alles beachtet, habe aber festgestellt, dass ich sowohl unter
http://localhost/ als auch unter
https://localhost/
jeweils einen Ordner "webdav" angelegt hatte. Das Hinzufügen des zweiten Eintrags sorgte wohl dafür, dass es in der Datei applicationHost.config zu einem Doppeleintrag kam, der verhinderte, dass ich für
https://localhost/webdav
die "WEBdav-Einstellungen" überhaupt vornehmen konnte: beim Öffnen des Features erschien eine Fehlermeldung. Löschen des Ordners "webdav" unter https://localhost/ und Anlegen eines neuen Ordners mit anderem Namen löste das Problem. Nachdem ich "jeder darf alles" in den WEBdav-Einstellungen für diesen Ordner angelet hatte funktionierte auch das Mapping mit
net use x: https://localhost:56000/webdavssl/ /user:webdav #User#webdav /persistent:no
unter Verwendung des Users "webdav" auf dem lokalen Rechner. Auf meinem Test-Notebook klappt es also. Konsequenz: die WEBdav-Einstellungen sind also doch wichtig. Ordnerfreigaben hat es nicht gebraucht. Das kann natürlich auf daran liegen, dass es lokale Ordner sind, auf die ich automatisch Rechte habe.
--
Soweit so gut. Natürlich habe ist dasselbe Spiel nun auf einem seit eninger Zeit laufenden Produktionsserver ausprobiert. Unter
net use x: https://localhost/webdav/ /user:[Name] [Passwort] /persistent:no
also LOKAL erhalte ich wieder den Fehler 67 "Ordner nicht gefunden, während ich im Fernzugriff über das Internet mit
net use x: https://[website]/webdav/ /user:[Name] [Passwort] /persistent:no
den Systemfehler 1244 "Benutzer wurde nicht authentifiziert" erhalte. => der Ordner wird also gefunden, nur die Authentifizierung klappt nicht. Mit denselben Credentials bin ich im Browserfenster jedoch erfolgreich.
Bei genauerem Hinsehen stellte ich jedoch fest, daß auch dort die Situation vorlag, daß es sowohl unter der Default-WEB-Site (http) als auch unter der SSL-WEB-Site (https) einen gleichnamigen Unterordner namens webdav (Name könnte auch anders lauten) gibt.
Man kommt auf gleichlautende Namensvergabe natürlich, wenn man versucht, für http und https symetrisch zu administrieren. Aber auch auf dem Server erhalte ich Ärger mit der Datei applicationHost.config wegen Doppeleintrags, was man allerdings nicht sofort bemerkt und vor allem nur asymetrisch bemerkt wird: bei einem der beiden Einträge nämlich gibt es Gemecker, beim anderen nicht.
Kurz und gut: das ist eine blöde Falle, in die man hineintappen kann, wobei man im Grunde alles richtig gemacht hat. Ich werde jetzt auf dem genannten Server das ganze Arrangement enetsprechend umbauen und ich denke, daß es dann funktioniert.
Dennoch Dank für den Hinweis !
Walter
Also alles nur "verkonfiguriert" 
, na dann Haken dran, fertig.
p.
, na dann Haken dran, fertig.p.
Das dachte ich bis eben auch. Bevor ich mich an das Umbauen des Produktionsservers mache, wollte ich das Ganze nochmals üben und habe daher einen frischen Testserver 2008R2 mit einwandfrei laufendem IIS 7.5 (Clean Installation) hergenommen.
Dort gab es nur eine einzige site, nämlich die Default WEB Site unter http und zwar ohne Unterordner. Ich habe mal eben folgenes abgearbeitet:
webdav und Windows-Authentifizierung installieren; booten
webdav für die Default WEB Site aktivieren
Verzeichnisse durchsuchen aktivieren
WEBdav-Erstellungsregeln "jeder darf alles"
Authentifizierungsregeln : gecheckt
Windows-Authentifizierung für die Default WEB Site aktiviert; die anomyme Anmeldung deaktiviert
IIS neu gestartet.
So dachte ich, es wäre es ein Leichtes, sich mit
net use x: http://localhost user:Administrator [Passwort]
zu verbinden. Pustekuchen: "Fehler 67 Netzwerkordner nicht gefunden"
Im Browser ist aber alles ok, auch die Anmeldung klappt.
-- Einschub --
Der Versuch, von außen unter http://[IP-Adresse] zu verbinden fordert korrekt die Anmeldecrdentials ab, um dann anschließend (!!) zu behaupten, der Ordner wäre nicht vorhanden.
Gut; denke ich mir lege ich unterhalb von Default WEB Site einen Ordner docs an und verpasse diesem Ordner WEBdav-Einstellungen und versuche dann, mit
net use x: http://localhost/docs/ user:Administrator [Passwort]
zu verbinden. Und jetzt denke ich mich laust der Affe: weder für den Ordner docs noch für die Default WEB Site kann ich die WEBdav-Einstellungen aufrufen !! Ich erhalte wieder die Fehlermeldung wegen doppeltem Eintrag in die applicationHost.config ...und diesmal war garantiert nichts doppelt angelegt; wie auch in einem Pfad !! Es war ja ein ultraeinfaches System:
Default WEB Site
Default WEB Site/aspnet_client (automatisch angelegt bei der php-Installation)
Default WEB Site/docs (wieder gelöscht)
Lösung des Problems: Ich hatte -um ganz sicher zu gehen- sowohl der Default WEB Site als auch dem Server selbst WEBdav-Einstellungen verpaßt. Kaum hatte ich die WEBdav-Einstellungen auf Serverebene wieder gelöscht, was Gott sei Dank ging, konnte ich mich von außen mit
net use x: http://[IP-Adresse] mit der Default WEB Site verbinden. Nur noch diese Ebene hatte WEBdav-Einstellungen.
(nebenbei: mit localhost zu testen funktioniert nicht immer; von aussen ist es sicherer; liegt aber an anderer Baustelle)
Ich hatte nun die Idee der Regel, dass innerhalb eines Zweigs nur PARALLEL, also auf gleicher Ebene WEBdav-Einstellungen vorgenommen werden dürfen. Sie vererben sich nach unten; unterhalb der Vergabeebene dürfen keine weiteren WEBdav-Einstellungen vorgenommen werden.
Ein Test bestätigte die Richtigkeit dieser Überlegung: nach Anlegen entsprechender Unterordner konnte ich mich wahlweise mit
net use x: http[IP-Adresse]/ (mit WEBdav-Einstellungen)
net use x: http[IP-Adresse]/docs/
net use x: http[IP-Adresse]/docs2/
verbinden, ohne zusätzliche WEBdav-Einstellungen zu vergeben oder sonst etwas zu verändern.
Eine Gegenprobe mit
net use x: http[IP-Adresse]/ (OHNE WEBdav-Einstellungen)
net use x: http[IP-Adresse]/docs/ (MIT WEBdav-Einstellungen)
net use x: http[IP-Adresse]/docs2/ (MIT WEBdav-Einstellungen)
zeigte ebenfalls ein stöungsfreies Ergebnis ... mit dem Vorteil, daß es einem böswiligen findigen Besucher nicht mehr gelingt, sich mit net use x: http//[IP-Adresse]/, also der eigentlichen WEB-Site, auf der sich wahrscheinlich ein Internetauftritt befindet, verbinden kann.
Gesamtergebnis:
WEBdav-Einstellungen sind für ein erfolgreiches net use- Mapping notwendig; ebenso "Verzeichnisse durchsuchen".
Sie dürfen jedoch innerhalb einer Struktur (Server, Web-Site, Ordner) in jedem sich ergebenden Zweig nur so vergeben werden, dass sich beim Durchlaufen der Hierarchie von oben nach unten nur genau eine (!) WEBdav-Einstellung findet.
Dem Browser-Betrieb macht das nichts aus; der ist davon unabhängig.
Zudem kann nur empfohlen werden, statt der "Computer / Netzlaufwerk verbinden ..."-Geschichte den net use - Befehl zu nehmen. Erstens geht das schneller und zum zweiten habe ich es wirklich nur im Ausnahmefall erlebt, daß Mappings, die mit net use einwandfrei funktionieren, auch über die Formular-Mimik funktionierten.
Schwere Geburt und so etwas habe ich nirgendwo dokumentiert gefunden. Im Grunde könnten solche Probleme vermieden werden, wenn MS in den IIS-Manager etwas mehr Logikkontrolle eingebaut hätte.
Mein Gott, Walter !!
Dort gab es nur eine einzige site, nämlich die Default WEB Site unter http und zwar ohne Unterordner. Ich habe mal eben folgenes abgearbeitet:
webdav und Windows-Authentifizierung installieren; booten
webdav für die Default WEB Site aktivieren
Verzeichnisse durchsuchen aktivieren
WEBdav-Erstellungsregeln "jeder darf alles"
Authentifizierungsregeln : gecheckt
Windows-Authentifizierung für die Default WEB Site aktiviert; die anomyme Anmeldung deaktiviert
IIS neu gestartet.
So dachte ich, es wäre es ein Leichtes, sich mit
net use x: http://localhost user:Administrator [Passwort]
zu verbinden. Pustekuchen: "Fehler 67 Netzwerkordner nicht gefunden"
Im Browser ist aber alles ok, auch die Anmeldung klappt.
-- Einschub --
Der Versuch, von außen unter http://[IP-Adresse] zu verbinden fordert korrekt die Anmeldecrdentials ab, um dann anschließend (!!) zu behaupten, der Ordner wäre nicht vorhanden.
Gut; denke ich mir lege ich unterhalb von Default WEB Site einen Ordner docs an und verpasse diesem Ordner WEBdav-Einstellungen und versuche dann, mit
net use x: http://localhost/docs/ user:Administrator [Passwort]
zu verbinden. Und jetzt denke ich mich laust der Affe: weder für den Ordner docs noch für die Default WEB Site kann ich die WEBdav-Einstellungen aufrufen !! Ich erhalte wieder die Fehlermeldung wegen doppeltem Eintrag in die applicationHost.config ...und diesmal war garantiert nichts doppelt angelegt; wie auch in einem Pfad !! Es war ja ein ultraeinfaches System:
Default WEB Site
Default WEB Site/aspnet_client (automatisch angelegt bei der php-Installation)
Default WEB Site/docs (wieder gelöscht)
Lösung des Problems: Ich hatte -um ganz sicher zu gehen- sowohl der Default WEB Site als auch dem Server selbst WEBdav-Einstellungen verpaßt. Kaum hatte ich die WEBdav-Einstellungen auf Serverebene wieder gelöscht, was Gott sei Dank ging, konnte ich mich von außen mit
net use x: http://[IP-Adresse] mit der Default WEB Site verbinden. Nur noch diese Ebene hatte WEBdav-Einstellungen.
(nebenbei: mit localhost zu testen funktioniert nicht immer; von aussen ist es sicherer; liegt aber an anderer Baustelle)
Ich hatte nun die Idee der Regel, dass innerhalb eines Zweigs nur PARALLEL, also auf gleicher Ebene WEBdav-Einstellungen vorgenommen werden dürfen. Sie vererben sich nach unten; unterhalb der Vergabeebene dürfen keine weiteren WEBdav-Einstellungen vorgenommen werden.
Ein Test bestätigte die Richtigkeit dieser Überlegung: nach Anlegen entsprechender Unterordner konnte ich mich wahlweise mit
net use x: http[IP-Adresse]/ (mit WEBdav-Einstellungen)
net use x: http[IP-Adresse]/docs/
net use x: http[IP-Adresse]/docs2/
verbinden, ohne zusätzliche WEBdav-Einstellungen zu vergeben oder sonst etwas zu verändern.
Eine Gegenprobe mit
net use x: http[IP-Adresse]/ (OHNE WEBdav-Einstellungen)
net use x: http[IP-Adresse]/docs/ (MIT WEBdav-Einstellungen)
net use x: http[IP-Adresse]/docs2/ (MIT WEBdav-Einstellungen)
zeigte ebenfalls ein stöungsfreies Ergebnis ... mit dem Vorteil, daß es einem böswiligen findigen Besucher nicht mehr gelingt, sich mit net use x: http//[IP-Adresse]/, also der eigentlichen WEB-Site, auf der sich wahrscheinlich ein Internetauftritt befindet, verbinden kann.
Gesamtergebnis:
WEBdav-Einstellungen sind für ein erfolgreiches net use- Mapping notwendig; ebenso "Verzeichnisse durchsuchen".
Sie dürfen jedoch innerhalb einer Struktur (Server, Web-Site, Ordner) in jedem sich ergebenden Zweig nur so vergeben werden, dass sich beim Durchlaufen der Hierarchie von oben nach unten nur genau eine (!) WEBdav-Einstellung findet.
Dem Browser-Betrieb macht das nichts aus; der ist davon unabhängig.
Zudem kann nur empfohlen werden, statt der "Computer / Netzlaufwerk verbinden ..."-Geschichte den net use - Befehl zu nehmen. Erstens geht das schneller und zum zweiten habe ich es wirklich nur im Ausnahmefall erlebt, daß Mappings, die mit net use einwandfrei funktionieren, auch über die Formular-Mimik funktionierten.
Schwere Geburt und so etwas habe ich nirgendwo dokumentiert gefunden. Im Grunde könnten solche Probleme vermieden werden, wenn MS in den IIS-Manager etwas mehr Logikkontrolle eingebaut hätte.
Mein Gott, Walter !!
Steht alles in der Doku wenn man sie denn vorher mal lesen würde . Da sind solche Romane echt überflüssig... Hier brauchte es nämlich nur einen einzigen Versuch 
und et läuft, naja bist halt wieder um eine Erkenntnis reicher minge Walter .
. Da sind solche Romane echt überflüssig... Hier brauchte es nämlich nur einen einzigen Versuch und et läuft, naja bist halt wieder um eine Erkenntnis reicher minge Walter .
.-) Danke für den Hinweis, verehrter P. ! Ganz so trivial ist das Thema für jemanden, der sich da gerade neu einarbeitet, ja nun nicht, denn sonst wären im Netz nicht so viele Anfragen unterwegs.
(Was ist mit "Hier brauchte es nur einen Versuch" gemeint ? )
Ich dokumentiere ganz gerne neu Erarbeitetes etwas ausführlicher und kürze das später zusammen. Je mehr Anfangsfehler man macht, desto sicherer ist man danach.
Nachdem die Verbindungen mit http mittlerweile einwandfrei klappen und via Browser auch die ssl-Site erreichbar ist, müsste eigentlich auch
https://[site] /user:[USER] [PASSWORD] /persistant=no zum Erfolg führen.
https://[site] /persistant=no
müsste zumindest dazu führen, dass Benutzername + PW abgefragt werden.
Das passiert aber (nach Test gegen 2 Server-Systeme 2008 + 2008R2) nicht. Statt der Abfrage der Credentials erhalte ich die Antwort "Fehler 1790 Netzwerkanmeldung nicht möglich", sofern ich die Anfrage gegen einen IIS auf Server 2008 und Server 2008R2 richte.
Lasse ich die Anfrage
net use x: https://localhost:56000/webdavssl/ /persistent:no
=> führt zu x: \\localhost@SSL@56000\webdavssl
jedoch gegen den IIS auf meinem Notebook WIN 8.1 laufen, funktioniert das tadellos !
(mit Carot vom Notebook aus erhalte ich übrigens dasselbe Ergebnis.)
nota: alle Server bzw. Geräte, also auch das Notebook, haben lediglich ein selbstausgestelltes Zertifikat.
Liegt es an den Servern 2008, muß da irgendetwas aktiviert werden ?
Habe einiges gelesen, aber nichts Passendes gefunden. Es wird vor allem nicht klar, ob es möglicherweise doch am Zertifikat liegt, denn niemand sagt, ob das Zertifikat nur beim Browserbetrieb benötigt wird oder generell für eine ssl-Verbindung, also auch auf der net use-Ebene.
Für einen Tipp zu meiner Erleuchtung wäre ich dankbar.
Gruss Walter
--
Apropos Lesen von Doku's: dokumentiert ist ausreichend häufig auch das Verbinden etwa mit dem 1und1-WEB-Speicher über den Computer/Netzlaufwerk verbinden - Klapperatismus. Das hat bei all' meinen Versuchen auf ca. 15 Maschinen -mit identischem Ziel- genau EINMAL funktioniert und danach nie wieder. Mit net use fluppt es von denselben Maschinen wie 'ne 1.
(Was ist mit "Hier brauchte es nur einen Versuch" gemeint ? )
Ich dokumentiere ganz gerne neu Erarbeitetes etwas ausführlicher und kürze das später zusammen. Je mehr Anfangsfehler man macht, desto sicherer ist man danach.
Nachdem die Verbindungen mit http mittlerweile einwandfrei klappen und via Browser auch die ssl-Site erreichbar ist, müsste eigentlich auch
https://[site] /user:[USER] [PASSWORD] /persistant=no zum Erfolg führen.
https://[site] /persistant=no
müsste zumindest dazu führen, dass Benutzername + PW abgefragt werden.
Das passiert aber (nach Test gegen 2 Server-Systeme 2008 + 2008R2) nicht. Statt der Abfrage der Credentials erhalte ich die Antwort "Fehler 1790 Netzwerkanmeldung nicht möglich", sofern ich die Anfrage gegen einen IIS auf Server 2008 und Server 2008R2 richte.
Lasse ich die Anfrage
net use x: https://localhost:56000/webdavssl/ /persistent:no
=> führt zu x: \\localhost@SSL@56000\webdavssl
jedoch gegen den IIS auf meinem Notebook WIN 8.1 laufen, funktioniert das tadellos !
(mit Carot vom Notebook aus erhalte ich übrigens dasselbe Ergebnis.)
nota: alle Server bzw. Geräte, also auch das Notebook, haben lediglich ein selbstausgestelltes Zertifikat.
Liegt es an den Servern 2008, muß da irgendetwas aktiviert werden ?
Habe einiges gelesen, aber nichts Passendes gefunden. Es wird vor allem nicht klar, ob es möglicherweise doch am Zertifikat liegt, denn niemand sagt, ob das Zertifikat nur beim Browserbetrieb benötigt wird oder generell für eine ssl-Verbindung, also auch auf der net use-Ebene.
Für einen Tipp zu meiner Erleuchtung wäre ich dankbar.
Gruss Walter
--
Apropos Lesen von Doku's: dokumentiert ist ausreichend häufig auch das Verbinden etwa mit dem 1und1-WEB-Speicher über den Computer/Netzlaufwerk verbinden - Klapperatismus. Das hat bei all' meinen Versuchen auf ca. 15 Maschinen -mit identischem Ziel- genau EINMAL funktioniert und danach nie wieder. Mit net use fluppt es von denselben Maschinen wie 'ne 1.
