Jump to content

vader.darth

Members
  • Gesamte Inhalte

    32
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von vader.darth

Enthusiast

Enthusiast (6/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Hallo Zusammen, wir betreiben in unserer Firma 3 Exchange-Server, 2 Exchange mit Postfachrolle und 1 Exchanger als reinen OWA. Zuerst mal zur Konfiguration: Standort 1 Exchange1.firma.local OWA.firma.local Standort 2 Exchange2.firma.local OWA wird in unserem Hause sehr selten eingesetzt, es wurde jetzt aber bei einer Umstellung festgestellt, dass dieser nicht mehr funktioniert. Sobald ich bei exchange1.firma.local sowie bei owa.firma.local OWA aufrufe erscheint die formularbasierte Anmeldemaske und nach Eingabe von Benutzername und Kennwort kommt die Fehlermeldung:“ Die Outlook Web App ist nicht verfügbar. Falls das Problem weiterhin besteht, wenden Sie sich an den Helpdesk“ Wiederhole ich den Vorgang bei exchange2.firma.local funktioniert alles einwandfrei. Ich dachte diese Funktion steht standardmäßig bei jedem Exchanger mit Clientrolle zur Verfügung. Wie kann ich das Umstellen dass owa.firma.local wieder diesen Job übernimmt? Führe ich GetOWAVirtualDirectory auf den Servern aus bekomme ich folgende Infos: Owa.firma.local Name Server OwaVersion ---- ------ ---------- owa (Default Web Site) exchange2 Exchange2010 owa (Default Web Site) exchange1 Exchange2010 owa (Default Web Site) owa Exchange2010 exchange2.firma.local Name Server OwaVersion ---- ------ ---------- owa (Default Web Site) exchange2 Exchange2010 owa (Default Web Site) exchange1 Exchange2010 owa (Default Web Site) owa Exchange2010 exchange2.firma.local Name Server OwaVersion ---- ------ ---------- owa (Default Web Site) exchange2 Exchange2010 owa (Default Web Site) exchange1 Exchange2010 owa (Default Web Site) owa Exchange2010 Habt Ihr da bitte eine Tipp für mich was ich hier tun kann? Danke schon mal im Voraus. VG Michl
  2. Hallo Zusammen, ich habe zur Zeit einen kleinen Knoten im Hirn und ich hoffe eine/r von Euch kann mir diesen Knoten lösen ;o) Folgende Problematik: Ich habe 2 Gesamtstrukturen, wobei ich User, Gruppen und Computer der Gesellschaft2 auf Gesellschaft1 migrieren möchte. 1. Gesamtstruktur gesellschaft1.local Exchange 2010 SP2 selbstzertifiziertes SSL-Zertifikat 2. Gesamtstruktur gesellschaft2.local Exchange 2007 SP2 selbstzertifiziertes SSL-Zertifikat Die zwei Gesellschaften sind mit einer Gesamtstrukturvertrauensstellung verbunden, die DNS-Auflösung funktioniert in beide Richtungen und den ersten Test-User konnte ich auch problemlos migrieren. Jetzt war der nächste Gedanke in der Gesellschaft1 unter Exchange 2010 eine Exchange-Gesamtstruktur hinzuzufügen in dem ich den Server aus Gesellschaft 2 angebe um danach die Postfächer einfach in die neue Struktur verschieben zu können. Im Assistenten werde ich aufgefordert einen Anzeigenamen "Gesellschaft2" und den Servernamen "https://exchange.gesellschaft2.local/PowerShell" einzugeben. Darauf bekomme ich die FM:"Das SSL-Zertifikat enthält einen allgemeinen Namen (CN), der nicht mit dem Hostnamen übereinstimmt. Muss ich hier jetzt ein Zertifikat auf den Servernamen erstellen und einbinden? Nachdem der Server auch gleichzeitig OWA-Server ist könnte dies ja zu Problemen unserer Außendienstmitarbeiter führen. Kann ich diese Zertifikatsmeldung irgendwie umgehen oder habe ich einen prinzipiellen Denkfehler? Vielen Dank schon mal im Voraus für Eure Unterstützung. VG Michl
  3. ....werd ich einer der nächsten Nächte nochmal testen. Nochmal Unzustellbarkeitsrückmeldung finden meine Kollegen mit Sicherheit nicht so toll ;o) Danke Dir. VG Michl
  4. Hallo Zusammen, heute bin ich auf ein Problem gestoßen das ich nicht nachvollziehen kann. Wir haben zwei Standorte (über IPSec verbunden), derzeit 2 Domänen die wir über eine Gesamtstrukturvertrauensstellung miteinander verknüpfen möchten um letztendlich durch eine Migration zusammenführen möchten. Beide Domänen besitzen eine eigene Exchangestruktur die bisher völlig unabhängig voneinander arbeiten. Zuerst habe ich in den zwei Domänen eine sekundäre DNS-Zone konfiguriert, Namensauflösung funktioniert problemlos. Danach habe ich die Gesamtstrukturvertrauensstellung bidirektonal eingerichtet. Danach wurden Mails der Domäne 1 als unzustellbar zurückgewiesen. In der Unzustellbarkeitsmail war jedoch der Mail-Server der Domäne 2 und die FM:"Unable to relay" aufgeführt. Im Systemmanager der jeweiligen Exchangeserver wird der "fremde" Exchanger nicht mit aufgeführt. Wie kann es sein, dass er versucht die Mails an diesen Server auszuliefern? In der Firewall-Policy steht der richtige Server zur Zustellung. Lösche ich die sekundären DNS-Zonen und die Gesamtstrukturvertrauensstellung, werden die Mails wieder problemlos zugestellt. Könnt Ihr mir bitte Tipps geben wo ich im Moment meinen Denkfehler habe? Danke schon mal im Voraus. VG Michl
  5. Hallo Zusammen, ich habe eine Frage bzgl. einer Zugriffsregel auf einem ISA-Server 2006. Ein Kunde betreibt einen ISA als Edgefirewall konfiguriert und hat sich jetzt ein Videokonferenzsystem gekauft. Das Konferenzsystem läuft im internen Netz, muss allerdings mit bestimmten Ports auch vom Internet aus zugänglich sein. Ich habe jetzt ein benutzerdefiniertes Protokoll mit allen entsprechenden Ports (TCP 80, 443, 17990 und 17992 - UDP 50000 - 65535 eingehend) angelegt und eine Firewallrichtlinie "Zugriffsregel" von extern bis Server-IP-Adresse angelegt und das benutzerdefinierte Protokolle eingebunden. Die Verbindung vom Video-Server nach extern ist durch die Internet-Firewallrichtlinie gewährleistet. Jetzt besteht allerdings das Problem das jegliche Testverbindung über Port 80 und 17990 durch die Standardregel abgelehnt wird. Lege ich eine "Nicht-Webserver"-Firewallrichtilinie an, so ist der Zugriff über Port 80 problemlos möglich, allerdings kommt eine Fehlermeldung dass der Port 443 bereits auf einem anderen Socket verwendet wird und deswegen die Richtlinie nicht angewendet werden kann. Könnte mir bitte jemand einen Tipp geben wie ich die Sache in den Griff bekommen kann? Vielen Dank schon mal im Voraus. VG
  6. Hallo Zusammen, ich habe unter Exchange 2010 eine DB für die öffentlichen Ordner erstellt. Mit dem Befehl Add-PublicFolderAdministrativePermission -User domaene\username -Identity "\" -AccessRights AllExtendedRights möchte ich dem User die Berechtigung Vollzugriff für alle öffentlichen Ordner erteilen um anschließend einen Import aus einer PST anstoßen zu können. Gehe ich aber im Outlook auf die Öffentlichen Ordner und lasse mir die Berechtigungen anzeigen so hat dieser Benutzer ledliglich Leserechte, Unterordner erstellen. Eingesetzt wird Exchange 2010 Standard. Könntet Ihr mir bitte sagen was ich falsch mache? Danke schon mal im voraus VG Michl
  7. Hallo Zusammen, ich hätte da mal ein kleines Problem was mich am Freitag fast zur Verzweiflung getrieben hätte. Wir haben ein internes Netz geschützt durch eine Astaro-Firewall 192.168.158.0/24, desweiteren eine DMZ 192.168.159.0/24 die ebenfalls durch die Astaro-Firewall bereitgestellt wird. Im internen Netz steht ein Exchange-Server der mit dem ClientAccess-Server (OWA) im DMZ in beiden Richtungen kommunizieren soll. In der Firewall wird als einzig zulässige Kommunikation IPSec erlaubt. Betriebssystem auf allen Rechnern: Server 2008 Std. Exchange Server 2010 Client-Access Server: ebenfalls Exchange 2010 Jetzt ist meine Frage wie muss ich die IP-Sec-Richtlinie konfigurieren damit die Kommunikation zwischen den beiden Servern funktioniert? Bei der Konfiguration ist immer von Tunnelendpunkten die Rede. Ist der Tunnelendpunkt der zweite Server oder wird hier vom Gateway gesprochen? Wie muss ich beide Server konfigurieren damit der Datenverkehr in beide Richtungen problemlos möglich ist? Wäre über jeden Tipp dankbar. VG Michl
  8. Hallo Zusammen, ich suche seit langem einen Fehler den ich nicht nachvollziehen kann. Wir haben eine Draytek Vigor Firewall als Front-Firewall und als Backfirewall einen ISA2006-Server laufen, der den Zugriff ins Internet wie auch eine VPN-Einwahl bereitstellt. Die Ports für die VPN sind in der Draytek-Firewall freigegeben. Die Verbindung vom internen Netz ins Internet funktioniert ohne Probleme, jedoch der Zugriff über VPN aufs interne Netz macht sporadisch Probleme. Die Verbindung zwischen Client und Server steht, der Client hat auch eine IP-Adresse, jedoch können keine Resourcen angesprochen werden. Weder über ping, RPC etc. Der Fehler kann bereits 20 Sek. nach der Einwahl auftreten oder erst nach 4 Std. Zuerst habe ich die Soft-/Hardware im Verdacht gehabt und versuchte über einen Server 2008 die Routing und Ras-Funktion hierfür zu verwenden. Hier tritt der Fehler in gleichem Maße auf. Der Fehler tritt auch auf, wenn z.B. ein Dauerping auf eine Resource stattfindet um Verbindungstrennung zu vermeiden. In keinem der Log-Protokolle habe ich einen passenden Eintrag gefunden. Auf dem ISA habe ich sogar die Überwachung des einzelnen Rechners mitlaufen lassen und das Ergebnis war nur, dass die Verbindung getrennt wurde. Fehler tritt unter Windows7 wie auch unter XP auf und das bei unterschiedlichen Usern. Nachdem der Fehler vor und nach dem Umzug unserer Firma und somit auch nach einem Leitungswechsel exisitiert bin ich leider mit meinem Latein am Ende. Hat jemand Tipps, Tricks, Ideen wo ich hier bei der Fehlersuche ansetzen kann? Müssen nur timeout-Werte erhöht werden? Oder liegt es am am Protokoll? Wir verwendet PPTP. Wäre um jeden Tipp dankbar. VG Michl
  9. Servus, Firewallrichtlinie "VPN ins interne Netz" Von: Quarantäne-CPN-Clients VPN-Clients Nach: Intern Benutzer: Alle Benutzer Und der TMG ist in der Domäne. Was mir hier noch komischerweise auffällt, sobald der TMG auf dem Server installiert wurde können keine Windows-Updates mehr durchgeführt werden....weder über WSUS noch direkt von der MS-Site. Sobald der TMG deinstalliert wird, kann der Server auch wieder Updates empfangen. TMG-Version ist im übrigen 7.0.7734.100 VG
  10. So, jetzt bin ich wieder einen Schritt weiter und konnte der Protokollierung doch was herauskitzeln. Zugelassene Verbindung SUSH105 10.05.2010 17:49:06 Protokolltyp: Webproxy (Forward) Status: 403 Verboten Regel: VPN ins interne Netz Quelle: VPN-Clients (192.168.126.6:49538) Ziel: Intern (suha101.domain.net 192.168.118.200:80) Anforderung: OPTIONS http://192.168.118.200/ Filterinformationen: Req ID: 0d287078; Compression: client=No, server=No, compress rate=0% decompress rate=0% Protokoll: http Benutzer: domain\username Verweigerte Verbindung SUSH105 10.05.2010 17:49:07 Protokolltyp: Firewalldienst Status: Die Richtlinienregeln lassen die Benutzeranforderung nicht zu. Regel: Standardregel Quelle: VPN-Clients (192.168.126.6:137) Ziel: Lokaler Host (255.255.255.255:137) Protokoll: NetBios-Namendienst Protokolltyp: Firewalldienst Status: 0x80072743 WSAENETUNREACH Regel: VPN ins interne Netz Quelle: VPN-Clients (192.168.126.6:49545) Ziel: Intern (snas101.domain.net 192.168.118.183:445) Protokoll: Microsoft CIFS (TCP) Benutzer: domain\username Warum wird der Vorgang geblockt? Ich habe doch Standard-Richtlinien dafür kreiert!?!? Muss da noch was in den Systemrichtlinien verändert werden, oder muss ich da noch gesonderte Zugriffsregeln anlegen? VG Michl
  11. ich habe den route print beim alten ISA auch durchgeführt. Sieht komplett identisch aus...bis auf die Tatsache das da noch die IPv6-Konfig mit drin steht. Und die braucht man ja glaube ich für DirectAccess (wenn wir es bei uns implementieren sollten) Ich hätte beinahe gesagt es liegt an den Berechtigungen, aber die Standardregeln sind angelegt und mitprotokollieren kann ich da irgendwie nix. Na dann muss ich da mal weiterdocktern wenn ich wieder ein bisschen Zeit hab. Danke Dir für Deine Unterstützung.
  12. Ehrlich gesagt weiß ich nicht was diese permanente Route darstellt. Der Server ist im Grunde "nackig". Ich musste ihn aufgrund von kurzfristigem Hardwaretausch 2x installieren, Server 2008 und TMG. Beide Male stand ich vor dem selben Problem. Außer dem Webzugriff, den VPN-Einstellungen mittels der vorgegebenen "Assistenten" und (was beim ISA2006 standardmäßig vorhanden war) die Firewallrichtlinie für den VPN-Client-Zugriff. Ist das ein Bug? Eine Security-Einstellung? Habe ich was bei den Systemrichtlinien übersehen was Microsoft beim Versionswechsel berücksichtigt (fälschlicherweise oder nicht) Soweit ich gesehen habe ist der Server auf aktuellsten Stand, Malewareerkennung ist auch ausgeschalten. Die Einstellungen am Client stimmen auch. Wenn ich die IP-Adresse vom alten ISA eintrage kann ich problemlos den Tunnel aufbauen. VG Michl
  13. Ich weiß nicht was diese Route darstellt. Das Ding ist völlig nackig. Ich habe einen Server 2008 aufgesetzt, Netzwerkadapter konfiguriert, den TMG installiert, eine Webzugriffsregel erstellt und das VPN konfiguriert. Und dafür habe ich den Assistenten verwendet. Im Gegensatz zum ISA 2006 musste ich dann noch die VPN-Client-Regel händisch anlegen. Ansonsten ist da noch nichts passiert. Das Ding ist auch noch nicht produktiv. Ich kann aber aufgrund der MS-Seite und der dortigen Doku nicht wirklich einen Fehler feststellen, zumal ich den Server auf unterschiedlicher Hardware 2x installieren musste und auch 2x vor dem gleichen Problem stand. Es muss sich um eine Standardeinstellung oder Sicherheitseinstellung handeln. Oder könnte evtl. an einer Systemrichtlinie liegen? Ich bin zwar die Liste auch schon mind. 5x durchgegangen aber evtl. sieht man ja auch mal den Wald vor lauter Bäumen nicht. VG Michl
  14. Auf dem alten ISA-Server hatte er immer die erste IP-Adresse aus der Range für den Server selbst genommen. Hab das mit Deinem route-Befehl auf dem Client auch mal durchgeführt, jedoch ohne Erfolg.
×
×
  • Neu erstellen...