cj_berlin

Moin, solche "Kleinigkeiten" sind es, womit Citrix nach wie vor ein Schweinegeld verdient. Mit nativem RDS lautet Deine Antwort, wenig überraschend, TS03. Neue Session Collection, neuer TS, entsprechende Berechtigungen und fertig. Wenn es nur ein paar User sind, muss der Server ja auch nicht so groß dimensioniert sein. Alles andere ist eine Bastelei, die unmöglich ist, im Betrieb zu pflegen. Und wenn Du noch kein Verfahren hast, um einen "Standard-Terminalserver" innerhalb weniger Minuten bereitzustellen, dann wird's Zeit, das zu entwickeln. Diese Zeit ist nämlich besser investiert, als der Versuch, die produktive Farm für einen Test zu vergewaltigen.

Du musst die CSV vorher importieren und beim Durchlauf der Schleife abgleichen: Ist der User nicht drin, hinzufügen, ist der User drin und die letzte Erinnerung ist noch frisch, nix machen, ist der User drin und die letzte Erinnerung zu alt, aktualisieren und Mail schicken

Moin, Archiv, im Sinne des Exchange In-Situ-Archivs, ist *nicht* Bestandteil der OST. Das ist dort, wo viele Mobile Worker unterwegs sind, der Hauptgrund gegen diese Funktion. RegKey per @NorbertFe: https://support.microsoft.com/de-de/help/832925/how-to-configure-the-size-limit-for-both-pst-and-ost-files-in-outlook

Zeig mal wieder das komplette Skript mit allen Änderungen.

Was bekommst Du denn ausgegeben, wenn Du $UsersWithOldPasswordFromAD einfach an die Konsole ausgibst? EDIT: Ach, ich sehe: ArrayList... Mach mal für einen schnellen Test einfach ein Array daraus: $UsersWithOldPasswordFromAD = @()

...aber Software-Verteilung ist generell was, was man in einer wohlgemanagten Umgebung haben sollte Muss ja nicht gleich SCCM sein.

Zum Prüfen, ob ein Element in einer Sammlung enthalten ist, gibt es die Operatoren -in /-notin bzw. -contains/-notcontains . Wenn es Dir nur darum geht, ein Array mit Elementen zu ergänzen, die noch nicht drin sind, hier sind einige Techniken zusammengefasst: https://it-pro-berlin.de/2017/08/powershell-wie-schnell-sind-arrays/ EDIT: OK, habe jetzt gesehen, dass Du das Datum mitführen willst. Das kannst Du mit einem Custom Object machen, der die Properties sAMAccountName und LastDate hat. Also praktisch statt if ($PasswordAge -ge $WarningLevel) { $UsersWithOldPasswordFromAD += $ADUser.SamAccountName } so etwas wie if ($PasswordAge -ge $WarningLevel) { $UsersWithOldPasswordFromAD += [PSCustomObject]@{ 'sAMAccountName' = $ADUser.SamAccountName 'LastDate' = Get-Date } } Dann packst Du das alles in eine CSV mit Export-CSV. Beim nächsten Durchlauf importierst Du die CSV mit Import-CSV und machst in der Schleife dann so etwas wie $existingEntry = $UsersFromCSV.Where({$_.sAMAccoutnName -eq $ADUser.SamAccountName}) if ($existingEntry.Count -gt 0) { $LastReminderDays = ((Get-Date) - $existingEntry[0].LastDate).Days # je nachdem, wie lange her, nochmal erinnern und Datum aktualisieren } else { # anfügen }

Moin, die Domain-Funktionsebene konntest Du aber hochstufen? Was passiert, wenn Du die Aktion nicht vom ADAC, sondern von Users & Computers (Domäne) bzw. Domains & Trusts (Forest) vornimmst? Wie viele DCs sind insgesamt am Start? Leben alle noch? Funktioniert die Replikation?

Hoffentlich führt dieser Thread nicht dazu, dass Leute anfangen, ihre CAs auf Verdacht hin auf DCs zu installieren... Wobei natürlich, eine Issuing CA, die nur Smartcard-Zertifikate ausstellt, auf dem DC, und das Thema Revocation Lag bei SmartCards ist vom Tisch... Hmmm...

Set-OWAVirtualDirectory -LogonFormat PrincipalName

Schon, aber man kann ihn anweisen, die CRL häufiger zu ziehen als sie abläuft: Neu ausstellen muss man sie nach Sperrung eines Zertifikats natürlich manuell

Moin, das sind *zwei* Anwendungsfälle: wenn der User das Unternehmen verlässt, sperre sein Account im AD. Das wirkt sich auch auf die Smartcard-Authentifizierung aus. wenn er seinen Key verliert und Du wirklich nur das Zertifikat zurückziehen möchtest, muss der Domain Controller davon erfahren. Es geht also nicht um den CRL Cache auf den Clients, sondern auf den Domain Controllern.

Moin, zwei Punkte: CALs werden entweder pro Gerät (Physik) oder pro Benutzer (Physik) benötigt, und nicht pro AD-Account oder irgendetwas anderes. Ob sich Herr Müller überhaupt gegen das AD authentifiziert, ist unerheblich - er greift auf Dienste eines Windows Server Version XY zu, und braucht daher CALs in mindestens dieser Version. Positiv dabei ist: Herr Müller braucht sie nicht pro Server, sondern kann mit einer 2019er CAL auf alle Server 2019, 2016, 2012, 2008 usw. derselben Organisation zugreifen. Und auch "Organisation" ist in diesem Fall kaufmännisch zu verstehen und nicht mit einem AD-Forest o.ä. zu verwechseln Es gibt im Lizenzvertrag keinen "Mittelbaren Zugriff" auf Microsoft-Produkte. Wenn Herr Müllers MacBook auf eine Web-Applikation auf einem Linux-Server zugreift, der auf VMware ESXi virtualisiert ist, seine IP-Adresse aber von einem Windows DHCP-Server bekommt, braucht entweder Herr Müller oder sein Gerät eine CAL. So etwas wie ein Drucker braucht hingegen keine CAL, wenn er seine IP-Adresse von Windows-DHCP kriegt, sofern alle, die darauf drucken, eine User CAL haben.

Ich bin für 120 Aber auch danach passiert nix, außer, dass er warnt...

Bei mir hat das im GPO-Editor nicht funktioniert. Bei NTFS- oder Freigaberechten dagegen schon.

OK, also reden wir von dem gleichen, nur ich rechne in VMs und @lizenzdoc in Standard-Lizenzen Und ja, je nachdem wie man Break Even definiert, ist 12 oder 13 VMs Break Even.

Huch? https://www.microsoft.com/de-de/windows-server/pricing sagt: Standard = $972, also $486 pro VM, und DC = $6.155, somit 12,66x der Betrag. Wo ist der Fehler? Du bist der Profi

Die VMs sind für den Teil, wo mit Cores gerechnet wird, völlig uninteressant, denn die Windows Server-Lizenzierung gilt für das Blech. Die Anzahl VMs kommt dann ins Spiel, wenn Du entscheiden musst, ob Du Windows Server Datacenter brauchst oder mit Standard oder 2x Standard auskommst. *Dann* nimmst Du nämlich die maximale Anzahl Windows Sever-VMs, die zu irgendeinem Zeitpunkt theoretisch auf einem Host gleichzeitig laufen könnten. Liegt die Zahl über 12, ist Datacenter billiger. Liegt sie darunter, musst Du so oft Standard lizensieren, bis die doppelte Anzahl der Standard-Lizenzen über der Maximalzahl VMs liegt.

Gegenfrage: Was verwendest Du denn sonst?

...aber leider werden User *reportet* und nicht Menschen. Darüber muss man dann halt mit dem Auditor sprechen. Mit 2019 werden User CALs übrigens auch getrackt, daher wird das Halbieren evtl. nicht zum Ziel führen.

Hmmm. Ich habe es gerade aus Spaß im Labor ausprobiert. Der Session Host erbt nicht das Zertifikat vom Deployment, dieses ist in keinem Store vorhanden: Und dennoch wird bei der Verbindung... ...das Zertifikat des Deployments (und auch dessen Name) verwendet: Die einzige Anpassung, die ich gemacht habe, ist: aber das beseitigt *eigentlich* einen anderen Pop-Up. Der RD-Listener am Broker hat allerdings sehr wohl das Wildcard-Zertifikat gebunden. Na toll, jetzt kann ich keine Screenshots mehr posten. Aber eine andere Idee: Hat Dein Wildcard-Zertifikat den Wildcard-String auch im SAN oder evtl. nur im Subject?

Nein, User CALs in eine nicht vertrauende Domain pumpen kann der RDS-Lizenzserver nicht. Das ist das, wovon ich vorhin schrieb: Du brauchst einen Lizenzserver pro Forest und das Lizenzpaket somit 2x installiert.

Dann ist irgendwas mit Deinem Deployment nicht so wie es sein soll. Normalerweise spielen die individuellen Zertifikate der Hosts keine Rolle. Hast Du evtl. eine GPO für die Infrastruktur-Server, die zufällig auch auf Deine Farm wirkt und wo die Zertifikatsvorlage für RDP-Zertifikate festgelegt wird? Kannst Du die Session Hosts einmal aus dem Deployment entfernen und wieder hinzufügen? Oder einfach schnell eine VM in eine neue Session Collection stecken und schauen, ob das Problem immer noch auftritt?

Das allererste Beispiel sollte es tun.

Bestimmt nicht. Es gibt keine lebendigen Systeme mehr, die zwar .BAT, aber keine .CMD unterstützen Hier sind nette Beispiele für FTP-Skripte mit Windows-Bordmitteln: https://www.dostips.com/DtTipsFtpBatchScript.php