cj_berlin

Moin, da musst Du schauen, wie Du die Windows 10-Maschine in diesem Konstrukt lizenziert bekommst. Aus Sicht des Essentials ist es in Ordnung, er darf virtuell betrieben werden.

Moin, im Volume Licensing Service Center sind alle ISOs zum Download vorhanden. Falls Du keine Volumenlizenz hast, musst Du denjenigen fragen, der Dir die Lizenz verkauft hat, welche Dich zum Upgrade berechtigt.

Das VPN von der Fritz!Box erfordert unter Windows eine eigene Client-Software. Als Beispiel für eine Alternative hier ein ausführliches Tutorial, wie man ein IPSec-VPN mit pfSense einrichtet.

Und die nächste Frage: Sind die Clients alle Windows oder sind auch andere Betriebssysteme dabei? Windows beherrscht von Hause aus Standardverfahren PPTP, L2TP und IPSec plus noch spezifische Verfahren wie AlwaysOn-VPN. Abhängig davon, was die Clients auf dem Server tun sollen, ist VPN ggfls. nicht die beste Lösung. Oft ist ein Terminalserver und ein Remote Desktop-Gateway besser geeignet - z.B. wenn die fragliche Anwendung empfindlich gegenüber Latenzen oder Paketverlust ist.

Moin, also funktioniert anscheinend eher der Zeitclient nicht auf Deinem DC Wir hatten vor ein paar Tagen hier einen Thread zu dem Thema. Dort gab es einige Tipps zum Troubleshooting. Speziell Logging einschalten und mit /stripchart die Konnektivität prüfen. Versuche das bitte umzusetzen und poste, falls das immer noch kein Licht ins Dunkle bringt, die Ausgaben hier. Nachtrag: Hier der Thread.

Ja, kann man. Schau Dir folgende Schnipsel an: [datetime]::IsLeapYear('1972') [datetime]::IsLeapYear('2001') [datetime]::DaysInMonth(1972,2) [datetime]::DaysInMonth(2001,2) $today = Get-Date $today.DayOfWeek $today.DayOfWeek.value__ $tomorrow = $today.AddDays(1) $yesterday = $today.AddDays(-1) $newyear = Get-Date -Year ($today.Year + 1) -Month 1 -Day 1 -Hour 0 -Minute 0 -Second 0 Get-Date | fl *

Ordner sehen und gemappt bekommen sind zwei verschiedene Dinge, oder? Das Sehen erreichst Du mit Zugriffsrechten, da braucht es kein Skript. Und jeder, der wenigstens das Recht hat, Ordner aufzulisten, wird alle persönlichen Ordner sehen, auch wenn er sie nicht öffnen kann... Wie die GPOs cross-domain funktionieren, musst Du auch berücksichtigen. Wenn auf dem Terminalserver Loopback Processing aktiviert ist, dann gilt nur die Policy aus der Domain, wo der Server steht, auch wenn es sich dabei um Benutzer-Einstellungen handelt. Andernfalls musst Du die Cross-Forest-Anwendung der GPOs per GPO aktivieren.

Wo auch immer - Logon Skript, GPO, geplanter Task bei Logon. Überall kannst Du %USERNAME% verwenden, falls die freigegebenen Ordner dieser Konvention folgen. Wenn also der Zielpfad für einen individuellen Ordner immer lautet \\fileserver.domain1.de\shares\userhomes\%USERNAME% dann kannst Du ihn halt einfach verwende, und ob der User MUELLLER4711 aus der gleichen Domäne kommt oder nicht, ist egal - Hauptsache, den User gibt's einmal und er hat Rechte auf die Freigabe und auf den Ordner...

Moin, ich habe den Post jetzt zweimal gelesen und verstehe leider immer noch nicht, was Du erreichen möchtest. Zwei Domänen oder zwei Standorte? Wie hängt das zusammen? Wenn die Domänen sich bidirektional vertrauen, kannst Du Ressourcen in Domäne 1 für User in Domäne 2 berechtigen und umgekehrt. Ein Laufwerkmapping hat ja nicht primär was mit Identitäten zu tun, sondern eher mit Pfaden, und da ist die Domäne egal... Versuch bitte, die Herausforderung noch einmal konkreter zu beschreiben

Moin, auch wenn es keine direkte Antwort auf Deine Frage ist: Wir haben in ein paar Tagen 2021. Tu Dir selbst einen Gefallen und mach es in PowerShell. Da steht Dir die gesamte Macht der .NET DateTime-Klasse zur Verfügung.

Moin, vergiss DOS. In PowerShell ist DateTime unabhängig vom Locale. Erst, wenn Du einen DateTime-Wert als Text ausgibst oder die Datumswerte aus einer Textquelle einlesen musst, musst Du dir Gedanken um Formate machen. Einfach (Get-Date).AddMinutes(120) für zwei Stunden, und gut. Apropos: Es ist New-LocalUser, nicht Add-LocalUser. Ja, das ist in der Tat ein Problem. Lass das sein. Wenn das unbedingt sein muss, pack die Aktionen in Scheduled Tasks und gib den Anwendern das Recht, diese Tasks auszuführen.

Da ist ein Reset- und ein Clear-Button (Loch) vorne links. Damit geht es auch ohne Verbindungen.

Die fehlt nicht, die heißt einfach "CU3 und älter". Ist doch klar: later, älter, das passt schon Ich denke bei sowas immer an "Katzenpfötchen" - da gab es mal einen Artikel in den Docs zu "PAW" (Privileged Admin Workstations)

Richtig, und Exchange 2016 geht nicht auf Server 2019. Umgekehrt auch nicht

Gibt es auch. Für ein vollwertiges RDS-Deployment mit RemoteApps oder mehreren Session Collections,

Ja, freilich. Solange Heinz, Klaus und Christa unterschiedliche Usernamen haben, haben sie auch unterschiedliche Benutzerprofile Und ja, die Anwendung muss a. serverfähig und b. multisession-fähig sein. Aber wenn der Hersteller zum Terminalserver geraten hat, würde ich das in diesem Fall voraussetzen...

Wenn das die Adresse des Servers ist, ja Ich würde bei so etwas zwar immer lieber mit DNS-Namen arbeiten als mit IP-Adressen, aber es ist Dir natürlich überlassen,

Es ist ein MULTIUSER System. Alle verbinden sich zum gleichen Server und jeder kriegt einen eigenen Desktop. Sofern Du nichts einschränkst, stehen dann auf diesem Desktop alle auf dem Server installierten Applikationen zur Verfügung. Wenn Du das einschränken willst, verfahre genau so wie Du es bei einem Desktop-PC machen würdest, auf dem mehrere Personen sich abwechselnd anmelden: Zugriffsrechte, AppLocker usw. Wenn Du die Applikation als Einzelapplikation anbieten willst, brauchst Du einen Connection Broker und RDWeb. Dann kannst Du die Applikation als RemoteApp veröffentlichen, ohne jedem User einen ganzen Server-Desktop zur Verfügung zu stellen. Oder Du definierst die Anwendung als "bei Start der Sitzung starten", das will aber gut getestet werden, eigentlich will Microsoft davon weg.

Moin, wie schon vermutet: Du vermischst Äpfel mit Birnen. Terminalserver = RD Session Host = sitzungsbasierte VDI = Multi-User Windows = mehrere User melden sich gleichzeitig am selben Server an und jeder kriegt eine eigene Sitzung. VDI = RD Virtualization Host = Maschinenbasierte VDI = Single-User Windows = jeder User bekommt eine separate VM aus einer Vorlage. Wenn Deine Anwendungen in einer Multiuser-Umgebung gut spielen, bist Du mit Terminalservern normalerweise besser bedient.

Moin, grundsätzlich ist jede Server-Lizenz downgradefähig. Wo Du a. die Binaries und b. den Schlüssel findest, falls Du keinen KMS oder HVBA oder ADBA benutzt, sagt Dir der Hersteller allerdings nicht.

Ja, und wo soll da ein Unterschied sein? Die Windows - Oberfläche des Servers ist auch der Desktop. Wenn Du VDI brauchst (warum?), bist Du beim Terminalserver falsch.

Was ist denn für Dich ein VDesktop? Und nein, es geht vermutlich nicht um IP-Virtualisierung.

"Funktioniert nicht" ist keine Fehlerbeschreibung. Erwartest Du, dass die neue Maschine ihre Adresse per DHCP bezieht? Oder hast Du ihr eine fixe IP gegeben? Kann sie den Host pingen? Kann sie den Gateway pingen? usw. usw.

Moin, wenn der Terminalserver und die Endgeräte sich in derselben Domäne befinden oder sich die Domänen vertrauen, würdest Du mit etwas handwerklichem Geschick auch einen Single-Sign-On zum Terminalserver hinkriegen. Wenn zwischen dem Client und dem Terminalserver keine gemeinsame Authentifizierungsbasis existiert, nun ja... dann brauchst Du logischerweise zwei Logins. Ich rate dringend davon ab, Terminalserver als Workgroup, d.h. ohne AD, zu betreiben. Die Integration mit O365 erfordert eine Synchronisierung der Benutzer ins Azure AD, damit man ihnen a. Lizenzen zuweisen kann, und sie b. diese für sich beanspruchen können. Du kannst die User zwar auch ausschließlich in der Cloud pflegen, aber es ist nicht effektiv und Du hast zwingend eine zusätzliche Anmeldung.