RobertWi

Moin, doch, das hat schon ein wenig geholfen. Folgende Schritte: - Sicherstellen, dass das Konto nicht gesperrt ist - Sicherstellen, dass das Konto nicht deaktiviert ist - Kennwort zurücksetzen - lokalen Kennworttresor auf dem SBS (hierfür muss man als der User angemeldet sein) komplett leeren - die MMC-Dateien aus dem Userprofil nochmal löschen - abmelden und neu anmelden

Moin, nein, das ist neu bei Exchange 2013 und korrekt so. Siehe auch hier: http://blogs.technet.com/b/exchange/archive/2013/01/25/exchange-2013-client-access-server-role.aspx (Abschnitt "Outlook Connectivity")

Die kleine grüne Fahne ist jetzt ein kleiner grauer Stern.

Moin, melde Dich mal als der User an und geh nach: C:\Users\USERNAME\AppData\Roaming\Microsoft\MMC darin findet Du Dateien die mit Exchange beginnen (und eventuell Public Folder *). Diese löschen und die EMC danach starten.

Moin, Outlook Regeln sind auch ein beliebter Mailverschieber. und was genau steht denn in der Nachrichtenverfolgung?

Moin, ja, die waren schon bei Exchange 2010 überflüssig und wurden nicht mehr verwendet. Bei Exchange 2013 gibt es sie daher nicht mehr.

Ja, die kannst Du ja ändern. Allerdings würde ich mich fragen, warum die NDR erhalten. :)

Dann musst Du die Frage stellen, woher die internen die NDR bekommen. Wenn sie die von externen Servern bekommen, sind die Meldungen zu 99% von diesen Servern bestimmt. Stell's halt ein, wundere Dich aber nicht, wenn es nicht alle Meldungen erreicht.

Moin, schaust Du hier: get-help new-SystemMessage -Detailed Nachtrag: Aber die Nachricht sehen ja i.d.R. nur extern, und was interessiert die, ob das Ding bei Euch Help Desk oder Service Desk heißt?

Moin, ich fürchte, dass wirst Du ohne externe Hilfe dann nicht gelöst bekommen, eventuell sogar nur mit Unterstützung des Microsoft-Supportes. Normalerweise würde ich das so machen: - Maschine platt machen - Metadatacleanup und die Rest vom neuen DC zu löschen - ADSIEDIT, um die Rest der missglückten Exchange-Installation zu löschen Das Problem ist: Alle Schritte kannst Du durch DEINE Rettungsversuche nun auch nicht mehr machen. Du hast nun einen halben Exchange drauf, den Du auch supported nicht mehr los wirst. Und Du hast Rest des DC in AD, die Reste der 2 Exchange-Installationen in AD, usw. Auch wenn wir noch ein wenig weiterbasteln: Früher oder später knallt es das nächste Mal. Exchange verzeiht keine Fehler und Exchange vergisst auch keine. Ergo: Das übersteigt die Möglichkeiten eines Forums, dass muss sich jemand mit wirklich Ahnung vor Ort ansehen. Und ein allgemeiner Tipp: Wenn die Agenturmanagment-Software so teuer ist, würde ich die NIEMALS mit irgendwas anderem zusammen auf einen Server packen - und schon gar nicht mir Exchange. Ein fehlgeschlagenes Exchange-Update kannst Du bei guter Vorbereitung in 30 Minuten beheben - mit Neuinstallation des Servers. Eine so wichtige Software gehört unbedingt auf ein eigenes Gerät. Und Geld kann dann keine Rolle spielen, sonst ist die Software nicht so wichtig.

Prima, danke für das Feedback.

Wir brauchen auch Hilfe, z.B. ein klein wenig mehr Infos über die Umgebung.

Moin, die Mail-Adresse, die Du im Telnet benutzt, ist ungültig. Bitte verwendet dort zum Testen eine gültige Adresse, am besten erst mal eine, die intern auch existiert. Danach kannst Du mit einer "fremden" probieren.

Und was genau ist denn das Problem? Nach der Beschreibung funktioniert doch alles?!

An dieser Stelle spielt Exchange keine Rolle, weil die Daten ja vom IIS kommen. Die entsprechende Konfig ist daher im IIS zu machen. Das Senden könnte man einschränken, in dem man den IIS entsprechend konfiguriert: http://technet.microsoft.com/de-de/library/aa996835(v=exchg.141).aspx Gilt aber nur pro Anlage, mehrere sind als möglich. Schwieriger wird das mit dem Empfangen. Da habe ich auf die Schnelle nichts gefunden. Eventuell geht das über die Anforderungsfilterung.

Wasch mich, aber mach mich nicht nass. Na ja, manche Entscheider brauchen erst einen richtigen Crash, bevor sie kapieren, dass IT heutzutage genauso zum Unternehmen gehört, wie die Produktionsmaschine in der Halle. TLS steht für "Transport Layer Security" uns ist eine Verschlüsselung auf Ebene von SMTP. Hierbei kann zwischen einem Client und einem Server oder auch zwischen zwei Servern verschlüsselt sein. Es ist aber eine reine Verschlüsselung, d.h. es ist keine gegenseitige Authentizität enthalten. (Es gibt hier zwar Domain-Security, aber das bezieht sich auf zwei genau definierte Partner.) Siehe hier: http://www.msxfaq.net/spam/filter-tls.htm Siehe hier: http://www.msxfaq.net/signcrypt/gateway.htm Bei Frank findest Du auch ein Produkt, da seine Firma selbst eines vertreibt.

Moin, schau Dir die Hilfe an: get-help Set-OwaMailboxPolicy -Detailed Da ist alles drin, eine Größenbegrenzung für Anhänge habe ich nicht gefunden. Willst Du die Größe von Anhängen bei SENDEN (also den Upload) oder beim EMPFANGEN (also den Download) begrenzen?

Vernünftige Verschlüsselung bekommst Du nicht umsonst. Sie kostet entweder Zeit und/oder Geld. Das ist grundsätzlich korrekt. Allerdings geht Ende-zu-Ende-Verschlüsselung auch nur, wenn der Empfänger ein Zertifikat hat. Du brauchst für Deine Leute ein Zertifikat (nicht vertrauenswürdige kannst Du selbst bauen und einfach per AD verteilen, für vertrauenswürdige brauchst Du normalerweise das zutun des Benutzers). Viele Firmen gehen daher eher dazu über, zentral Lösungen über eine Gateway zu machen. Das hat den Vorteil, dass man die Schlüssel nur einmal hinterlegen muss. Aber es ist eben keine echte Ende-zu-Ende (was machmal auch nicht verkehrt ist, weil Vertreter bei Ende-zu-Ende ausgesperrt werden). Verschlüsselung auf dem Transport-Weg wäre TLS, was relativ einfach einzurichten ist. Das ist dann aber nur SMTP, und wieder nur, wenn die Gegenseite mitspielt. Bei dem Kostenrahmen lohnt es sich kaum, weiter nachzudenken. Vernünftige Lösungen bekommst Du dafür nicht.

Moin, na ja, Du kannst ja nur sinnvoll verschlüsseln, wenn die gegenüberliegende Seite mitspielt. Was wäre Dir denn lieber? Verschlüsselung im Transportweg? Organisation-zu-Organisation-Verschlüsselung? Ende-zu-Ende-Verschlüsselung?

Mit gar keinem. POP-Connectoren sind Mist und machen meistens mehr Probleme, als sie lösen. Ich kann mir nur einige sehr wenig Fälle vorstellen, wo sie sinnvoll sind. STMP-Zustellung. Eine POP-Connector sollte auf keinen Fall Spam-Filterung vornehme, sonst gibt es erst recht böse Fehler.

Moin, im kurzen - vermutlich nicht kompletten - Überblick: CAS: - Zertifikat - vDirs - IIS-Einstellungen HT: - Empfangs-Connectoren

Moin, Das ist korrekt. Der Name stimmt ja nun nicht mehr. Ja. Wobei echte "Self-Signed" offiziell nicht supported sind. Sie funktionieren zwar, aber das kann sich theoretisch mit jedem Update ändern. Eindeutig besser wäre daher ein intern signiertes Zertifikat. Die eigene CA wird dann an die Clients verteilt (GPO) und dann kannst Du beliebig neue Zertifikate ausstellen - ohne auf dem Client was ändern zu müssen. Nein, da der IIS pro IP-Adresse nur ein Zertifikat kennt. Eine zweite IP-Adresse ist extrem aufwendig und beim SBS imho gar nicht erlaubt. Warum dann den Krampf mit selbstsignierten Zertifikaten? Echte Zertifikate mit einem Jahr Laufzeit bekommt man kostenlos, und auch mit mehr Jahren kosten die nicht die Welt (5 Jahre, 59 Euro). Und da Dir Dir ja eh in nächster Zeit Gedanken über einen Austausch machen musst, würde ich mir keinen Stress machen. Kostenloses Zertifikat für ein Jahr und dann in die saubere Planung für SBS 2011 oder Windows 2012 gehen. Und da Du für Exchange > 2003 sowieso zwingend Zertifikate brauchst, musst Du Dir dann eh sinnvolle Gedanken machen, wie Du das sinnvoll machst.

Und prüfe mal DCDIAG auf jedem DC. Die Replikation kann man sehr gut mit "repadmin /showrepl" prüfen.

Moin, im Prinzip hängt das vom jeweiligen Produkt ab, aber in den meisten Fällen sind die ISO vollkommen identisch und werden nur über den Lizenzkey gesteuert.

Moin, lösche mal den Eintrag, der von Outlook vorgeschlagen wird und suche dann erneut aus dem Adressbuch den Eintrag heraus.