RobertWi

Nein, wieso auch? Empty RAM ist wasted RAM wissen die Linuxer schon seit 20 Jahren. Warum sollte der freie Speicher ungenutzt rumliegen? Es ist doch viel effektiver, wenn er verwendet wird. Und Exchange nutzt ihn sinnvoll und erhöht die Performance damit. Exchange nutzt immer den verfügbaren Speichern. Problematisch wird es erst, wenn Exchange den Speicher nicht mehr frei gibt, wenn ein anderes Programm ihn braucht (z.B. beim Backup). Dann allerdings ist zu wenig RAM im Rechner die Ursache, nicht der hohe Verbrauch.

Moin, glaub uns: Das willst Du nicht - solange Du nicht ganz genau weißt, was und warum Du das tust. Und wenn Du das wüsstest, wüsstest Du auch, warum das eine ganz schlechte Lösung ist, die mehr Ärger macht und Dein Problem vermutlich nicht lösen wird. Daher: Warum genau willst Du den Speicher begrenzen?

Moin, na ja, auch wenn Namen Schall und Rauch sind, ersetzt das nicht das Wissen über die Funktionsweise von Exchange. Darum ist es ja so schwer, in einem Forum zu erklären, wie das mit den Namen funktioniert, da man wissen muss, was ein CAS-Array, Load Balancer, internalURL, externalURL, Autodiscover, SplitDNS, etc. ist und wann was wie benutzt wird. Mein erste Schritt von zwei Stunden "Namenssuche" besteht darin, dass ich den Leuten Exchange erkläre (1,5 Stunden) und im Rest weiß der Kunde dann meist selbst, welche Namen er braucht und wie man die Namen, die Exchange nutzt und die, die im Zertifikat stehen, synchronisiert. Nutze die Funktion "E-Mail-Autokonfiguration testen...." in Outlook. Da siehst Du zum einen die URL, die Outlook intern für Autodiscover nimmt. Diese wird mit der EMS und Set-ClientAccessServer geändert. Außerdem sind noch die URLs wichtig, die danach für OAB, Verfügbarkeitsdienst und Abwesenheitsassistent benutzt werden. Die erste kann über die EMC (Serverkonfig -> Clientaccess -> OAB-Verteilung), die zweite leider wieder nur über die EMS mit "Set-WebservicesVirtualdirectory" geändert werden. Da Du nun schon das Zertifikat hast, wirst Du die URLs anpassen müssen. Danke SplintDNS ist das aber kein Problem und die URLs müssten auf "mail.domain.com" geändert werden. BTW: Wenn Du bei der Outlook-Einrichtung intern als Servernamen auch "mail.domain.com" nimmst, hast Du also als CAS-Array (das ist der RPC-Teil von Outlook) den gleichen Namen, wie für den HTTP-Teil benutzt. Das ist nicht empfohlen. Du solltest für den RPC-Teil (=CAS-Array) einen eigenen Namen nehmen, der muss auch nicht ins Zertifikat. Das widerspricht zwar meinen obigen Ausführungen, hier gibt es aber andere Gründe, warum man das macht, die wichtiger sind und in Outlook stecken.

Ob Du was vergessen hast, können wir aus der Ferne nicht sagen, da wir Deine Infrastruktur nicht kennen. Du hast da aber eher zu viel drin. Aber da das ja ein internes Zertifikat ist, ist das nicht so schlimm. Bei Fehlern baust Du halt ein neues.

Moin, je nach Konfig der Authentifikation steht das im IIS-Log. Und natürlich sollte auch der DC diese Vorgänge protokollieren, wenn man dort die passenden Protokollierungen aktiviert hat. Und vor Auswertungen der Betriebsrat fragen, der könnte was dagegen haben.

Moin, aber Namen sind doch nur "Schall und Rauch". Ob ein Server per SMTP seine Mail an "owa.domäne", "mail.domäne" oder "christkindlmarkt.domäne" verschickt, ist ihm doch vollkommen wurscht. Du machst den passenden MX-Eintrag, der zeigt auf einen Host und fertig. Und wenn hinter dem Host nur eine Adresse hängt, dann reicht auch ein Name. Für SMTP/TLS brauchst Du ein Zertifikat, das auf den FQDN des Mailservers (so, wie er sich im HELO meldet) ausgestellt ist. Aber wieder: Der Name ist doch egal. MTLS setze ich nicht ein und habe ich bei Exchange auch noch nicht wirklich erlebt (eher bei Webserver-Farmen, Lync, o.ä.).

Moin, das erste Problem ist wie so oft: Definiere die Problemstellung korrekt. E-Mail werden bei Exchange nicht "abgeholt". E-Mail verbleiben (solange man kein POP3 nutzt) auf dem Server und werden höchsten gelesen. Es gibt zwar Protokolle, welches Outlook sich mit Exchange verbindet (irgendwo in den Log-Ordnern), aber IMHO nicht, mit welchen Postfach. Und welche Mails gelesen worden sein, steht da auch nicht drin. Die Diagnoseprotokollierung kann mehr protokollieren, aber IMHO auch nicht das Postfach, nur den Client. Und welche Mails der gelesen hat, ist ohne vorherige Aktivierung des Auditlogs gar nicht zu sehen.

Wenn die Meldung erst nach einer Minute kommt, ist das Problem mit hoher Wahrscheinlichkeit nicht bei Autodiscover, sondern eher bei der OAB- oder der EWS-Url zu suchen. Nutze die "E-Mail-Autokonfiguration testen..."-Funktion von Outlook, um die übertragenen URLs für Autodiscover, OAB, Abwesenheitsassistent und Verfügbarkeitsdienst zu prüfen. Diese URLs müssen zum Zertifikat passen.

Ach so, das mit den Namen bezog sich auf PSW. Ja, interne Namen sind bei vielen CA/RA nicht möglich. Anstelle von mail.* und owa.* reicht halt einfach ein Eintrag. Da Du darüber OWA machst und die Leute tendenziell am meisten dort die URL eingeben würden, würde ich nur owa.* benutzen. Ich habe ja auch nicht gesagt, dass ihr viele Namen habt, nur, dass die Anzahl zwischen 1 und N schwanken kann und Pauschalaussagen daher nicht möglich sind. Du hast z.B. eine SpliDNS-Konfiguration, was auch Auswirkungen auf die Namen hat. Mit einem SRV-Eintrag für autodiscover könntest Du die Anzahl der Namen im Zertifikat auf einen senken. Das geht aber nur, wenn Du auch wirklich SRV-Einträge setzen kannst.

Moin, ehrlich gesagt, sind exakte Aussagen ohne genaue Analyse der Umgebung (Netzwerk, DNS, Anzahl Server, etc.) nicht wirklich möglich. Wenn ich beim Kunden bin, dauert es schon mal zwei Stunden, bis wir alle Namen festgelegt haben. Die Anzahl der NOTWENDIGEN Namen ist zwischen 1 und N variabel. Die anzahl der möglichen Namen weicht davon noch mal ab. Deine Namensliste oben KANN man so machen, muss man aber nicht. Spontan würde ich z.B. mail.* oder owa.* weglassen. Wenn es eh auf die gleiche IP zeigt, kostet das ein doppelter Name nur unnötig Geld. Was genau meinst Du mit "Nun sollen ja auch Interne Servernamen ab 2016 wegfallen, sodass ich es für die Zukunft schon gerne sauber hätte."?

Oha, danke für die Info. Dann werden die nächsten Wochen spannend, weil das WMF 3.0 und RU ja munter via WSUS verteilt werden. Das Thema wird übrigens intern schon heftig diskutiert.

Ja, wie gesagt; Port-Änderungen sind nicht vorgesehen und daher auch nicht möglich. Du kannst das nur vor Exchange lösen. Oder mit einer zweiten IP-Adressen.

Moin, das wird Dir nicht gefallen: Port-Änderungen sind in Exchange nicht möglich. Du müsstest eine URL-Umschreibung in der Firewall machen.

Ja, das klingt gut.

Zu den Fragen 1. Kann man ohne nähere Infos zum gesamten Netzwerk nicht beantworten. 2. Vermutlich ist es erforderlich, aber siehe Antwort 1. (allerdings schadet es auch nichts) 3. Siehe meinen Eingangslink; das kann im Outlook geändert werden, aber nur lokal auf dem Outlook-Client

Oh je, dann hoffe ich nicht, dass man das nur mit einer Neuinstallation wieder los wird. Allerdings ist es wirklich so: - Exchange ist noch nicht dafür freigegeben (wird sich vermutlich mit SP 3 ändern) - es gibt auch an anderer Stelle Probleme damit

Keine Ahnung, denn ich habe das noch nicht installiert. ;)

Moin, hast Du eventuell zufällig das optionale Update für das WMF 3.0 installiert? Das ist die PowerShell 3.0 und die ist noch nicht für den Einsatz bei Exchange freigegeben und muss daher wieder runter.

Moin, ein wenig mehr Fehlerbeschreibung wäre schon sinnvoll, also beginnen wir mal mit einem Link: MSXFAQ.DE:WinRM Bitte auch den Links im ersten Abschnitt folgen!

Moin, Du hast den Fehler mit internen Clients? Warum sind die nicht AD-Mitglied? Normalerweise ist das ein "externes" Problem, dann also auf dem DNS für das Internet zu machen.

Am SBS kann man nicht viel machen (und ich bin auch kein Freund davon). Aber es ist doch wohl Deine Entscheidung, ob da noch ERP, MySQL, eine andere Datenbank und andere Dienst drauf laufen, oder? Der erste Teile einer Problemlösungsstrategie besteht darin, so sauber vorzuarbeiten, dass es gar nicht erst zu Problemen kommt. Wenn Dein MySQL den SBS zerschießt, ist das Geschrei viel größer und der Aufwand viel höher, als von vornherein zu sagen: Können wir so nicht machen, muss sauber designt anders aussehen. Denn richtig: Das ist ein DISKUSSIONforum und in diesem muss es auch erlaubt sein, Dir zu sagen, dass Du mit großen Schritten auf eine Wand zurennst, oder? Denn wenn das Kind in den Brunnen gefallen ist, wo wirst Du dann fragen? Noch kannst Du sinnvoll was ändern. ;)

Nachtrag: Die Tatsache, dass sich Exchange NUR 8 GM der verfügbaren 16 GB nimmt (das wäre normalerweise mehr), ist schon ein guter Indikator, dass der Server zu wenig RAM hat.

Moin, ein Outlook-Client, der nicht Domänen-Mitglied ist, versucht "autodiscover.mail-domäne" aufzurufen um darüber Autodiscover zu machen. Entweder baut ihr das Zertifikat neu und nehmt den Autodiscover-Eintrag dort auch mit auf. Oder ihr macht einen SRV-Eintrag in DNS. Hier schreibt Frank alles zum Thema Autodiscover, den SRV-Eintrag findest Du da auch: MSXFAQ.DE - Autodiscover

Wenn ich das lese, bekomme ich die Kinnlade nicht mehr rauf. Da laufen dann insgesamt DREI verschieden SQL-Server, diverse andere Applikationen und Nutzerdaten auf EINER Festplatte und EINEM Server. Da sind so ziemlich alle Fehler in Bezug auf Exchange gemacht worden, die man machen kann. Bitte berichte weiter, ich brauche solche negativ Erfahrungen, um Kunden die teilweise sehr merkwürdigen Wünsche auszureden. :)

Danke Nils, für die Ergänzung. Beim Server 2012 habe ich mir das noch nicht angeschaut, das wird dann vermutlich aber auch erst mit Ex 2013 sauber funktionieren.