=BT=Viper

Ich hatte schon mal das Archiv zum Test aktiviert, da hatte es auch funktioniert. Nach dem Test wurde es wieder abgeschalten. Nun sollen es einige User haben. Habe es aktiviert aber es will nicht. Im OWA wird das Archiv angezeigt, aber es wird nichts archiviert. Folgendes wurde eingestellt: 1. Aufbewarungstag: Nach 14 Tagen in Archiv verschieben. 2. Aufbewahrungsrichtlinie erstellt und mit Aufbewahrungstag verknüpft. 3. Compilance Archiv beim User aktiviert und die Achiv Datenbank ausgewählt. Bei Usern mit denen ich die Archivierung schonmal erfolgreich getestet hatte, sehe ich auch das Daten in der DB liegen. Es wird aber nichts neues archiviert, bzw. sehe ich bei diesen Usern die bisherigen Mails nicht.

Ich bin momentan dabei Exchange zu migrieren. Leider kann ich hier nicht alle Postfächer auf einmal machen. Bei einem Test habe ich nun festgestellt das der Exch2003 keine Mails an den 2010 zustellt. Sie hängen in der Warteschlage welche einen SMTP-Protokollfehler meldet. Ich habe den Routinggruppen Connector neu erstellt, was auch nix gebracht hat. Es ist auch kein Smarthost hinterlegt. Postfächer konnten problemlos verschoben werden. (Beide Server sind in der selben Domäne.)

Hi, ich denke wir haben das gleiche Problem http://www.mcseboard.de/topic/200210-zugriff-auf-große-netzwerkordner-als-user-sehr-langsam/ Probier das mal http://www.computerwissen.de/windows/windows-probleme-loesen/artikel/windows-7-ordner-oeffnen-dauert-ewig-hier-ist-die-loesung.html Habe bei mir nicht sofort eine Besserung fest gestellt, kann aber auch gut sein das man etwas warten muss, gerade bei großen Ordnern.

Habe das hier gefunden, http://www.computerwissen.de/windows/windows-probleme-loesen/artikel/windows-7-ordner-oeffnen-dauert-ewig-hier-ist-die-loesung.html würde mir momentan auch einleuchten in Bezug auf diesen Threat: http://www.mcseboard.de/topic/193378-dateizugriff-extrem-langsam-hintergrundsuche Ich habs mal umgestellt und werde ein Paar Tage warten. Da der Ordner recht groß ist könnte ich mir vorstellen das es einige Zeit dauert.

Es muss ja was mit den Benutzern zu tun haben und nicht mit der Netzwerklast. Sobald ich als Admin über das LAN komme, flutscht der Zugriff.

Also ich hab es mal auf 4 Gruppen herunterreduziert, was aber keine merkliche Besserung ergab.

D:\VOL1\Dokumente\ABT_Cad\Einkauf_dxf_Zeichnungen DOMÄNE\ABT_EINKAUF:(OI)(CI)(M) DOMÄNE\AV2:(I)(OI)(CI)(M) DOMÄNE\Kowollik:(I)(OI)(CI)(M) DOMÄNE\Skrga:(I)(OI)(CI)(M) DOMÄNE\ABT_AV:(I)(OI)(CI)(RX) DOMÄNE\ABT_AV1:(I)(OI)(CI)(RX) DOMÄNE\ABT_CAD:(I)(OI)(CI)(M) DOMÄNE\ABT_EINKAUF:(I)(OI)(CI)(RX) DOMÄNE\ABT_EMPFANG:(I)(OI)(CI)(RX) DOMÄNE\ABT_TEVERKAUF:(I)(OI)(CI)(RX) DOMÄNE\ABT_VERKAUF:(I)(OI)(CI)(RX) DOMÄNE\ABT_WERKSTATT:(I)(OI)(CI)(RX) DOMÄNE\ABT_BUCHHALTUNG:(I)(OI)(CI)(RX) DOMÄNE\AfterSales:(I)(OI)(CI)(M) DOMÄNE\AV9:(I)(OI)(CI)(M) DOMÄNE\AV11:(I)(OI)(CI)(M) DOMÄNE\walter:(I)(OI)(CI)(M) DOMÄNE\qaqish:(I)(OI)(CI)(F) DOMÄNE\theinert:(I)(OI)(CI)(M) NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F) DOMÄNE\AV1:(I)(OI)(CI)(M) DOMÄNE\cadremote02:(I)(CI)(RX) DOMÄNE\Administrator:(I)(OI)(CI)(F) DOMÄNE\Dom„nen-Admins:(I)(OI)(CI)(F) DOMÄNE\Dom„nen-Benutzer:(I)(CI)(RX) VORDEFINIERT\Administratoren:(I)(OI)(CI)(F) 1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten.

Ich hab jetzt schon einiges im Netz zu ähnlichen Problemen gefunden, wie z.B. auch das hier http://www.mcseboard.de/topic/193378-dateizugriff-extrem-langsam-hintergrundsuche Auffallend ist bei mir das Problem bei Ordnern mit wirklich vielen Dateien egal welchen Typs. Allein bis alle Dateien angezeigt werden dauert es und der grüne Balken benötigt um die 20 Sekunden. Was aber verwunderlich ist, melde ich mich am PC als Domänen-Admin an, habe ich das Problem nicht. Alles flutscht wie es sollte. Ich habe auch einen PC der nicht in der Domäne ist. Wenn ich hier auf die Freigabe zugreife und authentifiziere mich als Domänenadmin, ist alles schnell. Komme ich als Domänenbenutzer ist es wieder langsam. Admins haben auf den Ordner Vollzugriff und Benutzer Schreib/Leserechte. Der Server ist ein 2008 R2 und die Clients Win7 Pro. Ich kann es reproduzieren, aber ich hab keine Idee von was es kommen könnte. Ideen?

Die Frage erübrigt sich denn es funktioniert. (Es sind in der Regel Office H&B) Ich will nochmals zusammenfassen was zum Erfolg geführt hat: 1. Host Eintrag beim Provider (Exchange.domäne.de) der auf die öffentliche IP des Servers verweist (DMZ). 2. Virtuelle Verzeichnisse, Outlook Anyware, Autodiscover... überall die externe URL hinterlegt, auch da wo eigentlich die interne rein sollte. 3. E-Mail des ÖO auf die externe Domäne geändert. 4. SplitDNS konfiguriert 5. Neues Zertifikat mit externer Adresse erzeugt. 6. Sollte bei externen Clients über VPN keine saubere DNS Auflösung möglich sein, muss die Hosts angepasst werden. 7. Bei externen war es dennoch notwendig die Outlook Verbiundungseigenschaften anzupassen (HPPT aktivieren und den Exchange Proxy hinterlegen) Vielen Dank für eure Hilfe!

Es wird Office 2007, 2010 und 2013 genutzt. Interessant ist, ein Client der per VPN sich mit dem Exchange verbindet kann das Comilance Archiv und ÖO anzeigen, nur nicht wegen dem Zertifikat öffnen. Ein Client im LAN momentan nur den ÖO. Aber für das CompArc wurde auch die Mail noch nicht auf die Ext. Domain geändert. Wenn ich mir die Verbindungseigenschaften anschaue sind da absolut Unterschiede auffallend. In Zukunft sollte natürlich alles mit der externen URL verbunden werden damit es funktioniert. Wobei mir dann doch nicht wirklich klar ist warum MS zwischen externer und interner URL unterscheidet wenn ich dann doch überall das Gleiche eingebe.

Okay, kappiert.... THX Ich habe jetzt alle virtuellen Verzeichnisse auf die externe URL umgestellt, sowie Outlook Anywhere und auch die AutoDiscoverServiceInternalUri. (Hierfür habe ich natürlich auch noch eine Zone angelegt mit dem entsprechenden Host Eintrag.) Ich bin jetzt auch einen Schritt weiter. Einen NichtDomänen Client konnte ich im LAN verbinden und sehe zumindest die ÖO. Jedoch kann ich diese momentan nicht öffnen da die externe URL noch im Zertifikat fehlt und ich einen Zertifikatsfehler bekomme. Also werde ich heute Nacht das Zertifikat neu erzeugen und per GPO an die Clients verteilen. Das Compilance-Archiv kann ich momentan noch nicht sehen, aber ich denke das liegt daran das ich hier auch die externe Mail Domäne setzen muss statt der internen.

Zwei Hostzonen? Was meinst du damit. Ich hätte jetzt eine Zone für die ext. Domain gemacht und dort den externen Namen des Servers auf die interne IP zeigen lassen.

Das Livesystem? ;) Und für SplitDNS muss ich eine Zone anlegen. Dann ist erstmal die Firmenwebseite nicht erreichbar. OK da kann ich die externe IP für den Webserver hinterlegen. Abgesehen davon vermute ich mal, dass die Clients ihre Verbindung verlieren werden. Also doch eher mal am WE testen...

Okay... Dann nur mal ne Frage zum Verständnis. Intern tut es ja bei mir und die nicht Domänen Clients werden über einen VPN zugreifen. Die externe Domain wird eigentlich nie genutzt. Smatphones und OWA nutzen momentan die öffentliche IP. Wäre es da nicht logischer die interne URL auch als externe einzutragen?

OK jetzt konnte ich endlich nochmal testen, bzw. Änderungen vornehmen die jedoch leider noch nicht zum Erfolg geführt haben. Der Konnektivitäts Test von MS war übrigens erfolgreich, wobei dieser ja von extern kommt. Mein Problem mit dem ÖO besteht ja auch intern. Ich beschreibe euch am besten den momentanen ist Zustand... Virtuelle Verzeichnisse: Hier ist überall der interne FQDN des Exchange hinterlegt. Komisch ist das hier meine Änderungen bei AutoDiscover wohl nicht übernommen werden. Wie kann ich hier die external URI definieren? Zertifikat, volgende Alternative Antragstellernamen sind hinterlegt: int. FQDN des Exchange, AutoDiscover.IntDom.local, AutoDiscover.ExtDom.de, Int.Dom.local, ExtDom.de Outlook Anyware: Hier ist jeweils der interne FQDN und die externe Domäne hinterlegt. Das Postfach für den ÖO hat nun die externe E-Mail Adresse. Wenn ich einen NichtDomänen Client im LAN mit dem Exchange verbinden will, z.B. Outlook 2007, will das Autodiscover nicht. Ich muss ihm explizit sagen das er eine HTTP Verbindung machen soll und muss auch den Exchange von Hand als Proxy angeben. Danach klappt die Verbindung, jedoch ohne ÖO. Also muss ich ja noch einen Bock im Autodiscover haben. Aber welcher?

OK ich habe nun diesen Artikel gefunden: http://www.behnsen.net/exchange-2013-oeffentliche-ordner-werden-in-outlook-nicht-angezeigt Damit leuchtet ein das ich doch ein AutoDiscover Problem habe. Denn die Adresse des ÖO ist natürlich @Domäne.local. Nur stellt sich für mich die Frage, ist es in meinem Fall wirklich der richtige Weg die Adresse auf @Domäne.de umzustellen oder doch nochmals das AutoDiscover anzuschaun? Momentan habe ich für AutoDiscover keine ExternalUri hinterlegt.

Selbst wenn ich einen Client im LAN habe der kein Domänenmitglied ist bekomme ich die ÖO nicht angezeigt.

Hi, ich muss das Thema doch nochmals aufgreifen... Prinzipiell funktioniert der Exchange prima. Ich habe nur ein Problem, Clients die nicht in der Domäne sind sehen die öffentlichen Ordner und auch das Compilance Archiv nicht. Beide Bereiche sind in eigenen Datenbanken. Outlook und die Ereignisanzeige melden keine Fehler. Eine Überlegung habe ich noch... Ich habe mir mein Zertifikat nochmals angeschaut. Hier stehen momentan folgende Antragstellernamen drin: exchange01.domäne.local AutoDiscover.Domäne.local AutoDiscover.Domäne.de Domäne.local Domäne.de Was mir momentan darin fehlt ist: exchange01 die öffentliche IP Wobei der Zugriff mit iPhones von extern problemlos funktioniert und die externen Outlook momentan per VPN zugreifen. Daher glaube ich kaum das es daran liegen kann.

Also ich habe noch immer ein Problem mit den externen Clients die nicht in der Domäne sind. Die bekomme ich nicht an den Exchange ran. In der Hosts Datei hab ich den Servernamen und den FQDN hinterlegt. Wobei mir aufgefallen ist das der Server mit 27c5b8ec-a860-4e1a-95e6-e0794444bf98@domäne.local bei den Clients hinterlegt ist. Das kann ja so nicht funktionieren. wobei ich diesen Namen nirgends hinterlegt habe.

Einen NichtDomänenClient konnte ich verbinden. Autodiscover und Zertifikat wurden wie oben beschrieben erstellt, danke! Ich musste noch in den Verbindungseigenschaften von Outlook den FQDN des Exchange als Proxy hinterlegen. Jedoch sehe ich keine öffentlichen Ordner. (Diese liegen in einer anderen DB) Dazu kommt noch, dass ich bei Outlook 2013 noch immer die Meldung bekomme, dass ein Problem mit dem Sicherheitszertifikat des Proxy besteht. Und ein Loginfenster erscheint. Ich kann eingeben was ich will, bringt nix. Ich kann die ÖOs auch nicht erweiten. Meldung: Der Ordner kann nicht erweitert werden. MS Exchange ist nicht verfügbar... Es gibt hierzu Hotfixe vom August 2013, die waren aber schon installiert. Also es ist echt seltsam! Ich habe hier auch ein Outlook 2013 das sich problemlos verbindet. Ich komme auch ohne Gemecker auf die ÖO. Das Zertifikat wird mittlerweile per GPO verteil. Ich habe mir im Outlook mal die Verbindungseigenschaften angesehen, alles identisch. Hat da noch jemand eine Idee?

Die stehen korrekt drin, also z.B. https://server.dom.local/owa Aber ich hab mich zu früh gefreut, dass Login Fenster kommt doch wieder. Denke das hängt mit der Proxyfehlermeldung zusammen. Komisch, der Fehler tritt gerade nur an meinem testPC auf. Bei den anderen Usern nicht sobald der Zertifikat importiert wird. Ich kann dann auch nicht auf die Öffentlichen Ordner zugreifen. Mit welchem User ich es versuche ist egal.

Hmmm..... ich habe den internen FQDN beim OA hinterlegt. Autodiscover funktioniert auch. Ich habe ein neues Zertifikat erstellt und überall Server.domäne.local eingetragen, bis auf die eine Stelle wo Autodiscover.dom.local drin steht. Wenn ich Outlook neu öffne kommt die Meldung das ein Problem mit dem Sicherheitszertifikat des Proxyservers vorliegt. Der Name entspricht nicht der Zielwebseite "Servername" (nicht der FQDN). Fehlercode 10 Das Zertifikat habe ich bei den vertrauenswürdigen Stammzertifizierungsstellen importiert. Zumindest kommt jetzt nicht mehr der Fehler das ein Login Fenster aufpoppt. Nur einige Clients werden nicht in der Domäne sein.

Danke schonmal für diese Info! Das ich das Zertifikat bei den Clients importieren muss ist klar. Kann ich ja auch per GPO verteilen. (Ich hab übrigens keine CA sondern nutze die von Exchange selbst signierten.) Trage ich für den externen Host bei Outlook Anywhere den FQDN oder nur den Servernamen ein? Beim Zertifikat stellt sich für mich dennoch die frage was ich für die externen Zugriffe eintrage. Wenn dann wird ja mit der festen IP des ISP zugegriffen, oder per VPN auf den Namen. Also auch der interne FQDN? Und bei den internen Sachen incl. POP IMAP, OA auch der FQDN? Der Assistent schlägt hier den reinen Servernamen vor, ohne Domäne.

Ich plage mich mit diesem Problem schon einige Tage herum, konnte aber keine vernünftige Lösung finden. Aber erstmal zum System: Server 2008 R2 mit Exchange 2013 SP1 / Clients Win7 mit Outlook 2007-2013 Mails werden per POPCon abgeholt, der Exchange ist momentan nicht von extern erreichbar. Es werden aber Outlook sich per VPN verbinden und natürlich Smartphones mit der festen IP des DSL. Es begann damit das ich Clients habe die nicht in der Domäne sind und Outlook nicht verbunden werden konnte. Meine Recherche ergab das ich das Autodiscover und das Zertifikat richtig erstellen muss. Nachdem ich ein neues Zertifikat erstellt habe, bekomme ich bei den Clients die in der Domäne sind die Meldung das ein Problem mit dem Zertifikat des Proxy vorliegt und Benutzer und Kennwort wird abgefragt, die Anmeldung schlägt aber fehl. Outlook Anywhere sieht so aus: Externer Host ist leer (Was sollte da rein? VPN Clients werden sich mit dem internen Servernamen verbinden) Interner Host "Server.dom.local" Authtifizierung "Aushandeln" SSL ist zugelassen Ich bin mir sicher das ich einen Bock bei den Werten für das Zertifikat gebaut habe. Kann mir jemand sagen was in meinem Fall für Werte gesetzt werden müssen für: Outlook Web App intern/extern OAB intern/extern Exchange Webdienste intern/extern Active Sync intern/extern Autoermittlung intern/extern POP IMAP Outlook Anywhere Danke vorab!

Ich habe genau das selbe Szenario und das selbe Problem. Gibt es mittlerweile eine Lösung? Bei mir sollen halt externe Clients mittels VPN auf den Exchange zugreifen. Bei älteren Exchange Versionen hab ich lediglich den Servernamen in der hosts hinterlegen müssen.