Alle Aktivitäten

Hab ich auch mal gemacht, aber nur, weil der Kunde zu Exchange 2003 sollte. Und den ADC gabs nur für Exchange 5.5. Aber von 5.0 auf 5.5 ging ja so wie heute per Inplace ;) Sowas hab ich auch 2004 oder so gesehen. War keine Hochschule, sondern in der Wirtschaft kombiniert mit einem komischen Domänenkonstrukt und eDirectory ;)

Moin, ein früherer Kunde von mir kokettierte Anfang der Nullerjahre immer mit der Feststellung, dass seine User immer noch den Exchange Client 4.0 einsetzen würden. Dazu Schedule+ (was er so vorlas, also "scheduhle-plus") für den Kalenderzugriff. Zu dem Zeitpunkt lief auf dem Backend "schon" Exchange 5.0. Den haben wir per Holzhammer da wegmigriert, weil der Rest der Umgebung auch so war - also neue Domain und PST-Import. Das war immerhin eine Hochschule. Wenn auch eine ziemlich kleine. Gruß, Nils

Meine erste Migration (mit Teilweiser Bauchlandung…) war von 5.0 nach 5.5 Lief alles noch unter NT

Meine erste Migration war nach Exchange 4.0. Aber ich würde meinen, 5.0 habe ich nie angefasst. 5.5 dann um so mehr.

Ja, aber da hieß es MSMail ;) Wenn man das als Vorläufer bezeichnen mag. Wobei ich keinen persönlich kenne (glaube ich jedenfalls), der vor Exchange 5.0 schon mit MS Mailprodukten zu tun hatte.

Fehlen da nicht vier Monate bis zum 02. April 2036? Oder gab es noch etwas vor Exchange 4.0?

Wie kommst du auf die 40 Jahre? Als EoS Datum steht da 31.12.2035, also 10 1/2 Jahre. Oder kapiere ich den Witz nicht?

Dann geht Exchange on Prem mit mir in Rente

Moin, Wie @MrCocktail auf LinkedIn gepostet hat hier der Lifecycle von Exchange SE https://learn.microsoft.com/en-us/lifecycle/additional-support-server-modern-lifecycle-policy Also werden wir 40 Jahre Exchange bekommen…

Hi, welche Einstellungen hast du denn da genau per GPO konfiguriert? Verlinke die doch ggfs. kurz von Group Policy Search. Die Benutzer melden sich später mit ihren "ganz normalen Konten" am Gerät an und nach der Abmeldung soll das lokal erstellte Profil gelöscht werden? Zusätzlich sind für den "normalen Betrieb" Roaming Profiles im Einsatz, die genau nicht auf dem Suface Go genutzt werden sollen? Gruß Jan

Hallo zusammen, Meine Problemstellung: Mehrere Benutzer sollen sich temp. auf einem Client (Surface GO) anmelden ohne Profil Sync. aber die Standard GPO sollen dennoch wirken damit sie auf den Druckserver zugriff haben. Ich habe bereits ein System mit folgenden GPO versehen: - Temporäres Konto - Löschen des temp. Profils nach abmelden Mein Problem ist gerade das wenn ich die GPO auf das Gerät anwende, den Benutzern es nicht möglich ist über klick auf Benutzer sich abzumelden. Habt Ihr evtl.. eine Lösung außer mit einem Code Schnipsel per Doppelklick auf dem Desktop. Danke

Moin an Board, dann wollen wir mal - ich koche Kaffee Bergfest! Allen einen angenehmen Mittwoch, bleibt gesund! Hier derzeit klar bei 15°C, es wird ein meist sonniger Tag bis etwa 21°C

Ist mir bisher auch auf keinem der Geräte/Server aufgefallen. Sollte was sein, dann würde ich mal genauer nachschauen. 👀

genauso wie bei mir leider

Hi, wie sieht denn der (ganz) genaue Mailflow aus? Nicht das dort noch irgendwas zwischen steckt, was auch noch irgendwie in SMTP / E-Mail reingrätscht. Gruß Jan

Die Meldung kommt jedenfalls nicht von den exchange eigenen Transport Agents. WEnn Avast raus ist (disable-transportagent) einfach mal testen. Im Logfile des Exchange Servers muss das dann aber eben auch auftauchen.

Avast Premium Business Security

Welches Produkt?

Aber woher dann? Ich hatte testweise den AV bzw. den Transport Agent von unserem AV Programm deaktiviert und auch deinstalliert.

Moin an Board, auf geht’s in den Tag - ich koche Kaffee Allen einen guten Dienstag, bleibt gesund! Aktuell leichte Bewölkung bei 15°C, später kommt die Sonne durch bis etwa 21°C Kurze Schauer erwartet gegen 18:00h

Nein, bestimmt nicht…

Danke, Norbert, für die ausführlichen Infos. Dank dir und den Links habe ich heute viel neues dazu gelernt. jetzt lese ich mir erst mal alles nochmal genau durch. Einen schönen Tag wünsche ich dir

Ja und nur bei diesem Zertifikat/VDir. Dem selfsigned Zertifikat werden SMTP und die Backendseite zugeordnet (für SMTP ist das das DEFAULT Zertifikat, man beantwortet die Frage also mit Ja) Dem externen Zertifikat kannst du SMTP, http und imap und pop zuweisen. Für SMTP ist es NUR dann zuständig, wenn im Empfangs-/Sendeconnector auch ein Name im HELO String steht, der im Zertifikat auftaucht. Also NICHT im Defaultconnector. Die Frage bei der SMTP Zuweisung beantwortet man also in dem Fall mit NEIN (außer man weiß sehr genau was man tut und warum). Egal, was einfacher für dich ist. IMAP ist für den Empfang nicht für den Versand. Welches Zertifikat du nutzt hängt davon ab, welchen Namen du im CRM System hinterlegt hast (lokaler Exchange oder der Name des externen Zertifikats) und ob dein CRM das ggf. akzeptiert, wenn es dem Zertifikat nicht vertraut. IMAP und SMTP laufen weder über Default noch Backend-Webseite, weil es keine Web-Protokolle sind. ;) Bye Norbert

da hast natürlich recht, das ist schon ein Unterschied. Also, wenn ich das per Powershell anlege, kann ich hinterher ins IIS gehen und dort dem Back End bei Bindungen zuweisen? ich habe das nun per Powershell angelegt. Ja, hier sind es 5 Jahre. Nun noch 3 Fragen bitte, dann kann ich mal damit arbeiten: 1) Welche Dienste müssen/sollten dem self-signed Zertifikat und dem externen Zertifikat zugewiesen werden? 2) Die Zuweisung der Dienste dann per EAC oder Powershell? 3) Wir haben ein CRM-System, mit dem man per IMAP eMails schicken kann. Da ist natürlich der Exchange als IMAP/SMTP-Server eingetragen. Welches Zertifikat ist hierfür verantwortlich (self-signed oder das externe), und läuft das über Default Web Site oder Back End und es sind hier für die Dienste IMAP/SMTP notwendig? Ich danke dir für deine Zeit und Expertise

Deswegen hab ich dir ja auch den Powershellbefehl hingeschrieben und gesagt machs per Powershell weils logischer ist als diese Klickorgie. ;)