cj_berlin

vor 3 Stunden schrieb andrew:

 

 also \\DomainXY.Local\NETLOGON\Scripts\nameSkript,ps1 = Dieser Pfad steht im Feld Skriptname und im Feld Skriptparameter habe ich folgendes hineingeschrieben: -ExecutionPolicy Bypass

 

Das ist natürlich falsch. -ExecutionPolicy ist kein Parameter Deines Skripts, sondern ein Parameter von powershell.exe 

Ich muss die Reise planen, und im September werden sich die Projekte eh überschlagen, und dann ist irgendwann womöglich noch der PSDAY.UK (wenn man dann denn dorthin reisen kann). Außerdem ist die Anmeldung, die ich im Sinn habe, bereits offen  

Das ist richtig, aber die Webseite liest sich so, als ob es nur der Freitag wäre. Ich frag mal nach.

vor 5 Stunden schrieb kamikatze:

Habe heute mit Erstaunen gelesen dass dieses Jahr wieder die CIM in Lingen stattfindet. Mal gucken ob ich hinfahre

 

...aber diesmal irgendwie am Freitag?..

vor einer Stunde schrieb NorbertFe:

Man packt auf den zweiten DC auch DHCP? ;) 

Nein  Auch nicht auf den ersten. DHCP und Printserver packt man *nicht* auf einen DC. 

Falls der Benutzer lokaler Administrator ist, kannst Du gar nichts für ihn unterbinden.

Ich würde sagen, die Umleitung beim Provider ist zu rigoros vorgenommen worden, denn hinter der Autodiscover-Adresse verbirgt sich gar kein Exchange (mehr)...

Moin,

wie äußert sich "Empfangen nicht möglich" denn genau? Intern oder extern? Bei intern ist es evtl. die gecachte X.500-Adresse, die natürlich nicht mitgekommen ist.

Split Permissions prüfen:

• Container "Exchange Protected Groups" ist vorhanden und hat "Exchange Windows Permissions" drin
• Exchange Windows Permissions beinhaltet NICHT Exchange Trusted Subsystem

Eventuell wurden Split Permissions ursprünglich eingerichtet und dann zurück gerollt. In diesem Fall muss noch

New-ManagementRoleAssignment "Mail Recipient Creation_Organization Management" –Role "Mail Recipient Creation" –SecurityGroup "Organization Management"

New-ManagementRoleAssignment "Security Group Creation and Membership_Organization Management" –Role "Security Group Creation and Membership" –SecurityGroup "Organization Management"

New-ManagementRoleAssignment "Mail Recipient Creation_Recipient Management" –Role "Mail Recipient Creation" –SecurityGroup "Recipient Management"

ausgeführt werden.

vor einer Stunde schrieb testperson:

einen temporären Domain Controller aufsetzen und sobald der alte abgeschaltet ist, einen neuen Domain Controller mit altem Namen (und IP) bereitstellen und dort die (vorher exportierten) Shares wieder einrichten. Danach den temporären DC wieder entsorgen.

Diese Vorgehensweise hat auch den Charme, dass alle Systeme, bei denen Du sonst vergessen hättest, den DNS-Server umzutragen, weiterhin funktionieren.

vor 29 Minuten schrieb MurdocX:

Mich wundert nur, warum man eine Migration anfängt und sich erst währenddessen Gedanken darüber macht, statt von Anfang an.

Mich wundert es mittlerweile nicht mehr. Bin ich jetzt abgestumpft oder einfach nur Realist?

Das hat man ja auch zu Server 2019-RC-Zeiten vermutet, weil Microsoft die RDS-Rolle vergessen hat. Das wäre auf jeden Fall der richtige Weg (zumindest, wenn die Limits aufgehoben und nicht auf 10 oder 15 aufgeweicht werden).

Und Server 2022 ist ja als TP schon da.

Aber im Enterprise-Umfeld braucht das, was da vorgestellt wurde, definitiv kein Mensch.

Was mich ein bißchen bekümmert, ist die nun sehr hohe Divergenz in der GUI zwischen Server und Client. Aber bevor sie die neue GUI als Default auf jeden Infrastruktur-Server klatschen, sollen lieber die Terminalserver "altbacken" aussehen  

Moin,

da die Anwendung ja im Benutzer-Kontext startet, kann sie nicht vor der Anmeldung gestartet werden

Ansonsten schau Dir die Kosk Modes von Windows an: https://docs.microsoft.com/de-de/windows/configuration/kiosk-methods , vielleicht ist für Dich das Passende dabei...

Vermutlich sind für die Remote Domain die automatischen Weiterleitungen gesperrt (Get-RemoteDomain ist Dein Freund hier).

Ansonsten würde ich das eher mit Set-Mailbox -ForwardingAddress <...> -DeliverToMailboxAndForward $true (oder $false, wenn Du eh alle Mails nochmal migrieren willst) lösen.

Moin,

das kann an vier Stellen geregelt sein:

• Richtlinie am Host (GPO, LocalGPO, RDS-Bereitstellung)
• Einstellungen am Remote Desktop Gateway, falls dieser verwendet wird
• Einstellungen im AD-Objekt des Benutzers (Reiter "Environment")
• Einstellungen im Client bei Verbindungserstellung

Ja, das ist korrekt. Gern wird aber vergessen, dass der RDG ebenfalls zu den RDS-CAL-pflichtigen Funktionen gehört.

vor 3 Stunden schrieb Weingeist:

- User hat Windows PC und greift auf Desktop OS auf Server zu (Typisch VDI): Windows Client der zugreift muss Enterprise + SA haben, RDS CAL nicht notwendig

 

Das ist nur richtig, falls die VDI mit VMware, Citrix oder einer anderen Third Party betrieben wird. Kommt Microsoft-VDI zum Einsatz, und sei es nur der Remote Desktop-Gateway, ist tatsächlich eine RDS-CAL notwendig. 

nslookup im debug mode. Da siehst Du, wer was gefragt wird und was er antwortet.

vor 17 Minuten schrieb Peterzz:

Wird nicht beim Lizenzserveraktiveren eine Verbindung mit dem Microsoft Clearinghouse über das Internet hergestellt? 

Schon, aber das Clerainghouse hat ja keine Informationen darüber, was für Lizenzen Du irgendwo herum liegen hast  

vor 2 Minuten schrieb Peterzz:

Erkennt der RDS Lizenzserver auf dem 2019 automatisch die vorhanden User CALs?

Was meinst Du mit automatisch erkennen? Bei welchem Vorgang?

Wenn Du 2019er CALs im VL hast, spiel sie in den 2019er Server ein, dann sind sie aktiv.

Moin,

Du kannst ein Lizenzpaket einfach mit dem Wizard im RDS-Lizenzmanager auf einen Server der gleichen oder einer neueren Version umziehen, sofern beide Server gleichzeitig am Laufen und erreichbar sind. Das macht aber aus 2012er RDC-CALs keine 2019er RDS-CALs. Letztere musst Du, wie von @Nobbyaushb angeregt, aus dem VL neu beziehen, und dann gelten sie auch für ältere Versionen.

vor 3 Minuten schrieb scnugg:

Ich glaube wir meinen vielleicht tatsächlich verschiedene Dinge Ich rede davon, dass ich direkt auf dem Host bin und mich dann über den Hyper-V Manager mit den Desktop-VMs verbinde. Die Frage ist, ob man dann pro Desktop-VM lizenzrechtlich eine RDP-CAL benötigt um auf diese zugreifen zu "dürfen" und dort als Benutzer zu arbeiten.

Sobald in der Remote-Sitzung irgendwas passiert, was über die Verwaltung dieser Maschine hinausgeht, brauchst Du eine RDS-CAL (Server-OS) oder eine VDA / SA (Client-OS).

Moin,

eine mögliche Lösung wurde Dir bereits von @testperson präsentiert. Für das Client-Management gibt es aus Security-Sicht nur zwei valide Ansätze:

1. Classic Management: Der Client ist drin. Er ist Mitglied im AD und hat direkten Netzwerkzugriff auf Anwendungen und Ressourcen. Anwendungen sind lokal installiert. Zugriff auf externe Ressourcen ist geregelt durch Firewall, Webfilter, Proxy etc. Wenn der Client sich außerhalb des Netzes befindet, regelt die lokale Firewall auf dem Client den Zugriff so, dass die einzige Adresse, die direkt erreicht werden kann, die des VPN-Konzentrators ist. Der gesamte Traffic geht durch den VPN-Tunnel.
2. Der Client ist draußen. Er ist nicht Mitglied im AD und ist mit Modern Management gemanaged (WorkspaceONE, Intune, whatever). Die Arbeit wird auf Terminalservern / VDI verrichtet, der Zugriff auf diese mit einem Reverse Proxy (UAG, Netscaler, RDG, ...) abgesichert. Auch das Client-Netz im Firmengebäude ist als "untrusted" eingestuft. Keine Anwendungen auf dem Client, zumindest keine, die Daten verarbeiten.

Alle Mischformen zwischen diesen beiden Extremen sind Augenwischerei und Selbstbetrug. Und wenn man sich für das Szenario 2 entscheidet, kann man den Internetzugriff des Clients in einem vernünftigen Maße durchaus zulassen.

vor 33 Minuten schrieb scnugg:

Und das Windows in den VMs, auf die zugegriffen wird, muss dann unbedingt mit diesem ISO installiert und mit diesem Schlüssel aktiviert worden sein? Oder ist das optional? Danke.

Das ist beides optional. Nur kannst Du VDI nur mit KMS (technisch) sinnvoll betreiben, und KMS Keys gibt nur mit VL.