Alle Aktivitäten

Das kannst du so argumentieren und handhaben. Wie viel Arbeit ist es aber, das "kurz" in ein GPO zu packen und auf alle Systeme auszurollen? Lohnt es da "groß zu diskutieren" bzw. Energie in die Abwägung zu stecken?

Hi, oder auch: Kein RDP oder File Share mehr nach letzten Windows Update (LSA(LsaSrv) Event ID 6167) - Microsoft Q&A Es findet sich zum September Patchday unter Server 2025 / Win 11 24H2 recht viel in diese Richtung. Gruß Jan

Hast du evtl. das SMBv1 Problem was mit den September Updates mal wieder da ist? Nur als Idee Windows 10/11: September 2025-Updates verursachen SMBv1-ProblemeBorns IT- und Windows-Blog

Moin, ich wollte nicht in Abrede stellen, dass deine Gründe valide sind. Und als ich meinte, du musst die angehen - erstens weißt du das ja, und zweitens ist auch klar, dass das nicht so einfach in deiner Macht liegt. Davon solltest du dich aber nicht hindern lassen, den Teil, den du kontrollieren kannst, für dich sinnvoll zu bauen. Das eine tun, ohne das andere zu lassen. Ich rate dabei aber, nicht zu viel auf einmal zu wollen. Sonst wirst du nie fertig, und du baust dir deine eigene Überforderung. IT-Sicherheit kann man immer noch mal besser machen, aber genau das ist der Punkt: Es ist ein Prozess. Mach Dinge Schritt für Schritt. Viele Risiken, die es grundsätzlich gibt, sind in einer konkreten Situation gar nicht relevant oder recht unwahrscheinlich, die muss man dann auch nicht im ersten Schritt ausschalten. Nein, würde man nicht. Das sind unterschiedliche Netze. Die Hosts haben ein eigenes Betriebssystem und einen eigenen Netzwerkstack, der mit denen der VMs nichts zu tun hat. Da das in Hyper-V leider nicht besonders übersichtlich gebaut ist und da auch viele Internet-Quellen das nicht gut darstellen, hab ich das mal selbst beschrieben. Das ist im Detail zwar nicht mehr ganz aktuell, die Grundzüge sind aber noch dieselben. [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Finde den Fehler. Du verheimlichst uns was. ;) Kopier das doch einfach vollständig aus der Exchange Shell raus, mit Prompt zu Beginn und am Ende.

Hi, 2x Windows 1124H2 mit aktuellen Updates. Auf einem PC ist das Datenlaufwerk via "D%" freigegeben! Seit einem der letzte MS Updates funktioniert der SMB Zugriff vom anderen PC nicht mehr! Auf beiden Systemen befindet sich ein gleichnamiges Benutzerkonto (mit Adminrechten) und auch die Kennwörter sind identisch! Das Security Eventlog wirft folgendes aus: Bei der Anmeldung ist ein Fehler aufgetreten (Ereignis-ID: 4625)! Diese ID sieht man auch, wenn man ein falsches Kennwort eingibt, allerdings ist dann der Fehlertext ein anderer (Benutzername oder Kennwort falsch)! Was wir schon alles probiert haben: - Die Anmeldeinformationsverwaltung geleert und beide Systeme neugestartet - Die Verbindung über andere Accounts (z.B. den integrierten Administrator) probiert - Verschiedene Schreibweisen ausprobiert (\\smbserver_hostname\username) oder (\\smbserver_ip\username) oder auch nur (username) - Eine neue sichtbare Freigabe erstellt - Insecure Guest Logins erlaubt (https://learn.microsoft.com/en-us/answers/questions/2189515/windows-11-24h2-and-insecure-guest-logins-settings?forum=windowsclient-all&referrer=answers) Fällt sonst noch Jemandem etwas dazu ein, oder muss man da jetzt mit Wireshark ran? Danke!

Da gebe ich dir ja absolut recht, aber wie soll man sowas lösen? Ich habe zum Thema "Rechenzentrum" schon Dinge mitbekommen, die darf man niemandem erzählen... Zumindest mich hat die Geschichte mit Südwestfalen-IT kein bisschen erstaunt, es wundert mich eher dass da nicht noch mehr kam in letzter Zeit. Wenn ich den Admin Approval Mode für den Built-In Admin aktivieren würde, wäre Veeam ja nicht mehr in der Lage sich am Hyper-V-Host anzumelden. Wie gesagt, Veeam außerhalb Domäne = entweder Built-In Admin oder UAC deaktivieren. Ist b***d, aber laut Veeam nicht zu ändern. Scheint auf jeden Fall zu funktionieren, habe mal ne Deny-All Inbound am Hyper-V-Host für eine Client-IP erstellt. Zugriff war vom entsprechenden Client auf den Hyper-V-Host nicht mehr möglich. Aber warum sollte ich das ganze auf den restlichen System umgekehrt auch implementieren? Wer erfolgreich am Hyper-V-Host ist kann ohne Probleme auf alle Server-VM's zugreifen, da hilft die Firewallregel nichts. Die einzigen Server bei denen das Sinn machen würde wären doch höchstens der Veeam Server und der physische DC? Oder habe ich da einen Denkfehler?

OK, ich kann die Gründe durchaus nachvollziehen, aber die Lösung kann dann doch nicht sein, das nächste "suboptimale" Konstrukt in Betrieb zu nehmen. Aber jeder wie er mag.

Klingt schon mal nach ner Idee... Also auf den Hyper-V-Hosts Deny für alle IP-Adressen der Hosts und Clients, abgesehen vom Backup-Server und dem Backup-Proxy... Aber würde ich damit dann nicht nur das Management-Netz der Hyper-V-Hosts beschränken, sondern auch das VM-Netz? Das wäre natürlich dann ziemlich b***d Wäre natürlich auch recht Wartungsintensiv in Sachen neue Hosts/Clients, je nach IP Range.

An der Stelle könnte man darüber nachdenken, an den Hyper-V Hosts - losgelöst ob Domain / Workgroup - per Windows Firewall eine Deny In- / Outbound Regel zu erstellen, die eben die IP Range(s) der Workloads / restlichen Systeme abdeckt. Auf den restlichen Systemen wird das Ruleset dann einfach "umgekehrt" implementiert. Zwischen Hyper-V Hosts und Veeam Server bzw. ggfs. zwischen Veema Server und Workloads müsstest du dann etwas granularer rangehen. Bzw. auch wenn die Hosts in der Domain sind.

Die "Gründe" sind einfach; wir hängen an einem Rechenzentrum das die Firewall und das damit verbundene Routing kontrolliert. Da komme ich nicht dran. Leider reicht auch mein Know-How nicht aus, um z.B. einfach mal noch ne zweite Firewall "davor" zu setzen im Produktivnetz. Und Hilfe darf man da leider nicht erwarten, da ist Personal dünn gesät und gutes erst recht... Ich muss also erstmal mit dem klar kommen was ich habe und was ich beeinflussen kann.

Moin, wenn du schon auf der Ebene nachdenkst und argumentierst - was sinnvoll ist -, dann solltest du in Betracht ziehen, einen separaten Infrastruktur-Forest für deine Host-Umgebung einzurichten. Dort hast du dann die Vorteile der Domänenverwaltung und kannst die Domäne getrennt von deiner Produktionsdomäne absichern. Sollte es dort dann ein Problem geben, ist der andere Forest nicht automatisch mit korrumpiert. Ich stimme aber auch Jan zu - das Niveau, das du erreichen willst, ist mit den "Gründen", die du nebulös anführst, nicht vereinbar. An die wirst du auch ran müssen. Gruß, Nils

Hi, ich würde - losgelöst von Workgroup / Domain - ASAP "Gründe" beseitigen. Die Frage wäre, ob man den Admin Approval Mode nicht generell auch für den Built-In Admin aktiviert (User Account Control Admin Approval Mode for the Built-in Administrator account - Windows 10 | Microsoft Learn). Gruß Jan

Ja, da liegst du schon richtig. Es war auf jeden Fall der Gedanke, die Sicherheit damit etwas zu verbessern. Leider sind da halt dann die oben genannten Dinge, die das ganze dann wieder ins Gegenteil verdrehen... Ich hätte kein Problem mit zurück auf Anfang, dafür habe ich das ganze ja erstmal eher als Test aufgesetzt. Zurzeit habe ich ehrlich gesagt eher nicht die Einschätzung, dass der Hyper-V-Cluster in der Workgroup unter den oben genannten Voraussetzungen eine große Verbesserung der Sicherheit darstellt im Gegensatz zur Domänenmitgliedschaft.

Fragen wir doch mal, was du dir vom Workgroup Cluster versprichst. Meiner Erfahrung nach, dürfte das in vielen Umgebungen nicht zwingend zu mehr Sicherheit sondern zu mehr Umgehungslösungen führen. Die Diskussion dazu im anderen Thread führte ja offenbar zu deiner Testumgebung. Evtl. nochmal zurück an den Anfang?

Vielleicht liegts ja daran ;)

Hallo Leute, ich schon wieder, sorry dass ich hier das Forum gerade mit meine Fragen bombardiere Aber ich muss hier Entscheidungen treffen mit denen ich dann vermutlich einige Jahre leben muss, daher ist jede Hilfe wertvoll. In dem Thread hier (https://www.mcseboard.de/topic/231670-frage-2-hyper-v-hosts-an-einem-san/) waren ja schon einige Stimmen pro und contra Hyper-V-Cluster in der Workgroup zu lesen. Leider hat sich jetzt durch Veeam B&R ein weiteres unschönes Problem ergeben; um einen Hyper-V-Workgroup-Cluster zu sichern, muss man auf den Hyper-V-Hosts entweder die Remote-UAC ausschalten oder für die Verbindung von Veeam zum Cluster DEN Administrator-Account auf den Hyper-V-Hosts nutzen. Eigentlich mal wieder zwei Dinge die man NICHT tun sollte... Jetzt stellt sich für mich die Frage welche Kröte ich schlucke; die oben genannten Fakten des Workgroup-Clusters oder packe ich den Cluster in meine Domain, wo ich alle Admin-Konten in den Protected Users habe (bis auf den einen, dessen PW liegt im Tresor), aber auch alle anderen Nachteile der Domänenmitgliedschaft habe; und eben auch die Vorteile der Verwaltbarkeit. Leider ist Netzwerksegmentierung und damit ein Management-VLAN aus Gründen (noch) nicht möglich, daher ist das derzeit keine Option die die Sicherheit erhöhen würde. Ich erwarte hier natürlich nicht "die Lösung" des Problems, letztendlich muss ich das ja selbst entscheiden. Ich würde aber gerne mal verschiedene Meinungen dazu hören, schadet ja nie...

Hi TM, habe ich auch versucht - kommt dasselbe: $FTE = Get-DynamicDistributionGroup -Identity "AllUsers" Get-Recipient -RecipientPreviewFilter ($FTE.RecipientFilter) $FTE = Get-DynamicDistributionGroup -Identity "AllUsers" Get-Recipient -RecipientPreviewFilter ($FTE.RecipientFilter) Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'AllUsers' nicht auf 'dc.domain.de' gefunden wurde. + CategoryInfo : NotSpecified: (:) [Get-DynamicDistributionGroup], ManagementObjectNotFoundException + FullyQualifiedErrorId : [Server=Exchange,RequestId=629692342325-345d-423-348-45453345345,TimeStamp=15.09.2025 11:11: 56] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] EB6E08FA,Microsoft.Exchange.Management.RecipientTas ks.GetDistributionGroupMember + PSComputerName : Exchange.domain.de

Du hast ja auch eine "New-DynamicDistributionGroup" erstellt und keine "Get-DistributionGroupMember". Siehe: View members of a dynamic distribution group | Microsoft Learn

Hi, also hier der Versuch: (angelegt auf dem Exchange - Fehler?) New-DynamicDistributionGroup -Name "AllUsersVG1" -Alias "AllUsersVG1" -PrimarySmtpAddress "AllUsers@vg1.de" -RecipientFilter "(PrimarySmtpAddress -like '*@VG1.de')" Er legt die Gruppe an. (Get-DynamicDistributionGroup ok Wenn ich jetzt schauen möchte wer drinnen ist, bekomme ich die Fehlermeldung: Get-DistributionGroupMember -Identity "AllUsersVG1" Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'AllUsers' nicht auf 'dc.domain.de' gefunden wurde. + CategoryInfo : InvalidData: (:) [Get-DistributionGroupMember], ManagementObjectNotFoundException + FullyQualifiedErrorId : [Server=Exchange,RequestId=629692342325-345d-423-348-45453345345,TimeStamp=15.09.2025 11:11: 56] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] EB6E08FA,Microsoft.Exchange.Management.RecipientTas ks.GetDistributionGroupMember + PSComputerName : Exchange.domain.de ?? Danke!

Moin an Board, so starten wir dann in den Tag - ich koche Kaffee Allen einen erfolgreichen Dienstag, bleibt gesund! Hier noch bedeckt bei 14°C die sich wie 8°C anfühlen Es wird ein windiger und regnerischer Tag bis etwa 18°C

Ja komisch. Alle sagen da kommt ne Wand und MS sagt wenn ihr vorher mit 200km/h rechtzeitig abbremst reicht da ja. ;)

Oh ja, Lebkuchen, Stollen und Co. liegen bei uns schon seit Anfang August aus. Wenn das so weitergeht, liegen bald die ersten Schoko-Hasen "zwischen den Jahren" im Regal. Natürlich nur zur Erinnerung für die Prokrastinations-Experten. VG Damian

Na ja, immerhin warnen sie VOR dem Ende, nicht NACHHER. VG Damian

OT: Einfach zwei, drei Mal am Tag laufen lassen Update-MgGroup -GroupId <Id> -MembershipRuleProcessingState Paused Start-Sleep -Seconds 5 Update-MgGroup -GroupId <Id> -MembershipRuleProcessingState On (Bei dynamischen Gruppen für Autopilot Geräte bzw. fürs Deployment Profil kann ich mal noch nicht über langsame Updates der Mitglieder klagen.)