Mike-Sbg

Die Policy-Einstellungen sind: in der MMC Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation Dort gibt es 2 Punkte: Abrufen von Gerätemetadaten aus dem Internet verhindern Suchreihenfolge für Quellspeicherote für Gerätetreiber festlegen Es müssen beide Punkte konfiguriert werden damit es funktioniert!

Nein, allerdings habe ich eine Policy gefunden, wo man das endgültig abschalten kann ... warum sich das Verhalten jedoch plötzlich geändert hat, konnte ich nicht rausfinden. Wenn wer die Policy brauchen sollte, dann bitte um kurze Antwort

Die Richtlinien funktionieren grundsätzlich. z.B. kein der User kein Windows-Update aufrufen, Bildschirmschonerzwang udgl. funktionieren (also beide User- und Computerpolicy funktionieren) Treiber ist die gute Frage: Wie kann ich einen Treiber nachsehen, der noch gar nicht installiert ist bzw. wo die Hardware noch nicht angeschlossen und über Plug&Play installiert wurde?

Ja die Rechner sind alle am gleichen Updatstand .. auch ServicePack haben wir keines zwischenzeitlich eingespielt. Daß die Richtlinie nicht greifen könnte, ist auch eine Vermutung die ich schon hatte, aber wie könnte ich das diagnostieren bzw. beweisen?

Hallo Leute, ich habe hier die Ehre fast 2300 Win7-Rechner (Win7 64-bit) zu administrieren. Diese Rechner sind alle mittels automatischer Installation (Lite-Touch) aufgesetzt und haben die gleichen Policy-Files (unter Windows\system32\grouppolicy) -> notwendig, da wir kein AD im Einsatz haben. In diesen Policy-Files ist das Downloaden von Updates mittels Windows-Update unterbunden. Somit sollten auch keine Driver heruntergeladen werden. Soweit so gut ... jedoch haben wir folgendes Problem: Als wir eine Microsoft LifeCam HD-5000 angeschlossen haben, führt dies bei Rechnern die wir bis zu einem gewissen Datum aufgesetzt haben nur zu dem berühmten "Ding-Dong" und alles funktioniert ... bei neueren Installationen (gleiche Hardwaretype) versucht er jedoch von Microsoft einen Treiber bzw. die Live-Software herunterzuladen und scheitert dann an der Softwareinstallation, weil der User keine Adminrechte hat (die WebCam funktioniert aber im Anschluß) Die Policies sind ident, die Hardware als auch das Installationsimage sind gleich ... jedoch gibt es diesen Unterschied ... kann mir vielleicht jemand einen Denkanstoß geben. :confused:

Hallo Marc, es geht eigentlich "nur" um die Registry-Keys in der HKCU, die diesen Posting beiliegen. Diese werden vom ActiveSync angelegt, wenn ein User dieses das erste Mal startet. Vielleicht wirst Du noch die eine oder andere Anpassung vorgnehmen müssen. UserRegistry.zip

Hallo Marc, wir haben das Problem dadurch gelöst, um einfach die erforderlich Registry-Keys in die Default-Policy der User einzutragen. Ist zwar nicht wirklich eine ellegante Lösung, aber sie funktioniert. Leider wird Dir das bei Deinem Problem nicht weiterhelfen fürchte ich! Kleiner Hinweis fast ein wenig Off-Topic: Paß auf dem WM 6.1 Geräten, wenn Du mehr als mit einer Quelle syncen willst, das macht nämlich massive Probleme ... das Internet ist voll von möglichen (nicht funktionierenden) Lösungsansätzen!

Nein über Tivoli (= ein Softwareverteilungstool einer großen "blauen" Firma ... Ich denke es ist nicht klar angekommen, was ich meine: Die Installation läuft durch ... ohne Fehlermeldung Nur bei jedem User der dann in Folge das ActiveSymc erstmalig startet, läuft der Installier wieder an, und wenn der User keine Adminrechte hat, gibt es eine Fehlermeldung (obwohl das Ding anschließend läuft)

Ich möchte in meiner Firma ActiveSync 4.5 silent so installieren, daß es dann auch bei jedem User (ohne Adminrechte) ohne vorhergehende Fehlermeldung funktioniert. Bei ActiveSync 4.2 hat das problemlos funktioniert. Beim 4.5 wo ich nur noch eine MSI Datei habe, beginnt er beim ersten Starten der Installation mit dem Kopieren von Dateien (wir verwenden die Switches /i und /qn /l*v) Das ist sehr unbefriedigend, zumal diese Installation mit einem Fehler abbricht, wenn der User keine Adminrechte hat (Kunststück will ja im Windows Ordner herumkopieren) Hintergrundinfo: Wir setzen WinXP mit SP2 ein Bitte um Hilfe!

@Blub: Danke, zwar arbeitet unsere NT-Domain ohne Kerberos sondern noch mit NTLM V2 aber nichts desto trotz, läuft man dort in das selbe Probleme hinein. Der STRG+ALT+ENTF-Dialog macht da offensichtlich mehr, wie am Domain-Controller das Kennwort zu setzen .... und da war es wieder mein Problem :rolleyes:

Danke für die Tipps. nur leider ergeben sich genau die 2 Probleme: Mit Net User kann ich (mit den richtigen Berechtiigungen) ein User-Kennwort auf dem Domain-Controller zurücksetzen ... das wirkt sich aber nicht sofort auf den Client aus. In dier Zeit bis zum Reboot - so meine Erfahrungen - funktioniert der Client dann sehr komisch, sodaß er z.B. auf gewisse File-Server sich nicht mehr verbinden darf. Das Script hilft mir nur bei der Änderung von lokalen Usern weiter, nicht jedoch bei Usern der Domain. Wenn ich versuche auf einen lokal gecacheten User zuzugreifen, bekommen die Scripts alle den Fehler, daß sie den User nicht finden können, was mache ich da falsch? Was ich bräuchte, sind genau die Routinen, die sich hinter dem STRG+ALT+ENTF + Kennwort verbergen

Hallo Leute, ich habe folgendes Problem: Eine Workstation in einer Windows NT/Samba-Domain. Darauf ist ein "normaler" User angemeldet. Ich möchte jetzt ein Script schreiben, mit dem das Kennwort dieses Users geändert wird. Wenn ich es nur auf dem Domain-Controller mache, führt das leider zu Problemen. Ich möchte also jene API nutzen, die auch hinter dem STRG+ALT+ENTF - Kennwort Ändern Dialog steckt. Kann mir da jemand weiterhelfen ... weil z.B. mit PSPASSWD.EXE kann man nur das Kennwort eine lokalen Users z.B. Administrator ändern.

Wir verwenden Ehternet mit 100 MBit full duplex IP-Adressen werden per DHCP vergeben Die Idee mit den Netzwerkdrivern ist gut, hat aber leider auch nichts gebracht :-(

Die Lösung ist eine fehlerhafte Deinstallationsroutine einer Vodafone UMTS-Karte. Die Netzwerkschnittstelle hat XP offensichtlich versucht anzusteuern, und diese Timeouts haben zu der langen Verzögerung geführt. Dies nur der Vollständigkeit halber

Wir verwenden Windows XP (SP2) und melden uns an einer WIN NT-Domain an. Das hat bis dato auch sehr gut funktioniert, nur leider haben wir seit kurzem ein Problem (genau genommen seit Einführung eines neuen Modells mit Dual-Core CPU): Die Anmedlung dürfte dem System etwas zu lange dauern, sodaß das System mit dem lokal zwischengespeicherten Profil hochfährt. Da wir jedoch Logon-Scripts verwenden, hat das für die User einige Nachteile wenn das passiert. Folgendes haben wir schon erfolglos probiert: Einspielen der Policy "SyncForegroundPolicy" Abschalten des Dual-Core (also im Single-Core Modus betreiben) Festlegung der Netzwerkgeschwindigkeit (= keine autonegoiate) Wenn der User sich abmeldet und wieder anmeldet geht alles ordnungsgemäß, nur beim Neustart tritt der Fehler auf. Hat irgendwie noch einen Tip was man da machen könnte?