Wolke2k4

Hallo allerseits, ich habe mal eine Frage: Ein Kunde hat an 2-4 seiner Rechner im Outlook ein Konto, welches als Microsoft Exchange gelistet ist und als Domain @outlook.de nutzt. Der Kunde hatte das Konto von einem IT-Dienstleister bekommen. Rechnungen für Office 365 hat der Kunde angeblich nicht, kann das Konto aber schon gut 3 Jahre nutzen. Worum kann es sich bei diesem Konto handeln? Ist das einfach ein kostenfreies 365 Konto? Nutzen tut der Kunde es primär für einen zentralen Kalender...

Danke, das ist, was ich "gesucht" habe! Da kann ich dann auch schon absehen, was der DMS Dienstleister argumentativ vorbringen wird: "Geht nicht, weil blablabla..." Aber das ist dann Nachgeplänkel, um das wir uns dann mit dem Kunden kümmern müssen. Mal schauen, wie das Ganze endet.

Das ist eine Alternative, die ich noch klären werde, hatte ich auch schon auf dem Radar.

Ja, selbst mit RP ist mir OWA und EWS alles nichts. Das ganze Gedöns und angepasse und all das, was so an Sicherheitslücken in der Vergangenheit lief und künftig noch kommt... Microsoft macht hier einfach großen Grütz. Und mir ist das eigentlich deutlich zu viel Aufwand für den Abgriff eines einzigen popligen Postfaches... Grundlegend seht Ihr in der Anpassung der Berechtigungen aber kein Problem?

Moin zusammen, ich habe hier eine extwas komplexere Situation, bei der mir leider auch nicht alle Details Dritter Beteiligter bekannt sind: - gehostetes DMS System von Dienstleister 1, welches via VPN an das Kundennetz angebunden ist - Hersteller des DMS und somit Dienstleister 2 - Supportdienstleister des DMS und daher Dienstleister 3 - IT-Dienstleister des Kunden und somit Dienstleister 4 - Kunde Soweit erstmal zu den Beteiligten. Nun soll vom DMS ein Zugriff auf ein einziges Exchange Postfach (liegt auf onPrem Exchange 2016 des Kunden) mittels EWS erfolgen (eRechnungen sollen dort abgegriffen werden), für das der Hersteller des DMS gern folgendes realisiert haben möchte (Aufgabe für IT-Dienstleister des Kunden) Sie müssen sicherstellen, dass das Benutzerkonto über die erforderlichen Berechtigungen für Microsoft Exchange Server verfügt, insbesondere das Recht Exchange-Identitätswechsel (Rolle Exchange Impersonation). Mit diesem Recht können Aktionen auf allen Postfächern im Namen der entsprechenden Besitzer ausgeführt werden. Sie benötigen für das Benutzerkonto zum Identitätswechsel nur dann ein Microsoft Exchange-Postfach, wenn Sie xyz Dienst verwenden. Für abc Dienst in Microsoft Outlook ist kein Microsoft Exchange Postfach für den Identitätswechsel notwendig. Sie können die Berechtigungen mit dem folgenden PowerShell-Befehl ändern: New-ManagementRoleAssignment –Name:impersonationAssignmentName – Role:ApplicationImpersonation Wenn Sie dem Benutzerkonto nur Rechte auf bestimmte Postfächer erteilen möchten, können Sie mit einem Filter für einen regulären, gefilterten Empfängerbereich (RecipientRestrictionFilter) die Berechtigungen einschränken. Sie können z.B. einen PowerShell-Befehl angeben, um einen Exchange-Identitätswechsel für das Dienstkonto auf die Postfächer 1 und 2 zu erteilen. Die beiden fett markierten Dienstnamen sind von mir geändert. Das sind Dienste des DMS, die anders benannt sind. Mich würde generell mal eure Einschätzung zu dieser Rechteanforderung interessieren. Glücklicherweise haben wir sonst solche Anwendungsanforderungen nicht. Rein vom Bauchgefühl her ist der unbeschränkte Zugriff auf alle Postfächer schon mal ein NoGo, sodass der Zugriff mindestens auf das eine Postfach beschränkt werden muss. Aber auch sonst halte ich eigentlich nicht viel vom EWS Zugriff von Third Party Anwendungen. Wie schätzt Ihr das ein?

Hallo allerseits, ich nutze seit geraumer Zeit ein Class 4 SMIME Zertifikat von CERTUM und verschicke damit alle Mails standardmäßig signiert. Immer wieder kommt es leider vor, dass bestimmte Empfänger diese signierten (wohlgemerkt nicht verschlüsselten) E-Mails (verschickt über Outlook 2019) aber nicht lesen können. Diese seien entweder leer oder enthielten einen Anhang, der den Mailtext aber nicht enthält... Certums Rückmeldung hierzu bisher unbrauchbar: Kann auftreten, wenn mehr als ein Zertifikat installiert ist, ich soll den Zertifikatsordner löschen und das Zert noch mal neu installieren. Häufig, wenn nicht gar immer, tritt das Problem auf jeden Fall bei Android auf. Ich habe aber auch schon Empfänger, die Office 365 nutzen... Hat jemand zufällig ähnliches erlebt und das fixen können? Im Support benutzen wir kein Class4 Zertifikat sondern ein Class1, solche Probleme haben wir dort bisher noch nie gehabt.

Das AD Snapin auf dem neuen DC zeigt nicht zufällig auf den alten DC? Die DNS Einstellungen des neuen DCs sind auch auf ihn selbst konfiguriert/zeigen auf seine eigene IP und nicht auf den alten DC?

Update zum Thema hierzu meinerseits: Zwischenzeitlich haben wir nun auch ein paar ASUS Boards von Wortmann Servern in den Fingern gehabt aber da ist es kaum besser. Mal wieder beschleicht einem das Gefühl, dass wieder nur Praktikaten an kritischen Stellen Entwicklungsarbeit leisten... Was wir (in Summe bei Intel und Asus aber auch Raid Controller Software wie bspw. LSI bei den Wortmann Servern) feststellen mussten: 1. keine Testfunktion für den Mailversand 2. kein Support für SMTPS 3. keine Verwendung von DNS Namen für SMTP Server 4. kein Customizing meldender Komponenten wie BMC/Management Interface und/oder RAID Controller, die für unsere automatisierte E-Mail Auswertung wichtig ist, um Kundensysteme eindeutig zuzuordnen... Ich meine wovon reden wir hier? Sicher nicht von Sachen, die es erst seit 2 Tagen gibt sondern von Basics. Ja die Wortmann Server sind günstig/günstiger, teils immer noch deutlich, wenn es gerade um die Verwendung von SSD/NVMe geht aber was diese Automatisierungsfunktionen für den Mailversand angeht, waren wir mit Fujitsu besser aufgestellt... Aber irgendwas ist ja immer. Wir werden nun mal den RASPI als separates Mail Relay ins Auge fassen.

Ja das sind Optionen, die ich auf jeden Fall forcieren werde, sollte der Umzug auf den 2003-er Member funktionieren. Danke erstmal fürs Feedback.

Hmmm Norbert, die Idee ist so simpel... Ich wusste schon, warum ich hier schreibe... Ich muss mal schauen, ob ich einen 2003-er Datenträger ISO bekomme (Actionpack wo bist Du?) Und dann ist die Frage, ob man diese Spezialsoftware darauf umgezogen bekommt. Zumindest für das Domain Thema wäre das erstmal eine Variante: 1. 2003-er Member Server installieren 2. Spezialsoftware darauf umziehen/lauffähig bekommen 3. SBS komplett ablösen --> Swing auf den 2012R2 DC und von dort zu 2022 4. SBS Goodbye... Wenn allerdings schon 2. nicht funktioniert, dann... A Karte...

Hallo zusammen, ich habe hier eine Umgebung vorgesetzt bekommen mit folgender Konstellation: 1. Windows Server 2003 SBS, der FSMO Halter und GC ist! (läuft glücklicherweise auf einem Hyper-V 2022 als VM) 2. Windows Server 2012R2, der auch DC ist (der alte Hyper-V) Nun soll die Umgebung aktualisiert/abgelöst werden und ich überlege gerade zu den entsprechenden Stolpersteinen: Das Kernproblem: Auf dem 2003-er Server läuft eine Spezialsoftware, dessen Entwicklerfirma es nicht mehr gibt, die aber eben leider noch immer im Unternehmen genutzt wird/werden muss. Mir ist klar, dass ich weder einen 2019 DC noch geschweige denn einen 2022 in dieses Uralt AD integriert bekomme. Soweit ich mich erinnern konnte und es eben recherchiert habe, muss der SBS FSMO Halter sein, da nach einem Transfer der Rollen dieser nach dem Kulanzzeitraum von 7 Tagen anfängt herunterzufahren?!? Damit bleibt m.E. der schlichte Umstand, dass im Grunde der SBS leer gezogen und für diese Spezialsoftware eine Lösung gefunden werden muss? Ich hatte überlegt, ob es vielleicht machbar wäre eine 2022-er Domain aufzusetzen, dort die Clients und die anderen beiden Server (1x neuer 2022-er Fileserver + 1x noch abzulösender 2012R2 Server) zu integrieren und dann eine Vertrauensstellung von der 2022-er Domain zur 2003-er herzustellen, damit die Spezialsoftware weiter genutzt werden kann... Letztlich ist mir aber auch klar, dass das nur ein weiteres hinauszögern des Unausweichlichen ist. Trotzdem würde mich eure Meinung interessieren, ob das Szenario mit der Vertrauensstellung möglich wäre. Danke schon mal vorab füre eure Antworten.

Also ich sag mal so: Als Fujitsu vor 2-4 Jahren massiv mit seinen Lieferproblemen anfing (das war noch vor Corona), sind wir auf Wortmann umgestiegen. Ich habe bei der Wortmann sicher bei den Servern nicht die bis ins kleinste ausgefeilten Funktionen und Features wie bei HP, Dell, Fujitsu usw. Aber ich sagt Dir, diese großen Player disqualifizieren sich aus mindestens folgenden Gründen: 1. schlechte Zuarbeit/Bearbeitungsdauer bei Angeboten (Fujitsu) 2. Preislich total überteuerte Server, wenns um NVMEs und SSDs geht 3. outgesourcter Support, dem Du oft erstmal erklären musst, was genau dein Problem ist 4. Zumeist nur max. 6 Jahre Garantieverlängerung --> Bei Wortmann hatte ich letztens ein System, wo die Wortmann nach 8 Jahren Laufzeit sagte: Sorry, können wie nicht mehr anbieten. Fujitsu und Co. kannste max. noch durch Drittanbeiter Garantieseitig verlängern... Ist aber auch wieder aufwand und dann eben ein neues Unternehmen in der Kette. Ich war viele Jahre auf Fujitsu festgelegt und punktuell hatten wir immer mal wieder HP und Dell in den Fingern. Bei Wortmann stimmt aber das Gesamtpaket und passt für uns und unsere Kunden besser.

Wortmann deckt sich noch mit Intel Boards ein und wird dann auf/mit MiTEC umstellen/weitermachen. Der Kollege meinte allerdings auch, dass MiTEC schon länger für Intel hinter den Kulissen produziert... Heißt aber wohl auch, dass dieser MIST mit den DNS/IP Adressen in der BMC sich wohl nicht so schnell verbessert.

Interessant, wohin das Thema geführt hat... da werde ich glatt mal bei meinem Wortmann Vertrieb anfragen! Danke für die Randinfo!!!

Ja das ist von allen Varianten wahrscheinlich die Beste, wenngleich wir es bei diesem Kunden erstmal dann doch mit HMAIL machen ("müssen") werden. Ein eigenständiger MTA (Firewall geht wie gesagt nicht) der losgelöst vom Serverblech ist, deckt damit alles ab, was notwendig ist. Danke @Intel für diesen Mist!!!!!!!