watson007

Hallo Günther, vielen Dank für die Infos. Bin halt nicht sicher, ob es lokal klappt, vielleicht habe ich da einen Denkfehler. Standardwebsite kommt ja mit {ip-address} oder {localhost}, da im IIS ohne Identität und ohne IP-Begrenzung auf Port 80 gemappt, und mit https://{ip-address}:443, da im SSL auf Port 443 gemappt. Geht soweit. ABER: Die Companyweb ist im IIS ja auf die Identität companyweb, mit IP-Begrenzung auf die Serveradresse bei Port 80, und SSL ohne IP-Begrenzung auf Port 444, gemappt. Für mein Dafürhalten müßte daher die Companyweb also auf dem Server bei Eingabe von https://companyweb:444 kommen, tut sie aber nicht. Mit http://companyweb erscheint sie, dies dürfte aber remote nicht funzen, da es ja die IP-Begrenzung gibt. Tja, was tun?

Hallo, vielen Dank für die schnelle Antwort. Ich habe das Workaround durchlaufen lassen, zumindest hat's nicht geschadet ;). Allerdings bin ich wahrscheinlich zu dämlich, ich krieg den remote-Zugriff einfach nicht hin. Aus lokaler Sicht ist es ja eigentlich ganz einfach, die webroot ist http://companyweb und der Remoteplatz ist localhost bzw. Server-IP. Remoteplatz läuft ja so über den Port 80, wenn ich https verwende über den Port 443, auch das funktioniert entsprechend. Nicht funktionieren tut es hingegen schon lokal, wenn ich https://companyweb:444 eingebe, gehe ich richtig in der Annahme, dass es dann freilich remote gleich gar nicht gehen kann?

Hallo xelafield, genau diese Änderungen wären natürlich hochinteressant, ich stehe momentan vor denselbem Problem (Updates erfolgten auch bei mir VOR SBS-Installation und companyweb geht remote nicht: http://www.mcseboard.de/windows-forum-ms-backoffice-31/sbs-firmenwebsite-wiederherstellen-123923.html). Vielleicht hat ja noch jemand ein ähnliches Problem gehabt, den 299 EUR-Anruf bei MS wollt ich mir eigentlich gern sparen :D.

Hallo, heute nun konnte ich -dank Hilfe des Kunden beim einlegen der CD 3- die Sharepoint-companyweb wieder installieren. Auch wenn, wie bereits beschrieben, einige Teile des Workarounds (Beitrag GuetherH) nicht durchführbar waren, hat am Ende erstaunlicherweise alles sehr gut geklappt. Die companyweb ist jetzt -zumindest auf dem Server- wieder aufrufbar und hat auch die vom Kunden gewünschten Standarddienste. Wie ich das jetzt auf der remote-site verfügbar mache, weiß ich zwar noch nicht, aber da muß ich mich einfach mal einlesen. Vielen Dank an GuentherH!

Hallo, ich hatte hier http://www.mcseboard.de/windows-forum-lan-wan-32/sbs-ras-keine-stabile-client-anbindung-moeglich-123862.html schon mal einen Thread gemacht, das Problem besteht leider immer noch und ich weiß ehrlich gesagt auch nicht mehr, wo ich noch suchen kann (es geht um die sich nach einigen Stunden bis Tagen automatisch deaktivierende RAS-Funktionalität). Da die derzeit einzigste "Krücken-Lösung" das täglich einmalige Durchlaufen des Internet-Connection Wizard (Asistent für Internetzugang, VPN und RAS) ist (Neustart oder Dienste-Reset bringt hingegen nichts), suche ich nach einer Automatisierungsmöglichkeit. Im Moment realisiere ich es so, dass ich einen Link auf icw.exe gesetzt habe und manuell die Konfig (ohne Veränderungen:rolleyes:) durchlaufen lasse, inklusiv Neuaktivierung FW. Zwar entsteht bei jedem neuen icw-Durchlauf eine Scriptdatei (\\networking\icw\configxx.vbs), das alleinige Starten dieses VBS schickt den Wizard jedoch ungefragt ins Nirwana (auch VNC geht dann flöten, Server selbst bleibt mit "Scrpit-Error" hängen). Andererseits könnte genau in diesem Script die Lösung des Problems versteckt sein, immerhin muß es ja definitiv einen oder mehrere Scripteinträge geben, die eine "Reparatur" des Problems bewirken. Kennt sich da zufällig jemand damit aus?

Hallo, wie versprochen der Zwischenstand. Ich habe mal das Workaround von MS bis dahin abgearbeitet, bis die companyweb entfernt ist. Die gute Hälfte der Anweisungen konnten so nicht ausgeführt werden, da es die beschriebenen Einträge (teils durch Übersetzungsfehler, teils weil sie einfach nicht da waren) nicht ausgeführt werden. Ein Eintrag im IIS-Anwendungspool ließ sich ferner nicht nach Anweisung löschen, da er Anwendungen enthält. Hoffe, dass es trotzdem für Teil 2, die Neuinstallation, reicht. Hab da jetzt bloß ein "kleines" Problem, die 680 MB der benötigten CD 3 zum Kundenserver zu transportieren. Dort ist am Wochenende niemand da und es kann die CD dort also nicht eingelegt werden, hätte ich vorher dran denken müssen. Außerdem ist Wochenende immer schlecht, falls beim Neustart etwas schief läuft -es kann keiner das Knöpfchen drücken. Bis jetzt funktionieren VPN und RemoteApps noch, hab' ja aber auch noch nicht neu gestartet :p. Es läuft also alles auf Fortsetzung am Montag hinaus, berichte dann weiter ...

Hallo, vielen Dank - das sieht sehr gut aus, werde mich heute nachmittag mal daran machen und dann vom Ergebnis berichten. Beste Grüße, Watson007

Hallo, serverseitig leider nicht. Ich hätte (neben einer täglichen Sicherung der Datenpartition) ein Image (Drive Snapshot) von einem weit zurückliegenden Stand, dort könnte ich ggf. mit dem Image Explorer bestimmte Files zurückholen, müßte halt dann nur wissen, welche ;-). Komplettes Restore vom Image käme praktisch einer Neuinstallation gleich, da sich indes viel geändert hat und das Aufspielen der Images auf Raid-Verbund immer eine recht hakelige Sache ist. Beste Grüße, Watson007

Hallo, ich habe hier einen funktionsfähigen SBS 2003-R2, Kunde möchte allerdings den Urzustand der IIS-Firmenwebsite wiederhergestellt haben (mit Urlaubsplaner usw.). Weiß jemand, wie ich die gesamte Webroot (von Install-CD o.ä.) wiederherstellen kann, möglichst ohne den Rest (AD, Routing/RAS usw.) kaputt zu machen? Danke, Watson007

Hallo, ich will kurz mein Problem beschreiben: SBS eingerichtet, alles soweit standardmäßig, 2 NIC (getrennte IP-Segmente), AD, Benutzer usw. Einwahl des SBS (und dessen LAN-Clients) über den SBS-Router/Firewall. DSL kommt von einem Modemrouter, bei diesem werden GRE, 80, 1723 und 5900 durchgeleitet, gelangen dann zu NIC 1 des SBS (192.168.0.20) und gehen via Firewall an den Server und dessen NIC 2 (192.168.1.1). In der SBS-Firewall habe lasse ich FTP, SMTP, POP3, RDP, https, 1701, 1723, 80, 444, 4125 durchleiten, ferner schicke ich 5900 an localhost (VNC ging irgendwie nicht anders). Im LAN funktioniert alles top, Clients bekommen IP zugewiesen, Ressourcen sind erreichbar, Internetzugang geht, Anwendungen (mit Datenpool auf Server) laufen. Mein Problem ist das RAS, speziell die Einwahl der standortfernen Clients. Es ist eigentlich einfach (mit Assistenten) konfiguriert. RAS-Rechte über Benutzereigenschaften definiert, Adressvergabe an die Clients auch über DHCP, auch der Server zieht sich ins einer Funktion als RAS-Mitglied eine dynamische Adresse aus dem DHCP-Pool. Soweit alles funktional, sowohl die Client-Einwahl über VPN als auch über Remote-Acess (Webarbeitsplatz über https) klappen. Leider aber nicht lange :(. Die Einwahl klappt jedesmal für ein paar Stunden, danach ist ein Ansprechen des Servers aus dem WAN über VPN oder https nicht mehr möglich. Der Server als solches ist aber noch da, ich komme problemlos mit VNC drauf. Was tue ich dann: Ich lasse schlicht und einfach den Internetverbindungs-Assistenten (icw.exe) noch einmal, ohne Änderung irgendwelcher Parameter durchlaufen, und dann geht es wieder für ein paar Stunden bis einen Tag. Wichtig ist dabei, dass explizit die Firewall noch einmal durchkonfiguriert wird (ohne dabei Änderungen durchzuführen, sondern einfach alles durchclicken). Ein Serverneustart, ein Neustart der relevanten Dienste, ein Durchkonfigurieren des VPN-Assis oder ein Rücksetzen des DHCP bringt hingegen nichts. Erstaunlicherweise tritt dieser Effekt auch dann auf, wenn die SBS-Firewall komplett deaktiviert wird! Relevante Ereignisprotokoll-Einträge gibt es nicht. Ich bin ziemlich ratlos, mit einer Suche im Internet bin ich auch nicht wirklich weiter gekommen, in der MS Knowledge Base gleich gar nicht ;-). Lasse jetzt mehrmals am Tag den icw laufen, damit es so aussieht als ob VPN zuverlässig geht :shock:. Eine Besonderheit weißt dieses Netz auf: Die WAN-IP-Adresse (und damit auch die VPN-Adresse) ist dynamisch und wird (über einen im Modemrouter enthaltenen DynDNS-Client) geupdatet. Der Client kennt daher nur eine Adresse in der Art xyz.dyndns.org, dies ist dann folglich auch der hinterlegte Zertifikatsserver. Meine Frage ist daher, ab jemand dieses Problem kennt bzw. eine Idee für die Fehlereingrenzung hat? Kann ein Zusammenhang mit der dynDNS bestehen und welcher? Was kann das bloß für eine Funktion sein, die das "Ausschalten" der Remote-Einwahl nach einiger Zeit bewirkt, ohne dabei die anderen Serverdienste zu beeinflussen (http-Startseite des Servers bleibt weiterhin erreichbar). Es sieht also irgendwie so aus, als ob die Ports für VPN und SSL nach einiger Zeit funktiuonslos bzw. deaktiviert werden, keine Ahnung warum und auf welcher Ebene ich suchen kann. Würde mich sehr über eine Hilfe oder Ideen freuen. Beste Grüße, Watson007