NorbertFe

Tja dann mußt du dir was skripten ;)

Dann mußt du für die Ressourcenpostfächer die Kalenderberechtigungen ändern: foreach ($Mailbox in (get-mailbox | Where-Object { $_.IsResource -eq 'true'})) { Set-MailboxFolderPermission -identity "$($Mailbox.Name):\Kalender" -AccessRights LimitedDetails -User Standard } Falls englisch, ggf. nochmal mit :\calendar

Irgendwo müssen sich doch auch Prinzipienreiter sinnvoll beschäftigen können. ;)

Naja die Liste der Betroffenen ica wurde ja nochmal aktualisiert und ist jetzt deutlich kürzer. Die pkis können aber auch nix dafür, wenn die crls nicht überprüft werden und abgesehen davon wird ja nun wirklich nicht jede Verbindung aufs Neue überprüft. Also wird man die Auswirkungen möglicherweise erst in ein paar Tagen spüren.

Nein braucht er nicht, denn die Maschine soll es ja übernehmen und die hat er explizit eingetragen. Das was du meinst kommt nur bei Nutzer-gpo zum tragen.

SMS passcode kann doch auch softtoken otp. Evtl. Kann man das ja einfach nutzen. Bin mir grad nicht sicher, ob man dann trotzdem eine Nummer benötigt.

Haben wir auch im Einsatz. Ich meine man kann das bei denen drin lassen, die kein Problem damit haben und bei den anderen manuell oder sogar aus anderer Quelle importieren. Müßte ich mal nachschauen.

Muss denn die Nummer im ad und dann auch noch in diesem Feld stehen? Kenne einige Lösungen, da kann die Nummer auch manuell eingetragen werden oder eben in einem nicht so offensichtlichen Feld. welche Lösung setzt ihr denn nun ein, bevor man hier sinnlos (beiderseits) drumrumredet. ;) Welche? Naja ist euer Problem und ihr sucht eine Lösung. Meinst du, du bist zielführend?

Naja vermutlich wollten sie den Leuten auch etwas Zeit geben.

Interessant, dass die Fehler lt. release notes aber schon in der 13.0-58.30 behoben sind, die aber schon irgendwann im Juni veröffentlicht wurde. :)

Re-FS oder NTFS fällt mir dabei ein.

Das ist egal, denn der Raum sagt ja selbstständig zu und ist unabhängig von den anderen x Teilnehmern. WEnn die alle zusagen wirds halt eng im Raum. Ähnliches Thema hatten wir neulich schon:

Und dann?

Mit on premise exchange wäre mir nix bekannt. Für die Cloud gibts Lösungen.

Ich würde kein Wildcardzertifikat verwenden, aber ja man kann das verwenden. Wenn mans richtig macht, gibts auch keine Probleme. Alternativ kann man bevor man ne Frage stellt natürlich auch mal ins Forum paar Zeilen tiefer schauen:

Ist doch egal. Wirf alle in eine out oder auch unter ous. Wie schon gesagt ist dem exchange das egal und ein Nutzer sieht davon sowieso nix. Also mach es so, dass es administrativ sinnvoll ist.

Nennt sich Stateful. ;) Der Traffic wird intern initiiert und die Firewall "wartet" quasi auf die Rückantwort.

Bing grad zu faul mir die anzusehen. :) Vielleicht hat ja jemand was griffbereit.

Mach doch mal nen Feature Request. :) Die sind manchmal ja ganz fix.

https://docs.microsoft.com/de-de/deployoffice/deploy-microsoft-365-apps-remote-desktop-services

Evtl. Auch einen Blick wert: https://www.codetwo.com/exchange-migration/

Kommt auf die Anforderungen an. Solange die nicht klar sind... aber unabhängig davon ist das Verständnis notwendig, wie Softwareverteilung funktioniert. Dann ist das Produkt fast egal. ;)

Ist ja immer die Frage nach einem „Vergleich“. ;) für den einen ist gut ja was anderes als für den anderen.

Das ist aber ein mailscanner... ;)

Wegen Gründen. ;) 1. Weil das dann USERbezogen wäre und nicht pro Maschine und somit der Anforderung widerspräche und 2. Weils "Mist®" ist. 3. Müßte man sich dann assign und publish anschauen, und erfahrungsgemäß tritt dann 2. in Kraft. Das sowieso.