Viprex

Hallo wilgin, danke für deine Antwort. Es tut mir leid wenn ich undeutlich formuliert habe. In meinem 2 Post fehlt das Wort "nicht" in Ich möchte eigentlich nicht über den Fehler 6008 konkret reden. Es geht mir um die Techniken rund um richtlinienbasierte Verwaltung. Die oben genannte Richtlinie ist nur ein Beispiel für Richtlinien basierend auf der Auswertung von Ereignissen. Wir können auch jeden anderen Fehler aus den Ereignisprotokollen als Beispiel nehmen, das Problem bei den Richtlinien bleibt gleich: Einmal im Windows Ereignisprotokoll gelistete Einträge werden anscheinend immer wieder gefunden, auch wenn diese mittlerweile obsolet sind. Ich würde gerne wissen wir man damit korrekt umgeht, ob es eine Quittierungsmöglichkeit für solche "Richtlinientreffer" gibt oder ob Richtlinien dieser Art unnütz sind weil man eben nicht einschränken kann? Immerhin handelt es sich hier um ein Beispiel aus den MS best practice Richtlinien. Ich hätte erwartet, dass diese auch "funktionieren" und nicht nur blendendes Schmuckwerk sind. Nochmal vielen Dank für eure Hilfe und Meinungen.

Hallo nochmal, nutzt niemand die richtlinienbasierte Verwaltung? Ich finde die ganz charmant um Compliance Bedingungen festzulegen und auf deren Einhaltung zu prüfen, wie z.B. ist das sa auch deaktiviert. Meine Frage oben ist eher genereller Natur und bezieht sich konkret auf Hilfestellung zu der og. Richtlinie. Vielmehr soll diese als Beispiel dienen. Hat niemand eine Idee wir man mit solchen Richtlinien umzugehen hat, die denselben Fehler immer und immer wieder finden? Ist das evtl. also die Schwachstelle bei den Richtlinien und daher wirds nicht genutzt?

Hallo zusammen, ich fange gerade an mich mit der richtlinienbasierten Verwaltung auseinander zu setzen. Als Einstieg habe ich u. A. die Best Practice Richtlinien von Microsoft angeschaut, genauer: "Fehler aufgrund eines Systemfehlers im Windows-Ereignisprotokoll" Diese Richtlinie schaut im Ereignisprotokoll nach, ob es einen Fehler mit Code 6008 gibt: IsNull(ExecuteWql('Numeric', 'root\CIMV2', 'select EventCode from Win32_NTLogEvent where EventCode=6008 and Logfile="System"'), 0) Jetzt scheint es aber so, dass die Richtlinie immer wieder auslöst, weil sie immer wieder denselben Fehler findet (also wirklich denselben!). Stimmt ja auch, der Fehler steht ja auch im Ereignislog. Meine Frage: Wie gehe ich denn nun damit um? Es ist in meinen Augen sinnlos das die Richtlinie immer wieder auslöst weil sie den Fehler findet. Der Fehler kann ja auch sehr sehr alt sein. Wie quittiere ich denn die Richtlinie, damit sie diesen gefundenen Fehler im Ereignislog nicht mehr beachtet und wohlmöglich erneut auslöst. Danke für eure Meinungen und Hilfe!

Hallo Community, ich habe ein Problem mit Regeln (Regel-Assistent) in einem Outlook 2013 Postfach an einem Exchange 2010 Server. Situation An einem zentralen Postfach laufen Alarmmails ein. Diese werden dann anhand von Bedingungen kategorisiert und in verschiedene Ordner verschoben. Trotz der Aktion "Keine weiteren Regeln anwenden" passiert es (jedes mal) reproduzierbar, dass eine Regel bei eingehender Mail diese korrekt erkennt und entsprechend kategorisiert, dann allerdings zwischen 1 und 4 Kopien davon im Zielordner erstellt. Dieses Verhalten ist nicht zu beobachten, wenn ich die Aktion "Kategorisieren" ausschalte. Es scheint also an der Kategorisierung zu liegen Test Zum Testen habe ich auch mal alle anderen Regeln deaktiviert, Problem besteht weiterhin. Weitere Regeln sind mir nicht bekannt, ich hoffe mal nicht das noch jemand Zugriff auf das Postfach hat und dort mit Regeln arbeitet - was auch sinnbefreit wäre da derjenige mit der Mails ja auch nichts anfangen könnte). Das Problem tritt auch nur auf, wenn die Mail "ganz neu" eingeht. Kopiere ich die Mail (eine der 3 og. Kopien) aus dem Unterordner zurück in den Posteingang und sage manuell Regel anwenden, ist alles bestens. Regel Nach Erhalt einer Nachricht mit Telefonliste: Fehler melden im Betreff diese der Kategorie Test zuordnen und diese in den Ordner Statusmails verschieben und keine weiteren Regeln anwenden Hilfe... Ich trete auf der Stelle und habe keine Ahnung, woran dies noch liegen könnte und freue mich über jede Hilfe. Vielen Dank und beste Grüße aus dem hohen Norden!

naja, nicht bewusst zumindest. Ich gehe davon aus, dass der Server seitdem auch nicht neu gestartet wurde. Bin Dienstag wieder vor Ort, schaue mir das dann nochmal an. Ich weiß aber nicht, was der Dienst mit dem Hinzufügen eines Treibers zu tun hat (Image könnte ich noch nachvollziehen). Seit der Installation des RIS sind ja auch schon ein paar Tage vergangen und der Dienst wurde seitdem definitiv neu gestartet. Alles andere funktioniert ja auch. Der Pfad ist eben nur falsch.

Ok, mal anders gefragt: Es gibt hier doch bestimmt einige, die auch noch RIS einsetzen. Wäre da vielleicht jemand bereit, sich kurz die %syspreppath% Variable im OSChooser Screen anzuschauen? Wie lautet bei euch der Pfad? Ich habe keine Lust, alles auf WDS umzustellen, da die flat images gut laufen.

wirklich niemand? Ich bin doch bestimmt nicht der erste, der Probleme damit hatte. Vll. könnte ja mal jemand von euch nachprüfen, welchen Pfad eure syspreppath Variable auf dem letzten Screen anzeigt? Falls mir keiner bei dem Thema helfen kann, habt ihr Ideen, wo ich noch Hilfe finde? Vielleicht eine passende Newsgroup parat?

Hallo, ich habe ein RIPrep Image von einem Laptop mit Sysprep.exe erstellt. Dieses liegt jetzt genau wie unsere ganzen unattended falt-images auf unserem RIS. Jetzt wollte ich das Image auf genau dasselbe Laptop zurückspielen, bekomme jedoch nach dem Verlassen der OSChooser Screens den Fehler, dass angeblich der Netzwerkkartentreiber fehlt. 1. Das wundert mich, ist das Image doch vom selben Laptop, wo vorher noch alles lief. 2. Das Anzeigen der Variable %SYSPREPDRIVERS% im letzten Installscreen brachte zu Tage, dass der Pfad auf einen falschen Ordner läuft, nämlich auf den 1. Ordner mit dem Standard Flat Image und dort ins i368 Verzeichnis. 3. In der *.sif Datei stehen folgenden Einträge: [setupData] OsLoadOptions = "/noguiboot /fastdetect" SetupSourceDevice ="\Device\LanmanRedirector\%SERVERNAME%\RemInst\%INSTALLPATH%" SysPrepDevice="\Device\LanmanRedirector\%SERVERNAME%\RemInst\%SYSPREPPATH%" SysPrepDriversDevice="\Device\LanmanRedirector\%SERVERNAME%\RemInst\%SYSPREPDRIVERS%" Auch der Installpath zeigt interessanterweise auf denselben Pfad, nämlich auf das Standard flat-image. Nur Syspreppath zeigt korrekt auf den i286 Ordner des Images. Was kann ich machen? Ich habe also probiert, ganz stupide die Netzwerkkartentreiber in das i368 Verzeichnis des flat-images zu kopieren, ohne Erfolg. Kann ich die Pfade hier einfach anpassen? Sind die u. U. gar nicht nötig? Warum tritt das Problem auf? Vielen Dank.

Ich ware gerade an einem dieser Rechner 1. es ist ein alter PC mit noch 2 Partitionen. 2. Windows ist dort auf Partition d: installiert. 3. Mein Filecopy Skript hatte den Fehler, dass es auf c:\windows\system32 kopiert hat und nicht auf %systemdrive%\windows\system32. Damit ist bei der betreffenden Nutzerin der Bildschirmschoner zwar auf c:\windows\system32 gelandet, nicht aber auf dem genutzten d:\windows\system32.... Ein Kopieren der Dateien zum entsprechenden Ort löste das Problem. 4. Die Richtlinien haben alle korrekt gezogen, das habe ich mir auf dem Rechner angeschaut (mit rsop.msc). Damit ist das Problem gelöst. Fehlt nur noch der 2. PC. Das schaue ich mir demnächst auch mal an. Der 3 Client war einfach nur nicht im entsprechenden Wirkbereich untergebracht, das war aber leicht herauszufinden und zu lösen. Stimmt, lokale Richtlinien werden von den Richtliniensätzen überschrieben. Lokale Registry Einträge aber nicht, oder? Denn ich habe hier immer noch ein Problem mit 2 anderen Client PCs, die sich immer bei unserem WSUS Server melden, obwohl die entsprechende Richtlinie gar nicht gesetzt ist (bzw. entgegenteilig konfiguriert wurde). Wahrscheinlich sind das 2 der alten Clients, die damals über Reg Settings für den WSUS kopnfiguriert wurden. Das ist aber ein ganz anderes Problem und soll hier nicht Thema werden. Wollte nur wissen, wie sich das verhält (Merksatz LSD OU ist bekannt :P). Ich vermute, dass nun alles wie gewohnt funktioniert. Vielen Dank für deine Hilfe.

Ja, auf circa 100 anderen PCs funktioniert alles wunderbar. Ich kann mir nur vorstellen, dass irgendeine lokale Konfiguration auf dem PC dazwischen schießt.

Nein, es ist nichts Sicherheitsgefiltert. Dort steht nach wie vor uns wie seit Beginn "Authentifizierte Benutzer". Ich habe allerdings vor kurzem in der Delegierung einen Benutzer hinzugefügt und explizit Gruppenrichtlinien verweigern gesetzt. Das sollte ja aber keine Auswirkung auf die beiden anderen User haben, zumal zumindest bei der einen das Problem vorher bestand.

korrekt. Und genau das funktioniert bei 2 Clients nicht. nein. Der Rechner ist seitdem aber auch schon ein paar mal neu gestartet worden, sollte sich also die Richtlinie gezogen haben. Ich habe auch noch nicht weiter testen können, ob es am Benutzer oder Computer liegt. Ich werde das morgen hoffentlich noch schaffen.

Ok, nächstes Mal erst genau suchen. http://www.mcseboard.de/microsoft-lizenzen-50/vista-downgrade-xp-pro-115347.html Leider hat das bei mir so nicht funktioniert. Ich wurde bei der telefonischen Aktivierung nicht gefragt, ob ich den Key mehrfach einsetze. Ich konnte Windows mit dem mehrfach genutzten XP Key aktivieren, jetzt bereits auf 2 "Vista-PCs". Jemand eine Idee, warum und wieso? Edit: Und wenn ein Mod so nett wäre, den Thread in den Lizenz Bereich zu verschieben, wäre ich ihm sehr dankbar. Tschuldigung :)

Jetzt habe ich gerade unseren RIS/WDS mit XP Pro unattended fertig, da kommen mir die ersten PCs mit Vista Business Key unter. Laut Downgrade-Rechte - Microsoft Schweiz gibt es ein Downgrade Recht für diese Lizenzen. Leider funktioniert der Vista Key nicht mit meiner unattended Installation (was mich nicht überrascht). Es liegen aber die Twinload CDs bei. Dort wird anscheinend erst das Vista installiert um es dann in ein XP Pro umzuwandeln?! Das finde ich jetzt ja mal bescheiden. Wie gehe ich jetzt mit der neu gekauften Hardware samt Vista Key um? Wie bekomme ich die XP Pro unattended Installationen jetzt aktiviert?

Ja, da hast du mich falsch verstanden. In der alten Situation hatte ich eine Bilschirmschoner-GPO direkt den Benutzer OUs zugeordnet. Nachdem ich herausgefunden hatte, dass es den Loopbackmodus gibt, habe ich die Benutzer GPOs gelöscht und mit in die Computer GPO für den Bildschirmschoner geschrieben (dort wird der FlashPlayer installiert sowie die Dateien per Start Skript ins system32 Verzeichnis kopiert) und gleichzeitig in dieser GPO den Loopbackmodus aktiviert. Es sollten also eigentlich keine Änderungen bei den Benutzer zu sehen sein, denn sie bekommen die gleichen Richtlinien jetzt per Loopback aus der Computerkonfig draugeblasen. Leider funktioniert das nicht bei allen. Es gibt mittlerweile mind. 2 Nutzer (mehr haben sich nicht gemeldet), bei denen der Bildschirmschoner jetzt nicht mehr aktiviert ist.

Nein, steht auf Ersetzen. Die GPO bezieht sich nicht auf Terminalserver Clients, obwohl diese Clients teilweise Citrix Anwendungen laufen lassen. Meinst du, dass von da etwas anderes raufgeschoben wird? Es ist aber nichts derartiges in den GPO's konfiguriert, wir starten hier quasi gerade erst richtig durch mit AD und GPO.

Neues Problem: Alte Situation: Benutzerrichtlinien wurden User direkt zugeordnet. Neue Situation: Loopbackverarbeitungsmodus wurde eingeschaltet, die Benutzerrichtlinien werden jetzt über die Computer an die User weiter geleitet. Einige User klagen darüber, dass die ehemals funktionierenden Einstellungen nicht mehr greifen (es geht hier um einen Bildschirmschoner). Ich habe mir mal den RSOP angeguckt und zu dem PC und dem entsprechenden User habe ich auch eine Ausrufezeichen bei der Installation der FlashPlayerSoftware für den Bildschirmschoner. Die Benutzereinstellungen werden aber dennoch korrekt angezeigt. Anbei mal ein Screenshot des Richtlinienergebnissatzes. Kostenlos Bilder hochladen mit Hostpix Bilderhosting

Vielen Dank, das funktioniert. Wer hätte gedacht, dass es so einfach ist und nur an einem fehlenden Parameter liegt. Manchmal denkt man wirklich deutlich zu kompliziert.

Ich benötige eine Lösung für folgendes Problem: Im Rahmen einer unattended Installation von Windows XP SP2 sollen beim 1. Systemstart zahlreiche Programme installiert werden. Dies geschieht momentan über Einträge in der Registry unter RunOnceEx. Funktioniert perfekt, bis ich das Problem hatte, dass ich während dieser Installation dem Admin die Möglichkeit geben muss, zu wählen, ob er eine Office 2003SBE Retail oder Volume Licence Installation machen will. Ich dachte, das löse ich am Besten mit einer kleinen Weiche, die dem Choice Befehl nachgebaut ist. Das funktioniert auch. Jetzt ist es aber so, dass die Installationen an sich silent ablaufen. Das bedeutet, dass nach der Weiche sofort das Office 2003 Setup gestartet wird und dann silent installiert wird. Das ist auch gut so. Allerdings startet dann parallel auch der nachfolgende Installationsaufruf, was in diesem Fall das Office 2003 SP3 ist. Und das dies nicht funktioniert, ist klar. Jetzt frage ich, wie ich das Problem am Besten löse. Vorgabe ist, soviel Silent und unattended wie möglich zu haben. Bisher habe ich folgendes: Eintrag in der Registry (beim 1. Anmelden des Installationsbenutzer werden die nachfolgenden Befehle ausgeführt) REG ADD %KEY%\061 /VE /D "Office 2003 SBE " /f REG ADD %KEY%\061 /V 1 /D "%SystemDrive%\install\Software\OFFICE\office.bat" /f REG ADD %KEY%\062 /VE /D "Office 2003 Service Pack 3 " /f REG ADD %KEY%\062 /V 1 /D "%SystemDrive%\install\Software\OFFICE\SP3.exe /q" /f office.bat echo off cls :start ECHO. ECHO Bitte wahle die Installationsart von Office 2003 SBE: ECHO. ECHO 1.: Office 2003 SBE Retail Key ECHO 2.: Office 2003 SBE Volume Licence Key ECHO. set choice= set /p choice=Bitte Taste [1] oder Taste [2] gefolgt von [ENTER] druecken. if not ´%choice%´==´´ set choice=%choice:~0,1% if ´%choice%´==´1´ goto retail if ´%choice%´==´2´ goto volume ECHO "%choice%" ist keine gueltige Eingabe! goto start :retail start %SystemDrive%\install\SOFTWARE\OFFICE\RETAIL\setup.exe TRANSFORMS=%SystemDrive%\install\SOFTWARE\OFFICE\RETAIL\setup_fully_silent.mst /qb goto end :volume start %SystemDrive%\install\SOFTWARE\OFFICE\VOLUME\setup.exe TRANSFORMS=%SystemDrive%\install\SOFTWARE\OFFICE\VOLUME\setup_fully_silent.mst /qb goto end :end Ich dachte schon, dass ich das SP3 dann einfach mit in der office.bat aufrufen lassen, glaube aber, dass dies nicht funktioniert, weil die Batch Datei leider sofort geschlossen wird, sobald das Office 2003 Setup gestartet wurde (und wenn das SP3 dort aufgerufen würde, so installiert es sich auch parallel). Seht ihr also eine Möglichkeit, das Office 2003 Setup nach seiner Beendigung zu fragen, obwohl es full silent ausgeführt wird? Was würdet ihr vorschlagen?

Danke, das funktioniert jetzt auch super. Ich hatte nur vergessen, den Haken explizit auch bei verweigern zu setzen :)

Vielen herzlichen Dank für die Auskunft. Das ist genau das, was ich hören wollte. Funktioniert perfekt. Klasse. Jetzt habe ich aber noch eine kurze Frage: man stelle sich vor, ich habe ein eine Richtlinie, die sowohl Computer- als auch Benutzerrichtlinien enthält. Loopbackverarbeitung ist aktiviert, die Richtlinie wurde nur Computerobjekten zugewiesen. Es gibt jetzt aber einen Benutzer, für den diese Richtlinie nicht gelten soll. Wie kann ich diesen Benutzer rausfiltern? Ich habe ihn in der GPO unter dem Reiter Delegierung eingetragen und den Haken bei "Gruppenrichtlinie übernehmen" (zu finden unter Erweitert) entfernt. Jetzt ist nur noch "Lesen" ausgewählt. Ein kurzer Test hat ergeben, dass die Richtlinie nach einem Neustart noch gezogen hat (was mich auch nicht wundert, denn die Computerrichtlinie galt ja noch für den Computer und es könnte sein, dass über die Loopbackrichtlinie die Benutzerrichtlinie dennoch für de Benutzer galt). Was ist jetzt der einfachste Weg, bestimmte Benutzer von dieser Richtlinie auszuschließen?

Ja, so habe ich mir das bisher auch immer gedacht. Jetzt habe ich in einem anderen Forum aber gelesen, dass man das umbiegen kann. Ich zitiere mal: "Du kannst diese Policy auch auf einer OU mit Computerkonten setzen, Du mußt lediglich in den Einstellungen angeben, welche Benutzergruppe sie ziehen soll." Daher dachte ich, dass es vielleicht geht, zu sagen, dass eine Benutzerrichtlinie immer dann gelten soll, wenn sich der Benutzer an den PC anmeldet, für den das Richtlinienobjekt verknüpft ist (ich sage mit Absicht Richtlinienobjekt, da die Benutzerrichtlinie ja nicht für einen PC gelten kann, wie du ja schon gesagt hast). So könnte man unterschiedliche Richtlinien wirken lassen, je nachdem, wo sich der Benutzer anmeldet. Das würde vieles einfacher machen. Frage 2 ist damit aber leider nicht geklärt :) Hast du darauf vielleicht auch eine Antwort? Jedenfalls schonmal vielen Dank für die schnelle Antwort.

Beispiel Standort: Standort -Computer --Abteilung 1.00 ---UnterOU 1.10 --Abteilung 2.00 -Benutzer --Abteilung 1.01 ---UnterOU 1.11 --Abteilung 2.01 Wenn ich eine Gruppenrichtlinie für Benutzereinstelllungen wie die Bildschirmschonereinstellungen habe und diese Richtlinie nur mit Abteilung 1.00 verknüpfe, ziehen die Richtlinien dann immer für den Benutzer, der sich an PC's aus Computer - Abteilung 1.00 anmeldet? Oder muss ich diese Richtlinie auch explizit für Benutzer - Abteilung 1.01 setzen, wenn dieses die Richtlinie befolgen sollen? Gibt es eine Möglichkeit, dies genau so zu regeln? 2. Frage: Kann ich verhindern, dass PC's aus UnterOU 2.00 die Richtlinien von Abteilung 1.00 übernehmen? Gleiche Frage gilt für den Benutzerteil. Ich möchte also die Vererbung verhindern, ohne dafür extra ein gegenteiliges Richtlinienobjekt verknüpfen zu müssen (und dann z. B. mit "Richtlinienvererbung deaktivieren" arbeiten zu müssen).

Und weshalb landen dann meine alten Installationen in der Schleife? Ich meine, die Keys sind legal, ich aktiviere Windows und schwups, kommt die Aktivierung wieder :( Sehr unfreundlich von MS. Da schadet man den ehrlichen Usern bzw. den Firmen wieder, um die bösen Buben strafen zu können, oder wie soll ich das jetzt interpretieren? Die alten Schlüssel funktionieren ja schließlich auch mit den neuen CD's (warum auch nicht, sind ja schließlich normale Keys).

Naja, wirklich schlimm ist es nicht, ich freue mich nur jetzt schon auf die ersten Beschwerden von Usern, die Englisch nicht mögen... Vielleicht kann ich ja auch eine alte CD zum laufen bringen. Dort haben wir in letzter Zeit nur das Problem, dass sich die alten unattended Installationen nicht mehr zum laufen kriegen, weil die in einer Aktivierungsschleife landen :(