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?

Habe mir es runtergeladen ... schaut mich sehr interessant an ...

Hallo,

ich suche eine Möglichkeit für eine Treiberinstallation per Kommadozeile:

Es liegt eine .inf Datei vor und zwei .sys-Dateien. Wenn man die Installation manuell unter Gerätemanager-->Treiber aktualisieren durchführt klappt alles.

Ich suche nun eine Möglichkeit die Installation per Befehl auszulösen.

Die Lösung die mir "Google" gezeigt hat:

rundll32 setupapi.dll,InstallHinfSection 132 <.inf-Datei>

Bringt immer eine Fehlermeldung.(ausgenommen bei Druckerinstallationen)

Die derzeitigen Messungen belegen 4 x 120 Sekunden + Profil-Initalisierung.

Somit kommen wir immer ziemlich genau auf 10 Minuten

Nur warum dauert es dann trotzdem so lange?

Ein Zugriff ist NICHT möglich, und das soll auch so sein. Es ist dabei unerheblich, ob der Rechner mit dem Internet oder einem Insel-LAN verbunden ist.

Der Client soll mit lokal hochfahren mit den Cached Credentials

Nein wir verwenden keine Roaming-Profiles.

Beim Sniffen konnten wir feststellen, daß er 4 Mal versucht den PDC und den BDC zu erreichen mit einem Abstand von gut 2 Minuten ...

Ja die Meldung kenne ich schon immer (logisch bei NT-Domain)... nur daß die Anmeldung so extrem lange (ca. 10 Minuten) dauert ist neu ...

Hallo Leute,

wir verwenden eine WinNT - Domain.

Unsere Clients verwenden WindowsXP und verbinden sich unter Zuhilfenahme einer LMHOSTS auf den Domain-Controller ... soweit so gut.

Ist so ein Client allerdings im Internet, dauert es bis zu 10 Minuten, nachdem der User sein Kennwort eingegeben hat, bist der Explorer gestartet wird.

In dieser Zeit haben wir mittels Taskmanager beobachtet, passiert am System überhaupt nichts, lediglich die userinit.exe läuft (und das mit < 1 % Systemlast)

Im Ereignislog steht nur, daß keine Verbindung zum AD mölglich war.

Ist der Rechner ganz ohne Netzwerkverbindung (also Kabel abgesteckt) geht die Anmeldung in Sekunden.

Kann mir da jemand einen Tipp geben, da ich hier vermute, daß es sich um ein Timeout handelt

Hallo Bert,

danke für die Info nur das Sicherheitsprotokoll ist das etwas "russisch" bzw umständlich.

Ich dachte da an so etwas wie REGSHOT für die Registry, wo man dann zum Schluß einen Bericht bekommen würde

LG Mike

Hallo Leute,

ich habe eine relativ einfache Frage, habe aber bis dato noch kein Freeware oder Open-Source-Tool gefunden, mit dem ich das erreichen konnte:

Ich will überprüfen, welche Datein auf einem Laufwerk verändert (hinzugefügt, gelöscht, ....) wurden, seit ein gewisses Programm gelaufen ist (z.B. Setup-Routine bzw. auch ein normales Programm)

Hat da jemand einen Tipp für mich?