=BT=Viper

Ich habe die Migration von ÖO von EX2010 zu 2013 durchgeführt. Soweit hat das gut funktioniert nach diesem Artikel https://technet.microsoft.com/de-de/library/jj150486(v=exchg.150).aspx Mein Problem ist jetzt, daß die Mailbox noch immer auf "holdformigration" steht wenn ich (Get-Organizationconfig).rootpublicfoldermailbox ausführe. Set-OrganizationConfig -PublicFoldersLockedforMigration:$false -PublicFolderMigrationComplete:$true Bringt da keine Änderung. Also wie bekomme ich das PublicFolder aus diesem Status raus?

Also momentan werden zwei WNDAP350 von Netgear genutzt. Die Richtantennen sind außen an den Montagehallen angebracht. Die Einstellungen wurden damals auch mit dem Support von Netgear optimiert. Mit einem PC hat es bisher recht gut funktioniert. Klar, Wetter usw. spielen da schon eine Rolle und man hat beim arbeiten auch gemerkt das es nur 300MBit/s sind. Gemessen hatte ich so um die 85% der Bandbreite. Derzeit sind 3 Rechner betroffen. Ein extra Server fällt aufgrund der Software Architektur raus. Es laufen mittlerweile mehrere Anwendungen über das Netz und gerade das neue InforCOM 7.5 gibt bei den Datenbankzugriffen wohl schneller auf, vor allem wenn zwei PCs gleichzeitig über die Bridge zugreifen. Ein Rohr liegt nicht unter der Strasse und diese ist eine öffentliche. @lefg: Danke mal für den Link, sieht interessant aus. RDP ist natürlich auch eine Möglichkeit. Zumindest die Hauptanwendung kann ich denen mal kurzfristig als Remote App geben.

Ja das wäre auch mein Favorit. Aber das war der GL bisher zu teuer. Naja, wenn die Leute nicht arbeiten können ist es teurer...

Ein Kunde hat eine WLAN Brücke mit 300 MBit/s über die Strasse, also so ca. 50m. Da es jetzt eine neue Anwendung gibt und auch ein Rechner dazu gekommen ist, reicht das nicht mehr aus. Leider reicht das nicht mehr aus. War eh schon immer ein Flaschenhals. Jetzt bin ich auf der Suche nach einer Gigabit WLAN Brücke oder ähnliches. Alternativ könnte auch Glasfaser unter der Strasse gelegt werden. Richtfunk wäre auch eine Möglichkeit, kotet aber auch einiges. Was habt ihr da für Erfahrungen/Empfehlungen?

Ich hab jetzt mal die DB neu angelegt, hat aber auch nix gebracht. Hat keiner ne Idee warum es nicht klappt?

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?