daabm
-
Gesamte Inhalte
5.657 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von daabm
-
-
-
Ich glaub, er hat's nicht so mit lesen. Den Link zu den GP-Settings für RUP-Pfade hatte ich auch schon gepostet...
-
Schön, daß andere den gleichen alten Müll in ihren Umgebungen finden
Darfst meinen Post gerne als Antwort markieren, das ehrt mich dann...
-
regedit ist Dein Freund. HKLM\System\CurrentControlSet\Services\<ServiceName> ersatzlos entsorgen... Und der Dienstname sollte sich im Eventlog finden
BTW: Irgendeinen Namen wirst Du ja haben, den Anzeigenamen z.B. Und mit sc kann man sich dazu auch den Dienstnamen anzeigen lassen. Spoiler: "getkeyname"...
-
Ja. Der unterste Eintrag wäre jetzt interessant. Aber egal was in dem drin steht, falsch ist es auf jeden Fall
-
Ich glaub, ich red grad chinesisch... Wichtig ist grad nicht, was im Profilpfad im AD steht, sondern welche NTFS-Rechte auf \\Server\TS-Profile vergeben wurden. Du willst nicht lesen, oder? Steht alles in dem MS-Artikel oben...
-
1
-
-
Die Ordner erstellt nicht der Server, sondern der User. Hast Du meinen Link mal aufmerksam gelesen? Ich weiß grad nicht, was Windows bei fehlschlagenden RDS-Profilen macht - wenn ich das programmiert hätte, würde ich einen Fallback auf das "normale" Profil implementieren.
-
vor 17 Minuten schrieb Cryer:
Ich habe mich natürlich mit dem entsprechenden Benutzer angemeldet.
Ja, schön
Und welche Rechte hat dieser User auf dem Profilshare/-verzeichnis? (Also Share- und NTFS-Rechte...)
-
vor 10 Minuten schrieb Cryer:
Zudem habe ich in den RDS-Profileordner, den ich bei "Remotedesktopdienste-Profil" eingetragen habe reingeschaut. Der Server legt dort aber kein Profil an.
Das macht ja auch nicht der Server, das macht der User. Sind die Rechte da so gesetzt, wie es für die Auto-Erstellung von RUP-Ordnern erforderlich ist? https://docs.microsoft.com/de-de/windows-server/storage/folder-redirection/deploy-roaming-user-profiles
-
Ich werf mal ne ganz andere Frage in die Runde: Woraus schließt der TO, daß der Client "nur auf DC2" angelegt wird?
Wenn es tatsächlich so ist, daß Du bei dsquery|get-adcomputer|dsa.msc beide DCs nacheinander auswählst und der Client nur auf DC2 zu finden ist, dann funktioniert Deine Replikation eben NICHT. Und das liegt i.d.R. an fehlenden SRV-Records im DNS. Externes DNS bei AD ist nix für zuhause, das müssen Profis machen - IMHO. Und sogar die haben ihre Probleme damit.
-
So als Code-Sample:
Get-DistributionGroup | Foreach { Get-Irgendwas -Identity $_ }
Und Tante Google ist bei Powershell ÄUSSERST aussagefreudig
-
Aktion "löschen" wäre glaub einfacher gewesen
-
Hast Du das Profil nur im AD-Konto definiert? Das kann man auch per GPO (computerbezogen) festlegen...
https://gpsearch.azurewebsites.net/#2587
https://gpsearch.azurewebsites.net/#2500
-
Waren da Berechtigungen auf Registry "RPC" mit drin? Dann kann ich das Verhalten bestätigen, das haben "hochqualifizierte Admins" früher gerne gemacht. Inzwischen sind aber neue Standardgruppen dazu gekommen (konkret "Alle Anwendungspakete"), und wenn die fehlen, tritt der von Dir beschriebene Fehler auf. Woher ich das weiß? Hab selber so eine GPO geerbt...
-
Ich seh auch nur Pixelsalat - und eine dreizeilige Taskleiste. Damit kann niemand viel anfangen.
-
Ne, die Surfaces kommen ab Werk mit aktiviertem TPM und aktivierter Verschlüsselung. Ich kann mich aber nicht mehr genau erinnern, wie das initial auf die Speicherung des Recovery Key hingewiesen hat - ich glaube, ich hab mich schon direkt mit dem MS-Konto angemeldet. Und das ganze "Kleingedruckte" liest ja niemand mehr, weil es einfach zu viel geworden ist :-(
-
Nur Home kann nicht sein - meiner ist von einen Surface Pro3, das kam mit Professional. Aber "non domain joined" und "nicht Enterprise" kann sein - ich hab grad genauer geschaut, der Key ist von 2013 und damit hoffnungslos veraltet. Ich hab das Pro3 damals erst mal so in Betrieb genommen und später erst auf Enterprise und Domain umgestellt. Kann sein, daß der Key noch von "davor" übrig ist. Man lernt jeden Tag dazu
-
vor 4 Stunden schrieb Dukel:
Sobald man gebootet hat und das System ist entschlüsselt (bzw. der Key im Ram) gibt es Möglichkeiten (wenn auch nicht ganz so einfache als komplett ohne Verschlüsselung) an die Daten heranzukommen. Es sollte reichen, wenn man den Server ans Netzwerk hängt und mittels Brute Force oder ausnutzen von Sicherheitslücken an die Daten oder an einen Zugang kommt.
Wenn man ein Passwort braucht um zu booten für Bitlocker hat der Dieb keine Chance (es sei denn er klaut die USV gleich mit und hällt den Server am Leben).
Damit machst Du Dir halt das Leben auch extrem schwer - wenn zum Boot eine PIN erforderlich ist, rennst dann bei jedem Patchday stundenlang (virtuell) auf den ILOs rum und tippst die überall ein? Ich würd ja sagen "nicht praktikabel"...
-
Die Webservices von MS interessieren sich glücklicheweise nicht für groß oder klein
Und Home oder Enterprise ist egal, hier ist es Enterprise.
-
...und eine kleine Erklärung, was genau nun das Problem war und wie genau es gelöst wurde, wäre auch nett... Hilft dann dem nächsten.
-
@tesso Den Link hat er selber schon gepostet - und wenn ich bei mir schaue, finde ich da auch meinen Recovery Key. So gesehen weiß ich auch nicht, was da grad schiefgeht...
-
@4zap es gibt keine technische Alternative zu Brain 2.0...
Euch hätte eine Tier-Trennung geholfen - Domain Admins "Deny Interactive Logon" auf Clients und Member Servern (- ESAE). Und Cached Credentials auf 0 bei Desktops/Servern, auf 1 bei Laptops. Dann hat sich das mit dem Hash aus lokaler SAM auslesen relativ erledigt.
Aber das ist auch nur ein kleiner Stein im großen Security-Mosaik.
-
1
-
-
KeePass rafft das irgendwie, welches Fenster es auswählen muß - hab mich da aber auch noch nicht wirklich eingelesen. Das Risiko des wahlfreien Abspulens ist mir wohlbekannt
-
Für die Diagnose werfe ich mal "nltest /dsaddresstosite:" in den Raum
Domain Controller synchronisieren nicht
in Active Directory Forum
Geschrieben
Ich zitier mich mal selber - eine Antwort darauf wäre vmtl. hilfreich.