Jump to content

Mack

Members
  • Gesamte Inhalte

    56
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Mack

  1. Die holen ihre E-Mails in lokalen Outlooksen per Pop, oder greifen per Imap zu. Perspektivisch kommen allen in den Exchange. Cloud ist von der GF abgelehnt.
  2. Guten Morgen, ich konnte es gestern Abend an dem Platz noch testen und die Mail kommt tatsächlich sauber an. G Data Support sagt, sie kennen diesbezüglich keine Probleme. Bleibt nur noch der Pop Holer, oder ggf. Exchange, was ich aber auch ausschließen würde, da die Mails ja intern sauber laufen. Besten Dank für den Input. 👍 Die Domain ist wild verstreut und der Exchange macht nur einen Teil. Soll aber zukünftig auf SMTP Zustellung umgestellt werden.
  3. Hallo liebe Gemeinde, folgende Situation: - lokaler Exchange 2019 (aktuell gepatcht) - Outlook 2016 (aktuell gepatcht) - Emaildomain wird per Pop3 Holer abgerufen und lokal zugestellt - auf dem Exchange läuft das G Data AV/Spam Plugin - S/Mime Zertifikate werden lokal im Outlookprofil konfiguriert und nicht in einem Gateway Intern zugestellte E-Mails werden beim Empfänger als S/Mime signiert angezeigt, alles ok. Von Extern kommende verschlüsselt und signiert zugestellte E-Mails können entschlüsselt werden und die Signatur wird korrekt angezeigt. Von Extern kommende nur signierte E-Mails werden zugestellt, aber die S/Mime Signatur wird im Outlook nicht angezeigt. Beim Provider ist die Signatur aber noch als Anhang im Webmailer zu sehen. Da das G Data Plugin ja auch bei internen E-Mails durchlaufen wird, würde ich es eher ausschließen. Die leider etwas sparsamen Logs geben da aber auch nichts her, dass da etwas entfernt worden wäre. Der Pop3 Holer (PopCon) ist ja auch schon lange am Markt und dazu habe ich auch keine entsprechenden bekannte Bugs gefunden Schaue ich mir generell den Header einer signierten E-Mail an, wo die Signatur sauber angezeigt wird, steht dort beim wohl relevanten Teil: "Content-Type: multipart/signed; protocol="application/pkcs7-signature";" Bei der "kaputten" E-Mail hier steht dort stattdessen: "Content-Type: multipart/alternative;" Ich bin leider nicht so firm, was hier die technischen Details angeht. Ich habe dazu nur gefunden, dass letztes bedeutet, dass die E-Mail in 2 Teilen vorliegt, dem Text und HTML Teil. Ich kann das aber nicht weiter deuten, auf was das ggf. hindeuten würde. Generell finde ich zu der Problematik, dass digital signierte E-Mails ohne Signatur ankommen leider auch wenig bis nichts. Deswegen hoffe ich, ihr könnt mir ein paar Tipps oder Hinweise geben, was ich noch ausprobieren kann, bzw. in welche Richtung ich recherchieren sollte. Besten Dank.
  4. Sorry, wenn das Thema zu groß und unspezifisch für ein Forum ist. Ich habe wohl, im Nachhinein betrachtet, auch eine nicht unerhebliche Info weggelassen, die Eure Antworten ggf. durchaus beeinflusst haben könnte. Das Konstrukt ist nämlich am Ende das Ergebnis einer Migration aus aktuell drei Standorten mit zwei eigenen lokalen Domänen und einer lokalen Arbeitsgruppe. Da die alte IT aber so hannebüchen aufgesetzt wurde, ist eine klassische Migration zumindest einer der alten Domänen nicht erwogen worden. Die neue Architektur sollte also bei Null beginnen und dann die Inhalte nach und nach aus den alten Strukturen übernehmen. Da es unter Anderem diverse Individuallösungen gibt, besteht die Migration aus sehr viel Handarbeit und wird daher wohl über längere Zeit gehen. Deswegen sehe ich auch nicht wie man zumindest anfänglich mit MX Umstellung arbeiten kann, ohne den Mailfluß der anderen Stellen (inkl. lokaler Outlookse) zu verhindern. Perspektivisch gebe ich euch aber Recht, ist eine wie auch immer dann gestaltete direkte Mailzustellung prinzipiell besser. Es gibt bestimmt auch viele gute Gründe alles zentral zu organisieren. Gleichzeitig wird dann allerdings auch der Anspruch an Ausfallsicherheit immer höher. Der zu betreibende Aufwand dabei steigt schnell bezüglich Kosten, Aufwand und auch notwendigem Know How, was ggf. zu weiteren Kosten wieder eingekauft werden muss. Daher präferiert man prinzipiell den dezentralen Ansatz, da dann einzelne Standorte trotz Ausfalles eines anderen in großen Teilen weiter arbeitsfähig sind. Und schließlich spielt, zumindest für uns, auch eine Rolle, wo kommt man her (IT technisch) und wo will man hin, was braucht man und wieviel kann man investieren und leisten. Längst nicht jedes Szenario ist dabei das best Mögliche, sondern im Zweifel werden Kompromisse gemacht werden (müssen). Ich möchte hier dann aber auch eure Zeit nicht überstrapazieren mit einem für das Forum zu hoch aufgehängtem Thema. Ihr habt ja schon Denkanstöße gegeben und erwähnt, was euch stört, dass es technisch aber prinzipiell wohl im großen Ganzen so funktionieren kann. In Zukunft geht es sicherlich in Richtung MX Umstellung, RDP in Maßen, ob nun als Terminal Server, oder virtuellem Windows 11. (Danke für den Tipp) Vielen Dank für euer Feedback.
  5. Liebe Community, vorweg, das Thema betrifft einige Forenbereiche. Wenn ich hier eher falsch positioniert bin, bitte ich die Forenadmin, das Thema in einen passenderen Bereich zu verschieben. Im Rahmen eines Projekts soll das folgende Szenario umgesetzt werden, und ich möchte euch fragen, ob es realisierbar ist, bzw. ob besondere Aspekte beachtet werden müssen, die hier in der Auflistung fehlen. Es ist nicht gewünscht, externe Cloud-Lösungen wie Exchange Online zu verwenden. Das Projekt umfasst derzeit drei Standorte, möglicherweise in Zukunft bis zu sechs. Alle Standorte sind über ein Side-to-Side-VPN (SDSL 50mbit aufwärts) miteinander verbunden. Separate Internetverbindungen stehen jeweils für den allgemeinen Internetzugang zur Verfügung. Es existiert eine gemeinsame Windows AD-Domäne (2022) und eine einzige SMTP-Domäne. An jedem Standort gibt es lokale Fileserver, Domänencontroller mit DNS-Funktion und Exchange Server (2019). Da die SMTP-Domäne auch über die drei Standorte hinaus genutzt wird, verweisen die MX-Einträge weiterhin auf den Provider. E-Mails werden über Pop3 (PopCon) an den jeweiligen Standorten abgeholt und an den lokalen Exchange-Server zugestellt. Die Mitarbeiter arbeiten auch hauptsächlich an ihren jeweiligen Standorten. Daher sollte der Großteil des Datenverkehrs ebenfalls lokal stattfinden. Externe Zugriffe (Smartphones, Notebooks) erfolgen ausschließlich über IPSec-Einwahl-VPNs zu den jeweiligen Standorten. Die externe Autodiscover-Funktion befragt somit das externe DNS und leitet die Anfragen an den Provider weiter. Dort wird dann nur E-Mail angeboten, was momentan auch ausreichend ist. Das interne DNS enthält mehrere HOST-A-Einträge für "autodiscover.contoso.local" mit den entsprechenden IP-Adressen der Exchange-Server (DNS-Round-Robin). An jedem Standort wird voraussichtlich auch ein RDP-Server betrieben, um Mitarbeiter, die sich abwechselnd an Standort A und B befinden, zu unterstützen. Dadurch können sie sich mit dem Standort verbinden, an dem ihr Postfach gehostet ist, um den Datenverkehr über das Standort-VPN für Outlook zu minimieren. Wir erwarten primär standortübergreifenden Datenverkehr bei AD- und DNS-Replikationen sowie beim internen E-Mail-Verkehr von Exchange zu Exchange. Und natürlich auch wenn jemand mal explizit auf ein Datenlaufwerk am anderen Standort zugreift. In einer früheren Überlegung gingen wir noch von einem zentralen Standort aus, an dem alle Server zusammengeführt und ausschließlich über RDP (via VPN) angeboten wären. Aufgrund unserer Bedenken hinsichtlich der Planungssicherheit in Bezug auf Microsofts Unterstützung von Office auf Terminalservern, sowie der nötigen Vermeidung von Azure-Lösungen aus verschiedenen Gründen, versuchen wir nun, durch das dezentrale Konzept die Datenströme zu optimieren und trotz einer einfacheren Architektur eine gemeinsame Arbeitsumgebung zu erreichen. In der oben genannten aktuellen Planung kommt RDP offensichtlich auch vor, jedoch sollte dessen Bedeutung geringer gehalten werden, um im Fall einer möglichen Abkündigung durch Microsoft weniger Auswirkungen zu haben. Im schlimmsten Fall würden die Clients dann direkt auf die Server zugreifen. Ich wäre dankbar für eine Einschätzung und konstruktives Feedback. Beste Grüße Dirk
  6. Das ist ja ziemlich enttäuschend. Aber ich hatte sowas befürchtet. Lizenzen wären da, aber nur wegen einer mobile App gleich eine Hybrid Umgebung aufsetzen, deren Voraussetzung auch wieder die Erreichbarkeit von 443 voraussetzt, welche dann mit einem ReverseProxy etc. abgesichert wird, ist wohl weit über das Ziel hinaus. Dann werde ich wohl 3rd Party Apps prüfen und ggf. vorschlagen müssen. Besten Dank.
  7. Hallo Zusammen, wir haben hier einen lokalen Exchange 2016 (aktuelle CU) laufen. "Normale" Windows Domäne (2016) (2 DC, 1 Exchange) an einem Standort. Windows Domäne = SMTP Domäne intern DNS mit autodiscover zeigt auf interne IP des Exchange externe DNS zeigt auf externe IP (wer hätt's gedacht) Der Exchange hat auf autodiscover.contoso.com und outlook.contoso.com auch ein offizielles Zertifikat laufen. Seit Hafnium ist der Exchange extern allerdings nicht mehr per HTTPs erreichbar, sondern nur noch SMTP. Das interne Autodiscover löst korrekt zum Exchange auf,. Das externe Autodiscover, unter anderem mit MS Remote Connectivity Analyzer getestet, ebenfalls, sofern man für den Test kurz die "443-Hosen" am Router runterlässt. Alle Windows Outlook Clients schnuckeln seit jeher mit dem Exchange und auch OWA ist kein Problem. Stock Apps von Apple (Mail/Kalender ...) funktionieren ebenfalls seit jeher von extern (per VPN) und intern ohne Probleme. Nun soll aus bestimmten Gründen auch Outlook for iOS/Android eingesetzt werden. Und dabei haben wir das Problem, dass die Kontoanlage im Smartphone keinen Erfolg bringt Es ist keine Anmeldung am Exchange möglich. "login failed" Das Smartphone ist via Wifi angebunden und erhält per lokalem DHCP die gleichen Angaben wie die Windows Clients auch. Also IP des Netzwerkes inkl. dem DNS der lokalen Domäne. OWA vom Handy geht ohne Probleme und die Stock Apps ebenfalls. Nur Outlook bekommt es nicht auf die Kette. Gehe ich am Router hin und mache 443 zum Exchange wieder auf, funktioniert es. Das lässt für mich nur den Schluss nahe, dass sich Outlook mobile beim Autodiscover nicht auf auf den internen DNS verlässt, sondern (hardcoded?) einfach einen externen anfragt, welche natürlich die externe IP zurückgibt. Ich sehe in den Routerlogs dann auch einige IPs aus dem Microsoft Universum aufpoppen. Aber das kann doch nicht sein oder? Sehe ich hier was nicht, kann man was anders machen? Hat hier auch jemand das Problem einen on Premise mit Outlook mobile verbinden zu müssen? Ich bin jespannt. :-/
  8. Ich bin noch das finale Feedback schuldig, als dass die Nachwelt von meinen "Leiden" profitieren kann. Also, das dcpromo lief tatsächlich sauber durch, nachdem beide DCs via SMB1 miteinander quatschen konnten.
  9. Definitiv. Auf (hoffentlich) nicht allzu lange Sicht ist der 2008 ja eh weg. Dort konnte ich jetzt nur testweise nicht am SMB spielen wg. dem Neustart.
  10. Ah, das könnte natürlich sein und klingt "praxisnah" . Danke für den Hinweis.
  11. Also, Ich bin schon etwas weiter und verhalten optimistisch die Ursache gefunden zu haben. Ich habe mir mal das SMB auf dem 2008 R2 angeschaut und der läuft noch auf SMB1, was auf dem Server 2019 ja standardmäßig deaktiviert ist. So habe ich jetzt mal testweise SMB1 auf dem neuen Server zugelassen. Den Neustart dort kann ich gerade durchführen und siehe da: Ich kann vom alten DC den neuen in der AD GUI verwalten, bei den Betriebsmasterrollen wird der aktuelle (neue) nicht mehr als FEHLER - offline angezeigt. Ein dcdiag vom alten zum neuen Server lief eben vor der SMB1 Freischaltung noch in massive Fehlermeldung und schnuckelt jetzt durch. (DCdiag jeweils lokal lief super) Mir war einerseits nicht bewusst, dass SMB so eine Rolle zwischen DCs spielt, vor allen Dingen, wenn alle Replikationen (AD, DNS) augenscheinlich laufen. Und anderseits hatte ich SMB1 nicht auf dem Schirm, da doch eigentlich 2008 R2 schon mit SMB 2 bzw. 2.1 läuft?! Ich werde dcpromo natürlich noch machen bei nächster Gelegenheit und hier die Ergebnisse posten.
  12. Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : ALTER SERVER Primäres DNS-Suffix . . . . . . . : DOMAIN.TLD Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : DOMAIN.TLD Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: DOMAIN.TLD Beschreibung. . . . . . . . . . . : Broadcom BCM5708C NetXtreme II GigE (NDIS VBD Client) Physikalische Adresse . . . . . . : 00-18-8B-31-20-12 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::855a:3f6a:7446:18d8%10(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.0.198(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.0.254 DNS-Server . . . . . . . . . . . : ::1 192.168.0.41 192.168.0.198 NetBIOS über TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.{0DBD2924-5BD7-41D6-9B97-BF665DE1ED70}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: DOMAIN.TLD Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter Teredo Tunneling Pseudo-Interface: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : NEUER SERVER Primäres DNS-Suffix . . . . . . . : DOMAIN.TLD Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : DOMAIN.TLD Ethernet-Adapter Ethernet: Verbindungsspezifisches DNS-Suffix: DOMAIN.TLD Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter Physische Adresse . . . . . . . . : 00-15-5D-00-33-00 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::9878:730c:689a:f3f9%7(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.0.41(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.0.254 DHCPv6-IAID . . . . . . . . . . . : 67114333 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-25-D8-5B-3D-00-15-5D-00-33-00 DNS-Server . . . . . . . . . . . : ::1 192.168.0.198 192.168.0.41 NetBIOS über TCP/IP . . . . . . . : Aktiviert
  13. Nein, da ist keines definiert. Dort sind lediglich die Default Einstellungen hinterlegt ("Standardname-des-ersten-Standorts")
  14. Ich beziehe mich auf die Ereignisanzeige, Administrative Ereignisse, Also Anwendung, System, Active Directory, DNS Server etc.
  15. Ja, beide Server zeigen in den Logs nur wiederkehrende DFSR Events (5014 und 5002) regelmäßig abends um 19:00. Danach findet aber eine erfolgreiche Verbindung statt. Ich sehe auch gerade, um 19:00 findet die Windows Server Sicherung statt. Die automatischen Dienste laufen alle. Vor allen Dingen auch der RPC. Pff, da bin ich auf dünnem Eis unterwegs. Die GC werden zumindest bei beiden angezeigt. Ganz ehrlich, wüsste ich nicht genau, wonach ich da nun schauen muss. VPN bzw. MTU Probleme können wir ausschließen. Sorry, hatte ich nicht erwähnt. Es ist nur ein Standort. Keine Router oder Routen zwischen den DCs.
  16. Dazu kann ich sagen, dass zumindest IP4 gegenüber IP6 präferiert werden soll (Stichwort DisabledComponents HEX20). Ich bin aber was IP6 angeht ehrlich gesagt wenig bewandert. Aktiv ist da nichts explizit konfiguriert. Der Router macht IP4 Jopp. In den Logs steht nichts. Vielleicht kann man dazu explizit das Logniveau anheben, damit da mehr steht?!
  17. Der war u.a. auch noch DATEV (sag nix, habe ich so übernommen) und aktuell DHCP, sowie vor allen Dingen File Server. DATEV ist wegmigriert. Der DHCP ist natürlich kein Problem. Die Filestruktur ist Kraut und Rüben und soll (muss!) aufgeräumt werden, was sich leider hinzieht. Es muss noch eine Exchange 2016 zu 2019 Migration (andere Server) on Premise laufen und da habe ich halt das Problem mit dem AD Level. Da die Filemigration sich hinzieht, wollte ich schon einmal demoten, damit ich die AD anheben kann für Server 2019 und am Exchange weitermachen kann.
  18. Moin Nils, das ist dazu leider völlig ungesprächig. Sporadisch moppert DFSR, dass er mal eine Verbindung nicht hinbekommen hat. Meldet aber kurze Zeit später die erfolgreiche Verbindung. Ansonsten sind die administrativen Ereignissse erstaunlich leer. Während des DCPromo als solches wird überhaupt nichts geloggt.
  19. Mein Problem ist einen Windows 2008 R2 Server zu demoten. Situation: Eine Windows Domäne mit aktuell zwei Domänencontrollern. Einmal ein Windows Server 2008 R2 und einmal ein Server 2019. Die aktuelle Domänenfunktionsstufe ist auf den maximal möglichen Stand 2008 R2. Beide DC sind natürlich auch DNS. Der primäre DNS des einen zeigt jeweils auf den anderen, der sekundäre auf sich selbst. Ein NSlookup löst die Server und die Domäne korrekt auf. DCDiag zeigt keine Fehler, FRS wurde im Vorfeld auf das aktuelle DFRS ohne offensichtliche Probleme migriert. Die AD Synchronisation habe ich u.A. mit dem AD Replication Status Tool von Microsoft geprüft und zeigt den Erfolg der Replication. Auch banale Tests mit einer Ordneranlage im Netlogon etc. werden wie erwartet repliziert. Die FSMO Rollen wurden dann per Powershell auf den neuen DC umgezogen. Ein netdom query auf beiden DCs löst sauber auf, dass alle Rollen beim neuen DC sind. Die Uhrzeiten der DCs sind synchron. Soweit so simpel. Nun möchte ich den alten DC per DCPromo demoten. Der Assistent bricht dann allerdings beim Entfernen der Rolle ab. "der angegebene Netzwerkname ist nicht verfügbar." Schaue ich mir die Betriebsmaster Rollen über die AD GUI auf dem neuen DC an, sieht alles aus wie erwartet. Schaue ich mir diese allerdings auf dem alten DC dort an, steht beim aktuellen Rolleninhaber nur "Fehler". Ebenso kann ich vom alten DC den neuen DC auch nicht verwalten. ("Netzwerkname wurde nicht gefunden") Der alte DC kann aber durchaus andere Memberserver oder PCs verwalten, ebenso kann der neue DC von anderen Servern verwaltet werden. Die Firewallregeln kann ich ausschließen. Ein temporäres Deaktivieren der Firewall auf dem neuen DC hat daher erwartungsgemäß auch nichts gebracht. Wenn ich versuche vom Servermanager des alten DC mich mit dem neuen DC zu verbinden, schlägt das ebenso fehl. "Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Der WS-Verwaltungsdienst kann die Anforderung nicht verarbeiten. Der Ressourcen-URI ...://schemas.microsoft.com/powershell/Microsoft.ServerM... wurde nicht im Katalog der WS-Verwaltung gefunden. Der Katalog enthält die Metadaten zur Beschreibung von Ressourcen oder logischen Endpunkten..." Verstehen tue ich das allerdings leider nicht. Any insights was hier los sein könnte?
  20. Punkt 1 stimmt und soll auch zeitnah behoben werden. Allerdings ist das nächste Servicefenster erst in 3 Wochen. Punkt 2 verstehe ich leider die Frage nicht. Der Ordner wurde durch einen Mitarbeiter angelegt, welcher die Adressen zukünftig pflegen soll. Der Onlinemode, weil die Outlook`se auf einer RDS Farm laufen und RDS und Exchange laufen als Hyper V auf der gleichen HW Maschine. Problem ist mittlerweile gelöst. Für die Nachwelt: Die Kontakte in der globalen Adressliste hatten ursprünglich die externe Adresse als Haupt SMTP und eine .local als 2. Adresse, welche über eine Adressgenerierung erzeugt wurde. Der Mitarbeiter hat nun diese Kontakte aus der globalen in den eigenen Kontaktordner kopiert und dann von dort aus in den öffentlichen Kontaktordner. Angezeigt wurde im Kontakt dann allerdings nur die externe Haupt SMTP Adresse Ein jetzt weitergeleiteter NDR Bericht zeigt mir nun aber, dass Exchange das S/Mime wohl auf die .local anwenden will und das logischerweise verweigert, sowie eine Zustellung natürlich ebenfalls nicht möglich ist. Der Kontakt wurde manuell neu angelegt, Zertifikat hinterlegt, Autovervollständigen bereinigt und et voilá.
  21. Wir haben einen Exchange Server Standard 2016 CU 8. Die Mitarbeiter greifen von Outlook 2016 Clients im Online Mode darauf zu. Bis dato wurden externe S/Mime Kontakte in der globalen Adressliste zur Verfügung gestellt. Nun ist ein neuer öffentlicher Kontakteordner angelegt worden und die Kontakte wurden dort ebenfalls erstellt und mit den öffentlichen Zertifikatsschlüsseln versorgt. Möchte nun ein Mitarbeiter an eine dieser Adressen mailen, bekommt er den Hinweis: "Diese E-Mail-Nachricht kann nicht zugestellt werden, weil deren E-Mail-Adresse nicht mehr gültig ist." Die Autovervollständigenliste wurde schon bereinigt bzw. die problematischen Einträge einzeln gelöscht. Die globale Adressliste wurde mittlerweile ebenfalls bereinigt. Das Problem bleibt aber leider weiterhin bestehen. Any Ideas? Gruß Dirk
  22. Mensch zahni, da hätt ich auch drauf kommen können/sollen. Ich hab es nur aus Outlook heraus getestet und in der Tat versäumt, Outlook auch für die Teilen-Funktion freizuschalten. So klappt es tatsächlich. Einziger Haken, ich habe weniger Optionen die Bilder zu verkleinern, als via Mail. Aber dennoch ggf. eine "Not"-Lösung. Danke schon mal. Da es zur Zeit bei der Domain keine Möglichkeit gibt MX und DNS Einträge zu setzen, gibt es auch kein offizielles Zertifikat für Exchange. Ergo sind die iPhones zumindest im Moment noch nicht per EAS am Exchange dran. Die Bilder werden über lokale IMAPs versand. Aber da sich die Providersituation hoffentlich bald ändert, werden die Konten auf den Smartphones zukünftig Exchangekonten sein. Von daher, wenn Du da jemand triggern kannst...
  23. Korrekt. Es geht um den Versand der Bilder vom iPhone per Email (App heißt bei Apple "Mail" ) an die Firma. Andere Dateiarten werden in der Tat immer als Anhang versand. Das Problem mit anderen Apps (zumindest Outlook App) ist, dass man jedes Bild einzeln anhängen muss. Email auf, Anhang Bild - Zugriff Mediathek, Auswahl Album, Bild auswählen und wieder von vorn. Da hier täglich viele Bilder geschickt werden, ist das nicht praktikabel. Ebenso wenig die iCloud, da bei diverse Locations, diverse Fälle, dann die Zuordnung der Bilder erschweren. So werden 1 Dutzend Fotos markiert, teilen per Email, Betreff und los gehts. Diesen Workflow wollen die Leute nicht verlieren.
  24. Hallo, wir haben hier einen Standard Exchange 2016 CU8 laufen. Außendienstmitarbeiter schicken von der Baustelle diverse mit dem iPhone (aktuelles IOS) regelmässig gemachte Fotos per Email in die Firma. Vor kurzem gab es noch keinen Exchangeserver, sondern nur lokale Outlook'se. Die Bilder kamen in den Mails immer als Anhang an. Seit Umstellung auf Exchange werden die Bilder aber immer inline (im Nachrichtentext) angezeigt. Von der Weiterverarbeitung wäre es aber sehr praktisch, die Bilder weiterhin als Anhang zu erhalten (alle gleichzeitig speichern, drucken etc). Nun habe ich mir die Header der Emails angeschaut. Die iPhones verschicken diese Emails mit : Content-Type: multipart/mixed boundary="Apple-Mail...." Content-Transfer-Endoding 7bit Wenn ich das richtig verstanden habe, gehört zum multipart/mixed eigentlich noch der Parameter content-disposition, welcher angibt, ob der Anhang inline oder als Attachement zu behandeln ist. Diesen Parameter geben die iPhones aber beim Versand via "Mail" Applikation wohl nicht mit auf den Weg. Weiterhin habe ich https://blogs.technet.microsoft.com/exchange/2011/04/21/mixed-ing-it-up-multipartmixed-messages-and-you/ gefunden, wo Microsoft u. a. beschreibt, wie es versucht, die Lesbarkeit bei multipart/mixed Emails speziell mit Apple zu erhöhen: "To create the aggregate body, we check each MIME part in the /mixed body. If a MIME part has a disposition of Attachment, it goes to the attachment well. I am not going to argue with a client that specifies that it is an attachment. If a body part has a disposition of inline or not set, if it is a plain text or html body part, we add it to the aggregate body. If the body part is an image which can be displayed inline, we add a link to it in the aggregate body. If the body part is not text, or is an image we can't display inline, it goes to the well." Wenn ich das also alles richtig verstanden habe, lässt Apple bei der Generierung der Emailheader entsprechenden Part weg und Exchange wandelt die Anhänge zwecks Lesbarkeit automatisch zur inline Ansicht um. Ist das soweit korrekt? Ich vermute ich habe dann auch keine Möglichkeit das Verhalten zu steuern? Oder wie machen das andere, welche ggf. die gleiche Ausgangssituation haben?
  25. Jo, soweit ich das kenne, kommt die, wie so vieles beim SBS, einfach mit. Nun, halt das Zertifikat des neuen DCs. Das wäre ja möglich. Bin mir halt unsicher über die Konsequenzen, wenn schon ein DC Zertifikat in der Domäne besteht. Ob der DC sich unabhängig davon gegenüber den Clients als vertrauenswürdig zeigt, bzw. die Clients das Zert prüfen wollen und mangels AD ZertStelle dann meckern.
×
×
  • Neu erstellen...