olc

Hi, @Gruffy: Mach am besten einen neuen Thread auf mit einer genauen Fehlerbeschreibung. Sonst wird es hier zu unübersichtlich. Vermutlich meinst Du die alten Zertifikate - darin kann die CRL Lokation nicht mehr verändert werden, das geht nur bei neu ausgestellten Zertifikaten. Wie gesagt, am besten neuer Thread. @Tom: Es macht sich meist nicht so gut, einen Thread zu "kapern". Also auch hier gilt es, einen neuen Thread zu öffnen. Grundsätzlich gilt: Wenn Du zusätzliche Zertifikate nicht benötigst, dann solltest Du die Ausstellung unterbinden. Viele Grüße olc

Hi Steven, ohne Kontext kann man solche Ausgaben nur schwer interpretieren. Was passiert denn um diesen Bereich herum? Was sagt ein Netzwerktrace? Und vor allen Dingen: Hast Du konkrete Probleme oder ist das reine Neugier? Bei konkreten Problemen wäre es sinnvoll, wenn Du hier den Kontext angibst. ;) Viele Grüße olc

Hi, ich verstehe die Frag leider nicht ganz: Wenn Du die Daten auf dem alten System nicht mehr haben möchtest, warum löschst Du diese nicht einfach, bevor Du den Server "zurück" holst? Oder laß vorher einen ROBOCOPY Job mit "/MR" Schalter laufen - dann werden nur neue Daten von der Quelle zum Ziel übertragen und zusätzlich nicht (mehr) vorhandene Daten der Quelle am Ziel gelöscht. Viele Grüße olc

Hi, bei "Roaming Profiles" kannst Du einzelne Verzeichnisse ausschließen: Group Policy Recommendations for Roaming User Profiles: Group Policy Wo liegt denn die Konfigurationsdatei genau? Viele Grüße olc

Hi, als Ergänzung: https://www.mcseboard.de/windows-7-forum-76/rdp-server-2008-zertifikat-sperrpruefung-157785.html Viele Grüße olc

Genau, gerade wenn Du "pipen" magst, sind BATCH Script "ein Witz" gegen die PowerShell, Aber ich merke schon - Dir geht es nicht um eine Verbesserung. Du bist da "konservativ". :wink2: Viele Grüße olc

@Esta: Noch nicht, oder zumindest nur im Testbetrieb. Und was würden wir uns mehr wünschen, als noch mehr Kontrolle unserer (Ess-) Gewohn- und Eigenheiten? ;) @GreenDevil: Wie soll die Energieeffizienz bei dem Teil aussehen? Viele Grüße olc

Hi, das ist meines Erachtens keine sinnvolle Möglichkeit - denn hier spielen Volume GUIDs etc. eine Rolle, so daß das schnell problematisch werden könnte. Wie schon angesprochen - generell macht meiner Meinung nach DFSR Sinn oder halt "quick and dirty" Robocopy im SYSTEM Kontext. Viele Grüße olc

Hi, siehst Du - wenn man sich darauf einläßt, gibt es diverse andere sinnvolle Möglichkeiten. ;) Übrigens ist zumindest der Standard "Befehlssatz" auch bei PSV1 und PSV2 gleich - von daher ist der Einwand von Dir also nicht ganz korrekt. Warum es nicht mehr mit der Pipe funktioniert? Entweder es ist ein Fehler der CMD oder es wurde schlichtweg abgeschaltet, weil es nicht wirklich schön ist. :wink2: Viele Grüße olc

Hi, hier ist keine Abstimmungsmöglichkeit - oder übersehe ich diese? Viele Grüße olc

Hi Janson, die Arbeit hier im Board ist freiwillig und in der Freizeit der Teilnehmer hier. Die Community profitiert nur von dieser Arbeit, wenn sie hier im Forum erfolgt. Private Sessions können Dienstleister für Bezahlung leisten, "nebenbei" ist das kaum möglich. Ich vermute also, daß sich niemand / kaum jemand für solche Sessions zur Verfügung stellt. Nimm es uns bitte nicht krumm, aber das führt zu weit. :) Viele Grüße olc

Hi Andreas, bitte entferne die benutzerspezifischen Daten aus dem Post oben... ;) Die von Dir genannten Speicherorte meinte ich... :) Ich kenne mich mit WLAN Auth. nicht so gut aus, aber ich würde vermuten, daß das entsprechende 802.1x Einstellungen nicht korrekt konfiguriert sind. Prüf doch einmal mittels NETSH, ob die Einstellungen korrekt sind. Viele Grüße olc

Hi, wie genau lautet die Fehlermeldung? Liegen die Zertifikate auch auf den richtigen Clients / Benutzerspeichern? Viele Grüße olc

Hi Grete, ich denke, es würde mit einem Scheduled Task sinnvoller einzurichten sein. Um welche Betriebssysteme handelt es sich? In XP kannst Du etwa "Eventriggers.exe" nutzen, unter Vista ist diese Funktionalität gleich Builtin. Wenn es sich um eine Domänenumgebung handelt, könntest Du unter Umständen auch mit den Group Policy Preferences arbeiten, da diese eine Ausführung innerhalb einer bestimmten Zeit ermöglichen. Alternativ fragst Du mittels remote Abfragen auf allen Clients ab, ob noch Benutzersessions aktiv sind. Falls nicht, fährst Du den Rechner herunter. Das würde ich persönlich fast noch für am sinnvollsten halten. :) Viele Grüße olc Viele Grüße olc

Hi, anders gefragt: Was genau möchtest Du erreichen? Dieser Weg ist ja auch schon unter 2003 - na ja, sagen wir mal - nicht optimal gewesen. Im Normalfall wirst Du das Ziel mit diversen Tools oder der PowerShell ohne diese Umwege erreichen. Viele Grüße olc

Hi, ab Windows Vista / 2008 hast Du Sprachunabhängigkeit - d.h. der Kern des Systems ist immer englisch, alles andere ist nur ein "Aufsatz", also das MUI. Das hat sich im Vergleich zu XP / 2003 geändert. :) Viele Grüße olc

Hi Torsten, warum kopiert Ihr die Daten nicht im SYSTEM Kontext (etwa mit Robocopy)? Das funktioniert eigentlich fast immer, da SYSTEM wegen AV-Scanner, backup-Software etc. eigentlich (fast) immer in den entsprechenden ACLs steht. Viele Grüße olc

Hi, Du solltest nicht die Fehlermeldungen des Windows 7 Clients "falsch" interpretieren. Microsoft geht halt bei einem Domänenbeitritt von einer Active Directory Domäne aus, es wäre ja auch merkwürdig wenn es bei Microsoft Fehlermeldungen heißen würde: "Die Samba Domäne konnte nicht gefunden werden." :D Ich vermute, daß Du noch immer DNS bzw. WINS Probleme hast. Wie genau sieht denn Deine TCP/IP Konfiguaration auf dem Client aus, was sind die Ip-Adressen der WINS-Server und der DNS-Server als auch des SAMBA Systems / der SAMBA Systeme? Bestenfalls ziehst Du einmal einen Netzwerktrace inklusive eines NETLOGON Logs nach einem Reboot des Windows 7 Clients beim Versuch des Domänenbeitritts. Vorher "ipconfig /flushdns" und "netstat -R" und "netstat -RR" auf dem Windows 7 Client ausführen und dann direkt den Trace starten und Domänenbeitritt testen. Welche WINS Server bzw. DNS Server werden kontaktiert, was sind die Rückmeldungen im Trace? Viele Grüße olc

Hi, sehr cool, funktioniert echt gut und schnell. :) Viele Grüße olc

Hi, die "Lösung" weiß ich nicht, das müßte ich mir auch noch einmal etwas genauer anschauen. Aber von dem, was mir im Moment einfällt, denke ich nicht, daß Du einen nummerischen Wert nutzen kannst. Du wirst meiner Meinung nach tatsächlich einen Unicode String nutzen müssen, auch die Prüfung auf "nummerischer Wert mit 3 Stellen nach dem Komma" leistet das Active Directory Schema / die LDAP-Datenbank nicht - das muß die Applikation abfangen. Es wird von der AD DB stur geprüft, ob der übergebene Wert mit dem möglichen DB Datentypen übereinstimmt. Ich habe gerade noch einmal auf die möglichen Datentypen geschaut: Syntaxes (Windows) So wie ich das sehe, ist kein sinnvolleres Attribut dabei, als der String(Unicode): String(Unicode) Syntax (Windows) Ich denke nicht, daß die Applikation Probleme mit dem Datentypen bekommt: Die Datenbank ist dafür verantwortlich, das LDAP Protokoll selbst "interessiert" sich nicht dafür. Dementsprechend muß Deine Applikation die Interpretation der LDAP Antworten übernehmen, aber eben auch das "escaping" und "error handling" sowie das Formatieren der Rückgabewerte. Teste die Einrichtung wie oben von Dir angegeben in Deiner Testumgebung auch gegen die Applikation, dann bekommst Du die wenigsten Probleme bei der Einführung in die Produktivumgebung. Bei dem Thema: Wenn Deine Applikation die Attribute benötigt, lagen dann keine Anweisungen zur Einrichtung dabei bzw. keine LDIF-Dateien? Das würde ich persönlich recht merkwürdig finden... Viele Grüße olc

Hi, schau einmal hier hinein: Remote Desktop Services (Terminal Services) Team Blog : Vista Remote Desktop Connection Authentication FAQ Viele Grüße olc

Hi, ich meine es nicht böse, aber Du solltest Dir das noch einmal überlegen. Aus Deiner Antwort meine ich heraus zu lesen, daß Du Dich mit dem Thema noch nicht wirklich befaßt hast. Du zählst die unmittelbaren Aspekte auf, erwähnst jedoch mit keinem Satz Dinge wie "wie sieht es in Zukunft mit potentiellen Kollisionen aus", "welche OIDs verwende ich", "wie hoch sind die Lese- und Schreibzugriffe auf die Daten", "wie finden die Zugriffe auf die Attribute statt", "welche ACLs sind notwendig" und vieles mehr... Bevor Du Dir größere Probleme machst, solltest Du meiner Meinung nach noch einmal Grundlagenarbeit leisten. Siehe zum Beispiel hier: Windows Administration: Extending the Active Directory Schema Active Directory Schema Tools and Settings: Active Directory Ich weiß, daß Du das nicht hören wolltest. Aber ich denke, es wäre besser, wenn Du das in Ruhe erst einmal liest und verstehst. Es gibt nämlich meiner Erfahrung nach immer andere Möglichkeiten. :) Viele Grüße olc

Hi, bevor Du das Schema änderst: Warum sollen die Daten ins AD Schema? Gibt es nicht die Möglichkeit, das ganze in eine DB zu legen? Was sind die genauen Anforderungen? Viele Grüße olc

Hi, genau, in den Systemeigenschaften. Ich gehe davon aus, daß Du zumindest die Gruppe der Remote-Benutzer für den Zugriff freigegeben hast. Nicht, daß "nur" die Gruppenmitglieder fehlen. Wie genau hast Du die Firewall deaktiviert? Mittels Firewall GUI oder einfach den Dienst beendet. Letzteres hätte nicht den gewünschten Effekt. Wie sehen die Gruppenrichtlinien auf dem Server aus - wurde unter Umständen irgend etwas am Netzwerkzugriff oder an den Terminaldienste Einstellungen gedreht? Viele Grüße olc

Hi, vieleicht eine dumme Frage: Aber hast Du einmal auf dem Server "Remote Desktop" deaktiviert, übernommen und dann wieder aktiviert? Hatte schon Fälle, bei denen das geholfen hat. Außerdem check noch einmal die Firewall auf dem Server - ist RDP freigegeben? Die Clients kommen aus dem gleichen Subnetz? Viele Grüße olc