RobertWi

Nett, dass da nun eine Antwort steht, aber niemand mehr weiß, was mal die Frage war. So ist der Beitrag für Leute, die ein ähnliches Problem haben, quasi nutzlos geworden. :(

Korrekt, konnte ich aber nicht teste, habe ich nur zusammenkopiert.

Ist das wirklich so schwer? $smtp2 = "smtp:" + $name + "@test.com" Set-DistributionGroup $Name -emailaddresses @add{$smtp2} -EmailAddressPolicyEnabled $false

Moin, wenn er Dir schon sagt, dass das Prefix fehlt und Du das als korrekt erkennst, warum gibst Du es nicht an? -> "smtp:alias@test.com"

moin, 5 und 6 sind vertauscht. Falls das bei 8 der ex 2010 ist: Server mit installiertem Exchange dürfen nicht umbenannt werden. Und wahrscheinlich fehlen viele Kleinigkeiten, aber im groben kann man das so machen.

Ok, sieht mal wieder danach aus, als würde sich ein Dienst nicht schnell genug beenden. - Öffne die Dienstekonsole, sortiere nach Starttyp und versuch möglichst viele von den Exchange Diensten zu sehen (Achtung, es gibt noch zwei, die nicht mit "Microsoft" beginnen: Formularbasierte Authentifikation und Geschützter Exchange Dienst Host). - Starte das Setup erneut und schau Dir an, bei welchem Dienst "Wird beendet" erscheint, aber nicht verschwindet. - Warte, bis das Setup abbricht, dass müsste dann eigentlich dazu führen, dass alle Dienste wieder laufen - Beende den/die Dienste, die Du oben ermittelt hast, von Hand, warte bis sie beendet sind und versuch dann die Installation noch mal

Moin, wie führst Du die Installation aus? Bist Du Admin, ist die Datei als Sicher markiert? Ist die Execution Policy korrekt? Greift ein Virenscanner ein? Ist das MSI-Logging aktriviert und bringt mehr Erkenntnisse?

Ja, die meinen wir. und da gibt es zentrale und dezentrale Produkte.

Ich meinte natürlich Mail Disclaimer, nicht den Signature Manager. Der hängt die Signatur drunter, egal, wie die Mail erstellt wurde und ändert auf Wunsch auch die Mail in den gesendeten Objekten. http://www.exclaimer.de/mail-disclaimers/

Moin, schau Dir Exclaimer an, mit Bordmitteln wird das nichts. Allerdings weiß ich nicht, ob man da die Administration delegieren kann.

Eine genauere Angabe, was nicht funktioniert, wäre eventuell hilfreich. Na ja, und ansonsten ist das halt Ex 2013. Da wurde gerne mal was aus unerfindlichen Gründen geändert, was seit Jahren problemlos klappte. Kann ich mir allerdings schwer vorstellen, weil die DiscoverSearchMailbox geöffnet werden kann, wenn man der Gruppe Discovery Management angehört.

Moin, grundsätzlich funktioniert die Berechtigungsvergabe auch mit Gruppen. Allerdings weiß ich nicht, ob Exchange darin Verschachtelung auflösen kann. Also probier es doch zuerst mal nur mit einer Ebene aus.

Moin, diese Änderungen werden bis zu 2 Stunden gecacht. Und nicht vergessen, dass der User sich abmelden und neu anmelden muss, wenn Du ihn in die Gruppe steckst.

OK. Lag eventuell auf dem alten 2003 der Dateifreigabezeuge? Dann müsstest Du vorher einen neuen festlegen.

Das mit dem Port ist unglücklich und IMHO falsch, aber dann nicht schädlich.

Moin, hat der schon mal funktioniert? Und wenn ja, was ist passiert/verändert worden? Was steht in der Log-Datei, die im zweiten Quote erwähnt wird?

JA, da ist die Frage wieder. Diesmal 6 Tage, seit der letzten.... Kurz gesagt: Du musst höchst normalerweise gar nichts ändern, weil Strato schon TLS macht und Exchange auch. Und in Deinem Protokoll sieht man auch, dass TLS benutzt wird. Die lange Form gibt es hier: http://www.mcseboard.de/topic/197229-eigener-exchange-ssl-umstellung/ http://www.mcseboard.de/topic/197179-sbs2011-tls-ssl-beim-provider-t-online/ http://social.technet.microsoft.com/Forums/de-DE/4752b649-f172-4608-9405-73017dbae1e4/umstellung-smtpport-auf-465-smtps?forum=exchange_serverde Wenn Du wirklich sicher gehen willst, musst Du einen Netzwerksniffer zwischen Exchange und Strato hängen. Nachtrag: Das mit den Port in dem Connector ist übrigens falsch. 587 ist Client-SMTP und das wird vermutlich wirklich nicht gehen. Server-SMTP mit TLS ist Port 25, ganz normal. BTW: Strato wird garantiert nicht auf zwingend Verschlüsselung bei SMT-TLS umstellen können. Es gibt Millionen Mailserver, die gar keine Verschlüsselung können, die man damit aussperren würde. Nachtrag 2: Franks Artikel muss man sehr genau lesen und sollte nur von Leuten verwendet werden, die GENAU wissen, was sie tun. Ein RequireTLS falsch angewendet, kann den Server sehr einsam machen. Aber das schreibt er da auch so.

Moin, vermutlich läuft da sonst noch was auf der Kiste, was einen Webservice anbietet. Das muss ja nicht zwingend im IIS sein, es kann auch ein Apache oder Tomcat sein. Und zum Testen wollte des Du mal den WinRM-Dienst stoppen und sehen, ob dann die Default Website startet (Exchange Konfig geht allerdings dann auch nicht, weil der WinRM braucht). Ich habe schon erlebt, dass WinRM falsch konfiguriert wurde.

Ich bin gespannt, was da später rauskommt.

Ich denke das Problem bei IT ist, dass die Leute immer noch glauben, dass das ganz einfach ist. Hier ein wenig klicken, hier ein wenig tippen -> scheint zu laufen. Aber ob es das wirklich tut, merkt man erst, wenn es Probleme gibt. Die Leute kommen doch am Auto auch nicht auf die Idee, die Bremsschläuche durchzuschneiden, weil das Fahrzeug doch ohne auch offensichtlich problemlos fährt.

Moin, offiziell kann man die Geschwindigkeit nicht erhöhen. Man kann zwar die Anzahl gleichzeitiger Verschiebevorgänge über eine .config-Datei ändern, aber nicht die Geschwindigkeit. Allerdings würde ich an Deiner Stelle mal ins Protokoll schauen. Das kann man auch während des Verschiebens öffnen und sieht dann, wo der Vorgang gerade steht. Ich tippe mal darauf, dass er bei fehlerhaften Elementen in Time Outs läuft. Na ja, und wenn das viele sind, sieht es am Ende so aus, als wäre der Vorgang insgesamt langsam.

Jetzt, wo ich nachschauen konnte, würde ich Dir da eine "1" empfehlen. Da es kein "Unlimited" gibt, dürfte "0" im Ernstfall für unendlich stehen. Aber warum spielst Du das nicht mal in einer Testumgebung nach? Oder machst eine Sicherung, die Du notfalls wieder zurückholen kannst?

Wenn ich so etwas lese, weiß ich nicht, ob ich weinen oder lachen soll. Weinen über ein Systemhaus, dass durch Inkompetenz glänzt, den Kunden abzockt und dadurch schlussendlich den gesamten Bereich der Dienstleister runterzieht. Verbunden mit Entscheidern (westie, damit meine ich nicht dich!), die sich blenden lassen und offensichtlich Ihren eingestellten und teuer bezahlten Leuten nichts zutrauen. Oder soll ich lachen, weil ihr damit in die Kategorie Kunden fallt, die irgendwann ihr System so gegen die Wand fahren, dass sie dann doch endlich mal richtige Fachkundige Unterstützung holen (Leute wie Norbert oder mich) und dann bereit sind, endlich angemessene Preise zu zahlen. Auch bei Dienstleistungen gilt i. d. R. der alte Spruch: Wer billig kauft, kauft zweimal. Fast wünsche ich mir, dass das bei Euch so richtig knallt und die wichtige Mail mit der 10 Millionen Euro Anfrage nicht ankommt und niemand sich erklären kann, wo die geblieben ist (ok, WIR wissen es ja). Und das dann die Chefs mal Rückrat beweisen und das Systemhaus für Ihren Beratungsmüll in Regress nehmen. Aber wahrscheinlich ist der einzige, der den Ärger abbekommt, der arme westie. westie, noch was für Deine Argumentekiste. Ärgerlich ist das hier: Diese Aussage ist FALSCH. Einfach nur falsch. Es gibt kein Header-Feld, in dem verbindlich der RCPT TO-Empfänger gespeichert wird. Und wird es auch nie geben, weil es nicht notwendig ist. Es gibt nur zwei Dinge: - Systeme, die sich strikt an den Standard halten und die NICHTS protokollieren (dazu gehört Exchange, kann jeder im Header einer Mail nachprüfen und zeige ich immer wieder gerne Kunden direkt mit telnet) - Systeme, die in irgendein, vollkommen ungenormtes Feld den RCPT TO schreiben. Das führt dann bei POP-Connectoren zu dieser lustigen Auswerte-Aktion.

Moin, wie Du am Gerät angemeldet bist, ist egal. Die Anmeldung muss bei SMTP erfolgen und das macht die Anwendung, die SMTP benutzt. Schau in das SMTP-Protokoll (eventuell vorher auf allen Empfangsconnectoren aktivieren). Darin kannst Du sehen, welcher Connector sich angeprochen fühlt und wie der Fehler lautet: http://www.symantec.com/business/support/index?page=content&id=HOWTO92299 http://serverfault.com/questions/269472/where-can-i-find-logs-of-emails-sent-from-an-exchange-relay

Moin, es gibt keinen eindeutigen "Best-Practise" für Zertifikate. Wenn es einen gäbe, würdest Du ihm Internet finden. Was umgesetzt wird, hängt vom Geld, Zeit, Geräten, DNS, Proxy und Wünschen ab. Und leider gehört auch Wissen dazu. Zum Beispiel das Wissen, dass Outlook mehrere Verbindungen zum OAB und EWS über HTTPS herstellt - immer. Exchange-Technisch ist es bei Dir wahrscheinlich das beste, wenn Du SpltDNS einsetzt und die URLs für intern und extern auf den gleichen Wert setzt. Dann funktioniert allerdings Autodiscover für mobile Geräte nicht fehlerfrei, hierfür bräuchtest Du ein SAN-Zertifikat, in dem auf die feste Autodiscover-URL enthalten ist. Wenn Dir jetzt schon der Kopf bei den Begriffen raucht, wäre das Hinzuziehen eines externen Beraters eventuell die effektivste Lösung. Ansonsten wirst Du sehr viel Zeit zum Lesen und Durchdenken brauchen. Ein guter Anfang (aber längst nicht vollständig) ist hier: http://www.msxfaq.de/howto/e2k7ssl.htm http://www.msxfaq.de/signcrypt/sancert.htm http://www.msxfaq.de/konzepte/namenswahl.htm