cj_berlin

Moin, damit ein Domänen-Rechner einer PKI vertraut, muss das Root-Zertifikat dieser PKI in seinem "Trusted Roots"-Store landen. Dafür gibt es vier Möglichkeiten: Registry = Du importierst einzeln Third Party = Microsoft importiert Group Policy = Group Policy Enterprise = DU veröffentlichst im LDAP Wenn also den Zertifikaten einer PKI in einem Forest vertraut werden soll, kannst Du zwischen den beiden unteren Varianten auswählen. Um Zertifikate zu beantragen, kannst Du natürlich Webservices einsetzen. Aber das Vertrauen muss trotzdem irgendwie hergestellt werden. In welche Richtung gehen denn die Trusts?

Moin, wenn Du in den Views die Spalte einfach nur mit ausgibst, ändert sich nichts (außer dem ausgegebenen Datentyp). Dort, wo Du die Spalte auswertest und/oder transformierst, muss die Bedingung/die Transformation datetime berücksichtigen statt nvarchar.

Moin, mit "Host" meinst Du vermutlich gerade nicht "Host" (das wäre ein ESXi, kein Windows Server), sondern "VM", richtig? Es spricht nichts gegen diese Vorgehensweise, wenn Du ein großes Volume brauchst.

Moin, Security Logs aller DCs nach Event 4624 durchsuchen und die Metadaten der Events auswerten. Damit das funktioniert, Auditing einschalten. Alternativ: Auf allen Clients die C:\Users\*\NTUSER.DAT auflisten und den Zeitstempel auswerten.

Hier noch der obligatorische Hinweis, dass DHCP **und** WDS sind beides keine guten Kandidaten um auf DCs ausgeführt zu werden.

In dieser Hinsicht schon. Als es den Symantec Mail Security Gateway noch gab, war die Standard-Einstellung im zweibeinigen Setup genau so: es gibt eine Liste interner SMTP-Domains es gibt ein externes und ein internes Bein Mails mit Absendern (From: Header und/oder MAIL FROM:) aus internen Domains auf dem externen Bein werden sofort verworfen Mails ohne From: Header werden sofort verworfen Natürlich hat es den Leuten nicht gefallen, funktioniert hat es aber. So ziemlich das einzig gute, was ich über dieses Produkt sagen kann.

Das hilft aber nicht, wenn die Mail über den internen Connector reinkommt, aber nicht von dem angegebenen Absender stammt... Aber besser das als nichts. Vernünftige Mail-Gateways werden in der Regel eine vermeintlich interne Mail auf dem externen Bein gar nicht erst reinlassen.

Du meinst sicherlich, ihr habt eine interne PKI und nutzt die von dieser signierten Zertifikate? Selbstsigniert ist etwas anderes. In Outlook gibt es diese Möglichkeit nicht. Du könntest ein Makro schreiben, das beim Absenden feuert, schaut, an wen die Mail geht und dann signiert, falls intern. Was machst Du, falls eine Mail sowohl interne als auch externe Empfänger hat? Und habt ihr keine anderen Clients außer Outlook? OWA? Mobiltelefone? Mit denen wird alles, was Du für Outlook zusammengebastelt bekommst, nicht funktionieren... Was wäre so schlimm daran, Mails generell zu signieren, außer dass manche Leute anfangen könnten, euch verschlüsselte Mails zu senden? Man müsste einen CDP öffentlich verfügbar machen, aber es ist ja nur ein Webserver, auf dem zwei bis drei Dateien liegen...

Ja, sicher. Ist auch des Öfteren passiert, auch mit nennenswerter Belastung (VMs, Migrationstools usw.)

Moin, Du machst Dir das Leben viel zu schwer Wie wäre es mit der folgenden Modifikation: Die VM hat alle FSMO-Rollen inne An dem Tag, wo Du ein Backup der VM über den Air Gap schickst, zwingst Du alle Member (die online sind, also zumindest alle Server) ihr Computer-Kennwort zu ändern Wenn der Ernstfall kommt, machst Du folgendes: Physische DCs platt machen VM wiederherstellen Physische DCs aus den Metadaten bereinigen Physische DCs mit den alten Namen und IP-Adressen wieder promoten glücklich sein und Dich anspruchsvolleren Aufgaben zuwenden, die in solch einem Fall anfallen Das ganze beruht natürlich darauf, dass Du von den Membern irgendwie ein sauberes Bare Metal-Backup hast, denn diese werden vermutlich noch vor den DCs verschlüsselt, und selbst wenn nicht, Persistence kannst Du auf Membern doch auch nicht ausschließen, wenn die Umgebung schon befallen ist...

Danke! Und falls jemand von den "Enterbten" das doch noch einmal versuchen möchte - sagt bescheid

Moin, ohne Hybrid wird es schwierig. Also, um genau zu sein, ist es ohne Hybrid gar nicht vorgesehen.

So halte ich es auch. Mein Schwiegervater ist auch nach Jahren noch pissed, aber da muss er durch

...und Du hast natürlich ESU für Deinen Server 2008 abgeschlossen, damit er weiter gepatcht und vor Bedrohungen geschützt wird?

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