phatair

Hallo zusammen, Bei uns in der Domäne steht der Wert ms-DS-MachineAccountQuota auf 0, so dass kein User ohne explizite Delegation ein Gerät in die Domäne aufnehmen kann. Es gibt eine extra AD Sicherheitsgruppe in der die User enthalten sind, die Geräte in die Domäne aufnehmen können und diese AD Gruppe ist in dann in der AD berechtigt. Eine Frage hätte ich jetzt zum msDS-CreatorSid Attribut. Dieses wird ja erstellt, wenn ein User ohne Delegation ein Gerät aufnimmt. Das ist nur dann möglich, wenn ms-DS-MachineAccountQuota nicht auf 0 steht. Oder sehe ich das falsch? Ich habe nun bei uns nach Computerobjekten in der AD gesucht, die das Attribut msDS-CreatorSid besitzen. Mir werden hier fast alle Server aufgelistet. Diese wurden dann wohl vor der Anpassung des ms-DS-MachineAccountQuota Wertes in die Domäne aufgenommen und es wurde ein Account verwendet, der dafür nicht in der AD berechtigt war. Ich habe die SIDs geprüft, die bei den Servern im msDS-CreatorSid stehen, dass sind die Server Admin Accounts die auch jetzt das Recht haben Server in die Domäne aufzunehmen. Soweit ist das also OK. Meine Frage ist jetzt, kann ich diesen msDS-CreatorSid Eintrag irgendwie löschen oder muss ich dazu das Gerät aus der Domäne nehmen und wieder aufnehmen? Seht ihr es als kritisch an, wenn das msDS-CreatorSid Attribut bei den Server gefüllt ist, auch wenn es sich dabei um SIDs der aktuellen Server Admins handelt? In Bezug auf LAPS sollte das ja kein Sicherheitsrisiko darstellen, da diese Accounts das LAPS Passwort sowieso lesen dürfen und wenn einer der Admins nicht mehr im Unternehmen ist, wird der Account sowieso deaktiviert. Für Meinungen/Infos wäre ich sehr dankbar. Grüße

So machen wir es :) Bei der Planung und der Umsetzung für ein PAW bzw. auch Server Tier Konzept würden wir noch Externe Unterstützung benötigen. Falls uns hier jemand als externer Dienstleister unterstützten könnte, kann er sich gerne per PN an mich wenden. Vielen Dank schon mal. Grüße

Hallo zusammen, vielen Dank für eure Rückmeldungen. Ich gebe euch Recht, dass das Thema wahrscheinlich zu vielschichtig ist, um es hier im Forum zu diskutieren bzw. eine Lösung für uns zu finden. Ich werde mal schauen, ob und wie wir das über unseren bestehenden Dienstleister angehen können. Darf ich in diesem Zuge auch Fragen, wer von euch so eine Dienstleistung in Bezug auf PAW/Server Tiering anbietet oder ist das nicht gestattet?

Hallo zusammen, ich würde bei uns gerne mal ein dringendes Thema angehen. Das Thema wurden ja schon öfter mal diskutiert und ich wollte nicht einfach ein anderen Thema übernehmen. Aktuell nutzen bei uns die Admins ihre normalen Notebooks auch für jegliche administrative Tätigkeiten, d.h. auf diesen werden Management Konsolen gestartet, Admin Web GUIs aufgerufen und RDP Sessions zu Servern gestartet. Ein kurzer Überblick über die bestehenden Security Vorgaben VLAN Segmentierung für Server, RDMS, Management, IT, Clients, DMZ, usw vorhanden Routing über die zentrale Firewall inkl. granularer FW Regeln und Security Profiles für jedes VLAN und WAN Verbindung personalisierte Server Admin Accounts die nur auf zugewiesenen Servern genutzt werden können. personalisierte Client Admin Accounts die nur auf zugewiesenen Servern genutzt werden können. personalisierte Domain Admin Accounts die nur auf den DCs genutzt werden können. Spezielle "Fine grained password policies" für die Admin Accounts dedizierte Service Accounts die jeweils nur für einen Dienst/Aufgabe genutzt werden Kein "normaler" User hat Adminrechte bzw. einen Admin Account Standard Admin ist auf allen Servern deaktiviert. Unterschiedliche Passwörter für die lokalen Server Admins LAPS befindet sich aktuell in der Implementierung Kein Internet Zugriff für Server. Wenn benötigt, werden diese URLs/Ports explizit für diesen Server in der Edge Firewall geöffnet es werden noch keine Admin Tiers verwendet Nun nutzen wir, wie schon oben beschrieben, unsere Notebooks zum einen für die tägliche "non Admin Arbeit" wie Mails schreiben oder Recherche im Internet. Zugleich haben wir auf diesen Geräten auch unsere administrativen Tools installiert. Das ist natürlich alles andere als optimal und soll geändert werden. Die erste Idee war, für jeden Admin eine VM bereitzustellen und dort die notwendigen Tools zu installieren. Über das Notebook wird dann nur noch die normale Standard Tätigkeit durchgeführt. Credential Guard nutzen um die Anmeldedaten vor "Pass-the-Hash" Attacken zu schützen. -> Bei weiterer Recherche stellte sich dann aber raus, dass dies wohl nicht so einfach ist. Ein PAW sollte wohl eher anders rum genutzt werden. Also das NB als Admin Workstation und z.b. eine VMware als normale Arbeitsstation. Da die Admin Station aber nicht in der Domäne sein soll und besonders gehärtet sein muss, stellt sich das bei uns aktuell etwas schwierig da. Das Thema ist recht komplex, gerade wenn man auch die Admin Tiers mit einbezieht. Daher mal meine Frage in die Runde, was gibt es für Möglichkeiten um die aktuelle Situation mit den Admin Notebooks bei uns zu verbessern, aber ohne gleich die volle Ausbaustufe zu implementieren? Das würden wir aktuell absolut nicht schaffen. Auf der VMware Seite hätten wir noch genug Ressourcen um jedem Admin eine eigen VM bereitzustellen. Lässt sich da schon etwas bauen, damit wir etwas besser aufgestellt sind als jetzt? Ziel wäre es also: - Notebook für die tägliche User Arbeit - VM als Admin PC/"PAW" der z.B. nicht in der Domäne und gehärtet (Security Baselines ...) ist Vorgehen wäre dann so, dass man per RDP auf den "Admin PC" geht um dann dort die installierten Admin Tools zu nutzen oder sich von dort per RDP auf einen bestimmten Server einwählt. Damit hätte ich zumindest schon mal die Admin Tätigkeit von der täglichen Arbeit getrennt. Ein erster Schritt, dem noch weitere folgen müssen, aber besser so als es einfach so zu belassen wie es ist. Bin gespannt und dankbar für eure Antworten. Grüße

ich mosere ja nicht, sondern Suche jetzt nach Erfahrungen andere Aber wie gesagt, ich werde die beim nächsten Wartungsfenster aktualisieren und dann berichte, ob es problemlos abgelaufen ist.

Hi Norbert, den Link im Health Checker Report hatte ich ja geprüft. https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/VisualCRedistributableVersionCheck/ Ich habe aber weder bei dem Link noch bei den verlinkten Artikeln eine Info dazu gefunden, ob ich die einfach aktualisieren kann. Vor allem hatte mich im Health Checker die Info " This is not a requirement to upgrade, only a notification to bring to your attention." verunsichert und sagt eben nicht aus, dass es "problemlos" gemacht werden kann/soll. Wäre ja nicht die erste Abhängigkeit die man anfasst und auf einmal geht nix mehr. Ich werde das nun aber einfach mal machen. Denke auch, dass es kein Problem geben sollte. Ich werde berichten :)

Hallo zusammen, eine kurze Frage zum Exchange 2016. Der Health Checker sagt bei uns schon länger, dass die folgenden Redis nicht mehr aktuell sind Visual C++ 2012: Redistributable is outdate Visual C++ 2013: Redistributable is outdate Kann ich mir für die 2012 und 2013 Version von hier einfach die aktuellen Versionen runterladen und auf dem Exchange installieren oder sollte man das tunlichst vermeiden? Könnte ja auch sein, dass die (wenn benötigt) bei einem CU mit aktualisiert werden. Wir sind auf dem CU23 und SU 08/22, die Redis aber weiterhin von 2020 und daher gehe ich davon aus, dass die nicht aktualisiert werden. Auf Grund von Sicherheitslücken oder Bugfixes würde ich schon gerne die aktuelle Version nutzen. Für einen Tipp wäre ich sehr dankbar. Grüße

Die Grund war eher Zufall. Wir haben bei der LAPS Implementierung nach dem Attribut msDS-CreatorSid gesucht. 3 Rechner hatten dieses Attribut tatsächlich und wir haben diese Geräte eben aus der Domäne entfernt und wieder neu aufgenommen, um zu prüfen ob das Attribut leer bleibt, wenn wir die korrekten User verwenden. Dabei ist aufgefallen, dass die Geräte eben nicht deaktiviert werden. Ist jetzt nicht weiter tragisch, da bei uns die User keine lokalen Adminrechte haben und somit selber den Domänen austritt nicht durchführen können und damit auch keine "Leichen" im AD entstehen können. Komisch finde ich es trotzdem. An den Replikations-Effekt hatte ich auch gedacht, habe aber extra mal ein paar Stunden gewartet und zusätzlich auf allen DCs geprüft. Das Gerät wurde nicht deaktiviert.

An einem Test PC war das Verhalten wie folgt. Versuch 1 Mit einem lokaler Admin den PC in eine Workgroup gepackt. Bei der Anfrage für die Domäne einen User angegeben der definitiv Computer deaktivieren/löschen darf. Trotzdem war der PC danach nicht deaktiviert in der AD. Versuch 2 Den PC noch mal in die Domäne aufgenommen und mit dem Remove-Computer PS Command die Deregistrierung durchgeführt. Im Remove-Computer Command wurde der AD User mitgegeben. Als lokaler User wurde "current user" verwendet, dieser war lokaler Admin. Hier wurde das Computer Objekt in der AD deaktiviert. Jetzt habe ich diesen PC wieder in die Domäne aufgenommen und habe 1:1 noch mal das Prozedere aus Versuch1 durchgeführt. Jetzt wird das Computer Objekt in der AD auch deaktiviert. Ich verstehe es nicht, aber gut, wir werden es beobachten.

Ah ok, dann müsste ich es verstanden haben. Das heißt, dass aufkündigen erfolgt in 2 Schritten. Da ich als lokaler Admin die Workgroup auswähle, wird der Member (Client) auch aus der Domäne genommen und in die Workgroup gesteckt. Das passiert erstmal lokal. Danach authentifiziere ich mich noch gegen das AD und da der User nicht genügend Rechte hat bleibt das AD Computer Objekt aktiv, dass hat aber erstmal nichts mit den lokalen "Einstellungen" auf dem Member zu tun. Ich hätte jetzt trotzdem eine Fehlermeldung in Bezug auf das AD Objekt am Member erwartet, aber dann ist das wohl so nicht.

Danke Dir, Das mit dem aufnehmen weiß ich und ist bei uns auch auf 0 gesetzt und für den Domain Join ist eine AD Gruppe mit delegierten Rechten gesetzt. Das mit dem entfernen ist mir dann trotzdem ein Rätsel, das mit den lokalen Rechten hatte ich mir auch gedacht. Ich kann das aber auch mit einem User machen, der keine lokalen Adminrechte hat. Ich kann den Client mit einem normalen Standard AD User aus der Domäne nehmen. Das AD Objekt bleibt dann weiterhin aktiv im AD und der Client ist dann in der Workgroup. EDIT: Um es etwas genauer zu sagen - um von Domäne auf Workgroup umzustellen benötige ich natürlich administrative Rechte. Danach erscheint ja aber noch mal eine Authentifizierung gegenüber der Domäne und dort habe ich dann einfach einen normalen AD User eingetragen der keinerlei Rechte im AD oder auf dem Client hat.

Hallo zusammen, wenn ich bei uns Win 10 Clients aus der Domäne entferne, also am Client selber "Workgroup" auswähle, wird dieser Client in der AD nicht deaktiviert. Nach einem Reboot ist der Client zwar in der Workgroup, aber eben das AD Objekt weiterhin aktiv. Nun habe ich festgestellt, wenn ich beim entfernen des Clients den Domänen Administrator (als Test) angebe, wird der Client deaktiviert. Mache ich das aber mit unseren dedizierten Accounts, die auch für die Aufnahme von PCs in die Domäne berechtigt sind, wird der Client nicht deaktiviert. Das Problem war dann schnell gefunden, der User hatte nicht das Recht Computerobjekte zu löschen/deaktivieren. Er durfte nur Computer Objekte erstellen. Ich frage mich aber, warum konnte der Client trotzdem aus der AD entfernt und in die Workgroup aufgenommen werden. Hat jeder User das Recht ein Gerät aus der Domäne zu nehmen? Ist das per Default so? Grüße

Wir sprechen sowas von aneinander vorbei

Meinst du das ernst? Jede Software sollte grundsätzlich so funktionieren wie vom Hersteller definiert. Es geht doch nicht darum, wie ich mir das wünsche... Ein DC darf nicht einfach neu starten... das ist doch nicht nur mein persönlicher Anspruch... Deine Logik ist ja interessant. Danach kann jeder Hersteller machen was er will und einfach sagen, ist halt so. Bist a Depp Keine Software ist fehlerfrei, dass ist klar, aber hier muß man auch unterscheiden. Und ich bin auch seit knapp 20 Jahren it admin und habe die unterschiedlichsten Netzwerke administriert. Aus meiner Sicht hat sich die Qualität bei MS und den Updates in den letzten 2 Jahren deutlich verschlechtert. Es war früher sicherlich nicht top, aber besser. Aber die Aussagen mit dem testen und dem Anspruch an Software ist und bleibt für mich eine sehr fragwürdige und klingt eher nach Theorie als nach der Realität. Aber gut. Für mich ist hier Schluss mit der Diskussion. Das führt zu nichts und jeder hat so seine Ansichten.

Ähm... diesen Anspruch sollte man an eine Software haben dürfen. Komischerweise schaffen das auch viele Hersteller und MS hat das auch lange Zeit geschafft. Ich wußte nicht, dass "The SOFTWARE is provided AS-IS." bedeutet, dass die Software bei jedem Update nicht mehr wie gewünscht funktioniert. Wir kommen hier wohl nicht zusammen. Ich bleibe dabei, dass MS hier aktuell einen miesen Job macht und man das nicht einfach mit "ihr müsst halt Updates testen" abtun kann! Das ist vollkommen an der Realität vorbei argumentiert. Testen gehört grundsätzlich dazu, aber die Menge an fehlerhaften Updates von MS die grundlegende Features zerstören sind ein Unding und dürfen so einen Unternehmen nicht in der Regelmäßigkeit passieren. In der Theorie hat der Kunde natürlich die Wahl, in der Praxis aber nicht, da dafür die meisten Umgebungen viel zu sehr auf MS ausgerichtet und komplex sind. Vielleicht sorgt es dafür, dass zukünftige Projekte an andere Herstellern gehen und damit die Umgebung dann weniger MS lastig wird. Ich glaube aber eher nicht daran.

Sorry aber das ist vollkommen unrealistisch und klingt so als wäre jedes Unternehmen/IT Abteilung dazu in der Lage. Du lässt aber die Realität dabei komplett außen vor. Bei Windows clients mag das zum Teil noch zutreffen Server aber nur sehr schwer. Große Unternehmen können das machen, aber doch nicht jedes KMU. Nicht jedes Unternehmen hat eine Test Domäne und kann jedes System in einer Testumgebung abbilden. Das ist oft finanziell oder/und von der IT Mannschaft gar nicht zu bewältigen. Davon abgesehen sind in letzter Zeit die Microsoft Updates so miserabel, dass es dir passieren kann, dass in der Testumgebung alles sauber läuft und dann in der Produktivumgebung etwas schief geht. Außerdem sind das so gravierende Fehler, dass man sich fragt ob Microsoft überhaupt noch eine Qualitätssicherung hat. Admins sind keine beta tester und in einer einigermaßen normalen Windows IT Umgebung sollten solche Fehler nicht passieren, wenn Microsoft seinen Job machen würde.

Hi Thomas, bekanntes Problem, siehe hier (die einzelnen Artikel sind in dem Artikel verlinkt) ->https://www.borncity.com/blog/2022/01/14/microsoft-patchday-probleme-jan-2022-bugs-besttigt-updates-zurckgezogen/ Gibt noch mehr Probleme mit den Januar Updates. Macht langsam kein Spaß mehr Windows Server zu administrieren bzw. zu aktualisieren...

Hallo zusammen, Eine kurze Frage. Wir haben auf den meisten internen Servern den Internet Zugriff über unsere zentrale Firewall blockiert. Bei den Servern 2019 wird bei jeder Anmeldung der Browser geöffnet und versucht die Webseite www.msftconnecttest.com zu öffnen. Dies wird wohl durch NCSI ausgelöst, da Windows versucht zu prüfen ob eine Internetverbindung besteht. Nun könnten wir in der Firewall die benötigten urls freigegeben oder es gibt eine Möglichkeit NCSI per gpo zu deaktivieren. Hier schreibt Microsoft, dass dies nicht empfohlen wird. Gibt es irgendwelche Probleme, wenn man das deaktiviert? Es gibt zwar auch gpos um interne Server für NCSI zu nutzen, aber dazu müsste man ein einen Webserver laufen lassen um eine connection.txt bereitzustellen. Das ist mir die Funktion eigentlich nicht wert, da es ja nur um eine "online Prüfung" geht. Oder übersehe ich etwas? Vielen Dank. Gruß Steffen

Hier eine gute Übersicht von Tools, Infos und zB. bekannten IPs https://github.com/NCSC-NL/log4shell Eine Frage habe ich aber noch, da man darüber immer unterschiedliche Infos liest. Laut BSI ist ja die Lücke auch nutzbar, ohne das Schadcode nachgeladen wird. Bei uns haben so gut wie keine Server Internet Zugriff. Vor allem die Server in der DMZ haben das nicht. 2 Server in der DMZ nutzen tatsächlich Log4j. Einer konnte schon gepatched werden, der andere ist leider wichtig für den Unternehmensbetrieb und wurde so gut wie möglich isoliert. Er ist aber nicht per HTTP oder HTTPS von Extern erreichbar, was hoffentlich dazu führt, dass er noch nicht angegriffen wurde. Ist man etwas "sicherer" wenn die Server eben kein nachladen von Code ermöglichen oder spielt das tatsächlich keine Rolle? Ich lese immer wieder, dass über den String jndi:ldap:// der Angriff erfolgt und das würde doch bedeuten dass über den externen LDAP Server der Code nachgeladen werden muss.

Stimmt - gute Idee. Danke. Eine Frage habe ich doch noch. Ich würde gerne in den Profile Order, der in der VHDX enthalten ist, eine AD Sicherheitsgruppe in die ACL aufnehmen, damit die entsprechenden Admins beim mounten der VHDX im Problemfall auf das Profil zugreifen können. Im dem von dir verlinkten Powershell Script ist da ja problemlos möglich, aber wie mache ich das bei neuen VHDX Containern, die dann nicht über das Script erstellt werden? In den GPOs habe ich zwar die Richtlinie "Set access control for profile directory inside VHD" gefunden, aber meine Tests damit waren leider nicht erfolgreich. Hast du dazu noch eine Idee? Danke und Gruß

Ich mache noch mal einen neuen Beitrag, einfach damit es etwas übersichtlicher ist. ich hoffe das ist OK und es hilft vielleicht dem ein oder anderen der auch von Roaming Profiles zu FSLogix wechseln möchte. Ich habe den Fehler nun gefunden. Das Problem war, dass ich das Script mit einem User ausgeführt habe der lokal Adminrechte hatte (um überhaupt das VHDX mounten zu können) und auch auf das Target Ziel schreiben durfte. Er war aber nicht auf das Roaming Profile selber berechtigt und damit konnte er die Berechtigungen im VHDX nicht setzen. Das habe ich nun mal temporär angepasst und siehe da es läuft sauber durch. Einzig im Script Convert-Roaming-Profiles.ps1 musste ich an der Stelle wo die Berechtigungen gesetzt werden "Administrators" durch "Administratoren" ersetzen, da wir eine Deutsche Umgebung haben.

Hallo zusammen, soweit klappt die Migration nun erstmal. Das Script läuft sauber durch und ich habe es so angepasst, dass der Ordner für das FSLogix Profil USERNAME_SID ist und nicht mehr SID_USERNAME. Wenn ich mich dann allerdings am Test RDP Server anmelde, der für FSLogix konfiguriert ist, wird eine neue VHDX erstellt und meine migrierte in CORRUPTED_ umbenannt. Im FSLogix Log steht folgendes Creating new user profile disk (user's registry hive was missing) Laut Google ist das ein Problem mit der NTUser.dat, dass diese zum Beispiel nicht vorhanden ist oder wir noch eine andere Software/Lösung wie Roaming Profiles einsetzen die sich vorher die NTUser.dat geladen hat. Beides ist aber nicht mehr der Fall. Roaming Profiles habe ich in der GPO entfernt und ich habe in der VHDX nachgeschaut, dort ist die NTUser.dat vorhanden. Hat noch jemand eine Idee, woran das liegen kann? Kann bei der Migration innerhalb der VHDX die Berechtigung irgendwie zerschossen sein bzw. kann man das prüfen? Wenn ich die migrierte VHDX per FSLogix mounte kann ich erstmal nicht auf das Profil zugreifen. Ich muss die "Sicherheit" bearbeiten und mich als Besitzer eintragen. erst dann kann ich in das Profil schauen - ist das normal oder deutet das auf ein Berechtigungsproblem hin? EDIT: Gerade noch einen letzten Test gemacht 1. Neues sauberes FSLogix Profil durch FSLogix selber erstellen lassen. Diese VHDX mit dem FSLogix Tool gemounted. In das Profil kam ich erst rein, nach dem ich die typische Windows Meldung "sie benötigen Zugriff" bestätigt hatte. Damit war mein User zwar in der ACL Liste eingetragen aber das ist ja erstmal egal. Die Berechtigung war der eigentliche User, System und Admin 2. Das gleiche noch mal mit meinem migrierten FSLogix Container gemacht. Migrierte VHDX mit dem FSLogix Tool gemounted und versucht das Profil aufzurufen. Kam erstmal auch die typische Windows Meldung mit dem Zugriff. Die Meldung bestätigt und trotzdem kam ich nicht rein - es kam die Meldung, dass ich die Sicherheit bearbeiten muss. Also habe ich den Besitz übernommen und siehe da, es steht nichts in der ACL drin. Ich habe dann manuell SYSTEM mit Vollzugriff hinzugefügt und dann ging auch das anmelden mit diesem Container. Die Frage ist nun, wie bzw. wo läuft im Script mit der Berechtigung was schief. Oder liegt es am Ursprünglichen Roaming Profile...?

Ich antworte jetzt einfach auf mein Beitrag selber, da ich den Fehler gefunden habe. Es musste tatsächlich die komplette Hyper-V Plattform installiert werden und nicht nur die Verwaltungstools (so wie es ja auch in der Fehlermeldung steht). ich bin allerdings davon ausgegangen, dass das Scrpt das prüft (stand zumindest so in der Readme). Nach dem ich die hyper-v tools installiert habe, wurde auch das vhdx file erstellt. Nun muss ich morgen noch prüfen ob die Verwendung sauber funktioniert. Danke Jan für die Hilfe bis hier her.

also ich bin ratlos. ich habe jetzt auch das .V4 wieder angehängt. Trotzdem kommt der gleiche Fehler. Wenn ich folgende Befehl ausführe, erkennt er den User und auch die Version aber die SID und GUID kann er nicht auslesen New-MigrationObject -ProfilePath C:\temp\FSLOGIX\profiles\TEST-RDP.v4\ -Target C:\temp\FSLOGIX\ ProfilePath : C:\temp\FSLOGIX\profiles\TEST-RDP.v4\ Username : TEST-RDP Version : v4 UserSID : SID Not Found UserGUID : GUID Not Found Target : Cannot Copy Es gibt aber dieses AD Objekt. Ich habe die PS Konsole auch extra mit einem User gestartet, der Schreibzugriff auf die OU hat in der das Objekt liegt. Auch das hat nichts geholfen. Falls du noch eine Idee hast wäre ich dankbar, ansonsten würde ich die User wohl informieren, dass die Profile neu erstellt werden. die wichtigen Ordner haben wir ja sowieso umgeleitet. EDIT: Wenn ich Get-ADUser -identity test-rdp ausführe, dauert es etwas und dann erhalte ich die Meldung, dass der Server nicht verfügbar ist. Führe ich den Befehl auf einem der DCs aus, erhalte ich sofort die Infos. Ich habe unsere FW im Verdacht. EDIT2: also es lag tatsächlich an der FW. PS hatte den Port 9389 für die AD Abfrage genutzt und diesen hat unsere FW blockiert. Danach wurde der User gefunden. Nun kommt aber gleich der nächste Fehler. 10/21/2021 20:38:49 - Could not create or mount Profile Disk 10/21/2021 20:38:49 - Mit den Hyper-V-Verwaltungstools war kein Zugriff auf eine erwartete WMI-Klasse auf Computer "NB350" möglich. Dies kann darauf hinweisen, dass die Hyper-V-Plattform nicht auf dem Computer installiert ist oder dass die Version der Hyper-V-Plattform mit diesen Verwaltungstools nicht kompatibel ist. Ich habe auf meinem Win 10 20H2 einfach unter den "Windows Features aktivieren" die hyper-V-Verwaltungstools installiert. Muss ich hier noch weitere Module laden?

Hi Jan, "leider" gibt es einen AD User test-rdp und diesem gehört auch dieses Profil. Deshalb war ich so verwundert. Es sind auch alle notwendigen Module installiert (AD, HyperV und Pester). Das Profil liegt eben testweiter unter C:\temp auf meinem lokalen Notebook. Ich habe es aus dem UNC Pfad, wo die Profile normalerweise liegen, kopiert und extra die Endung .V4 gelöscht damit der Name sauber zugeordnet werden kann. Ich habe auch schon bei -Profilpath den abschließenden Backslash weggelassen. Ging trotzdem nicht. auch habe ich es mit meinem eigenen Profil getestet, auch dort kann er das AD Objekt nicht finden.