NorbertFe

Glück für die, die schon mehrheitlich 2022 im Einsatz haben. ;) Ich frag mich echt, was die bei MS immer rauchen.

Aussperren geht ja afair nicht mehr seit irgendeinem Update. ;) insofern also quasi gefahrlos.

Nur dass der to nicht den Standard hat, wenn ich mir sein erstes posting anschaue.

Hmm, am Ende doch aber Wurst. Auf den dcs ist es deaktiviert. Also sollten sich diese testclients dann nicht mehr sinnvoll anmelden können, oder?

Laß dir doch gern einfach alles aus der Nase ziehen. Niemand hier kann dir beim Tippen auf den Bildschirm schauen und hat deswegen auch nur begrenzte Vorstellung davon, was du jetzt genau vor dir an Problemen/Fehlern/Erfolgen siehst.

LOL.... na sowas. Er kennt deine DB nicht, weil du einen anderen Namen eingibst? Irgendwie schon schräg, oder? ;)

Gibts -filepath überhaupt noch? Wurde das nicht irgendwann ausgebaut? https://support.microsoft.com/en-us/topic/changes-in-exchange-server-powershell-cmdlets-and-exchange-admin-center-for-unc-path-inputs-kb5014278-36af1640-4389-4ff1-b805-d1d63715a0dd Step 1: $Export = Get-Mailbox Step 2: $Export|%{$_|New-MailboxExportRequest -FilePath “\\PC\Microsoft Exchange\$($_.name).pst”}

get-mailbox -Database FWDB1 | foreach {New-MailboxExportRequest -Mailbox $_.Alias -FilePath "\\srv-ekh-fs1\daten\IT\PST\$($_.alias).pst"" -BadItemLimit 10 Versuch mal so

Der User braucht keine Rechte, sondern der Exchange Server. https://learn.microsoft.com/en-us/powershell/module/exchange/new-mailboxexportrequest?view=exchange-ps

Ich würde sagen auf den DCs anschalten und die auch ggf. mal Rebooten. Danach dann für alle Clients. Denn die Clients sprechen ja signiert, wenn der Server zustimmt. Und der bietet ja jetzt nur noch mandatory SMB Signing an.

Wäre vielleicht sinnvoller, sowas eben nicht zum Tagesstart zu setzen, sondern eher zum Feierabend. ;)

korrekt. Das Deaktivieren hatte man zu 2003 Zeiten empfohlen, weil es da wohl Performanceprobleme gab (merkbar wegen der damaligen Hardware) und weil zu dieser Zeit natürlich noch jede Menge alte Systeme unterwegs waren, die damit nicht klarkamen. Beides sollte heutzutage der Vergangenheit angehören. :)

Richtig, deine DCs sind immer unsigniert (sowohl als Server als auch als Client). Insofern ist eben ein Test noch viel unnötiger ;) Oder willst du deine DCs noch mal einzeln bestücken.

Ja, wer oder was hindert dich? Natürlich kannst du das auch auf eine oder eine Gruppe von Maschinen anwenden. Macht halt nur meist nur Aufwand für die Erkenntnis, dass man es auch gleich komplett ausrollen konnte. In deinem Fall dürften sich ja sowieso schon alle Windows Maschinen per signed smb unterhalten. ;)

Afair Office seit Version 2016.

Sowohl als auch. Also jeweils in ddp und ddcp. Könntest du?

Naja da das alles multirole Server sind… erübrigt sich diese Denke. ;) Sieht man ja, wie toll das geht. ;) Warum? Ich kann da auch einfach einen Server runterfahren. Nicht schön, aber auch kein wirkliches Problem. ;) und nur weil ein Server in der dag ist, muss er noch lange keine Datenbankkopien haben.

Microsoft network client: Digitally sign communications (always) = enabled Microsoft network client: Digitally sign communications (if server agrees) = enabled Microsoft network server: Digitally sign communications (always) = enabled Microsoft network server: Digitally sign communications (if client agrees) = enabeld Und Network security: LAN Manager authentication level = Send NTLMv2 response only refuse LM & NTLM

Wenn der eh Mitglied der DAG werden soll, warum konfigurierst du dann erst rum außerhalb der DAG? Hätte man doch von Anfang an gleich in die DAG reinnehmen können, dann gäbs doch gar kein Problem, oder überseh ich was?

Get-clientaccessservices | fl *uri*

Sehr wahrscheinlich gar keine. Denn wenn das Auswirkungen in deiner Umgebung produziert, heißt es, dass da noch ziemlich alte Systeme beteiligt sind. Und die würdest du ja sicherlich kennen, oder? ;)

Ok es gibt eine Umgebung 😉

Tjo, ich weiß schon was du meinst, aber leider sind die Securitygötter immer die, auf die man am wenigsten hören möchte. Ich persönlich hab auch kein Problem damit, die 120 Tage weiterhin beizubehalten und nur die Länge zu erhöhen :)

Natürlich nicht. ;) Und ich bezweifle auch, dass es schon praxisrelevante Anzahlen von Umgebungen ohne NTLM gibt. ;)

Wir sind aktuell bei 14 Zeichen Länge und 10 History sowie 120 Tage maximales Kennwortalter und aktivierte Komplexität. Wir überlegen gerade, ob wir von den 120 Tagen hochgehen auf 365 und dafür 16 Zeichen erzwingen.