Alle Aktivitäten

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.

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.)

Nachdem Microsoft langsam rumdrängelt mit seinen Artikeln, dachte ich, ich poste den Link hier dann mal für alle, die es bisher nicht mitbekommen haben: https://techcommunity.microsoft.com/blog/exchange/t-1-month-exchange-server-2016-and-exchange-server-2019-end-of-support/4453133 Erst 3 Jahre Zeit verzögern und jetzt drängeln. Ganz mein Humor ;)

Wenn Du noch selbst einkaufen gehst und nicht alles liefern lässt, kannst Du Weihnachten nicht übersehen - geht schon los in den großen Supermärkten... Ist nur unsere fortgeschrittene Expertise in Prokrastination, die das zum Problem werden lässt

Also zumindest kannst Du dich dann schon mal an die Agilität der dynamischen Gruppen in Entra ID gewöhnen, solltest Du diese mal benötigen

Bekommst du sie nicht hin? Wir wissen es nicht. Liest sich jedenfalls bisher so. Also ja, du bekommst die Attributfilterung nicht hin. Und wenn du ein wenig mehr Infos in deine Anfrage und die Nachfragen deiner Helfer schreiben würdest, würde man auch keine blöden Antworten bekommen.

Dann wirst du mit nem RecipientFilter auf "EmailAddresses" filtern müssen, sofern das machbar ist oder eben meinen Ansatz wählen. Wo klemmt es denn bei deinem bisherigen Ansatz?

Ok, das wäre dann durchaus eine Erklärung... Nächstes mal bin ich (hoffentlich) schlauer

Ich wäre skeptisch, ob MSFT Webcast irgendwas mit Microsoft zu tun hat.

-RecipientFilter "(PrimarySmtpAddress -like '*@vg1.de')" oder so ähnlich