NorbertFe

probiers doch aus. dafür braucht man ja nur 4 VMs. ;) Und das setzt natürlich voraus, dass alle DBs immer auf allen 8 Servern vorhanden sind. Über welche Größenordnung von Nutzern reden wir denn?

So einfach kann die Cloud sein. ;)

Soweit ich mich erinnere kann man tatsächlich bis "last man standing" betreiben. Dann sollte man sich aber auch über DAC und die restlichen Punkte von Resilience die MS da vorsieht Gedanken machen.

Das hab ich dir ja gesagt, dass man den Haken ändern kann, wenn man es per XML regelt. Und der Verbindungstyp steht logischerweise auf Cachemode. Genau wie du das per GPO auch konfigurieren wirst. Also falsche "Erwartungshaltung" aber gelöst ist gelöst. ;) Schönes Wochenende Norbert

Lustiger ist ja eigentlich: Affected Products None.

Ist ja nicht so, dass man NUtzernamen und Kennwort nicht auf beliebigen anderen Geräten verwenden kann. Im Zweifel wirst du wohl im Exchange Log (IIS) nachschauen müssen woher die Authentifizierungsversuche kommen. Vorausgesetzt es handelt sich dabei tatsächlich um Exchange-Logins.

Der Exchange ist doch nicht das Problem, sondern nur der auslösende Faktor. Also Postfach löschen is auf jeden Fall überflüssig... Oder was denkst du, was mit einem "neuen Postfach" passieren würde? Wenn, dann wärs wohl eher das AD Konto. Aber Umbenennen eines Kontos ist eher keine sinnvolle Lösung. Ich tippe mal, dass wohl irgendwo doch noch ein Gerät steht, welches auf das Postfach zugreifen will und eben das falsche Kennwort verwendet. Muss man jetzt nur rausfinden welches. ;) Ist das ein normales Userkonto?

Nö und ich finds auch ziemlich "b***d", dass sowas dann hinter verschlossener Tür steht.

Ich? Nö, das sollen gefälligst die Kollegen tun. :) Wenn ich den Netapp Link so lese, wärs hilfreich zu wissen, welche Ontap Version denn den Fehler behebt/behoben hat. ;) Aber das fehlt irgendwie oder ich sehe es nicht.

Und was glaubst du, was der Haken in deinem Screenshot macht und wie die dazugehörige Policy heißt? ;) https://gpsearch.azurewebsites.net/Default_legacy.aspx?PolicyID=12496

Hmm und nu schwenken wir grad von Dell/EMC auf Netapp... ;) https://www.dell.com/support/article/de-de/sln321836/dell-response-to-the-ripple20-vulnerabilities?lang=en

Dann wirst du entweder die Lizenz (o365) in den anderen Tenant übertragen lassen müssen und auch die Domain (so denn schon eine darauf gebunden ist) oder du migrierst von einem tenant in den anderen.

sondern?

Ist das denn der selbe Tenant?

Ja genau das ist die Option. Die ist in Outlook einfach "mistig" bezeichnet. ;) Und wie du siehst ist das einfach ein Registry Wert, der da übergeben wird. Im Falle der xml sogar eben nur ein "Vorschlag". Wenn du sowieso nur Windows PCs in deiner Domäne bestücken willst, dann würde ich mir den XML Mist gar nicht antun (nur das notwendige) und den Rest per GPO oder GPP regeln.

Du sagst doch, dass du das Online Tool verwendest. Wenn ich da mal nachschaue: Dann wäre die Antwort ja ;) Und für die Faulen unter uns: <AppSettings> <User Key="software\microsoft\office\16.0\outlook\cached mode" Name="cacheothersmail" Value="0" Type="REG_DWORD" App="outlk16" Id="L_CacheOthersMail" /> </AppSettings>

Vermutlich nicht. Und GPO würde das ja nicht ersparen, denn per GPO wäre es nicht änderbar durch den Nutzer während die Config.xml ja nur "Grundwerte" vorgibt.

Hauptsache das ist nicht wie bei den anderen "Online Portal Prüfungen/Schulungen", in denen die Schulungsunterlagen dem Ist-Zustand um "Generationen" hinterherhinken. ;)

Wir reden also über eine Office Version die nicht mit GPOs klarkommt (denn mit denen ginge das problemlos) oder von Deployments auf nicht verwalteten Geräten?

Gibts Nachteile? :)

So würde ich das tun, ja.

Warum?

Ja genau so plus: https://support.microsoft.com/de-de/help/4489622/cumulative-update-23-for-exchange-server-2013

Tja auch dort gabs wohl einen Murphy

und gabs weitere Opfer oder nur die arme Tischplatte? ;)