Tiro

Fundstück

pack ein "net start messenger" ins Login-Skript. Der Dienst ist auch mittlerweile zu recht abgestellt. Zu nervig sind die Popups aus dem Internet und sicherheitstechnisch auch kein highlight. ;-)

hm, wenn ich mich recht erinnere, dann läuft der Dienst ab XP standardmäßig nicht auf dem Client.

mach doch mal auf einem betroffenen Rechner ein rsop.msc. Das Ergebnis ist manchmal sehr erhellend. :-) Was auch Laune machen würde, ist ein "mandatory" Profil. Dann können die Schüler ein bißchen rummurksen, aber nach dem Abmelden wird alles zurückgesetzt bzw. nicht gespeichert.

Es tut ja prinzipiell nicht weh, beide Gruppen für 1-2 Tage nebeneinander laufen zu lassen und dann die alten Gruppen zu entfernen.

Du erstellst eine neue GPO mit der einzigen Einstellung "cmd erlaubt" und verknüpft sie auf OU2.

Geht, aber das teuflische Detail ist, daß Du vermutlich beim nächsten Mal nicht dran denkst, daß die Vererbung abgeschaltet ist ;-) Besser ist die Lösung von Enno: Einfach eine weitere GPO auf die gewünschte OU setzen, welche die cmds wieder erlaubt. Da das die letzte OU ist, kommt auch die GPO als letzte und überschreibt die vorherige GPO (cmd verbieten) | OU (cmd verbieten + diverse) | OU1 (vererbt: cmd verbieten + diverse) | OU2 (cmd erlauben +diverse)

1) Was willst Du damit? 2) Aber mit AD DS kennst Du Dich schon aus, oder?

neu anmelden sollte hier genügen. (falls man es schneller "braucht" *bg*)

schon allein Sync of Updates: 0x80070057 WSUS.DE - Auf einmal Fehler 0x80070057 und WSUS.DE - Clients bekommen keine Updates Die anderen Fehler und "fatal errors" such ich dir nun aber nicht

1) Update auf WSUS 3.0 SP1 wäre schon mal ein Ansatz. 2) bei manchen Clients die partout nicht wollen habe ich eine cmd gebastelt, die bisher noch jeden Client wieder updatefähig gemacht hat. rem behebt probleme mit client, wenn er sich nicht am wsus meldet. rem Updatedienst vorher stoppen, danach wieder starten net stop wuauserv %windir%\system32\regsvr32.exe /s wuapi.dll %windir%\system32\regsvr32.exe /s wuaueng1.dll %windir%\system32\regsvr32.exe /s wuaueng.dll %windir%\system32\regsvr32.exe /s wucltui.dll %windir%\system32\regsvr32.exe /s wups.dll %windir%\system32\regsvr32.exe /s wuweb.dll %windir%\system32\regsvr32.exe /s wups2.dll %windir%\system32\regsvr32.exe /s msxml.dll %windir%\system32\regsvr32.exe /s msxml3.dll %windir%\system32\regsvr32.exe /s msxml2.dll %windir%\system32\regsvr32.exe /s qmgr.dll %windir%\system32\regsvr32.exe /s qmgrprxy.dll net start wuauserv Das kann man nach erfolgreichem Text mal für 2-3 Tage ins Loginskript einbauen.

*grusel* Das kann ich nicht so stehen lassen. Nachher glaubt es noch jemand. Pro Forest/ Gesamtstruktur: je 1 x Schema Master, 1x Domain Naming Master Pro Domain: PDC-Emulator, RID-Master, Infrastructure Master

Hm, ja geht. Was jetzt auch seltsam ist. Ich lösche die Datei x und lege sie neu an, aber als Erstelldatum hat sie den gestrigen Tag. Versteh ich nicht. :confused:

Nur als zusätzliche Option: OpenOffice Writer sollte für diese Größe auch genügen. Die Einarbeitungszeit ist deutlich geringer, weil man vieles noch aus der MS Office-Welt kennt und der Stylist (zentrale Verwaltungstelle für die Style-Vorlagen) ist eigentlich eine pfiffige Idee.

Ich sehe gerade, daß ich die Zeile mit Messagebox mitgepostet habe. (mein debugging für "Arme" *bg* ) Eigentlich steht nur eine Datei im Verzeichnis, die Differenz wird korrekt berechnet (laut msgbox), nur die Datei eben nicht gelöscht. :-(

Über das Login-Skript wird die Datei (die definitiv vor mehr als 7 Tage erstellt wurde) nicht gelöscht. Es treten keine Fehler auf. Wie läßt man sich das protokollieren? T

Ahoi miteinander, ich habe vermutlich Tomaten auf den Augen. Das folgende Script (Webfundstück) soll mir die Datei x im o.a. Verzeichnis löschen. Option Explicit Dim objWshNetwork 'Netzwerk Objekt Dim objWshShell 'Shell Objekt Dim objFso 'File System Objekt Dim objArgs 'Argumente Objekt Dim objEnv 'Umgebungs Objekt Dim objRegEx 'Regulärer Ausdruck Set objWshNetwork = CreateObject("WScript.Network") Set objWshShell = CreateObject("WScript.Shell") Set objFso = CreateObject("Scripting.FileSystemObject") Set objArgs = WScript.Arguments Set objEnv = objWshShell.Environment("Process") Set objRegEx = New RegExp '__________________________________________________________ Dim Ordner, Datei, Erstelldatum, Datum_Akt, Diff, Quelle Set Ordner = objFso.GetFolder("C:\temp\inventory") For Each Datei in Ordner.Files Quelle = Datei.Name Datum_Akt = Now Erstelldatum = Datei.DateCreated Diff = Datum_Akt - Erstelldatum msgbox Diff Set Datei = objFso.GetFile("C:\temp\inventory\" & Quelle) If Diff > 7.0 Then objFso.DeleteFile Datei End If Next Das funktioniert auch prima. Allerdings nur, wenn ich es lokal ausführe. Baue ich das ins Loginskript ein, dann tut es nicht. Warum? Sachdienliche Hinweise bitte nicht an jede Polizeidienststelle, sondern an mich Danke vorab T

Ich würde eher in den GPOs danach suchen und dort zentral abstellen (falls gewünscht) Sonst: At the system level: Create a new Registry key (without any value) NewNetworkWindowOff in HKLM\SYSTEM\CurrentControlSet\Control\Network\NewNetworkWindowOff

Hat der User evtl. die Einstellung, daß er erstmal nur eMail-Header runterlädt statt die ganze Mail?

1) verwendet man "verboten" besser nie :-) Oder wenn Du genau weißt, was Du tust, sonst kann das kann böse enden. 2) schau doch mal unter den erweiterten Sicherheitseinstellungen nach den "effektiven Berechtigungen" des Benutzers. 3) nur weil kein Haken in den Berechtigungen gesetzt ist, heißt das nicht, daß der Benutzer keine Rechte hat. Sie können vererbt sein.

Das ist "parental control" und war Bestandteil von Vista. Bei "7" muß man es über "live" nachinstallieren.

Alternativ könntest Du in der "AD Users and Computers"-Konsole unter Ansicht - "Spalten hinzufügen/ entfernen" die Abteilung einblenden und als Kostenstelleneintrag verwenden (sofern nicht schon verwendet). Oder "State", weil das in DE ja eh nicht so Verwendung findet, wie in USA. ;-)

Oder die "Hardcore-Variante": MCITP-Tagebuch: In dreizehn Tagen zum Windows-Administrator - PC-WELT Der Autor kommt zu einem anderen Schluß (wenn ich mich recht erinnere) Auf alle Fälle interessant zu lesen.

Ich habe da mal ein entfernt ähnliches Szenario bearbeitet. Durch das QM-Audit wurde die Abteilung X aufgefordert abgeschlossene Fälle nur noch lesend zur Verfügung zu stellen, damit sie nachträglich nicht mehr verändert werden können. Lange Rede, kurzer Sinn: Wenn ein Fall angeschlossen ist, dann wird er von dem Mitarbeiter in einen Unterordner verschoben, wo einmal nachts ein Skript die Rechte auf "lesen" ändert. Vielleicht ist das ja praktikabel für Euch? T

1) zugewiesene Software in der Computerkonfiguration installiert sich nur nach dem Neustart vor dem Anmelden. Wer es eilig hat, muß ein gpupdate /sync machen und neustarten. 2) Richtlinien vergibt man auf OUs, nicht auf Gruppen, Computer und Benutzer. Die Standard-Container Users (auf deutsch: Benutzer?) und Computers sind keine OUs. Darauf kann man keine GPOs setzen. 3) führe auf einem Client mal ein rsop.msc aus. Das Ergebnis ist meistens sehr erhellend. 4) Unter Gruppenrichtlinien - Übersicht, FAQ und Tutorials - How To - Softwarezuweisung ist eine ordentliche Beschreibung, die Du mal zur Sicherheit von oben nach unten durcharbeiten und mit Deinen Einstellungen vergleichen solltest. Gruß T