12
Windows 7 in AD2003 - Update über Proxy klappt nicht
Hallo erstmal! Bin hier gerade eben Mitglied geworden, weil es hier doch eine Menge interessanter Sachen zu finden gibt. Ich hoffe hier bei Bedarf Hilfe zu finden, und vielleicht auch mal geben zu können.
Seit kurzem setzen wir die ersten Win7-Pro-PC's in unserer AD2003-Domäne ein. Bislang gab es nur XP Pro auf den PC's.
Der Internetzugriff erfolgt generell über einen Squid-Proxy, der über eine Gruppenrichtlinie fest und durch den User nicht veränderbar vorgegeben wird. Das klappte auch mit Windows 7 und dem IE8 einwandfrei vom Moment des Domänenbeitritts an.
Das automatische Update der XP-Clients klappt immer. Das automatische Update der Win7-Rechner klappt NIE. Er fragt immer nach dem Benutzername und Kennwort des Proxies, die natürlich identisch mit denen des Benutzers am Rechner sind. Beim Arbeiten mit dem Explorer kommt die Abfrage nach Benutzername und Passwort auch nie. Aber egal was ich beim Windows-Update als Benutzername und Passwort auch eingebe. Es geht nicht!
Habe mir gestern stundenlang die Finger wundgegoogelt und kam immer wieder beim selben Punkt an:
netsh winhttp set proxy source=ie (oder auch die Variante mit direkter Angabe des Proxies und des Ports)
Alle möglichen Varianten habe ich zigmal probiert. Er setzt die Proxyeinstellungen zwar wie gewünscht, wie man mit
netsh winhttp show proxy
auch sehen kann.
Am Ergebnis ändert es aber nichts. Der Internetzugriff über den Explorer funktioniert immer und das Update funktioniert nie.
Was kann ich noch tun? Gibt es z.B. eine Möglichkeit über eine Gruppenrichtlinie für Windows-Updates den Proxy zu umgehen? Oder muß man was in Squid ändern. Nur. Warum funktioniert dann ALLES im Internet über den Explorer?
Seit kurzem setzen wir die ersten Win7-Pro-PC's in unserer AD2003-Domäne ein. Bislang gab es nur XP Pro auf den PC's.
Der Internetzugriff erfolgt generell über einen Squid-Proxy, der über eine Gruppenrichtlinie fest und durch den User nicht veränderbar vorgegeben wird. Das klappte auch mit Windows 7 und dem IE8 einwandfrei vom Moment des Domänenbeitritts an.
Das automatische Update der XP-Clients klappt immer. Das automatische Update der Win7-Rechner klappt NIE. Er fragt immer nach dem Benutzername und Kennwort des Proxies, die natürlich identisch mit denen des Benutzers am Rechner sind. Beim Arbeiten mit dem Explorer kommt die Abfrage nach Benutzername und Passwort auch nie. Aber egal was ich beim Windows-Update als Benutzername und Passwort auch eingebe. Es geht nicht!
Habe mir gestern stundenlang die Finger wundgegoogelt und kam immer wieder beim selben Punkt an:
netsh winhttp set proxy source=ie (oder auch die Variante mit direkter Angabe des Proxies und des Ports)
Alle möglichen Varianten habe ich zigmal probiert. Er setzt die Proxyeinstellungen zwar wie gewünscht, wie man mit
netsh winhttp show proxy
auch sehen kann.
Am Ergebnis ändert es aber nichts. Der Internetzugriff über den Explorer funktioniert immer und das Update funktioniert nie.
Was kann ich noch tun? Gibt es z.B. eine Möglichkeit über eine Gruppenrichtlinie für Windows-Updates den Proxy zu umgehen? Oder muß man was in Squid ändern. Nur. Warum funktioniert dann ALLES im Internet über den Explorer?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 168179
Url: https://administrator.de/contentid/168179
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
12 Kommentare
Neuester Kommentar
WindowsUpdates sind immer n bissl was besonderes. Da wird n bissl mehr benötigt außer HTTP; div. Dienste werden dazu benötigt der übern Proxie raus müsste.
Ob das konfigurierbar ist beim SQUID, keine Ahnung!
Was ich empfehlen würde ist ganz klar einen WSUS aufzusetzen! Ist wirklich nicht schwer; und die Inet-Leitung wird geschont.
Gruß
ravers
Ob das konfigurierbar ist beim SQUID, keine Ahnung!
Was ich empfehlen würde ist ganz klar einen WSUS aufzusetzen! Ist wirklich nicht schwer; und die Inet-Leitung wird geschont.
Gruß
ravers
Hi,
wie schaut die Benutzerauthentifzierung bei deinem Squid aus bzw. wenn deine User
im Internet Explorer etc. surfen wollen? Müssen Sie sich am Windows 7 dann auch nochmal
am Proxy anmelden oder passiert das automatisch?
wie schaut die Benutzerauthentifzierung bei deinem Squid aus bzw. wenn deine User
im Internet Explorer etc. surfen wollen? Müssen Sie sich am Windows 7 dann auch nochmal
am Proxy anmelden oder passiert das automatisch?
Hoi, Ihr seid aber fix!
@ Ravers: WSUS wäre für mich der Notausgang. Aus Zeitmangel (und Bequemlichkeit) habe ich mich bisher gescheut, da ranzugehen. Bislang war es ja auch schlichtweg nicht notwendig
@ daMopsi: Nein, die Benutzer müssen sich nicht nochmal authentifizieren. Das hatte ich früher mal so. Aber da ohnehin ein Benutzer = ein PC ist, habe ich das irgendwann deaktiviert. Es wird automatisch der angemeldete Benutzer durchgereicht und protokolliert.
@ Ravers: WSUS wäre für mich der Notausgang. Aus Zeitmangel (und Bequemlichkeit) habe ich mich bisher gescheut, da ranzugehen. Bislang war es ja auch schlichtweg nicht notwendig
@ daMopsi: Nein, die Benutzer müssen sich nicht nochmal authentifizieren. Das hatte ich früher mal so. Aber da ohnehin ein Benutzer = ein PC ist, habe ich das irgendwann deaktiviert. Es wird automatisch der angemeldete Benutzer durchgereicht und protokolliert.
läuft deine Proxyauthentifizierung über ntlm?
wenn ja, hast du schon mal geschaut ob du folgendes schon gemacht hast?
start - ausführen - secpol.msc - lokale Richtlinien - Sicherheitsoptionen - netzwerksicherheit: LAN Manager-Authentifizierungsebene
und das ganze auf LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden)
wenn ja, hast du schon mal geschaut ob du folgendes schon gemacht hast?
start - ausführen - secpol.msc - lokale Richtlinien - Sicherheitsoptionen - netzwerksicherheit: LAN Manager-Authentifizierungsebene
und das ganze auf LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden)
Glaub mir: ein WSUS aufzusetzen ist kinderleicht, dann noch die Einstellungen verteilen und gut ist.
Ohne Updates runterzuladen dauert die Geschicht wahrscheinlich keine Stunde. Das Herunterladen dauert natürlich etwas länger, und man muß n bissl HDD-Platz irgendwo haben.
Kommt natürlich drauf an für wieviel Clients. Bei 3-4 Rechnern würd ichs natürlich auch nicht machen.
Ohne Updates runterzuladen dauert die Geschicht wahrscheinlich keine Stunde. Das Herunterladen dauert natürlich etwas länger, und man muß n bissl HDD-Platz irgendwo haben.
Kommt natürlich drauf an für wieviel Clients. Bei 3-4 Rechnern würd ichs natürlich auch nicht machen.
Hi,
also aus meiner bescheidenen Sicht ist es nicht sehr clever, WSUS in einem größeren Umfeld nicht einzusetzen. Die Einarbeitungszeit ist relativ gering und die später eingesparte Zeit wiegt das locker auf. Kann Deine Antwort insofern nicht ganz nachvollziehen.
@ Ravers: WSUS wäre für mich der Notausgang. Aus Zeitmangel (und Bequemlichkeit) habe ich mich bisher gescheut, da
ranzugehen. Bislang war es ja auch schlichtweg nicht notwendig
ranzugehen. Bislang war es ja auch schlichtweg nicht notwendig
also aus meiner bescheidenen Sicht ist es nicht sehr clever, WSUS in einem größeren Umfeld nicht einzusetzen. Die Einarbeitungszeit ist relativ gering und die später eingesparte Zeit wiegt das locker auf. Kann Deine Antwort insofern nicht ganz nachvollziehen.
@ Ravers: Habe gerade mal die verschiedenen Varianten durchprobiert. Vorkonfiguriert war nichts. Habe nach jeder Änderung den Update-Dienst neu gestartet. Aber egal, was ich da auch einstelle: Der Explorer geht, Updates gehen nicht.
@Coreknabe: Ganze einfach! Was der Bauer nicht kennt.....
Aber ich bin absolut ja nicht beratungsresistent. Sonst hätte ich ja hier gar nicht erst gefragt
.
Habe mir daher gerade den WSUS runtergeladen. Leider schlug auch prompt die Installation auf meinem W2003X64-Domänencontroller fehl.
Fehler: mscoree nicht gefunden
Gibt's dazu auch eine spontane Idee?
@Coreknabe: Ganze einfach! Was der Bauer nicht kennt.....
Aber ich bin absolut ja nicht beratungsresistent. Sonst hätte ich ja hier gar nicht erst gefragt
.Habe mir daher gerade den WSUS runtergeladen. Leider schlug auch prompt die Installation auf meinem W2003X64-Domänencontroller fehl.
Fehler: mscoree nicht gefunden
Gibt's dazu auch eine spontane Idee?
In Google scheinbar auch noch nicht eingearbeitet?
http://support.microsoft.com/kb/316091/de
Auf Deutsch: .NET-Framework ist nicht installiert. Nebenbei bemerkt, halte ich es für keine allzu gute Idee, den WSUS auf nem DC zu installieren.
http://support.microsoft.com/kb/316091/de
Auf Deutsch: .NET-Framework ist nicht installiert. Nebenbei bemerkt, halte ich es für keine allzu gute Idee, den WSUS auf nem DC zu installieren.
Sorry, da bin ich schonmal drübergestopert. War mir aber entfallen.
Das erschwer die Sache natürlich. Die Sache ist die, daß unsere Umgebung so aussieht, daß wir im Moment einen (bald zwei) Xenserver laufen haben, auf denen praktische alles redundat vorhanden und an unterschiedlichen Stellen im Werk platziert sein wird. Auf den beiden XEN-Servern laufen
- jeweils drei geclusterte 2003er X64 Terminalserver
- ein Squid-Proxy
- ein DC
- ein MySQL-Server
- ein Samba Fileserver
- zwei 2000er Terminalserver, die aber nur noch für eine bestimmte Terminalemulation benutzt werden. Kostet kein Heu und spart neue Lizenzgebühren.
Das ganze funktioniert seit geraumer Zeit problemlos. Bis wir neuerdins die ersten Win 7 haben
.
So wie es aussieht, habe ich einfach keine freie 2003er-Server-Lizenz (oder 2008er Server-Lizenz), auf der ich WSUS installieren könnte. Es muß ja wohl ein Windows Server Betriebssystem sein, aber eben nicht 2003X64.
Gibt es noch andere andere Möglichkeiten oder muß ich in den sauberen Apfel beißen und mir noch extra eine Serverlizenz zulegen?
Das erschwer die Sache natürlich. Die Sache ist die, daß unsere Umgebung so aussieht, daß wir im Moment einen (bald zwei) Xenserver laufen haben, auf denen praktische alles redundat vorhanden und an unterschiedlichen Stellen im Werk platziert sein wird. Auf den beiden XEN-Servern laufen
- jeweils drei geclusterte 2003er X64 Terminalserver
- ein Squid-Proxy
- ein DC
- ein MySQL-Server
- ein Samba Fileserver
- zwei 2000er Terminalserver, die aber nur noch für eine bestimmte Terminalemulation benutzt werden. Kostet kein Heu und spart neue Lizenzgebühren.
Das ganze funktioniert seit geraumer Zeit problemlos. Bis wir neuerdins die ersten Win 7 haben
.So wie es aussieht, habe ich einfach keine freie 2003er-Server-Lizenz (oder 2008er Server-Lizenz), auf der ich WSUS installieren könnte. Es muß ja wohl ein Windows Server Betriebssystem sein, aber eben nicht 2003X64.
Gibt es noch andere andere Möglichkeiten oder muß ich in den sauberen Apfel beißen und mir noch extra eine Serverlizenz zulegen?
Da sitzen aber die Herren Sparemann & Söhne in der Geschäftsführung?
Auch von der IT-Seite erscheint mir die Planung / Umsetzung der Umgebung veraltet oder, wenn ich böse sein will, nicht durchdacht.
- EIN DC? Dafür aber geclusterte TS? Halbherzig, was nützt das schliesslich, wenn der einzige DC abraucht? Und nen Neustart für Updates braucht der doch ab und an auch mal?
- Vermutung: Die Server sind allesamt älter? Macht es nicht unwahrscheinlich, dass Fehler auftreten, die nur mühsam wieder gefixt werden können. Wenn überhaupt.
- Windows 7-Clients sind eher nicht wirklich gewollt, sondern man merkt, dass man mit dem alten Kram nicht weiter kommt? Da fängt's langsam an und ich verspreche Dir, dass da noch andere Klopper folgen werden.
Meine Empfehlung: In den sauren Apfel beißen und die Umgebung modernisieren. Alles virtualisieren. Unbedingt 2.DC installieren!!! Leistungfähigen Server kaufen, wenn's viele virtuelle Maschinen sein sollen, mit Server 2008 Datacenter, da braucht's für die virtuellen Maschinen keine weiteren Lizenzen, so das VM-OS denn auch Server 2008 ist. Muss die Umgebung wirklich ausfallsicher sein? Wenn ja, Cluster mit zweitem, identischen Server. Alternativ tun's auch zwei XEN-Server mit DRDB. So können vorhandene Windows-Lizenzen weiter genutzt werden. Wird aber auch nicht ewig Spaß bringen, da das Zusammenspiel Win7-Client <-> Server 2008 R2 deutlich spaßiger (auch vom Funktionsumfang und damit verbundener Möglichkeiten) und reibungsloser läuft.
Und wenn der Chef das Geld nicht locker machen will: Rechne mal zusammen, wieviel Zeit Du damit verbringen musst, den alten Ramsch weiterzubetreiben. Wie viel schwieriger die Fehlerbehebung im Fall der Fälle ist. Und schließlich wird's nicht leichter, da die Welt sich weiterdreht und der alte Gammel immer weniger unterstützt wird. Und Totschlagargument: Wenn ich wirklich Hochverfügbarkeit bereitstellen muss, brauche ich auch entsprechende Mittel und die kosten eben Geld. Ist nicht so? Dann kann die Umgebung wohl auch nicht so wichtig sein...
Auch von der IT-Seite erscheint mir die Planung / Umsetzung der Umgebung veraltet oder, wenn ich böse sein will, nicht durchdacht.
- EIN DC? Dafür aber geclusterte TS? Halbherzig, was nützt das schliesslich, wenn der einzige DC abraucht? Und nen Neustart für Updates braucht der doch ab und an auch mal?
- Vermutung: Die Server sind allesamt älter? Macht es nicht unwahrscheinlich, dass Fehler auftreten, die nur mühsam wieder gefixt werden können. Wenn überhaupt.
- Windows 7-Clients sind eher nicht wirklich gewollt, sondern man merkt, dass man mit dem alten Kram nicht weiter kommt? Da fängt's langsam an und ich verspreche Dir, dass da noch andere Klopper folgen werden.
Meine Empfehlung: In den sauren Apfel beißen und die Umgebung modernisieren. Alles virtualisieren. Unbedingt 2.DC installieren!!! Leistungfähigen Server kaufen, wenn's viele virtuelle Maschinen sein sollen, mit Server 2008 Datacenter, da braucht's für die virtuellen Maschinen keine weiteren Lizenzen, so das VM-OS denn auch Server 2008 ist. Muss die Umgebung wirklich ausfallsicher sein? Wenn ja, Cluster mit zweitem, identischen Server. Alternativ tun's auch zwei XEN-Server mit DRDB. So können vorhandene Windows-Lizenzen weiter genutzt werden. Wird aber auch nicht ewig Spaß bringen, da das Zusammenspiel Win7-Client <-> Server 2008 R2 deutlich spaßiger (auch vom Funktionsumfang und damit verbundener Möglichkeiten) und reibungsloser läuft.
Und wenn der Chef das Geld nicht locker machen will: Rechne mal zusammen, wieviel Zeit Du damit verbringen musst, den alten Ramsch weiterzubetreiben. Wie viel schwieriger die Fehlerbehebung im Fall der Fälle ist. Und schließlich wird's nicht leichter, da die Welt sich weiterdreht und der alte Gammel immer weniger unterstützt wird. Und Totschlagargument: Wenn ich wirklich Hochverfügbarkeit bereitstellen muss, brauche ich auch entsprechende Mittel und die kosten eben Geld. Ist nicht so? Dann kann die Umgebung wohl auch nicht so wichtig sein...
Spareman & Söhne sind dank der Wirtschaftskrise derzeit leider ausschlaggebend. Natürlich hätte ich auch gerne alles auf dem neuesten Stand. Leider ist das momentan einfach nicht finanzierbar.
Wie schon geschrieben, wird auch bald der zweite XEN-Server laufen. Der, auf dem bisher alles läuft, ist gerade erst ein gutes halbes Jahr alt und bislang sehr zuverlässig. Die Hardware für den zweiten XEN-Server ist auch schon komplett. Es fehlt momentan einfach nur die Zeit dafür um das ganze Projekt fertigzustellen.
Die virtuellen Server, die heute schon auf dem neuen XEN-Server laufen, waren vor nicht allzu langer Zeit noch auf einzelne Server verteilt. Am Schluß der ganzen Aktion wird es tatsächlich nur noch zwei wirklich gut motorisiere XEN-Server geben und alles wichtige ist dann redundant. Natürlich gibt es dann auch zwei DC's.
Das ganze sollte dann schon noch ein paar Jahre laufen, bis alles komplett neu umgekrempelt werden wird.
Wie schon geschrieben, wird auch bald der zweite XEN-Server laufen. Der, auf dem bisher alles läuft, ist gerade erst ein gutes halbes Jahr alt und bislang sehr zuverlässig. Die Hardware für den zweiten XEN-Server ist auch schon komplett. Es fehlt momentan einfach nur die Zeit dafür um das ganze Projekt fertigzustellen.
Die virtuellen Server, die heute schon auf dem neuen XEN-Server laufen, waren vor nicht allzu langer Zeit noch auf einzelne Server verteilt. Am Schluß der ganzen Aktion wird es tatsächlich nur noch zwei wirklich gut motorisiere XEN-Server geben und alles wichtige ist dann redundant. Natürlich gibt es dann auch zwei DC's.
Das ganze sollte dann schon noch ein paar Jahre laufen, bis alles komplett neu umgekrempelt werden wird.
Bin grade noch im Fundus am Suchen ob ich nicht noch eine freie 2003-Server-Lizenz im Schrank habe. Falls ja, dann packe ich den als virtuellen WSUS-Server auf den XEN-Server.
Falls nicht: Gibt's noch andere Ideen, wie ich das Problem lösen könnte?
Falls nicht: Gibt's noch andere Ideen, wie ich das Problem lösen könnte?
