Austausch unter IT-Professionals - Erfahrungen, Tipps, Fachsimpelei

Skysnake schrieb:
U2 sollte doch eigentlich auch SATA SSDs fressen oder nicht?
So wie ich das verstehe ist U.2 erstmal nur eine Steckverbindung. Welche Protokolle darüber genutzt werden können, entscheidet der dahinterliegende Controller. Ist das gleiche Problem wie mit M.2 auf den Mainboards.
 
Hm... ist halt an nen U2 Port am MB angeschlossen über die Backplane.

Laut MB Datenblatt laufen da 4x PCIe drüber. Ich hatte gehofft/erwartet, dass das PCIe/SATA links sind.

Verdammt, brüchte eigentlich 2x 1TB. Als U2 NVMe ist das ein teurer Spaß... -_-
 
U.2 hat zwar prinzipiell die Kontakte für SATA, aber ich glaube in den meisten Fällen ist U.2 nur als PCIe angebunden. Müsste man jetzt natürlich für den konreten Fall im Handbuch des Servers nachlesen.
Das ist auch nicht anders als die m.2 Slots bei Consumer-Boards: Bloß weil m.2 SATA und NVMe kann heißt das nicht, dass immer beides möglich ist.

Wer frei wählen können will, sollte auf U.3 achten. Wenn ich das richtig verstanden habe, sollte ein Gerät mit U.3 auch immer Tri-Mode (also SATA, SAS und NVMe) unterstützen.
 
Ja U3 ist interessant, ich habe das aber als kann nicht als muss verstanden. U3 hat halt PCIe4 und U2 nur PCIe3
 
Gibt auch U.2 als PCIe 4.0
Samsung PM1733, PM9A3, Intel P5510, alle neueren U.2 SSDs können PCIe 4.0

Bei U.3 Backplanes ist neu, dass die einzelnen Slots nicht fix beschaltet sein müssen. Für die SSDs ändert sich eigentlich wenig.
Wenn eine NVMe SSD gesteckt wird, dann wird die als PCIe durchgerecht.
Wenn eine SATA SSD gesteckt wird, dann wird die an den SATA Controller weitergereicht.
Der Artikel dazu ist gut geschrieben:
https://www.storagereview.com/news/evolving-storage-with-sff-ta-1001-u-3-universal-drive-bays

Skysnake schrieb:
Habe nen Server der nur noch zwei freie U2 slots hat
Welche Kiste hast du denn da stehen?
 
Mal so ne Kleinigkeit nebenher: ist es bei neuen 365 Accounts in deutsch immer noch so, dass sich User erst in Owa einloggen müssen und Zeitzone/Sprache festlegen oder ansonsten damit leben müssen, dass der Posteingang Inbox heißt?
 
Das Problem gibt es doch schon seit 3-4 Jahren. Outlook ist/war daran Schuld. Ich musste den Kampf mit dem Phänomen auch aufgeben.
 
Outlook pauschal nicht unbedingt, wenn man das im OWA vorher per Login entsprechend ändert hauts ja hin. Das ist nur saumäßig nervig, gerade dann wenn zur Migration PST genutzt werden und alles in Zweitordnern landet. Ich hatte gehofft dessen nimmt sich mal einer an aber Microsoft kennt seine eigenen Produkte selbst nicht (zumindest alles in Azure laut eigener Aussage).
 
Kurz zusammengefasst
- Das EXO v2 Modul in Powershell installieren
PowerShell:
Connect-ExchangeOnline -Credential (Get-Credential)
verbinden als Admin der Dinge darf

PowerShell:
Get-MailboxRegionalConfiguration -Identity $Identity
Damit ein Postfach abfragen wie die aktuellen Einstellungen aussehen

PowerShell:
Set-MailboxRegionalConfiguration -Identity $Identity -Language "de-DE" -DateFormat "dd.MM.yyyy" -TimeFormat "HH:mm" -TimeZone "W. Europe Standard Time" -LocalizeDefaultFolderName
damit dann setzen der Zeitzonenvorgaben
 
  • Gefällt mir
Reaktionen: holdes
Ah supi, zwar umständlich aber besser als das mit der Hand zu machen. Nur schade das MS da bisher keine Ambitionen zu hat. Der Fehler ist ja nun schon Jahre alt.
 
Also wenn ich das richtig abgespeichert habe, dann resultiert das ja eher aus zB einem fehlenden Hybrid Exchange der die Zeitzone anhand des lokalen ADs vorgeben würde. Bei reinen EXO Postfächern wird es halt auf Standard Englisch eingerichtet. Vermutlich gibts gar nix im AAD was die ablaufende Initialize Methode vom EXO abfragen könnte. Das weiß ich aber nicht sicher, so genau stecke ich in der Azure Welt auch nicht drin. Im DevOps würdeste den Bug vermutlich mit Resolved Reason = As Designed schließen.

PS: Und die Cmdlets baust du natürlich schön parametrisiert in deiner lokalen Powershell Umgebung ein und kannst dann zB Scripte mit foreach darauf loslassen die dir das gesammelt über n Accounts einstellt.
Der Aufwand hält sich dann in Grenzen.
 
morcego schrieb:
PS: Und die Cmdlets baust du natürlich schön parametrisiert in deiner lokalen Powershell Umgebung ein und kannst dann zB Scripte mit foreach darauf loslassen die dir das gesammelt über n Accounts einstellt.
Wenn's 'ne rein deutsche Umgebung ist kannste das auch übern Haufen werfen...

Get-Exomailbox | Set-MailboxRegionalConfiguration [...]
 
Aktuell ist es sowieso nicht mein Problem mit den Cloud Produkten sondern der Vertrieb und AzureFiles, das ist für die irgendwie ein rotes Tuch.
 
Rickmer schrieb:
Wenn's 'ne rein deutsche Umgebung ist kannste das auch übern Haufen werfen...

Get-Exomailbox | Set-MailboxRegionalConfiguration [...]
Das kannste natürlich so machen, allerdings seh ich persönlich keinen Grund ständig jedes Postfach neu einstellen zu lassen wenn ich nur ein neues Postfach erstelle und die Performance vom EXO ist als eher dürftig zu betiteln. Es dauert einfach sehr lange bis der durch alle Postfächer iteriert.
 
Okay, ich hatte eher eine Grundeinrichtung im Kopf, daher die Differenzen.
 
Jo dafür kann man das mal machen, spricht nix gegen.

Retirement of superseded Azure AD (Azure Active Directory) Connect Sync versions
  • Timing: In mid-March 2023, this policy will go into effect, and all versions prior to the last released version (latest version prior to mid-March 2022) will retire.
    • This policy does not change the retirement of all 1.x versions of Azure AD Connect Sync on August 31, 2022, which is due to the retirement of the SQL Server 2012 and Azure AD Authentication Library (ADAL) components.
  • Action: If you are not already using the latest release version of Azure AD Connect Sync, you should upgrade your Azure AD Connect Sync software before 12 months elapses from the date they were superseded by the newest version.
  • Roll-out: tenant level
https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-upgrade-previous-version

Das würd ich mal hier mitposten, war gestern in den MS Adminmails drin. Nicht das wie bei Outlook wieder alle einen Tag später rumweinen wieso da was streikt.
 
morcego schrieb:
This policy does not change the retirement of all 1.x versions of Azure AD Connect Sync on August 31, 2022, which is due to the retirement of the SQL Server 2012 and Azure AD Authentication Library (ADAL) components.
Good to know - wird dann Azure AD strikt den Sync verweigern, oder wird das 'einfach nicht mehr offiziell unterstützt'? Das klingt erstmal wie ersteres...

morcego schrieb:
Das würd ich mal hier mitposten, war gestern in den MS Adminmails drin. Nicht das wie bei Outlook wieder alle einen Tag später rumweinen wieso da was streikt.
MS Adminmails? Kenne ich noch nicht - ist das eine Art von Newsletter, wo man sich anmelden kann?
 
Ist bei euch auch schon das neue Zoom Feature angekommen?
Ich hau mich so weg, jedesmal wenn jemand an nem Zoom Meeting vorbei läuft, will der Zoom Room die/denjenigen als neuen Teilnehmer identifizieren und mitmachen lassen.
Das funktioniert sogar mit Flaschen die man in Sichtweite abstellt :evillol:
:evillol: :evillol:
 
  • Gefällt mir
Reaktionen: Rickmer und dominic.e
Heute hat ein Kunde eine interessante Mail erhalten:

Code:
Von: A.Mommer@telekom.de [mailto:A.Mommer@telekom.de] Im Auftrag von dk.Call-Center@telekom.de
Gesendet: Montag, 7. März 2022 11:07

Betreff: Sicherheitshinweis zu Ihrer DeutschlandLAN Connect IP

Sicherheitshinweis für Ticketnummer $Ticketnummer
 
| Kundennummer/Vertragsnummer: $Kundennummer
| Anschlussinhaber: $Firmenname
| Standort: $Standort
 
Sehr geehrter Herr $Kunde,
 
die Telekom Deutschland GmbH stellt Ihnen einen Internetzugang DeutschlandLAN Connect IP für den Standort $Standort zur Verfügung.
 
Zu Ihrem Internetzugang haben wir Hinweise auf Sicherheitslücken oder Konfigurationsfehler erhalten, die einen Angriff auf Ihr System und/oder einen Missbrauch Ihres Systems für Angriffe auf Dritte ermöglichen. Ersteres gefährdet gegebenenfalls die Integrität und Authentizität Ihrer Daten.
 
Folgende Informationen haben wir von dem Hinweisgeber erhalten:
 
Betroffene IP-Adresse: $IP
Zeitpunkt: 06.03.2022 07:24 Uhr
Offener Dienst: Microsoft-Exchange-Server (443)
Server-Version: Exchange Server 2010 SP3 Update Rollup 32 -> 14.3.513
 
Seit März 2021 hat Microsoft Sicherheitsupdates für mehrere kritische Schwachstellen im E-Mail- und Groupware-Server Exchange bereitstellt, die bereits aktiv von verschiedenen Angreifergruppen ausgenutzt werden (CVE-2021-26855, CVE-2021-34473, CVE-2021-26427, CVE-2021-42321).
 
Einige Schwachstellen wurden bereits vor Bereitstellung der Sicherheitsupdates aktiv von Angreifern ausgenutzt.
Daher sollten grundsätzlich ALLE Exchange-Server, auf denen vor Installation der Sicherheitsupdates webbasierte Dienste wie Outlook Web Access (OWA) offen aus dem Internet erreichbar waren, als kompromittiert angesehen und einer forensischen Untersuchung unterzogen werden.
 
Das BSI empfiehlt, webbasierte Dienste wie Outlook Web Access grundsätzlich nicht offen aus dem Internet erreichbar zu machen, sondern den Zugriff auf vertrauenswürdige Netze zu beschränken bzw. über eine VPN-Verbindung abzusichern.
 
Eine aktuelle CU-Version aus Januar 2022 sollte installiert werden, um die Lücke zu schließen.
 
Siehe auch:
https://docs.microsoft.com/de-de/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019
 
Um alle genannten Schwachstellen zu schließen,
sind mindestens folgende Build-Versionen erforderlich:
 
    Exchange Server 2019 CU10 > 15.02.0922.020
    Exchange Server 2019 CU11 > 15.02.0986.015
    Exchange Server 2016 CU21 > 15.01.2308.021
    Exchange Server 2016 CU22 > 15.01.2375.018
    Exchange Server 2013 CU23 > 15.00.1497.028
 
Alle weiteren Exchange Versionen können diese Lücke nicht, oder nicht mehr schließen!
 
Sie erhalten diese Information, da Sie für die DeutschlandLAN Connect IP als technischer Ansprechpartner hinterlegt worden sind.
 
Nehmen Sie dieses Schreiben von uns unbedingt zum Anlass, Ihr IT-System unverzüglich zu prüfen bzw. von einem Experten prüfen zu lassen, damit die Sicherheit Ihrer Systeme wiederhergestellt wird.
 
Wenn Sie darüber hinaus weitere Informationen benötigen oder Fragen haben, erreichen Sie uns von Montag bis Freitag zwischen 8:00 Uhr bis 22:00 Uhr, sowie Samstag von 8:00 Uhr bis 16:00 Uhr, direkt unter der kostenfreien Rufnummer 0800 330 1180. Halten Sie hierzu bitte Ihre Kundenummer und Ticket-Nummer, welche Sie oben in dieser E-Mail finden, bereit.
 
Freundliche Grüße aus Kiel
Ihr Telekom Sicherheitsteam
Axel Mommer
 
DEUTSCHE TELEKOM SECURITY GMBH
Fraud Management (STATIC IP)
Bonner Talweg 100, 53113 Bonn
E-Mail: dk.call-center@telekom.de
0800 330 1180 (Telefon Inland)
00800 330 11180 (Telefon International)

Das finde ich sehr interessant, dass hier plötzlich ein Hinweis für einen Exchange 2010 kommt, also habe ich Monate nach den Update-Orgien nochmal in die CVEs geschaut.

  • CVE-2021-42321: betrifft ausschließlich Exchange 2016/2019
  • CVE-2021-26427: betrifft ausschließlich Exchange 2013/2016/2019
  • CVE-2021-34473: betrifft ausschließlich Exchange 2013/2016/2019
  • CVE-2021-26855: Proxylogon, betrifft ausschließlich Exchange 2013/2016/2019

Das der Exchange 2010 hiervon betroffen sein soll, wäre mir neu und ich habe auch an keiner Stelle einen Hinweis dazu finden können.

Ich habe mich auch mal an die Rufnummer der Telekom gewendet, die genannt wurde, aber die Dame hat nicht den Eindruck hinterlassen, dass sie weiß, worum es im Detail geht. Die hatte mir erzählt, Exchange 2010 wurde damals von Microsoft komplett ausgelassen, weil dies nicht mehr im Support ist.
Die berief sich auf einen Artikel von Heise, dass das Support-Ende von Exchange 2010 nur bis Oktober 2020 verlängert wurde. Das mit dem Support stimmt zweifelsohne, aber das hat ja auch gestimmt als die Update Rollups 31 und 32 zu den neueren Sicherheitslücken released wurden.


Weiß da jemand etwas mehr zu? Gibt es von Microsoft irgendwo ein Statement, dass die CVEs für November 2021 oder Januar 2022 auch für Exchagne 2010 zutreffend sind, aber nicht gepatcht werden?
 
Zurück
Oben