cj_berlin

Noch nicht (aber ich bin ja auch nicht in der Runde). Gemunkelt wird, dass wir am Abend vor der Ignite (und der Rest der Welt dann am nächsten Tag) was hören könnten... Und übrigens, wie von @NorbertFe bereits angerissen: Inplace oder nicht, es ist aber schwer denkbar, dass Exchange jemals ein Inplace-Upgrade des darunterliegenden OS erlauben wird. Daher: Upgrade heute: 2016 auf 2012R2 -(Migration)-> 2019 auf 2019 -(Inplace)-> vNext auf 2019 ==> EOL = 09.01.2029 wegen Server 2019 Upgrade nächstes Jahr: 2016 auf 2012R2 -(Migration)-> vNext auf 2022 (vermutlich/hoffentlich) ==> EOL = 14.10.2031

OK, also ihr macht - entweder jetzt eine Migration, mit der ihr nichts gewinnt, und später (aber bis Oktober 2025) vielleicht ein Inplace, das vielleicht gelingt, vielleicht aber auch nicht - oder später (aber bis Oktober 2025) eine Migration, die höchstwahrscheinlich gelingt. Heißt, ihr wollt bis 2025 zwei Schritte machen, von denen einer für Exchange absolut neu ist, statt einem, der nach dem bekannten und erprobten Schema ablaufen wird?

Nur aus Interesse: Welches Killer-Feature treibt euch dazu? Ansonsten, wie bereits mehrfach angemerkt: Die Supportability Matrix ist die Bibel. Was nicht drauf steht, ist NICHT supported.

In der Berliner Verwaltung sagt man dazu "Probeechtbetrieb".

Ich kenne ganz viele, aber bei der Hälfte stehen in dieser sogenannten DMZ dann virtuelle Systeme, die Mitglied im AD sind Und wenn man dann sagt "Nein, Sie haben keine DMZ, sondern nur ein LAN-Segment mit Öffnung nach außen", sagen sie dann "aber der Hypervisor ist getrennt, und die Switche auch"...

Anscheinend haben die Jungs das vergessen Ich finde das zumindest nicht.

Auch für DataCenter-Kunden tickt schon die Uhr:

Moin, Get-ACL / Set-ACL oder, besser, https://www.powershellgallery.com/packages/NTFSSecurity

Verstehe ich nicht. Wenn das VPN Verbindungen zu einem Host zulässt, warum sollte es keine Verbindungen zu mehreren Hosts zulassen können?

Hmm. Aber warum können die VPN-Clients nicht jetzt schon auf die gesamte Farm zugreifen? Funktioniert die Namensauflösung nicht oder haben die VPN-Clients nicht auf alle Server der RDS-Bereitstellung Zugriff?

Moin, es heißt "Broker" mstsc /admin funktioniert nur, wenn der Zugreifende lokaler Admin auf dem Zielserver ist ist der Zugreifende nicht Admin, kannst Du den Broker nicht umgehen Lösungen: Zugriff auf die gesamte Farm per VPN ermöglichen Auf VPN verzichten und RDG einsetzen, macht das ganze auch performanter Den Standalone-Terminalserver nicht als Teil einer Farm bereitstellen.

Du verwechselst hier Ursache und Wirkung. Die Frage sollte lauten "Habe ich eine Chance, die CCNA-Prüfung zu bestehen, wenn keine CISCO-Erfahrung vorhanden ist, nur mit allgemeinem Wissen zu Switching & Routing? Ich habe es selbst noch nie versucht, habe aber die Prüfungsunterlagen mal gelesen und würde daher sagen, eher nein.

Doku lesen, siehe obigen Link. Dort wird der Parameter -Credential beschrieben, der die Authentifizierung ermöglicht.

Dann ist es vermutlich die Firewall

Moin, beschreib doch mal, was Du genau versuchst und was Du dabei genau siehst, Fehlermeldungen etc.

Weil es vermutlich um die Authentifizierung der User gegenüber der Webseite geht und nicht um das Vertrauen in das Zertifikat der Webseite

Moin, da Du ein Secret (private key) an jeden verteilen möchtest, der zufällig im Scope ist, geht es per GPO nicht. Aus dem gleichen Grund, warum man keine User mehr per GPO anlegen kann. Bleibt also nur Skript, und in diesem ist das PFX-Kennwort entweder im Klartext gespeichert, oder Du findest eine andere Möglichkeit VG

Moin, viele Notebook-Modelle haben diese Funktion im BIOS. Das wäre mit Sicherheit zuverlässiger, als irgendwelche Skripte aus dem Event Log zu feuern.

Das kann ich gerade weder hier noch woanders herauslesen. Es gibt aus meiner Sicht "nur" zwei stichhaltige Gründe, Server 2022 nicht als Domain Controller zu verwenden: Fehlender Support durch angeschlossene Anwendungen. Keine derzeit gültige Exchange-Version unterstützt zum Beispiel 2022er Domain Controller. Fehlende Treiber, falls ein Domain Controller auf Blech bereitgestellt werden soll. Allerdings fällt es mir schwer zu glauben, dass bei halbwegs aktuellen Server-Modellen Hardware verbaut wurde, für die ein Treiber fehlt. Magst Du deine Konfiguration grob beschreiben?

Wenn man wirklich nur für den Fall "Server wird geklaut" vorsorgen möchte, ist es auch im Server-Bereich durchaus praktikabel.

Jein. Network Unlock kann da durchaus helfen.

JA, deswegen macht man das entweder in Rotation (wenn man mehrere DCs hat) oder mit einem Interim-Server.

Kommt auf den Protector darauf an, den Du am Server einstellst. Wenn Du TPM+PIN beim Booten verlangst, ist es auch gut, wenn Platten MIT Server geklaut werden

Klar, BitLocker ist eine Volume-Verschlüsselung. Wenn eine Platte entsperrt ist, können alle Dienste auf die Daten dieser Platte zugreifen.

An dieser Stelle würde ich versuchen, RDP komplett nur über UDP zu fahren. Da haben Paketverluste zwar Audio-/Video-Artefakte zur Folge, aber die Stabilität der Sitzungen dürfte weniger von Paketverlusten beeinträchtigt sein. Hat diese Büchse auch eine GPU und die RemoteFX-Vorbereitung?