RobertWi

Die Hierarchie ist eindeutig und gilt für alle Exchange-Server in der Exchange-Organisation. Du könntest dann auch auf dem neuen Exchange nicht mehr auf die PF zugreifen.

Weil T-Online gerade extrem Stress macht, dass ab April User nur noch mit SSL und Port 465 senden können und Exchange-Admins jetzt Panik bekommen, dass das auch sie betrifft. In Microsoft-Forum gibt es zwei bis drei Anfragen pro Woche damit. Also auch hier noch mal: Angepasst wird Client SMTP, nicht Server SMTP. Wer als Client bei T-Online direkt einliefert muss was ändern. T-Online spricht wie Exchange auch TLS aus Port 25. Siehe auch hier: http://social.technet.microsoft.com/Forums/de-DE/7ee5e102-44b8-40aa-b67e-f8eb12b5cf66/windows-2008-sbs-exchange-server-umstellen-auf-ssl-beim-versenden-von-email-umstellen?forum=exchange_serverde http://social.technet.microsoft.com/Forums/de-DE/4752b649-f172-4608-9405-73017dbae1e4/umstellung-smtpport-auf-465-smtps?forum=exchange_serverde

Es gibt in diesem Fall aber kein ESM mehr... :P

Moin, wobei in dem Artikel mit ADSIEdit nur der RUS entfernt wird, nicht der Server. Server ist z.B. hier beschrieben: http://blog.dargel.at/2012/02/23/remove-legacy-exchange-server-using-adsi/ WICHTIG: Innerhalb der alten administrativen Gruppe auch den Container CN=SERVERS entfernen, aber auf KEINEN FALL die administrative Gruppe selbst, sonst droht ein Verlust der Public Folder: http://www.mcseboard.de/topic/191320-erste-administrative-gruppe-nach-migration-mit-adsi-edit-gel%C3%B6scht/

Und von welchen "Diagnose Logs" redest Du? Exchange kennt ungefähr ein Dutzend Logs an verschiedenen Stellen.

Sorry, stimmt. natürlich. Ist ja auch in Example 2 von Norberts Link. Ich habe beim Arbeiten nur halbgelesen und war gedanklich bei einem vollkommen anderem Thema.

Was hat "A-G-DL-P" mit fehlenden Werkzeugen zur Dokumentation und einfacher Verwaltung zu tun? Irgendwann sind die Grenzen von ADUC, Freigabe-Manager und Excel-Dateien erreicht und spätestens wenn ITIL ins Spiel kommt, muss man quasi zwangsläufig auf Dritt-Anbieter zurückgreifen. Aber das war jetzt nicht Thema hier.

Diese Regkey gibt es schon seit mind. Exchange 5.5.. Eventuell meinst Du die Throtteling Policys, die sind neu bei 2010: Klick. Allerdings protokollieren alle diese Einschränkungen ihr Überschreiten im Eventlog und sollten nur angepasst werden, wenn man entsprechende Fehler auch hat und sieht.

Das ist allgemein vollkommen klar. In der IT-Sicherheit kann es schon per Definition keinen Stillstand geben. Wir sind immer nur "Verteidiger" und haben Angreifer gegen uns, die über eine theoretisch unbegrenzte Zeitmenge verfügen. Es wird daher nie eine vollkommen sichere Umgebung geben, und man darf sich nie ausruhen. Ist schon kein Problem. Aber irgendwo muss man anfangen. Wie oben schon gesagt: Prinzipbedingt sind die Zäune immer zu niedrig. FIM hatten wir schon beleuchtet und erfüllte mehrere Wünsche nicht und war damit zu teuer. Für Berechtigungsmanagement wird zur Zeit "8MAN" angeschaut. Auch eine Baustelle. Was nützen die besten Passworte, wenn niemand einfach nachvollziehen kann, wer wo Berechtigungen auf diversen TB Storage mit 5000 bis 6000 Freigaben hat. Sieht auf den ersten Blick auch interessant aus.

Ja. "Aufgeweckt" wurden meine Cliente-Betreuer, als beim diesjährigen Premier-Auftakt ein Microsoft-Sicherheitsmensch erklärt, dass bei so gut wie allen gehakten ADs, die sie gefunden haben, PtH im Spiel war. Vollkommen korrekt. Natürlich wäre es perfekt, wenn man ein Tool hat, das alle Aspekte erfüllt. Aber selbst wenn man weiß, dass man einen Aspekt mangels Werkzeug zuerst mal nur organisatorisch und mit Disziplin erfüllen kann, heißt das nicht, dass man die anderen Aspekte deswegen komplett ignorieren kann. Der Sicherheitsbeauftragte hier fährt da ein ziemlich gute Linie: Anstelle eines massiven Stahltor und dann links und rechts einen kaputten Jägerzaun, lieber ein nicht ganz so gutes Tor, dafür aber insgesamt einen besseren Zaun. Da ist das Passwort- und Berechtigungskonzept ein Baustein und ich erstmal mit der Aufgabe dabei, überhaupt die Möglichkeiten zu evaluieren. Prima. Danke für den Link, sieht auf den ersten Blick gar nicht schlecht aus.

Das mit den TAPs scheint in diesem Jahr wirklich schiefgelaufen zu sein und wenn Du die letzten Mails der PG bzgl. des TAP-Programms richtig liest, scheint Microsoft da auch sehr unzufrieden zu sein. Wenn ich das richtig mitbekommen habe, waren es jedesmal MVPs, die bei CU3 und SP1 im letzten Augenblick Show-Stopper fanden, die die Auslieferung verzögerten. Das im TAP-Programm nicht bemerkt wird, dass man mobile Geräte nicht an neue Postfächer anbinden kann, wenn mehr als ein DC in der Site steht, kann ich immer noch nicht glauben.

Und Symantec scheint sich einzureihen. Auch hier wurden Probleme mit dem Virenscanner gemeldet. :(

Moin, danke für die rege Beteiligung. Ich hatte aufgrund der komplexen Fragestellung weniger befürchtet. ansehen werde ich mir das ganz sicher. Es sind ja auch "kleine" Lösungen mit Scripten denkbar. Nicht "meist", sondern "auch". Bei einem Server-/Client-Dienst würde ich hier gar keine technischen Schwierigkeiten sehen. Wenn der Server nicht erreichbar ist, wird das Passwort nicht geändert und landet auch nicht neu in der zentralen Datenbank. Damit sind dann die PW in DB und Client synchron, nur nicht so oft geändert. Das spielt aber auch keine Rolle. Wichtig ist zuerst, dass die Hashes auf den einzelnen Clients unterschiedlich sind. Da ist es erstmal egal, ob das Passwort 1 Tage oder 1 Monat alt ist - es soll nur anders sein, als bei den anderen Clients. Und mehr oder weniger regelmäßig geändert werden. Benutzerservice, eventuell auch lokale Systembetreuer. Diese haben keine weiteren Privilegien in Domäne oder Memberserver. Admins -> nie, aber es gibt halt auch kein Prinzip, dass das verhindert. In diesem Punkt geht es also nicht um 100%ige Sicherheit, sondern nur um Risiko-Senkung. Das Risiko, dass sich ein Trojaner, der PtH-Attacken fährt wird verringert, wenn Admins-Accounts auf den verschiedenen Clients andere PW haben. Und damit sinkt das Risiko, dass im Falle einer unerwünschten Admins-Anmeldung genau auf diesem Client ein Trojaner den Hash mitbekommt. Systemaccounts lassen wir mal bewusst außen vor. Natürlich sind Accounts für Virenscanner-, Softwareverteilung und Systemmanagement ein sehr hohes Risiko. Bei den lokalen Admins-Accounts geht es ja nicht nur um PtH. Wenn Kennwörter auf den Rechner überall gleich sind, sprechen die sich auch mal rum. Auch dass soll ja verhindert werden. Service-Accounts müssen davon getrennt, für jede Anwendung einzelnen untersucht und im Sinne des "Least Privileges" angewendet werden. Aber ich denke, nur weil man einen Punkt hat, der man als Risiko schlecht eindämmen kann, sollte man nicht alle anderen deswegen vernachlässigen. Vollkommen klar. Aber Sicherheit ist eben nicht nur ein Schalter, sondern besteht aus vielen Bestandteilen. Mir ging es hier explizit um lokale Admins-Accounts. Weiß ich. Ist aber deutlich komplizierter. Sicher, aber wie gesagt nur der zweite Schritt. Im ersten müssen die PW unterschiedlich sein. Und schon das ist schwer genug, umzusetzen. Beispiele? Wenn Du Angst hast, Namen zu nennen (was bei einer solchen Fragestellung i.d.R. kein Problem ist, denn ich frage ja explizit nach Anbietern), schick mir eine PM. Cursor in das Zitat stellen und mehrfach die Entertaste drücken. Zuerst kommen Leerzeilen, danach unterbrichst Du das Zitat.

IMHO gibt es keine Grenze, nur die Beschränkung "Items per Folder". Bis 10 GB -> i. d. R. vollkommen problemlos Bis 30 GB -> öfter mal Schwierigkeiten, wenn Postfächer ohne Cache Mode im gemeinsamen Zugriff sind; mit Cache Mode eher wenig probleme Für alles darüber hast Du oben schon die Infos selbst gepostet Siehe meine Antwort davor. Probleme verschwinden i.d.R., wenn das zusätzliche Postfach als echtes, natives Exchangekonto inkl. OST-Datei benutzt wird. Smartphones sind aus Exchange-Sicht egal, die haben ihre eigenen Grenzen. Normalerweise ist das bei einem korrekten EAS-Client aber egal, da dort nie das gesamte Postfach heruntergeladen wird, sondern nur der Ordner, den der User gerade öffnet. Was er nicht öffnet, landet auch nicht auf dem Smartphone.

IMHO ist die Meldung keine Systemmessage und nicht anpassbar.

Wobei Kaspersky dabei unschuldig ist. Natürlich wäre es schön, wenn Kaspersky das selbst erkennen würde, aber die korrekten Ausnahmen bei den Suchen einzustellen, ist normalerweise Aufgabe des Admins.

Der ist doch direkt im Post #43 über Dir, oder?

Der Transport-Teil scheint in Ex 2013 wirklich grundlegende Änderungen bekommen zu haben, dass der so oft in Problemen auftaucht. Ein Kunde hat mir beim Erscheinen von CU 3 erzählt, dass er einen Transport-Agenten programmiert hat und dieser mit jedem Update immer wieder angepasst werden musste. Die Schnittstelle für den Agenten wurde jedes mall, ohne Dokumentation und ohne ersichtlichen Grund verändert.

Ein Fehlerbericht: MVP-intern wurde festgestellt, dass Exclaimer mit SP 1 nicht mehr sauber zusammen läuft (hatten wir IMHO nach einem RU schon mal). Problem ist aber wohl schon bekannt und wird analysiert.

Moin, bei uns ist eine interessante Frage aufgetaucht, anlässlich einer Präsentation zu "Pass-the-Hash"-Angriffen. Gegeben sein, dass auf den Client-PCs lokale Admins-Konten existieren. Das Benutzen von Domänen-Konten ist nur begrenzt möglich, weil Notebooks auch ohne Netzwerk administrierbar sein müssen. Und gegen sei auch, dass ein komplettes Deaktivieren von LM/NTLM oder der Einsatz von Multi-Faktor-Authentifikation aufgrund externer Abhängigkeiten nicht flächendeckend umsetzbar ist. Die lokalen Konten werden via Gruppenrichtlinien erzeugt. Gewünscht wird ein lokaler Admin, der aber auf den PCs unterschiedliche Passwörter hat, z.B. ein Standard-PW plus dem Computernamen. Alternativ auch eine "Datenbank" in der die PW stehen. Und so richtig schick wäre es, wenn die lokalen PW z.B. dort ein lokales Programm, auch noch regelmäßig geändert würden (z.B. durch Ergänzung der Kalenderwoche). Wurde jemand schon mal mit einer solchen Aufgabe konfrontiert? Was könnten Lösungen sein - Dritt-Anbieter und Scripts eingeschlossen.

Moin, das macht Exchange bei Erreichen der Warnstufe eigentlich ganz von alleine.

Wenn Du mein oben 1:1 kopiert hast, fehlten einmal Anführungszeichen. Ein wenig Mitdenken wird seitens des Fragestellers schon erwartet. ;) Ich habe das oben so korrigiert, dass Du es nun 1:1. kopieren können solltest.

Dann hast Du im Befehl irgendwas vergessen, meist eine schließende Klammer oder schließende Anführungszeichen.

Wusste ich schon immer und das in meiner Signatur ist definitiv eine Falschaussage..... :P

Da ist ein Fehler im Technet-Artikel. Muss heißen: Get-User -Filter {Department -eq "Abschnittsleiter"} | Set-Mailbox -SharingPolicy "Kalender Freigabe AL" (oder auch Get-Receipient)