cj_berlin

Ich sage mal 'TLS 1.2', wenn ich Server 2008 lese. Habe allerdings keine konkreten Ansätze, wie man das testen könnte, außer, dass es haufenweise SChannel-Log-Einträge geben müsste. Hast Du eventuell eine GPO angewandt, die TLS 1.1 und darunter abschaltet, und die Maschine seitdem einfach noch nicht rebootet?

Die bleiben auch bei iSCSI getrennt, wenn man es richtig macht. Ich glaube, vom Tape-Argument mal abgesehen, dass der größte übriggebliebene Vorteil von FC inzwischen der gleiche ist wie bei Server Core: hält die Admins ein Stück weit davon ab, Unsinn zu treiben. Aber natürlich alles Ansichtssache, und die beste Technik ist ohnehin immer die, die das Team beherrscht, das sie betreiben soll.

...aber in Windows 11 immerhin nicht mehr (by default)

Tja, Nils... wir scheinen, was Virtualisierung angeht, endgültig in Paralleluniversen zu leben Und bei EMC, IBM, 3PAR oder HITACHI würde ich auch keinen Schritt zur Seite wagen, wenn ich keinen Dienstleister an meiner Seite wüßte, der das richtig gut kann.

Moin, und ich würde noch die Frage mit auf den Tisch werfen, ob die Hosts auch erneuert werden sollen. Ist dies der Fall, sollte auf jeden Fall hyperkonvergenter Storage (vSAN bzw. S2D, je nach Hypervisor) mit betrachtet werden. Das würde ich aber auf bestehenden Hosts nicht mehr machen, da sie vermutlich eh falsch ausgelegt sind (keine Festplatten-Cages, wenige 10G-NICs, dafür HBAs). Apropos: über welches Protokoll soll der neue Storage denn angebunden werden?

Moin, das Stichwort ist "IP Helper auf dem VLAN". Damit geht es automagically Falls Du zwei IP Subnetze im gleichen VLAN betreibst, kannst Du es auch gleich sein lassen und einfach ein größeres Subnetz nehmen.

### Ausführung von PS Skripts erlauben Set-ExecutionPolicy -ExecutionPolicy Bypass -Force Das sehe ich andauernd. Was glaubst Du, was diese Zeile bewirkt, wenn die Execution Policy die Ausführung des Skriptes nicht zulässt, wo das drinsteht?

Erster!

Ja, mach mal aus den Anführungszeichen dreifache Anführungszeichen

Moin, ein Upgrade des SQL Servers auf 2019 ist von 2012 aufwärts supported und sollte für die reine Database Engine gut funktionieren. Spannender ist aber die Frage nach dem OS. SQL 2019 wird ab Server 2016 unterstützt, SQL 2014 wurde auf Server 2019 natürlich nie (offiziell) getestet. Persönlich würde ich so etwas niemals machen, aber ich bin da ein gebranntes Kind und auch generell kein Fan von Inplace.

Moin, schau hier: https://docs.microsoft.com/en-us/Exchange/architecture/mailbox-servers/recreate-arbitration-mailboxes?view=exchserver-2019

... und "Enteron" soviel wie "Darm" bedeutet

Moin, die Basis-Funktionalität geht sogar mit Exchange-Bordmitteln. Ansonsten sind die genannten Produkte gut, bewährt, es wäre noch Gangl zu nennen, aber dann hat sich die Créme de la créme auch schon versammelt. Was Du allerdings grundsätzlich abwägen müsst, ist dies: Der Disclaimer (und Signatur) kann entweder im Client oder im Transport (Exchange Transport-Agent oder Gateway hinter Exchange) angehängt werden. Beide Verfahren haben ihre Vor- und Nachteile: PRO Client: S/MIME funktioniert ohne irgendwelche Artefakte Preview durch den Absender möglich Funktioniert gleichermaßen on premises und in der Cloud CONTRA Client: Plug-In muss verteilt und verwaltet werden Funktioniert nicht mit mobilen Endgeräten oder Mails, die aus Systemen verschickt werden Gleiche Signatur für alle Empfänger (intern + extern) Absender kann Signatur beeinflussen Zugriff auf AD im Offline-Betrieb nicht ohne weiteres möglich (Mails im Flieger vorschreiben) PRO Agent: Funktioniert für alle Mails, egal auf welchem Wege sie reinkommen Unterschiedliche Signatur für intern/extern in der gleichen Mail möglich Verwaltungsaufwand in der Regel deutlich geringer als bei Client, der überall hin verteilt werden muss CONTRA Agent: Muss installiert und verwaltet werden S/MIME funktioniert nicht transparent (da der Body nach dem Signieren/Verschlüsseln verändert werden muss) Exchange Transport Agent kann nicht in die Cloud "mitgenommen" werden (eine Gateway-Lösung hingegen schon)

Das ist natürlich falsch. -ExecutionPolicy ist kein Parameter Deines Skripts, sondern ein Parameter von powershell.exe

Ich muss die Reise planen, und im September werden sich die Projekte eh überschlagen, und dann ist irgendwann womöglich noch der PSDAY.UK (wenn man dann denn dorthin reisen kann). Außerdem ist die Anmeldung, die ich im Sinn habe, bereits offen

Das ist richtig, aber die Webseite liest sich so, als ob es nur der Freitag wäre. Ich frag mal nach.

...aber diesmal irgendwie am Freitag?..

Nein Auch nicht auf den ersten. DHCP und Printserver packt man *nicht* auf einen DC.

Falls der Benutzer lokaler Administrator ist, kannst Du gar nichts für ihn unterbinden.

Ich würde sagen, die Umleitung beim Provider ist zu rigoros vorgenommen worden, denn hinter der Autodiscover-Adresse verbirgt sich gar kein Exchange (mehr)...

Moin, wie äußert sich "Empfangen nicht möglich" denn genau? Intern oder extern? Bei intern ist es evtl. die gecachte X.500-Adresse, die natürlich nicht mitgekommen ist.

Split Permissions prüfen: Container "Exchange Protected Groups" ist vorhanden und hat "Exchange Windows Permissions" drin Exchange Windows Permissions beinhaltet NICHT Exchange Trusted Subsystem Eventuell wurden Split Permissions ursprünglich eingerichtet und dann zurück gerollt. In diesem Fall muss noch New-ManagementRoleAssignment "Mail Recipient Creation_Organization Management" –Role "Mail Recipient Creation" –SecurityGroup "Organization Management" New-ManagementRoleAssignment "Security Group Creation and Membership_Organization Management" –Role "Security Group Creation and Membership" –SecurityGroup "Organization Management" New-ManagementRoleAssignment "Mail Recipient Creation_Recipient Management" –Role "Mail Recipient Creation" –SecurityGroup "Recipient Management" ausgeführt werden.

Diese Vorgehensweise hat auch den Charme, dass alle Systeme, bei denen Du sonst vergessen hättest, den DNS-Server umzutragen, weiterhin funktionieren.

Mich wundert es mittlerweile nicht mehr. Bin ich jetzt abgestumpft oder einfach nur Realist?

Das hat man ja auch zu Server 2019-RC-Zeiten vermutet, weil Microsoft die RDS-Rolle vergessen hat. Das wäre auf jeden Fall der richtige Weg (zumindest, wenn die Limits aufgehoben und nicht auf 10 oder 15 aufgeweicht werden). Und Server 2022 ist ja als TP schon da.