noobi

Das hatte mehrere Gründe... Zum einen hat sich der Name der Firma geändert, zum anderen gab es sehr viele Altlasten und ein ziemliches Durcheinander, es war einfach keine richtige Struktur da. Mit dem neuen Server habe ich dann komplett bei 0 angefangen und alles sauber neu aufgebaut. So habe ich jetzt alle Altlasten meines Vorgängers beseitigt. Genau richtig, das hat bisher auch genau so funktioniert, daher verstehe ich ja nicht, wo jetzt das Problem liegt.

Nein, auf den Workstations ist in der lokalen Gruppe Remotedesktopbenutzer kein User. Wie bekomme ich den lokalen User eines anderen PCs darein?! Den PC kann ich zwar hinzufügen, jedoch geht auch dann die Anmeldung per Remotedesktop nicht... Bei der vorherigen Konfig, hatte ich hier auch keine User hinterlegt...

Der PC ist schon in der Domäne, der Benutzer der automatisch angemeldet wird und über den die Remotedesktop-Sitzungen laufen sollen ist ein lokales Benutzerkonto.

Am lokalen PC (nicht in der Domäne) habe ich die entsprechenden Domänenbenutzer in die Gruppe der Remotedesktopbenutzer mitaufgenommen.

Ja, wie gesagt, die Checkbox ist normalerweise aktiv, ist hier nur zum testen deaktiviert worden. Muss mein lokaler Rechner in die BuiltIn Gruppe Remotedesktopbenutzer?! Wenn ja wie denn, wenn der nicht in der Domäne ist? Wie gesagt in den GPO habe ich auch schon diverse Einstellungen dazu getestet, alles jedoch ohne Erfolg... In der alten Domain hatte ich damals an den Workstations Remotedesktop aktiviert und sonst keinerlei Einstellungen angepasst und es hat sofort funktioniert. Aber jetzt klemmt es...

Hallo Zusammen, ich kämpfe nun schon seit Stunden mit meinem FatClient wie in diesem Thread bereits diskutiert, nutzen wir einen Windows 10 PC mit Autologon (kein Domänenmitglied), um zu Präsentationszwecken auf unsere Workstations (Domänenmitglieder) zuzugreifen. Das hatte bisher auch problemlos funktioniert. Die User der Workstation sind Mitglied in der Sicherheitsgruppe Remotedesktopbenutzer. Nun wurde ein neuer Server eingerichtet mit einer komplett neuen Domäne, nun ist es nicht mehr möglich per RD zuzugreifen. Von den Workstations komme ich auf die Windows 10 Kiste, aber umgekehrt nicht. Die Einstellungen sehen so aus, es funktionierte zuvor, jedoch auch mit der Checkbox... Nun habe ich schon diverse Einstellungen und auch GPOs getestet, alles jedoch ohne Erfolg. Wenn ich den Namen der Workstation eintrage, kommt auch die Benutzerabfrage, Domäne wird korrekt angezeigt, das passt soweit alles. Wenn dann das Passwort eingegeben wird kommt die Fehlermeldung: Kann mir jemand von euch sagen, wo hier das Problem liegen könnte?

@mwiederkehr Vielen Dank nochmals für den Tipp, habe die Benutzer mit dem User Profile Wizard umgezogen, das hat sehr schnell und unkompliziert funktioniert.

Danke für den Tipp, auf das Tool bin ich bei meiner Recherche auch sehr schnell gestoßen. Kann damit dann alles direkt am Client erledigt werden? Also erst sichern, dann im neuen Profil wieder einspielen oder geht das nicht? Ohje, so schlimm?

Hallo Zusammen, stehe gerade vor meiner ersten Benutzermigration. ich möchte 3 Benutzerprofile (Benutzer in Domäne ALT) in einen neue Domäne migrieren. Am besten einfach nur sämtliche Daten und Einstellungen die den User direkt auffallen. Also Desktop, Dokumente, Einstellungen usw. Sicherheitsgruppen usw. sind alle hinfällig, da völlig neu konfiguriert in der neuen Domäne. Gibt es eine Möglichkeit diese Daten 1:1 zu übernehmen und dem entsprechenden Benutzer in der neuen Domäne zuzuordnen? Sodass nach der Anmeldung in der neuen Domäne alles aussieht wie wie gehabt? Ist das so mit ADMT möglich oder verwendet ihr dazu andere Tools?

Oh Mist, das mache in der Regel auch, habe ich hier übersehen. Leider kann ich den Beitrag nicht mehr bearbeiten.... Kann das ein Moderator noch nachträglich löschen?

Problem ist erledigt, habe dem neu angelegten Domänen Admin User in die gleichen Sicherheitsgruppen hinzugefügt wie auch der lokale Administrator, neu gestartet und nun läuft es.

Hallo Zusammen, habe eben einen Hyper-V Server (Hyper-V Rolle auf Windows Server Standard 2019) installiert und die erste VM, den DC aufgesetzt. Nun habe ich den Hyper-V Server in die Domäne geholt, musste also neu starten. Nach dem Neustart konnte ich mich auch anmelden mit dem Domänenkonto. Nur leider ist im Hyper-V-Manager nun keine VM mehr... Der DC startet dann logischerweise auch nicht. DC wurde vorher sauber eingerichtet, DNS auf dem DC funktioniert... (sofern er läuft) DHCP erledigt aktuell noch der Router. Der Hyper-V-Server hat die IP 192.168.111.2, der DC 192.168.111.3, nur leider kommt die Fehlermeldung mit einer APIPA-Adresse... ipconfig am Hyper-V meldet folgendes, das sieht auch gut aus. C:\Users\admin>ipconfig /all Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : Hyper-V Primäres DNS-Suffix . . . . . . . : (entfernt).de Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : (entfernt).de Ethernet-Adapter Ethernet 2: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Emulex OneConnect OCe14102-NT, NIC #2 Physische Adresse . . . . . . . . : 00-90-FA-AA-CB-AE DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Ethernet-Adapter Ethernet 3: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: (entfernt).xnet Beschreibung. . . . . . . . . . . : Intel(R) I210 Gigabit Network Connection Physische Adresse . . . . . . . . : 00-25-90-BC-97-5C DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Ethernet-Adapter Ethernet 4: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Intel(R) I210 Gigabit Network Connection #2 Physische Adresse . . . . . . . . : 00-25-90-BC-97-5D DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Ethernet-Adapter vEthernet (Emulex OneConnect OCe14102-NT, NIC - Virtual Switch): Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter Physische Adresse . . . . . . . . : 00-90-FA-AA-CB-B6 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::6050:c84d:46bd:1ab4%5(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.111.2(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.111.1 DHCPv6-IAID . . . . . . . . . . . : 218140922 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-26-34-5C-DB-00-90-FA-AA-CB-B6 DNS-Server . . . . . . . . . . . : 192.168.111.3 NetBIOS über TCP/IP . . . . . . . : Aktiviert Die Adresse wird also nur im Server-Manager falsch dargestellt.... Auch wenn ich im Hyper-V-Manager den Host manuell auswählen möchte kommt eine Fehlermeldung... Wenn ich mich mit meinem lokalen Benutzerkonto Administrator anmelde ist der Zugriff kein Problem, nur wenn ich mich mit dem Domänen-Admin Anmelde gibt es diesen Fehler... Der Benutzer admin in der Domäne ist Mitglied von "Administratoren" sowie "Hyper-V-Administratoren" Ist jemandem dieses Problem bekannt?

Das hat mir jetzt keine Ruhe gelassen, habe mal eben den Vertreter angerufen... Wir haben die Versicherung im Juni 2019 abgeschlossen, damals galten 90 Tage, danach wurde bei neuen Verträgen sogar auf 60 Tage angepasst. Seid diesem Jahr ist diese Richtlinie aber komplett abgeschafft worden...

Ui, schande über mein Haupt... Ich kann mich noch gut an das Gespräch mit dem Versicherungsmakler erinnern, als wir die Voraussetzungen besprochen hatten. Da hieß es wir benötigen komplexe Passwörter, die alle 90 Tage geändert werden müssen... Das war bei uns nicht so krass. Die Versicherung forderte nur eine Dokumentation, in der wir erklären wie wir die Anforderungen erfüllen. (Passwörter X Zeichen, mit Zahlen und Sonderzeichen, Backup Wiederherstellungstest, usw.

Moin moin, also wir hatten bei uns auch immer Passwörter ohne Ablaufdatum. 2019 haben wir uns dazu entschlossen eine Cyberrisiko-Versicherung abzuschließen. Damit sind folgende Punkte abgedeckt: Cyber-Spionage Cyber-Vertrauensschadendeckung Cyber-Betriebsunterbrechung bei Cloud-Ausfall Cyber-Betriebsunterbrechung bei Systemausfall und technischen Problemen Grundvorraussetzung für diese Versicherung ist eine Passwortrichtlinie:

hast du vorher auch das probiert net use [Laufwerksbuchstabe]: /delete oder wenn du nur ein Netzlaufwerk hast, kannst du auch net use * /delete ausführen, damit werden alle Netzlaufwerke gelöscht. Danach sollte die Neuverbindung dann auch klappen, sofern das Ziel verfügbar ist...

Perfekt, Problem erledigt... Vielen Dank!!!

Danke für die schnelle Rückmeldung, werde ich testen...

Guten Abend, wie hier bereits diskutiert wurde, habe ich in unserem Besprechungsraum einen Windows 10 PC aufgestellt an einem TV für die Präsentation von CAD Modellen. Zugegriffen wird auf Windows 10 Workstations per Remotedesktopsitzung. Das CAD funktioniert problemlos wie schon besprochen. (Nur die 3D Maus funktioniert leider nicht, ist aber zu verschmerzen...) Wir haben auch ein CAD Tool, in dem 3D Modelle zusammen mit einem Laserscan (hier ein Video, was ein Laserscan überhaupt ist, falls unklar) dargestellt werden. Sobald der Laserscan nur leicht gedreht wird, friert der Bildschirm komplett ein, erst wenn die Remotedesktopverbindung komplett geschlossen und neu aufgebaut wird funktioniert es wieder. Bei erneutem drehen friert es aber direkt wieder ein. Im Internet liest man viel über ein eingefrorenes Bild aber mit schwarzem Bildschirm, das Bild bleibt bei mir aber einfach stehen, sehe dann also noch die Software. Viele Probleme scheint es auch beim Zugriff per VPN zu geben, wir sind aber im gleichen LAN Netzwerk intern, also auch nicht das Problem. Die Workstations haben Dampf ohne Ende, auch der PC auf die Sitzung läuft ist eine ausgemusterte Workstation mit einem i7, 16GB RAM und einer alten nVidia Quadro. Betriebssysteme sind auch aktuell... Ist jemandem von euch das Problem bekannt?

Alles klar, dann wird es ein „Fat-Client“...

Ui, darüber habe ich mir noch gar keine Gedanken gemacht. Also ist das so gar nicht zulässig was ich vorhabe. Dann ist ja das schlanke OS schon vom Tisch... Wenn ich die Kiste wie Norbert so schön sagt als "Fat-Client" mit Windows 10 Pro betreibe ist es aber wieder in Ordnung, oder seht ihr das anders?

Ja, starten wollen wir erstmal mit diesem einen Gerät. Sofern das alles gut läuft und funktioniert, ist es durchaus denkbar das zu erweitern. Wir haben ein paar PCs, wo kaum Leistung gefordert ist und die auch nicht permanent benötigt werden. Hier habe ich dann überlegt einfach eine VM auf dem Server laufen zu lassen, auf die dann zugegriffen wird. Aber eins nach dem anderen. Ja, da hast du völlig recht. Das geschieht bei sämtlichen Windows Geräten weitestgehend automatisch über datto RMM. Mit dem Thema muss man sich dann natürlich auch auseinandersetzen.

Ja, eine open source Variante wäre mir auch am liebsten. Nur welche, da gibt es ja unzählige Möglichkeiten. Hat denn von euch jemand eine open source Lösung im Einsatz, wenn ja welche?

Jabb...

Nein, das ist ausgeschlossen. Ist für den Zugriff aufs ERP ok, aber im CAD ist die Navigation nicht wirklich brauchbar...