reinerk

Guten Morgen, bin gerade im Forum am "stöbern" bezüglich dieses Themas: Mannomann,,die "Previews" verursachen an meinen Win 7 Clients und einem 2008R2 Server massive Probleme: Also ich empfehle diese Updates am WSUS abzulehnen, denn nach der Installation von KB3196686 +KB3197869 erscheinen an die 50 - 100 (!) 1101 Fehler .NET im Systemprotokoll. Das schlimme daran ist, daß selbst nach Deinstallation dieser Updates die Fehler bleiben. Also Systemimage zurück, Updates abgelehnt...und es funktioniert. Ganz Extrem ist es am Server 2008R2...hier funktioniert nicht mal mehr die VPN-Verbindung (unterschiedliche Fehlermeldungen). Hat jemand Ähnliches "beobachtet" ? P.S. Habe gerade das hier gefunden : http://www.infoworld.com/article/3142197/microsoft-windows/users-should-avoid-microsofts-just-released-preview-windows-patches.html

Jaaaaaa Jaaaaaaaaa :D Aber mal ernsthaft, und dann beenden wir das : Bevor ich irgendwelche Updates am WSUS genehmige, schau ich mal vorerst in die KB, um mich zu informieren, was da eigentlich installiert werden soll. Bisher nach der Sync auch immer problemlos. Gruß und nochmals Danke :)

Jetzt (!) fehlt nix mehr. Bisher waren diese Infos sofort nach Veröffentlichung verfügbar...heute nicht, und das hat mich etwas verwundert. Wenn ich sonst im WSUS nach der Sync den Link aufgerufen habe, dann gab's da auch sofort Infos. Naja...war heute eben etwas zögerlich das Ganze ;) Danke Dir für die Antwort

" Update für Windows 7 für x64-basierte Systeme (KB3092627) Downloadgröße: 2,2 MB Sie müssen ggf. den Computer neu starten, damit die Änderungen wirksam werden. Updatetyp: Wichtig Installieren Sie dieses Update, um Probleme in Windows zu beheben. Eine vollständige Liste der Problembehebungen in diesem Update finden Sie in dem entsprechenden Microsoft Knowledge Base-Artikel, der weitere Informationen bereitstellt. Nach der Installation dieser Komponente müssen Sie den Computer möglicherweise neu starten. Weitere Informationen: http://support.microsoft.com/kb/3092627 Hilfe und Support: http://support.microsoft.com" Sagt der WSUS Update für Windows 7 für x64-basierte Systeme (KB3092627) Downloadgröße: 2,2 MB Sie müssen ggf. den Computer neu starten, damit die Änderungen wirksam werden. Updatetyp: Optional Installieren Sie dieses Update, um Probleme in Windows zu beheben. Eine vollständige Liste der Problembehebungen in diesem Update finden Sie in dem entsprechenden Microsoft Knowledge Base-Artikel, der weitere Informationen bereitstellt. Nach der Installation dieser Komponente müssen Sie den Computer möglicherweise neu starten. Weitere Informationen: http://support.microsoft.com/kb/3092627 Hilfe und Support: http://support.microsoft.com Sagt die Onlinesuche

Guten Abend, hat jemand von Euch weiterführende Infos zu KB3092627 ? Wurde heute veröffentlicht, aber von MS gibt's nix dazu als Info. 2. Merkwürdigkeit : WSUS verteilt Update als "Wichtig" Onlineupdate sagt "Optional" Vielleicht findet jemand weiterführende Infos zu diesem Update. Danke Euch

Guten Abend, und vielen Dank für die Antworten. War einige Tage ausserhalb und daher nicht in der Lage, gleich zu antworten. Also : es handelt sich um einen Businessanschluß 1. IPv4 und IPv6 Adressen sind fest, selbst nach einem eventuellen Ausfall werden immer die gleichen IP-Adressen zugewiesen ( Pushservice der FB aktiv, also immer Info ) 2. Über MyFritz habe ich einen "hauseigenen" DynDNS von AVM, sollte also klappen, aber..... Nachdem ich mal einen "gesprächigen" Support am Telefon hatte ist mir da was interessantes mitgeteilt worden : Microsoft VPN-Clientsoftware wird derzeit nicht unterstützt und man verwies mich auf Fremdsoftware: Siemens oder Cisco zB. Erscheint mir dann für einen Businessanschluß dann doch schon heftig. OK..ich mach's dann über SSTP. Also nochmals Danke an Euch für die Antworten. Gruß Reiner

Guten Morgen, es gibt ein wirklich großes Problem mit L2TP/PPTP VPN Verbindungen in meinem Netzwerk nach einem Providerwechsel zu KD : Server : 2012R2 Essentials Clients : Windows 7 Professional RRAS ist auf dem Server korrekt eingerichtet Clients konnten sich bis zum ISP-Wechsel ohne Probleme per L2TP-Protokoll einwählen. Seit dem Wechsel und der Installation der neuen FritzBox 6490 Cable klappt da nix mehr. Im Router sind alle entsprechenden Ports wieder freigegeben. VPN mit SSTP klappt ( klar doch, die werden doch Port 443 nicht sperren können ) RDP (testweise freigegeben) klappt auch. Nachdem ich wirklich in Ruhe nochmals alle Einstellungen überprüft hatte, mit dem AVM Support und dem KD-Support telefoniert habe ( die sagen natürlich, daß da nix geblockt bzw. gefiltert wird ) bin ich mir nun mittlerweile (fast) sicher, daß da doch geblockt wird. Meine Frage jetzt an Euch : -Hat jemand längere Erfahrung mit der FritzBox 6490, und ich habe da vielleicht doch etwas übersehen ? -Hat jemand vielleicht eine Info, ob da bei KD doch was geblockt wird ? Danke schon mal für Euren Rat

Ja das dachte ich mir auch schon, bleibt auch nichts anderes mehr. So eine "Verfahrensweise" wie bei dem Kunden ist mir auch noch nicht begegnet ;) Ich danke Euch für die schnellen Antworten, Anregungen und die Hilfe :thumb1:

;-) nein, der 2. DSL Anschluß wurde dem Kunden auf's Auge gedrückt. Der Kunde hat einen VDSL Anschluß, an dem es lt. Aussage der Telekomiker keine feste IP-Adresse gibt. Das ist natürlich absoluter Schwachsinn, denn der Kunde hat einen Businesstarif, und 2 weitere Kunden von mir besitzen ebenfalls VDSL ( Businesstarif) mit fester IP Adresse. Dieser Kunde hier wollte eine feste IP-Adresse für seine VPN-Clients, und deshalb hat man ihm sann zu einem 2. DSL Anschluß "geraten" . Der Drops ist gelutscht, der Kunde hat den Vertrag an der Backe und nun muß man was draus machen. Das der SBS 2011 Standard keine 2 LAN-Karten unterstützt wußte ich nicht...ist das wirklich Fakt ? Wir reden hier vom SBS Standard. Gruß Reiner

Hallo, ich habe ein kleines Problem mit eingehenden VPN Verbindungen an einen SBS 2011. Ich glaube, ich habe da einen Denkfehler reingehauen und mir kann jemand helfen : Im Server stecken 2 Netzwerkkarten : Lan1 : 192.168.120.2 ( DC/Dhcp/DNS) Lan2 : 192.168.120.4 ( vorgesehen für eingehende VPN) Es gibt 2 Router : 192.168.120.1 192.168.120.3 2 Router deshalb, da es 2 DSL -Anschlüsse gibt ( Router2 mit fester IP, deshalb für VPN ) Die Konfig. LAN1 : 192.168.120.2 255.255.255.0 Gateway 192.168.120.1 DNS 192.168.120.2 Konfig LAN 2 192.168.120.4 255.255.255.0 kein Gateway DNS 192.168.120.2 In der RRAS Konfig werden den VPN-Clients Adressen von 192.168.120.101-151 zugewiesen Schnittstelle für den Relay-Agent ist die 192.168.120.2 Keine Verbindung von außen möglich. Steckt der Fehler vielleicht in der Konfig der Netzwerkkarten ? Eine VPN-Verbindung über Router 1 funktioniert, soll aber nicht sein, da die Clients die feste IP anwählen sollen. Wäre toll, wenn Ihr ne Lösung für mich hättet

Guten Morgen, nach dem gestrigen Patchday (11.12.12) funktionieren keine VPN Verbindungen über L2TP-Protokoll zum VPN Server in der Firma. Fehler 691 wird ausgegeben. :confused: Dabei wurden weder Zertifikate geändert noch sind Zertifikate gesperrt. Dieser Fehler trat nach der Installation der Updates und anschließendem Neustart des Servers ( 2008 R2 ) aus heiterem Himmel auf. Eine VPN-Verbindung per PPTP funktioniert, aber auch nur mit dem Konto des Administrators. Ich selbst bin in der Gruppe Domänen-Admins und bekomme keinen Zugriff, da es angeblich an der Authentifizierung scheitert. Merkwürdig ist nur, daß ich über diese PPTP-Verbindung per RDP an den Server rankomme, undzwar mit meinen Benutzerdaten, also sind weder Benutzename noch Kennwort falsch. Was könnte da passiert sein ?

Ja lang ist's her, das ist es natürlich. Vielen Dank für die flotte Antwort

Guten Abend, in der nächsten Woche steht mir ein etwas größeres Problem bevor und ich brauch da mal Eure Hilfe bzw. nützliche Links oder auch eigene Erfahrungsberichte : In einer Firma, die von uns seit Jan. d.J. betreut wird besteht folgendes Problem: In der Domäne befindet sich ein SBS 2003 und in der AD ein 2. DC ( Windows 2000) , der aber seit Monaten nicht mehr im Netz ist. Die haben nicht bemerkt, daß dieser Server im wahrsten Sinne des Wortes tot ist. Wie bekomme ich diese "DC-Leiche" am schnellsten aus der bestehenden Struktur ? Ich danke schon mal vorab.

Guten Abend Leute. Ich komme einfach nicht dahinter, warum beim Server 2008 der VPN-Zugriff nicht klappt : Server 2008 RRAS bei der Aktivierung als reinen VPN-Server eingerichtet. Habe das unzählige Male beim Server 2003 gemacht und es hat bisher gut funktioniert. Der externe Mitarbeiter soll mit seinem PC Vista Business und XP-Prof (kein Domänen-Mitglied)per Zertifikat + IPsec an den Server. Die Zertifikate wurden auf den Clients ordnungsgemäss installiert und in den Eigenschaften der VPN Verbindung die entsprechenden Einstellungen vorgenommen incl. "benutzerdefinierter IPSec-Schlüssel" eingetragen. In den Eigenschaften der Netzwerkverbindung wurde L2TP/IPSec gewählt und das hat wie gesagt auf dem ehemaligen VPN Server ( 2003 ) alles geklappt. Die Clients bekomen jetzt RAS Fehler 788. Ich denke, dass ich bei den NPS-Einstellungen am Server etwas übersehen oder vergessen habe...nur eben was ? Die entsprechenden Auth.-Methoden ( "EAP" und "Smartcard oder anderes Zertifikat" ) sind ausgewählt, der entsprechende Windowsgruppe "VPN" wurde der Zugriff gewährt und der IPSEc Schlüssel wurde eingetragen. Am Router wurden auch keine Einstellungen geändert. Mir ist folgendes aufgefallen : Beim internen Test von meinem Client ( Vista Business ) kommt die VPN Verbindung zwar zu Stande ( über private und auch öff. IP ) aber in den Details der VPN Verbindung erscheint keinerlei Verschlüsselung, sondern nur EAP als Authentifizierung. Ich weiss jetzt nicht mehr im Moment, wo ich bei der Fehlersuche ansetzen sollte. Wäre Super, hier Lösungsansätze zu erhalten

Sorry, hab's bemerkt

Hallo Leute, mir scheint, ich bin hier richtig, denn bei mir gibt's ähnliche Probleme, daher sollte das hier besprochen werden, denke ich mal, bevor ich da einen neuen Beitrag schreibe. Wie der Titel schon beschreibt, habe ich Probleme bei der Namensauflösung der anderen Rechner im (Test-)Netzwerk. Server = 2003 DC Client 1: Vista Business ( Domänmember ) Client 2: Win 7 Enterprise ( noch kein Domänmember ) Folgendes Problem : es ist nicht möglich den Server per Netbios-Name im Netzwerk zu finden Ping IP und Ping FQDN funktionieren. NSlookup fehlerfrei Also gehe ich davon aus, dass der Fehler nicht am DNS liegt. In den Eigenschaften der LAN-Verbindung ist NetBios over TCP/IP aktiv. Der Fehler tritt auch bei vollständig deaktivierter Windowsfirewall auf. Was mich zusätzlich wundert, ist : Dieser Fehler tritt auch auf, wenn ich als Server 2008-R2 einsetze. Offensichtlich scheint das aber nicht nur mein Problem zu sein : Namensauflösung im LAN funktioniert nicht - Windows 7 Netzwerk & Internet Wenn ich den Win 7 Rechner an der Domäne anmelde, läuft es erstmal alles reibungslos...Willkommen in der Domäne "CNS.LAN" Dann die Fehlermeldung, dass der Name des Clients nicht umbenannt werden kann in "W7E.CNS.LAN".....was aber doch geschieht, wenn man in den Eigenschaften..Computername nachschaut. Da ich mich jetzt irgendwie im Kreis drehe und keinen Lösungsansatz mehr habe, bitte ich Euch um Hilfe

Die Option ist nicht aktiv, daran kann es nicht liegen. Es ist übrigens auch aus folgendem Grund alles recht merkwürdig : Ich habe mir auf meinem Heim Arbeitsrechner ( Vista Business x64) das Stammzertifikat der Domäne und das (Problem-) Benutzerzertifikat des Users installiert..also in keinster Weise identisch mit den Anmeldedaten meines Rechners, der auch nie in dieser Domäne ein Member war, und ich bin sofort nach Aufruf der beschriebenen "Login.bat" mit den entsprechenden LW auf dem Server verbunden...somit schliesse ich auch "Berechtigungsprobleme" auf dem Server aus. Wenn der entsprechende User wieder mal Online ist, muss ich mal per Teamviewer "raufschaun" und nochmal alles abchecken. Bisher hatte ich noch keine Möglichkeit dazu. Wenn man mit "etwas Abstand" später nochmal alles überprüft, findet sich meistens der Fehler. Danke für die Antwort

Hallo Gemeinde, ich habe im Moment ein dringendes VPN-Problem zu bewältigen. Folgende Situation : SBS2003 mit installiertem RRAS und CA 2 Clients ( XP Prof. ) die als Homerechner per VPN mit EAP Authentifikation und IPSec auf den SBS zugreifen. Bis dahin funktioniert alles völlig fehlerfrei. Per Batchdatei sollen dann 2 Laufwerke gemountet werden, so dass diese 2 User die gleichen Netzlaufwerke wie an ihrem Büroarbeitsplatz zur Verfügung haben. Benutzernamen und Passwörter der beiden User sind identisch mit den Zugangsdaten vom Arbeitsplatzrechner. Trotzdem erfolgt immerwieder Benutzer / Passwortabfrage Dieses Scenario habe ich schon bei anderen Usern in anderen kleinen Firmen hinter mir, da klappt das völlig problemlos. In allen Fällen handelt es sich um ganz normale Domänenbenutzer mit entsprechenden Zugriffsrechten auf den jeweiligen Ordnern: Einwahl per Batchdatei (VPN-Verbindung + "net use" ) und der User ist "drin" Habe ich irgendwas übersehen ? Wieso werden trotz Zertifikat Benutzername + Passwort abgefragt Ich häng mal hier die Batch mit an : @echo off c:\windows\system32\rasphone.exe -d buero ping -n 1 192.168.116.2 >nul if errorlevel==0 goto verbinden echo Der Server ist nicht erreichbar, Laufwerke nicht verbunden ! goto end :verbinden net use O: \\192.168.116.2\AC /persistent:no net use P: \\192.168.116.2\PAK /persistent:no echo Laufwerke erfolgreich verbunden :) goto end :end pause exit Danke vorab erstmal

also die WSUS GPO ist neu erstellt aus der Default Domain Policy ( Du weisst wie das geht ) und nur in der Computerrichtlinie : "Administrative Vorlagen-Windows Komponenten- WindowsUpdate" entsprechende Einstellungen angepasst...der WSUS läuft ja auch fehlerfrei. Ich hatte in der Richtlinie : "Computer-Sicherheitseinstellungen- Richtlinien für Öffentliche Schlüssel-Einstellungen für die Überprüfung des Zertifikatpfades" die entsprechenden Standardeinstellungen aktiviert, und der von mir oben beschriebene Registryschlüssel bekam einen Wert zugewiesen, der sowohl die Updates über den WSUS als auch die direkten Online Microsoft Updates verhinderte und dann auch dafür sorgte, dass bei der 2. Anmeldung des Vista Clients, das Login unerträglich lange dauerte. Da dieser Unterschlüssel in der Registry zu den Trusted Publishers gehört, wundert es mich schon, dass kein Zugriff auf die Updateseite von MS möglich ist.

Da gebe ich Dir Recht, als der Vista Client noch Solo war und nicht in der Domäne, schlugen auf Grund dieser von mir getätigten Einträge in der lokalen Gruppenrichtlinie bezüglich der Zertifikate, die Automatischen Updates auch über "Microsoft Update" fehl

Vielleicht hast Du ja die gleichen Probleme wie ich : http://www.mcseboard.de/windows-vista-forum-55/vista-business-server-2008-dc-150631.html und dann schau Dir mal den Wert von diesem Schlüssel an. Lösch diesen Unterschlüssel und rufe die Updates nochmal ab

Ja Danke für's schnelle Antworten. Habe folgendes ausprobiert : 1. Sämtliche GPO's deaktiviert - Kein Wert gesetzt und alle Unterschlüssel bis auf "Safer" waren weg 2. WSUS GPO aktiviert - Alle Unterschlüssel wieder vorhanden aber alle "ohne Wert" ( also wie bei einer jungfräulichen Default Domain Policy, bis auf die WSUS Einstellungen ) 3. Default Domain Policy aktiviert - Unterschlüssel "Safer" wieder mit Wert "1" Das ganze hängt damit zusammen, dass ich in der GPO in den "Richtlinien für öffentliche Schlüssel" und den "Einstellungen für die Überprüfung des Zertifikatpfades" Optionen aktiviert hatte. Da dieser Reg-Schlüssel jetzt "ohne Wert" ist, werde ich das Ganze mal 2 Tage beobachten und mich dann noch mal fix melden, ob sich was getan hat.

Guten Abend Gemeinde, habe mir eine (kleine) Testumgebung aufgebaut : Vista Business + Server 2008 Standard ( beide 64 Bit ) Nachdem beide Systeme wirklich top "laufen" habe ich den Vista Client an der Domäne angemeldet...bis dahin alles in Ordnung. Ab der 2. Anmeldung des Clients ging's dann los : fast 10 min. Wartezeit bis ich angemeldet war, danach nur schleppende Reaktionen am Client. Folgendes ist mir aufgefallen : Auf dem Server 2008 ist der WSUS installiert. Bei dessen Erstsynchronisation ging's schon mit den ersten Fehlern los, dass "einige Updates nicht heruntergeladen werden können". Das Problem ist bekannt und sollte auch schnell behoben sein...dachte ich. Bin dann darauf gestossen, dass in der Registry folgender Schlüssel angelegt wird : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\TrustedPublisher\Safer mit dem Wert 1 Setzt man diesen Wert auf 0 und wiederholt den nicht durchgeführten Download in der WSUS Konsole, dann klappt das. ( Löschen des kompletten Unteschlüssels ..."Safer" bringt den gleichen Erfolg) Nun werden bei der Erstsynchronisation ja einige Mengen an Updates runtergeladen, so dass sich dieses Spiel auch wiederholt. Warum ich das hier erwähne ? Ganz einfach: Nach der Erstanmeldung des Vista-Clients am 2008 DC ist alles noch normal. Nun hat er aber die WSUS-GPO übernommen und bei der 2. Anmeldung kommt der von mir beschriebene Fehler zu Stande....fast 10 min. warten etc. In der Registry des Clients steht der gleiche Schlüssel : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\TrustedPublisher\Safer mit dem Wert 257. Unterschlüssel löschen, oder Wert auf 0 setzen und das Problem ist weg, der Client ist superfix an der Domäne angemeldet. Ich gehe also davon aus, dass es am WSUS liegen muss, der diesen Reg-Eintrag immer wieder neu erstellt ( mit den Standardwerten ). Kennt Ihr diesen Fehler oder hat jemand das gleiche Problem ? Sorry, bevor ich's vergesse : In beiden Systemlogs, sowohl Server, als auch Client tauchen keinerlei Fehlerereignisse auf.

Genau das passiert : Die Datei compmgmt.msc kann nicht geöffnet werden Möglicherweise existiert die Datei nicht (oh ja sie existiert), ist keine MMC-Konsole (was wohl dann?) oder wurde mit einer höheren MMC-version erstellt (Windows 7 ? ) Es könnte auch sein, dass Sie nicht dazu berechtigt sind, auf diese Datei zuzugreifen. ( das kann ich sehr wohl) @grizzly999 : ist eine Neuinstallation ( ca. 1 Woche alt ) und wie gesagt, nicht kaputt "getuned" und bisher völlig fehlerfrei

1. ja 2. ja – na dann eben *.msc kein MMC-SnapIn lässt sich öffnen