Sunny61

Wenn sie bei dir komplett ankommt, wie soll der Exchange sie dann wegschneiden? Was hast Du denn schon alles zur Findung einer Lösung unternommen?

Da würde ich die verwendete DNS-Konfig untersuchen, die Kette verfolgen. Evtl. hat ein DNS vom ISP Schluckauf.

Mit WSUS brauchst Du logischerweise den Haken nicht zu setzen. Denn per GPO gibst Du dem Client ja vor, in welchen Zeitabständen er nach Updates suchen soll. Wenn der Client keine WSUS konfiguriert hat, kannst Du IMHO den Haken auch nicht setzen, da er gar nicht zum setzen vorhanden ist.

Es wird Online nach Updates gesucht. Genauso wie früher bei XP als Du das über den Browser gemacht hast. Dann wird beim manuellen Aufruf auf dem WSUS nach verfügbaren Updates gesucht, sofern der Client den WSUS auch in der Registry eingetragen hat. Kannst Du übrigens recht schnell selbst feststellen. Wenn Du manuell suchen lässt, gehst Du gleichzeitig in die Commandline und führst ein netstat [ENTER] aus. Hier sollte jetzt dein WSUS als Ziel auftauchen.

Der Thread ist aus dem Jahr 2009, lass ihn bitte ruhen und eröffne einen neuen Thread, Danke. Zusätzlich ist hier auch nicht gewünscht, fremde Threads zu 'kapern'. Kannst Du in den Regeln nachlesen: http://www.mcseboard.de/topic/191452-regeln

Dieses 'Problem' existiert schon immer und wird auch immer bestehen bleiben. Du kannst versuchen mit ABE die Ordner auszublenden, die die Benutzer nicht 'sehen' dürfen. Solange sie keine NTFS-Berechtigungen haben, kann doch auch nichts passieren.

Hatte ich doch geschrieben: Du kannst die GPOs auch in der Domain ansiedeln, und einen passenden WMI-Filter auf das IP-Segment erstellen.

In unserem Fall hilft der Helpdesk den Benutzern beim wiederfinden. :)

Du kannst es so oder so machen, wie Du möchtest. Denk aber zukünftig dran, das Du GPOs auf den Standort zugewiesen hast. Du wärst nicht der erste der über ein solches vergessenes GPO stolpert.

Welche *genaue* Fehlermeldung bekommst Du bei *genau* welcher Aktion?

Richtig. Es würde aber *1* VL pro OS ausreichen, zumindest ist das mein Wissensstand in dieser Sache. Du darfst es nicht, reicht dir das nicht?

Du kannst den WSUS bzw. den BITS, das ist der Dienst der die Updates von A nach B transportiert, auch begrenzen. http://wsus.de/bits Richtig, Du kannst die GPOs auch in der Domain ansiedeln, und einen passenden WMI-Filter auf das IP-Segment erstellen. Dann bekommen Clients immer den richtigen WSUS, bzw. das richtige GPO zugewiesen. Wenn deine WSUS-Server auf W2008R2 oder kleiner installiert sind, prüfe unbedingt die Build des WSUS ab. Details wo die Build zu finden ist, welche Updates man für welche Build benötigt, findest Du in der WSUS-FAQ No. 44: http://wsus.de/faq

Es gibt leider immer noch Benutzer, die mit gedrückter linker Maustaste quer über den Bildschirm fahren, von daher kann ich den Wunsch nach der Rückfrage schon verstehen. Es ist für solche Benutzer schwer genug jeden Tag am PC zu arbeiten, noch schwerer sind sie von gewohnten Dingen abzubringen.

Hast Du denn auch die passende(n) Lizenz (VL) dafür im Schrank? Nur wenn Du mind. *1* VL-Lizenz zum passenden OS hast, darfst Du automatisiert Betriebssysteme installieren. Re-Imaging nennt sich das. Hier findest Du weitere Infos dazu: http://blogs.technet.com/b/ptsaustria/archive/2009/11/23/re-imaging-von-windows-7-und-anderen-produkten.aspx https://www.microsoft.com/en-us/Licensing/learn-more/brief-reimaging-rights.aspx Es gibt von MS das Microsoft Deployment Toolkit. Damit ist es recht einfach ein OS zu deployen. Beim erstellen eines Image ist unbedingt SYSPREP zu benutzen, und mach das alles trotzdem außerhalb der Windows Domain.

Hat der User ein Servergespeichertes TS-Profil? Wenn ja, dann dort mal ansetzen.

Nutze die Group Policy *Preferences* dafür.

Den Aufräumvorgang konfigurieren, schon ist in ein paar Tagen Ordnung auf dem DNS: http://www.faq-o-matic.net/2006/04/30/endlich-ordnung-auf-dem-dns-server/

Nein, das sieht schon sauber aus. Beenden wir die Diskussion hier, es funktioniert jetzt wieder bei dir. Beim nächsten Update kannst Du ja einen neuen Thread eröffnen. ;)

Gab es denn im Eventlog Einträge? Es muss welche geben, evtl. gibt es ein eigenes Log von Uninstall2Install. Geht bei mir komplett ohne den Eintrag.

Das Veröffentlichen war sicherlich ein Vorteil für die Admins, die meisten Anwender haben einfach nur installiert. Man kann es noch negativer ausdrücken: MS will nicht aufzeigen, welche riesigen Löcher gestopft wurden. ;) EDIT: Wenn sich ein paar Millionen Admins beschweren, ändert MS vielleicht die Strategie wieder. ;)

Hast Du denn auch die beiden Regeln für das installieren der neuen Version korrekt erstellt? Das *NOT* beim zweiten Teile berücksichtigt? Gibt es ein Transformfile dazu, wird der Installstring angepasst: Msiexec.exe /i {Name der MSI} /qn TRANSFORMS=Name der MST Hast Du kein MST, solltest Du es auch in der Reg löschen. Denn ansonsten wird ja versucht die MST mit im Installationsstring aufgerufen, und da sie nicht vorhanden ist, kann es nur fehlschlagen. Im Ereignisprotokoll solltest Du auch passende Meldungen finden.

Danke. Teilweise kann ich MS verstehen, mit den detaillierten Erläuterungen können evtl. helle Köpfe den Fehler aktiv ausnutzen. Durch das nicht kommunizieren soll das möglicherweise erschwert werden. Andersrum fördert es nicht das Vertrauen der Anwender/Administratoren in MS. Mit W10 wird sich das ein oder andere in Sachen Updates ändern, möglicherweise muss MS auch wieder zurückrudern, weil die Praxis anders aussieht als die Ms-Theorie.

Bitte nicht böse sein, aber ohne Grundlagen die IT einer Praxis aufbauen wollen, ist schon IMHO sehr gewagt. Am besten holst Du dir einen kompetenten Dienstleister ins Boot, dem dann über die Schulter schauen und auch noch etwas dabei lernen. Bitte bedenke auch, es sind nicht deine Daten die durch eine evtl. Fehlkonfiguration deinserseits ins Netz gelangen, es sind die der unbedarften Patienten. Die verlassen sich allerdings darauf, das ordentlich mit ihren Daten umgegangen wird.

Ist die Newsquelle geheim? Wenn nein, dann poste sie doch hier. Ohne Quellenangebe ist es nutzlos.

Evtl. hilft dir ja dieser Artikel weiter: http://blogs.technet.com/b/craigf/archive/2010/09/20/backing-up-and-restoring-domain-based-dfs-namespaces.aspx