PyroTFD

IMHO gibt es dafür ja WSUS ;)

schon mal LanSweeper angesehen? https://www.lansweeper.com/ ist für eine kleine Bude kostenlos und du kannst damit eigentlich sehr viel Abdecken

*hüstel* Update *hüstel* Ich würde mal schwer wetten, dass es mit einem aktuelleren Server darunter weg ist. (vor allem versteh ich nicht - ganz ohne Sarkasmus oder böse Unterstellung, warum man im Q3 von 2019 noch einen Fileserver nutzt, der softwaretechnisch 11 Jahre alt ist...)

@daabm jo, das wäre auch eine Möglichkeit. Mittlerweile gibt es für solche Dinge so viele verschiedene Möglichkeiten, dass es schon fast wieder witzig ist. docx oder andere neue Dateiendungen würde ich nicht unbedingt empfehlen. Da kann es schon mal andere Office Hersteller auch erwischen :) (zB: WPS Office oder LibreOffice können ja auch mit docx umgehen....) ;)

nachdem ich in letzter Zeit öfters merkwürdige SQL Verbindungsfehler hatte: schon mal mit ".\VEEAMSQL2012" probiert zu verbinden? hatte es in letzter Zeit öfters, dass der Hostname nicht mehr gemocht wurde für solche Verbindungen ...und SSMS als Admin starten kann auch noch helfen (wie oft ich schon darüber gestolpert bin...)

@kaineanung wenn du wirklich per GPO was ausrollen willst und dort auf 32 oder 64 Bit Office prüfen, dann wird die Sache auch nicht besser. Das Problem ist, dass du dann mit einem fachmännischem Griff per WMI - Check auf die Ordner zugreifen musst und DAS dauert noch länger als wenn du es mit einem Skriptlein machst. Der Rechner wird nämlich alle Ordner erst mal auflisten müssen und daher einlesen... WMI in den GPOs für 32 Bit SELECT * from Win32_Directory WHERE Name="C:\\Program Files (x86)\\Microsoft Office\\Office16\\STARTUP" bzw. SELECT * from Win32_Directory WHERE Name="C:\\Program Files (x86)\\Microsoft Office\\root\\Office16\\STARTUP" (je nach Office Version) WMI in den GPOs für 64 Bit dementsprechend SELECT * from Win32_Directory WHERE Name="C:\\Program Files\\Microsoft Office\\Office16\\STARTUP" bzw. SELECT * from Win32_Directory WHERE Name="C:\\Program Files\\Microsoft Office\\root\\Office16\\STARTUP" (je nach Office Version) ...ob das Skript .vbs oder .ps1 oder .kix oder .cmd/.bat als Endung hat ist entweder reine Vorliebe des Admins oder je nach Bedarf zu überlegen IMHO einer der schnellsten Checks für CMDs ist auf den Pfad der ospp.vbs zu checken - die ist nämlich jeweils in den Verzeichnis, der Office Version (wenn in "%programfiles(x86)%\microsoft office\office16\ospp.vbs" - dann 32-Bit) Vorteil ist, wenn du es als ein Allgemeines Skript schreibst, dann kannst es in diesem dann auch prüfen ob 32 oder 64 Bit und je nachdem die restlichen Befehle ausführen lassen. - wenn es geht, dann setze es einfach in eine Variable und schon brauchst du wahrscheinlich keine weiteren Unterschiede mehr von den ausgeführten Dingen. und wie und wo du das Skript ausführst - ob als Startskript am Client, im Netlogon (per Link oder GPO getriggert) das kommt am ehesten auf den Einsatz des jeweiligen Skriptes an - da bin ich ganz auf Seiten von @daabm :) --- Anmerkung meinerseits, weil es ja heißt: Es würde nicht gehen - würde es schon, es wäre nur mehr als schlecht es so zu nutzen!

Hehehe... es ist nicht fragwürdig - manche Dinge sind nur b***d zum Erklären... :) es geht hier nur um ein paar Daten die mitwandern und bisserl "programmatisches". Workarounds und Umstellungen in dem Falle sind eher Kostenfresser als ein 20 Zeilen Powershell Skript... Wie es halt üblich ist: Kosten. :) Aber danke, genau das was ich von dir bekommen habe hatte mir geholfen mit der SID $NULL, $SIDNEW = (whoami /User /FO Table /NH).split(' ') manchmal steht man einfach auf der Leitung und bemerkt es nicht...

ja, ausn AD klingt immer gut, nur am Client funktioniert "Get-ADUser" nicht ... hehehe... ABER das mit whoami ist mir neu gewesen - danke! DAS ist genau das was ich suche ...und ja, es geht um - nennen wir es mal so - eine Migration von Daten... nach links von Rechts und umgekehrt... ...wie gesagt, lieber nicht fragen Aber ja, das half! DANKE! Jetzt hab ich 100%

Habe eine spannende Frage und eventuell weiß wer die Antwort darauf - ich steh grad an und finde es nicht heraus... Folgende lustige Aufgabenstellung: 2 Domains mit bidirektionalem Trust viele Clients - User können und dürfen sich übergreifend anmelden. Gibt es eine Möglichkeit die SID herauszufinden, wenn sich ein User aus Domain A an einem Gerät aus der Domain B anmeldet? - und ja, es gibt die Registry - ich bräuchte es allerdings automatisch... Hintergrund - und bitte nicht hinterfragen: Ordner aus Profil A der Domäne A sollen automatisch ins Profil B der Domäne B portiert werden bei der Anmeldung Der Username ist gleich in beiden fällen, aber wie wir alle wissen nicht unbedingt das Profilverzeichnis aufgrund von Heirat, Scheidung, Anmeldeprobleme, ... Über die SID kann ich die Pfade aus der Registry auslesen - funktioniert einmalig :) Nur bekomm ich die SID nicht heraus... Ich habe es mit WMI per Powershell probiert und leider schnell herausgefunden: WMI is doof... da ist nur die hauseigene Domäne drin, aber nicht die "Vertraute" Hat wer eine Idee wo und wie ich das herausfinden kann? AD-Listen sind dabei leider keine Option... ---- EDIT ----- Ooookay.... war ja klar Genau nachdem ich das oben geschrieben habe bin ich mit'n Bürostuhl weg gerollt um was bei einem Kollegen zu sehen und anscheinend von der Leitung herunter... -> Enviroment Variable "Userprofile" für die, die es interessiert mit Powershell: (get-item Env:Userprofile).Value damit kann ich zumindest mal 95% der Dinge die ich brauche Abfangen. Trotzdem bräuchte ich noch die SID für was Anderes ... (und bevor wer fragt: Nope - SID-History könnte hierfür nicht genutzt werden...) Zumindest hab ich mir grad selbst die Frage beantwortet gehabt zwegs Profil - manchmal steht man wirklich auf der Leitung...

Nur eine kleine Zwischenfrage, weil ich Windows 7 und Defender lese... Defender war ja nur Windows 8.x und 10, davor musste er separat installiert werden und war als Windows Security Essentials bekannt. Ähm... hast du am WSUS auch die Windows Security Updates frei gegeben? (sind eh quasi neben den Defender Updates und eigentlich mehr oder weniger dasselbe, aber anderer Name, anderes Update, andere Flausen...)

Ah, schön das es das hier schon gibt... es gibt hierbei nämlich auch einen zweiten Fehler der zu der Anmeldeproblematik führen kann! Das es mit dem Homelaufwerk wie oben beschrieben zusammen hängt ist auch hier der Fall, nur bei meinem Kunden war es schon richtig gesetzt. Aber mit dem kleinen Kniff, dass es sich um eine DFS-Namespaces Umleitung handelte. Kurioserweise hatte ich dann das Problem genauso! Als ich den Pfad vom DFS auf den eigentlich physichen umgelegt hatte war der Spuk wieder vorbei. Danke Schlorg für die Ausführliche Beschreibung oben und danke an Microsoft, dass sie unser Leben doch wieder mit "neuen" Fehlern bereichern...

Grübel... ich hab mir grad den ganzen Thread angetan und in mal (halbwegs schnell) überflogen. Nur damit ich es richtig verstehe kurz zusammen gefasst: sagen wir es gibt 2 Räume mit je 20 Computern auf den Computern dürfen sich bestimme Schüler zu bestimmten Zeiten anmelden, danach wird der Zugang gesperrt. Danach sollen sie nicht mehr mit dem User rein kommen können bzw. nicht mehr surfen dürfen oder ähnliches. Anmelden darf man nur auf gewissen Geräten und nicht "frei nach Verfügung"... Stimmts so ungefähr? mir würden 3 Lösungen einfallen und die sind klarerweise mit ein wenig Arbeit verbunden (und bleibens auch...) 1. Da es sich ja um eine Domäne handelt, kannst du AD-Gruppen machen (sollte es eine Linux Domäne sein mit LDAP gehen auch dort Gruppen zu bilden). Die Gruppennamen sind Rechnername-Allow bzw. Rechnername-Deny (je nachdem ob du lieber verbieten willst oder erlauben) 2. Du legst auf jedem Rechner einmalig je diese Gruppe vom AD als "Erlaubter Login" und "Verbotener Login" fest (findet sich beides unter secpol.msc -> security settings -> local policies -> user rights assignment -> allow log on locally bzw. deny log on locally) 3. Du legst für den Schüler einen Account an und gibst ihm die Berechtigungen für den einen Computer zur Anmeldung per Gruppe und lässt ihn zusätzlich einfach "ablaufen" zu einem gewissen Zeitpunkt. 4. Surfberechtigungen kannst du zur Not auch anders abfangen, aber mit Proxy wäre es schon mal ganz gut ;) zweite Lösung - Smartcards und Smartcardreader damit kannst du mit der richtigen Software einstellen wer wie lange darf und auch steuern, wo sie sich anmelden dürfen. Im Endeffekt ist bei dieser Art wahrscheinlich der permanente Wartungsaufwand wesentlich einfacher als bei der ersten Lösung. dritte Lösung - die Softwarelösungen von Internet-Cafés (!) Solche Lokale haben genau dasselbe Problem: Wie lasse ich Leute bestimmte Dinge tun und andere nicht und das über bestimmte Zeiten ;) Zur Verwaltung im weiteren wahrscheinlich die einfachste Lösung. (gibt es auch ein paar -> Dr. Google findet schon die Links dazu) Das wären zumindest mal die Dinge die mir so einfallen würden zu dem Problem (ohne jetzt stark und viel mit GPOs rum zu basteln) Sonst finde ich das Konzept ganz in Ordnung mit restriktiertem Einsatz - wenn gleich ich da auch gewisse Probleme auch sehe ;)

Eine wirkliche Veränderung wäre mir so nie aufgefallen. er merkt halt, dass der Client fehlt und dementsprechend läuft die Zeit bis zur automatischen Abmeldung (wenn aktiv)

auch die Kennwortlänge geändert? Nur mal sicherheitshalber gefragt, weil dies nicht geschrieben wurde... btw. würde ich definitiv nicht zu kurzen Passwörtern raten - außer für abgeschottete Testsysteme (und selbst dort könnten es andere PWs sein)

So, sorry für keine Antwort so schnell wie eigentlich erhofft... :) (ja, manchmal sind andere Problemchen gerade wichtiger...) Backup-Space umfasst nun 6,5 TB - hat also ausreichend für obere Theorie ...und Warnung kommt noch immer Also daran lag es wohl nicht