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")

 

2. Früher war so eine kleine grüne Fahne neben der Liste von Threads an denen man sich beteiligt hat. Das fand ich ganz nett. Kann das wieder aktiviert werden (Prio3 - geb ich zu)

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?!

Wenn ich bewerbungen@xyz.de testweise auf einen Benutzer schicke, funktioniert alles. Schicke ich auf die interne gruppe personalabteilung@local.int , bekommt der Absender folgerichtig die Fehlermeldung:

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.

Genau sowas hab ich mir gedacht... besser gesagt war mit klar das der Kostenrahmen viel zu gering ist. Leider sind die Personen um die es geht, so gestrickt, dass es sicher sein muss wie Fort Nox aber nicht mehr kosten darf als ein IKEA Lebkuchehaus vor Weihnachten. I

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 ist, soweit ich verstanden habe nur eine Verschlüsselung zwischen Client und Mailserver. Die Kommunikation zwischen Sendemailserver und Empfangsmailserver ist weiterhin unverschlüsselt, bzw. genau so wie sie ohne TLS ist.

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

Diese Lösung klingt interessant, wenn sie Möglich ist zwischen verschiedenen Domänen zu vermitteln. Vor allem würden die Kosten dann bei einem ... also uns... hängen bleiben und müssten nicht weitergegeben werden, was auch erstmal nicht verkehrt ist. Hättest Du da nähere Infos für mich wie sowas heißt?

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.

Ich denke am besten wäre eine Ende zu Ende Verschlüsselung, allerdings habe ich bis jetzt nur Lösungen gefunden wo ich den öffentlichen Schlüssel von jedem beteiligten auf jedem PC installieren muss.

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).

Als Verschlüsselung auf dem Transportweg habe ich bis jetzt DE-Mail gefunden, welches sehr einfach einzurichten und sehr einfach Hand zu haben war, aber "aus Kostengründen" bei einem Mail aufkommen von max. 10 Mails im Monat wohlgemerkt, abgeschmettert wurde. 

Damit ist auch der Kostenrahmen von max. 5€ pro Monat aufgezeigt. 

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?

ich wollte mal nachfragen mit welchem POP3 Connector Ihr die Mails bei den Providern abholt.

Bisher nutzen wir Smartpop2Echange von Jam-Software.

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.

Ich würde aber auch gerne mal eine Alternative kennen.

STMP-Zustellung.

Es sollte eine Virenprüfung, Regeln und ein vernünftiger SPAM Filter enthalten sein.

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,

Ich habe eine Subdomain für die feste IP eingerichtet und wollte bei einem Outlook-Client diese eintragen. Leider erhalte ich dann von Outlook die Fehlermeldung, dass das Zertifikat nicht gültig ist.

Das ist korrekt. Der Name stimmt ja nun nicht mehr.

Wie gehe ich jetzt am besten vor? Einfach ein neues selbsterstelltes Zertifkat auf die neue Sub-Domain erstellen und an alle Clients verteilen?

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.

Kann man übergangsweise das alte Zertifikat weiter nutzen, damit man nach und nach umstellen kann?

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.

Wie verteilt man so ein Zertifikat am besten? Es sind nicht alle (Outlook-) Clients in der Domäne.

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.