Jump to content

NorbertFe

Expert Member
  • Gesamte Inhalte

    43.509
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von NorbertFe

  1. Hmm liest sich trotzdem irgendwie komisch. Denn abgesehen davon, dass es jetzt öffentlich gemacht wurde (ZDI) gibts dagegen ja keinen Patch (von dem einen mal abgesehen). Und eine wirksame mitigation ja offenbar auch nicht (wenn man mal von offline nehmen absieht). wann ist patchday? ;)
  2. Zwischen msi und c2r Versionen sind die Build Versionen nicht identisch. Aber 2310 ist auch nicht die komplette Build number. https://learn.microsoft.com/de-de/officeupdates/update-history-office-2019
  3. Ich hatte auch schon Kunden mit Exchange 2010 die auf sp1 geblieben sind oder auch Exchange 2013 sp1 die dann irgendwann mal migriert werden sollten. Gibts leider immer wieder mal.
  4. Nur wenn man eine draus macht. Eine Risikoabschätzung treffen (imho) viel zu wenige. Weder die, die sofort am besten auch Betas produktiv nutzen möchten, noch die mit Never Touch a Running System Mentalität. ;)
  5. Übrigens liest sich sowas einfacher, wenn man logfiles als Code formatiert.
  6. Sicherlich besser als bei be-/erkannten Lücken auf den nächsten patchday zu warten. Siehe Hafnium. Wer sich nicht selbst um seine Systeme kümmern kann oder will, sollte sie lieber nicht betreiben. ;)
  7. Ja, nur was hilft das, wenn die ganzen on-prem Exchange nie dieses Feature erhalten werden? ;)
  8. Wobei mir wieder einfällt, dass es leider immer noch DNS Provider/Hoster gibt, die sowas gar nicht ermöglichen.
  9. Muss mal schaueb, ob ich Montag Lust zum Testen finde. ;)
  10. du meinst so? Ich muss mal schauen, welche ciphers noch deaktiviert werden müssen. ;) und die Nutzer trotzdem noch Zugriff haben.
  11. Hatte ich neulich aber auch. Ein User bei dem sich ein ExO Postfach nicht mittels -PermanentlyClearPreviousMailboxInfo weil der O365 DC das Ding (Userkonto) angeblich nicht finden konnte. Ich durfte mir dann auch immer was von Backend und Konfiguration anhören.... Mein Problem war dann aber immerhin gelöst. ;)
  12. Hast du nur noch TLS 1.3 zugelassen? ;) Oder Photoshop bemüht?
  13. Mit Zusatztools könnte man das ggf. ändern, weil man dort dann den Absender umschreiben kann. Falls das helfen sollte.
  14. Die sind ja so fürsorglich. :) Sorry, aber diese Helpdesk Phrasen kann man ja nicht mehr ernst nehmen. Aber das wichtigste dabei ist, am besten noch während der Telefon-/Remotesession den Zufriedenheitsfragebogen ausfüllen.
  15. Das blöde ist, dass Exchange eigentlich immer Umleitung macht, auch wenn sie es Forwarding nennen.
  16. Was spricht dagegen, wenn du es einfach ausprobierst. ;) Afair ist es so, dass der ursprüngliche Empfänger erhalten bleibt, was dann regelmässig Probleme mit DMARC usw. verursacht.
  17. Gesehen hab ich sowas auch schon. Deswegen ist es trotzdem selten gut. ;)
  18. Ich bin halt unverbesserlicher Optimist ;)
  19. Ist es das denn? Übrigens "das" AD, bitte. :)
  20. Auch das ist doch unkritisch. Wenn du vorher SCCM im Einsatz hattest, kennst du vermutlich SCUP.
  21. Naja SCCM und GPO miteinander zu vergleichen ist schon (wie sag ichs freundlich?) sehr merkwürdig. Ich kenn ja eure Größe nicht, aber SCCM kann ja dann doch ein wenig mehr als das was man mit GPO maximal erreichen kann. Und WSUS? Den hat man doch bei SCCM normalerweise auch immer im Einsatz. So oder so, was willst du denn damit im Testnetzwerk? Sowas wie WSUS ist doch als "passive" Komponente problemlos im Produktivnetz einführbar, ohne dass es zu negativen Auswirkungen kommen kann. Bye Norbert
  22. Mal in der Fritzbox den Stromsparmodus abschalten für die Ethernet Ports ;)
  23. Sind doch alles selfsigned certificates. Da solltest du nicht mit der mmc hantieren.
  24. klar geht das. Schon immer und im Allgemeinen auch problemlos (solange der DC nur DC ist).
  25. Meist liegts an den Treibern.
×
×
  • Neu erstellen...