cj_berlin

Die meisten, die mich kennen, trauen sich nicht, die Frage zu stellen.

Ja. Wenn das halbwegs sauber gemanagt wurde, dann müsste ja jeder Server, der das Zertifikat hat, unter einem der FQDNs in den SANs dieses Zertifikats zu finden sein In der realen Welt, wenn Du den SHA-1 Thumbprinmt des Zertifikats hast, kannst Du Invoke-Command -ComputerName @("SERVER01","SERVER02") -ScriptBlock {Get-ChildItem Cert:\LocalMachine\My\<Thumbprint> -EA SilentlyContinue} abschießen. In der rechten Spalte siehst Du dann die Namen der Server, die das Zertifikat haben

Das Stichwort, das Du suchst, ist "User Account Control".

Das ist vielleicht gar nicht über Exchange gemacht worden. Doch selbst wenn, würde ich sagen, mit vertretbarem Aufwand nein.

Moin, Verteiler sind Gruppen (außer Dynamic Distribution Lists). Somit gilt für die Vorgänge das normale Auditing der Gruppenmitgliedschaften. Das kannst Du auf Deinen Domain Controllern aktivieren und aus den Event Logs ablesen: Audit Security Group Management - Windows Security | Microsoft Learn Audit Distribution Group Management - Windows Security | Microsoft Learn

Moin, nein, da muss man nichts aufräumen. Du hast dringlichere Aufgaben in Deiner Infrastruktur. Den Haken bei "Use root hints if forwarder is not available" rausnehmen und/oder die Linux-DNS als Root Hints eintragen und glücklich sein.

Moin, bitte schön: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/root-hints-reappear-after-removed

Was Nils gesagt hat. Allerdings bringt die Installation von SQL Server ein paar weitere Pakete mit sich, die durch die Deinstallation der Instanz nicht entfernt werden. Bevor Du sie aus "Programme und Features" deinstallierst, schau auf das Installationsdatum - es kann sein, dass sie für eine andere Anwendung benötigt werden und gar nicht mit dem SQL Server installiert wurden.

Bestimmt einfach nur gehofft, dass noch jemand kommt, um den Trester wegzubringen, und dann aufgegeben

Moin, nur damit es nicht ungesagt bleibt: seit Server 2016 ist es möglich, SPNs auch auf IP-basis zu vergeben und den Client per Registry anzuweisen, solche Service-Tickets anzufordern - das muss man aber halt tun wenn man aus irgendeinem Grund auf DNS nicht umstellen kann oder möchte, ist es durchaus möglich, die Anmeldung am Anmelde-Screen des Zielsystems durchzuführen statt per Pass-Through vom Client wenn man bereits am Client mit einem Konto angemeldet ist, das in die "Protected Users" gehört und aufgenommen wurde, und dieses Konto auch am Zielsystem verwenden möchte >>> Remote Credential Guard verwenden!

Da überschätzt Du, fürchte ich, das Interesse von Microsoft am Erbringen von Dienstleistungen und am Kennen von Umgebungen abgesehen von der eigenen Cloud In welcher Geographie?

Habe ich seit 1998 nicht mehr im Hause.

<OT>Außer CPU, gell? Da darf man 7:1 overcommitten SCNR </OT>

Ja, mit einer zweiten LUN ist alles kein Problem. Wir wissen aber noch nicht, ob es möglich ist.

Nicht ganz VMs herunterfahren - check VMs aus dem Hyper-V Manager entfernen - ich wüsste nicht, wie, denn dann löscht er die Konfiguration, und die ist vielleicht wertvoll Cluster aufbauen Storage als CSV präsentieren --> an dieser Stelle ändern sich die Pfade zu allen Dateien ganz von alleine, weil der Einstiegspunkt für das Volume aus Sicht dses Betriebssystems sich ändert Alle VMs im Hyper-V-Manager bzw. im Failover Cluster Manager importieren --> der Erfolg dieser Maßnahme wird davon abhängen, wie die Dateien der VMs im jetzigen Filesystem verteilt sind Ich empfehle Dir, wenn Du so etwas noch nie gemacht hast, das mit VMs zu spielen - zwei VMs als Hosts, eine VM als Storage, über iSCSI einbinden ist schnell gemacht, und Du weißt in etwa, wovon hier die ganze Zeit die Rede ist. Du musst die verschachtelten VMs ja nicht starten EDIT: In jedem Fall musst Du vorher für ein validiertes Backup sorgen!

ReFS bedeutet, dass nur ein Host schreiben kann (Redirected Mode=: Use Cluster Shared Volumes in a failover cluster | Microsoft Learn Unabhängig davon, musst Du alle VMs neu importieren, da sich die Pfade verändern (C:\ClusterStorage\Volume0\...)

Weiß ich nicht, ist so Oder war zumindest so, dass die Daten dann weg waren - und selbst wenn nicht, dann ändern sich ja zwangsläufig ALLE Pfade.

Moin, ein NTFS-Volume wird sich nicht ohne Datenverlust in ein Cluster Shared Volume konvertieren lassen. Wenn auf dem SAN noch Platz ist, dann ein zweites Volume anlegen, als Cluster Shared Volume eininden und die VMs umziehen.

Moin, Probleme mit Protected Users treten immer dann auf, wenn a. Sessions über 4h Dauer zwingend nötig sind (z.B. lang laufende Skripte) b. NTLM und/oder RC4 verwendet werden muss, weil das Zielsystem nichts besseres beherrscht c. Offline-Loginfähigkeit erwartet wird Alle Konten, die irgendwie privilegiert sind, sind da gut aufgehoben, solange die oberen drei Fälle kein Problem darstellen. EDIT: In allen drei Fällen gilt der Nebensatz ", aber dann hast Du ein anderes Problem, nämlich in Deinen Management-Prozessen" Und ja, ich weiß, die Sätze "Geht nicht" und "Geht bei uns nicht" werden auf dem Grabstein jedes Consultants stehen.

Wenn AppID und AppSecret verlangt werden, ist es nicht OAUTH, zumindest nicht mit den von Dir genannten Protokollen: https://learn.microsoft.com/de-de/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth

Habe ich jetzt nicht verstanden, aber Du wirst es schon ordentlich recherchiert haben. Was ist mit dem Referrals-Parameter? Habt ihr das versucht zu aktivieren und brachte das irgendeine Änderung? Das sollte eigentlich genau dafür da sein...

Moin, viel von ClearPass gehört, nie live gesehen, aber nach dem Überfliegen des Artikels (auf dem Phone) mal ganz b***d gefragt: kann man nicht zwei AD-basierte Authentication Sources hinzufügen?

Magst Du mal auf konkrete Ressourcen/Passagen in der CU-Beschreibung hinweisen, die Dich zu dieser Annahme verleitet haben?

So isses.

Also quasi den Job erledigt, für den sie bezahlt werden