RobertWi

Moin, es gibt keine "harten" Grenzen, nur Empfehlungen - und das sind auch "limits per folder", d.h. der User kann mehrere Kontakte-Ordner haben und das Limit damit erhöhen. Wichtig ist auch, welche Outlook Version zum Einsatz kommt. Hier gelten im Prinzip die gleichen Restriktionen wir für die gleichlautende Exchange Version. Zahlen siehe hier: https://social.technet.microsoft.com/Forums/exchange/en-US/bacbbc8c-b745-437e-b7be-2d24d42fd629/item-limit-per-folder?forum=exchange2010hosters http://blogs.technet.com/b/exchange/archive/2009/12/07/3408973.aspx Für 2013 habe ich keine genauen Zahlen, die sind aber eher noch höher.

Und wie sollen wir dann helfen? Wir wissen ja noch weniger über die Struktur, als die Beteiligten. Grundsätzlich funktioniert das. Ich habe sowohl Exchange 2013, die ich mit beiden Outlook-Versionen betreibe, als auch Office 365 Konten. Es gibt zwar in Exchange die Möglichkeit, bestimmte Outlook Versionen zu sperren, das gilt dann aber immer und bei jeder Anmeldung. Aber ich rate mal in eine andere Richtung: Benutzt ihr eventuell Roaming-Profiles und es liegt vielleicht gar nicht am Exchange sondern daran, dass die Outlook-Einstellungen im Profil die falsche Version haben. Das macht dann aber Probleme in beide Richtung und sollte tunlichst vermieden werden, denn Outlook kann es auf einem Rechner nur einmal geben, im Gegensatz zu Word oder Excel.

Moin, ich denke, man muss sich schon extrem b***d anstellen und es muss viel schiefgehen, um man mit der bloßen Installation einer internen CA was kaputt zu machen. Denn technisch ist eine CA kein Hexenwerk. Es sind eher die organisatorischen Fragen, die die Arbeit machen.

Wenn man Troubleshooting macht, dann im Sekundentakt. Kann man notfalls gut scripten...... :P

Meine Meinung ist: Das kommt darauf an. ;) Ich habe aber auch die Ahnung, dass beurteilen zu können und sowohl die eine als auch die andere Lösung zu implementieren. Wenn jemand keine/wenig Ahnung davon hat, ist es einfacher eines zu kaufen.

Ich benutze dafür "baretail" - läuft ohne Installation und hat gute Markierungsmöglichkeiten. Lästig ist lediglich, dass Exchange und Windows die Dateien nur mit erheblicher Verzögerung schreiben und ein echtes "tail" damit nicht möglich ist.

Moin, und nicht persönlich nehmen, aber wenn ich den zweiten Satz im Eingangsposting lese und die Antworten danach, dann klappen sich mir die Fußnägel hoch. Das Du nicht gut mit Mail/SMTP/Exchange auskennst, ist ok, niemand kann alles kennen. Aber dann schickt doch bitte jemand zu Eurem Kunden, der mehr über das Spezialgebiet "Mail" weiß. Dann müssten wir auch nichts über IP-Adressen und was ein Smarthost ist, erklären. :(

Ich hatte durchaus auch einige Beiträge in meinem Linkverzeichnis, bevor wir das intern diskutierten und ich mir die daraufhin mal wirklich kritisch durchlas.

Es gibt Leute, die den persönlich kennen, die erzählen, dass er ziemlich gut blenden kann. Und Tony Redmond (auch Exchange MVP) schreibt selbst für diverse Magazine, der erzählt immer wieder, dass in den Magazinen hoher Kostendruck herrscht und die Leute, die Lektor spielen, keine Ahnung haben. Die nehmen dann halt alles, was sie bekommen können. Es gibt mehrere MVP, die den Magazinen bereits angeboten haben, Korrektur zu lesen - allgemein und besonder bei Artikeln von dieser Person. Hier mal was zum Lesen als Beispiel, für die Weihnachtszeit: Posey (leider mit Paywall) - Reaktion Oder hier: http://powerwindows.wordpress.com/2013/01/03/3-benefits-of-running-exchange-server-in-a-virtualized-environment/ Mit so Highlights wie "dynamic memory" (nicht supported und nicht erlaubt bei Exchange), "creative ways" (bei Exchange braucht man alles, aber bestimmt nichts "creative"). Auch nett: http://powerwindows.wordpress.com/2013/01/10/the-pros-and-cons-of-using-database-availability-groups/ Ich empfehle unbedingt, den letzten Absatz "As you can see, " zu lesen. Und bevor aus dem ungläubigen Staunen Entsetzen wird, einen Klick auf Link zum Inhaber des Blogs, der nämlich... tata... Mitarbeiter bei EMC ist. ;) Den Rest kann sich dann jeder selbst zusammen reimen.

Richtig. Der Exchange bringt alles mit, was Du brauchst. Und falls Du ein AD-Werkzeug brauchst, kann man auf dem Exchange wunderbar ADSI per Powershell benutzen (theoretisch gibt es auch die AD-Module, die sind aber ab 2012 PS 3, während Exchange nur PS 2 nimmt).

Moin, wie immer: Um auf Inhalte eines Postfachs zuzugreifen, gibt es keine einfachen, eingebauten Möglichkeiten. Das Mittel der Wahl wäre es, ein Programm/Script zu schreiben und die Exchange Webservices zu nutzen - oder ein Drittanbieter-Tool zu suchen.

Anekdote dazu: "Brien Posey" wird in der Exchange MVP Gruppe also Ausdruck dafür verwendet, wenn jemand über ein Fachfremdes Thema redet und eigentlich keine Ahnung davon hat (Posey hat keine Ahnung von Exchange). So nach dem Motto: "Ich will jetzt nicht den Posey machen, aber ist es richtig, dass....." oder "Person XYZ spielt gerade Posey und erzählt hier ziemlichen Mist....". :P

Moin, korrekt. Wie Norbert schreibt: Geh das Problem an! Denn: Works as designed. Outlook merkt sich für den Kontakt in der Vorschlagsliste nicht den Namen oder die Mail-Adresse, sondern das sog. legacyExchangeDN-Attribute. Bei Deiner "Bastelei" ändert sich das leider bei jedem Löschen und neu anlegen. Und damit lässt sich der Vorschlag nicht mehr verwenden. Als Workaround könntest Du jetzt eine "pseudo LegacyDN" in den Kontakt eintragen. Hierbei musst Du dafür sorgen, dass dieser beim gleichen Kontakt immer identisch ist. Danach muss der Vorschlag in Outlook einmal entfernt werden und beim nächsten Mal hinzufügen wird dann der korrekte übernommen. Das geht aber nicht direkt beim Anlegen, sondern erst im nachhinein. Du müsstest also jeden Kontakt nach dem Anlegen noch mal anfassen. Aber ehrlich gesagt: Dieser dauerhafte Komplettimport ist schon Mist. Deutlicher besser wäre, wenn Du Änderungen "synchronisierst". Das macht Dir in Exchange deutlich weniger Stress, ist besser für den DC und erlaubt es auch beim Client wieder, das OAB zu benutzen. Das gibt es ja nicht ohne Grund und eine Standard-Funktion zu deaktivieren führt meist zu unerwünschten Nebeneffekten. Du musst es nur einmalig korrekt einbauen (geht problemlos auch per PS-Script aus der CSV-Datei) und wirst später deutlich weniger Ärger haben. Und bei der Anzahl lohnt sich der Aufwand. Du musst

Moin, Gegenfrage: Findest Du irgendwo die Aussage, dass es erlaubt wäre? Wenn man den Exchange-Entwicklern diese Frage stellt, dann kommt also Antwort zurück: Findest Du von uns (Exchange) irgendwo einen Hinweis, dass dieses Vorgehen supported ist -> Nein, also ist es unsupported. Solche Diskussionen hatten wir schon mehrfach mit der PG. Denn das Problem ist ein wenig vielschichtiger. Exchange und Outlook verlassen sich bei der Zertifikatsüberprüfung auf Windows. Daher gibt es in Outlook auf keine Funktion, ein Zertifikat als vertrauenswürdig zu betrachten. Andersrum kann man damit wunderbar den IE zum Testen verwenden, der wenn der einem Zertifikat vertraut, tut es auch Outlook. Folglich können die Entwickler von Exchange keine 100% Support-Aussage zu Zertifikaten sagen. In diesem Punkt können Sie nur Empfehlungen aussprechen, aber was da letztendlich geht, entscheiden die Windows-Entwickler. Es gibt hier einen langen Technet-Artikel zu Zertifikaten: Klick Kernaussagen in Bezug auf Self-Signed: Es gibt Geräte, da funktionieren sie gar nicht und es gibt Geräte, da machen sie Ärger. Offiziell wird da gesagt, dass sie mit Outlook Anywhere nicht funktionieren - und das ist seit 2013 immerhin die Standard-Verbindung zu Exchange. Ich weiß, dass hier noch 2010 im Gespräch ist, aber ein totes Pferd bleibt ein totes Pferd und wer sich einmal ein schlechtes Vorgehen angewöhnt hat, ist nur schwer davon anzubringen. Außerdem gibt es diesen alten Support-Artikel, der den Import des Self-Signed ausdrücklich als "Work Around" kennzeichnet und die Verwendung eines echten Zertifikates mit "you must install" festlegt: Klick Und dann bleibt ja am Ende immer noch die aktuelle Entwicklung im Zertifikatsbereich. Da hier die Sicherheitsschraube in den vergangenen Monaten sehr angezogen wurde, ist es für mich nur eine Frage der Zeit, bis Windows importierten Self-Signed auch nicht mehr vertraut. Nach der Welle der Anfragen bei "E-Mail made in Germany" ist die nächste Problem Welle schon am Horizont, wenn Windows SHA1-signierten Zertifikaten nicht mehr vertraut. Die sind leider heute noch Standard bei Exchange, was daran liegt, dass Windows vor 2012 noch gar keine SHA2-Zertifikate kann und der Versuch von Microsoft, das im Oktober zu implementieren, leider schief gegangen ist. Ich denke, es wird eine Menge Exchange-Admins geben, die sich dieses Problem nicht bewusst sind und eines Morgens aufwachen und feststellen, dass sich kein Windows-Rechner mehr verbinden kann. Ich finde, das muss sich ein Admin nicht auch noch mit den potentiellen Problemen von Self-Signed herumschlagen.

Das muss man nicht mal kaufen. Einjährige gibt es bei einigen Anbietern kostenlos (www.startssl.com). Trotzdem scheint mancher Admin davor Angst zu haben und nimmt lieber eine Bastellösung in Kauf, als es richtig zu machen.

Schon oft. Du installierst hoffentlich direkt mit SP 3?

LCR gibt es bei 2010 nicht mehr. Die DAG-Kopien liegen da immer auf getrennten Servern. Und was ist mit dem Whitespace?

Was für eine Kopie? Jeder Exchange Version legt genau eine "Kopie" der Datenbank an (=das Original) und ob Du weitere haben willst, entscheidet Du via LCR/SCR (2007) oder DAG (2010/13) selbst. Die liegen dann aber i.d.R. auf einem anderen Server. Und ob ein Defrag überhaupt was bringt, ist auch unklar. Was bringt denn der Befehl für eine Ausgaben: Get-MailboxDatabase -Status | Select-Object Server,Name,AvailableNewMailboxSpace

Moin, natürlich. Wie kommst Du darauf, dass die Mindestanforderung für die Co-Existenz nur für bestimmte Exchange-Server gelten könnte? Die Frage stellt sich eigentlich schon deshalb nicht, weil Du bereits unsupported bist, wenn Du Exchange 2007 in verschiedenen SP-Versionen nebeneinander betreibst - solange das nicht der Augenblick der SP-Installation selbst ist. Und nicht vergessen: Bei der SP-Installation zuerst CAS/HT, danach MBX aktualisieren.

Und außerdem bringt es wieder mal das Problem, dass irgendein Dritt-Anbieter-Produkte im SMTP-Strom mehr kaputt macht, als es hilft. Also am besten die UTM so konfigurieren, dass alles, was Port 25 ist unbearbeitet an Exchange durchgereicht wird.

Immer diese dämlichen Self-Signed Zertifikate. Daher mal wieder: Die sind grundsätzlich unsupported. Sie können also funktionieren, müssen aber nicht. Und bei den aktuellen Themen in Bezug auf SSL/TLS/SHA1 usw. würde es mich nicht wundern, wenn die Dinger in absehbarer Zeit nicht mehr Vertrauenswürdig gemacht werden können. Daher: Installier eine CA. Dauert 5 Minuten und bei einer AD-integrierten wird Dir das Root-CA automatisch in die Domain-GPO gesteckt. Und dann bezieh das Exchange-Zertifikat darüber. Das ganz ist nicht nur Standard, sondern bringt auch andere Vorteile, wenn man z.B Macros signieren will, irgendwelche internen Webseiten absichern will oder einfach weniger Ärger möchte.

Moin, technisch korrekt umgesetzt, solltest Du kein oder höchstens ein internes Root-CA-Zertifikat auf dem Server Client haben. Um Dir zu helfen, müsste man also erst mal genau wissen, wie der aktuelle Stand bei Dir ist.

Moin, Ausnahmen wären nur auf Domänen-Ebene möglich (neue Remote Domäne anlegen). Das gilt dann aber für alle Benutzer. Die einzige Lösung, die mir einfiele wäre das Anlegen von jeweils einem Kontakt und eine Weiterleitung an diesen (der hat ja eine interne Mail-Adresse). Alles andere wäre mehr oder weniger gebastelt.

Moin, vcard ist wie msg *im* Postfach, d.h. Du brauchst einen Client für den Import. Der Standard-Client wäre Outlook. Würden die als Kontakte in einer PST-Datei vorliegen, könntest Du sie auch wie EMS importieren. Das ist aber nur ins Postfach. In die GAL kannst Du so aber gar nicht importieren. Die GAL ist ein Abbild einer Adressliste und eine Adressliste bezieht sich auf Exchange-Objekte, die Du in Deinem AD hast. Einen anderen Speicherort für eine AL gibt es nicht. Wenn Du die vCards in CSV konvertierst, könntest Du diese dann in AD einlesen: http://mymcp.blogspot.de/2007/07/bulk-importing-contacts-from-csv-to.html http://www.emailquestions.com/microsoft-exchange/9199-bulk-import-migrate-contacts-into-microsoft-exchange.html

Moin, wenn dieser Server bei einem Hoster steht, musst Du vermutlich die DNS-Einstellungen anpassen. Die dürften auf den Hoster zeigen, sie müssen aber auf den DNS auf dem DC zeigen. Danach prüfe bitte zuerst, ob Du irgendwelche Fehlermeldungen in Bezug auf das AD gibt. Diese musst Du vorher beheben. BTW: Der Betrieb von Exchange auf Mietsoftware braucht spezielle Lizenzen (aus dem Kopf reicht bei 2007 nicht mal SA). Können wir davon ausgehen, dass Du die hast?