RalphT

Hallo, ich habe einen ziemlich unangenehmen Fehler: Zweitweise, unregelmäßig klemmt es im LAN. Dieser Stillstand kann für 2 Sekunden oder auch schon mal bis zu 30 Sekunden dauern. Es äüßert sich so, dass ein Dateizugriff auf einen der Netzlaufwerke nicht möglich ist. Oder man macht den Datei-Explorer auf und es zeigt sich nur ein Teil der Netzlaufwerke. Nach der Stillstandzeit werden alle Netzlaufwerke angezeigt. Dementsprechend klemmen auch die Programme, mit denen man auf den Netzlaufwerken arbeitet. Jetzt weiß ich nichgt so recht, wo man da suchen soll. Wenn Beschwerden kommen, ist der Fehler meist schon wieder weg. Ich habe hier ein paar Switche, 2 DCs mit 2003R2 und Clients alle in der Domäne. Hat da mal jemand einen Ansatz, wo und wie man den Fehler einkreisen könnte?

Jetzt habe ich den Eintrag in WAIK gefunden. Dort habe ich das Kommando eingetragen. Das mit dem Administrator funkioniert. Auch habe ich die paar Eingaben, die beim Setup verlangt werden unterdrücken können, indem noch der Eintrag "SkipI UserOOBE" unter Microsoft-Windows-Shell-Setup_neutral hinzugefügt wurde. Allerdings müssen dann die notwendigen Antworten auch in der Antwortdatei hinterlegt sein. Allerdings habe ich noch eine Frage: Wird denn unter Windows 7 keine Benutzerangabe und Angabe der Firma verlangt? Wenn ja, wo kann man diese Information einsehen? Unter Windows XP konnte man das mit rechter Maustaste - Arbeitsplatz einsehen. Kann ich auch dieses Benutzerangaben in der Antwortdatei mitgeben? Ich habe das jetzt erstmal über die Registrierung unter [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion] "RegisteredOrganization" "RegisteredOwner" festgelegt.

Ich hatte noch mal etwas zum Administratorkonto gegoogelt. Eine Lösung sei, dass das AutoLogon für den Admin in WAIK eingestellt werden kann/soll. Das stellt mich allerdings nicht so sehr zu frieden, da ich das nicht haben möchte. Ich muss also später, dass bei jedem Rechner dieses wieder rausnehmen. Das ist also wieder zusätzlich Arbeit. Eine andere, für mich elegantere Möglichkeit, soll ein Eintrag in der unattend.xml sein: In dieser Datei müsste ein DOS-Kommando "net user administrator /active:yes eingebaut werden. Das müsste man zum Schluss einfügen. Damit wäre dann die Sache ok. Äh, weiß jemand wie ich das da einfügen muss?

Hallo, ich befasse (quäle) mich gerade mit WAIK und sysprep herum. Ich habe hier ein paar Notebooks mit gleicher Hardware und wollte, wie bei WinXP, ein Image mit Acronis erstellen und verteilen. Bei WinXP hatte ich einen Ordner sysprep und eine Antwortdatei erstellt. Anschließend hatten alle Geräte eine andere SID. Das lief bislang immer perfekt. Jetzt habe ich WAIK installiert und komme nicht so mit den ganzen Einstellungen klar. Dazu habe ich ein paar spezielle Fragen: Nachdem sysprep -generalize /unattend:C:\unattend.xml ausgeführt worden ist und der Rechner mehrmal hochbootete, kommen noch ein paar Eingaben, die ich gerne unterdrückt hätte. Es kommt - eine Sprachauswahl - ein neuer User wird angelegt, gefolgt mit einer Vergabe des Rechernamens - außerdem wurde das Administratorkonto deaktiviert Diese Dinge hätte ich gerne noch "bereinigt". D.h. ich möchte keinen neuen User hinzufügen, das Adminkonto soll nicht deaktiviert werden, usw. Kann mir jemand dazu die Werte in WAIK nennen?

So, nachdem der angehende Renter wieder in der Firma war, bin ich nochmal dem DHCP-Problem nachgegangen. Wireshark wurde gestartet. Und siehe da, der Server hatte immer wieder abgelehnt (NAK) Daraufhin habe ich die Reservierung und unter Adressleases alles gelöscht, was mit dem NB zu tun hatte. Anschließend ohne Reservierung probiert. Dann ging es. Anschließend wieder eine Reservierung vorgenommen. Auch dann ging es noch. Was da nun schief lief kann ich nicht sagen. Dazu noch eine Frage: Ich habe das Protokoll vom Wireshark noch offen. Und in der Zeile (NAK) habe ich mal genauer nachgesehen. Wo steht denn hier, warum die Adressvergabe abgelehnt worden ist? Konnte so bis dahin nichts erkennen.

Ja, so ein angehender Renter braucht schon seine Ruhe. Ereignisanzeige?? Da hab ich überhaupt nicht dran gedacht. Das Ganze ging mir eh auf den Zeiger. Den IE und Proxy meine ich vergessen zu können. Ich muss mich erst mal auf die DHCP-Geschichte kümmern. Ich guck mal mit dem Wireshark. Der ist ja agnz gut zum gucken.

Ja, kann ich es jetzt leider nicht mehr testen, da der gute Mann mit dem Gerät schon Feierabend hat. Muss ich auf morgen verschieben.

Leider war dort nur ein Eintrag drin. Ich habe jetzt eine Systemwiederherstellung durchgeführt. Nachdem ich alles wieder manuell eingetippt habe, ging es. Was allerdings immer noch nicht funktioniert, ist der DHCP-Betrieb. Er findet keinen der beiden DHCP-Server. Gut man könnte mit dem Netzwerkmonitor auf dem Server jetzt mitschneiden, warum keine Adressvergabe zu Stande kommt. Aber ich denke, dass das NB noch einen Wurm drinnen hat.

Leider bin ich nicht fit in WIN7, aber vielleicht kann das hier ja mal jemand bei sich testen. Kann es denn sein, dass bei WIN7 zwei Gateways angezeigt werden können? Ein Ping auf den Router ist natürlich ok.

Leider liegt hier nicht der Fehler. Denn ein Ping auf andere Komponenten im LAN ist möglich. Ich habe mich an dieses NB gesetzt und von dort über den Browser an der Firewall angemeldet. Weiterhin ist dort VMware Server installiert. Ein Hostsystem hat sogar Internet über das LAN. Also ist das Ethernetmodul, die Verkabelung für ok. Nur das NB selber zickt rum.

IPCONFIG /ALL fällt mir nur eine Kleinigkeit auf: Beim Gateway zeigt er als ersten Eintrag 0.0.0.0 an darunter dann die richtige Gateway Adresse. (Ist das so, weil IPv6 hier nicht aktiviert ist?) Windows-Firewall ist aus. Ein Tracert meldet gleich zum Anfang: Zielhost nicht erreichbar. Die IP die davor steht, ist die IP vom NB. Eine Wählverbindug war über einen Stick eingerichtet. Ich habe die Verbindung gelöscht, aber daran lag es nicht.

Hallo, ich denke ein ganz einfaches Problem, aber irgendwie doch wohl nicht: Ich habe hier im Firmennetzwerk ein NB mit Win7 Home. Seit kurzem hat das Gerät kein Internet mehr. Zuerst holte sich das Gerät vom DHCP-Server keine IP-Adresse. Ich habe dann eine Adresse mit richtigen Gateway und DNS manuell eingetragen. Ein Ping nach draußen zeigt Zeitüberschreitung. DNS nach externen Adresssen löst er richtig auf. Intern kann das Gerät alles erreichen. Hm, was kann das sein?

So, jetzt nach einer weiteren Stunde der Fehlersuche habe ich den Fehler gefunden. Nutzer die von bestimmten Gruppen Mitglieder waren, den wurde auf ihrem Notebook der WLAN-Adapter und das Modem in der Systemsteuerung deaktiviert. Ich habe auf diesen Geräten eine Software installiert, die USB-Sticks, WLAN, Modems und Ports verbieten kann. Naja, da war halt ein Haken zuviel gesetzt.

Also, das Windows ist eine Volumenlizenz und wurde auf einem NB installiert. Anschließend mit Acronis die Images verteilt. Ich habe aber jedes kopierte NB mit sysprep erneut versiegelt. Der Fehler trat nach 1 Jahr Laufzeit erst auf. Ich werde am NB mal den Richtlinienergebnissatz anwenden. Ich schätze, dass ich da die Lösung finden werde. Die Gruppe Büro hat keine weiteren Mitgliedschaften. Aber ich kontrolliere das auch nochmal. Vielleicht hat ja jemand das geändert, was ich nicht hoffen will.

Hallo Light, ich denke nicht, da das alle 20 Notebooks betrifft. Die Ursache muss irgend eine Gemeinsamkeit für alle aufweisen.

Hallo, ich sitzte gerade vor einem ****en Fehler. Ich habe hier 20 Notebooks mit WinXP. Alle NBs verbinden sich über das WLAN mit dem Domänencontroller. Alle die Mitglieder, die der Gruppe Buero angehören, können sich nicht anmelden. Bei diesen Usern ist der WLAN-Adpater und das eing. Modem deaktiviert. Das betrifft auch User, die lokale Adminrechte auf dem NB haben. Schiebe ich den User in eine andere Gruppe in der AD, dann klappt alles problemlos. Eine 802.1x Authentifizierung habe ich hier nicht. Ich habe auch schon alle GPOs deaktiviert (auch die default GPO). Wo könnte man da noch suchen?

Du kannst bei Deinem Lancom das Intranet auf 192.168.1.0 /24 legen. Die DMZ auf 192.168.2.0/24. Das Gerät meine ich, hat 4 Ports. Du kannst beim Lancom jeden der 4 Ports so belegen, wie Du es benötigtst. Also z.B. Intranet auf Port 0+1 und DMZ auf 2+3. Somit hast Du schon mal 2 verschiedene Subnetze. Anschließend legst Du im Lancom Regeln in der Firewall an. Dort könnte man z.B. folgendes Szenario einstellen: Alles vom Intranet zur DMZ erlauben. Und nichts von der DMZ zum Intranet erlauben. Das wäre nur ein von ganz vielen Beispielen. Der DSL-Zugung ist für beide zugänglich. Aber auch hier kann man im Lancom z.B. gewisse Seite nur für die DMZ verbeiten. Also der Spielraum ist hier sehr hoch. Auch kann man das Internet für die DMZ "abschalten" so wie Du es nennst. Auch dieses lässt sich zeitbasiert steuern.

Danke noch mal für den Link, aber das kannte ich leider schon. Ich habe mich nach diesem HowTo unter Windows Server How-To Guides: Teil 1 – Einrichten einer Zertifizierungsstelle - ServerHowTo.de gerichtet. Dort ist auf Seite 2 auch beschrieben, wie das Zertifikat für den Computer installiert wird. Aber leider funktioniert das bei mir nicht. In der MMC unter Zertifikate (lokaler Computer) ist das Zertifikat unter "Eigene Zertifikate" sichtbar. Es scheint also da zu stehen, wo es auch hingehört. Aber scheinbar habe ich ja noch etwas falsch gemacht. Was mir noch aufgefallen ist: In dieser Anleitung weichen die Screenshots von meinen ab. Die Screenshots sind ja auf Windows 2003 Server gemacht worden. Das habe ich auch.

Ich habe das jetzt mal gemacht oder besser versucht, denn es geht leider noch nicht. Ich habe erst das Benutzerzertifkat über die Weboberfläche der CA installiert. Ein Computerzertifikat konnte ich da nicht finden. Ich habe dann auf dem Client einer MMC das Snap-in Zertifikate hinzugefügt. Beim Hinzufügen werde ich gefragt für wen. Dort habe ich "Computerkonto" gewählt. Anschließend habe ich unter "Eigene Zertifikate" ein neues Zertikat angefordert. War das richtig?

Hallo, ich habe in einer Testumgebung ein DC und einen Client über einen Switch der 8021.x unterstützt abgeschlossen. Ich wollte jetzt eine Authentifizierung über Zertifikate testen. Der Zugriff mit dem Client funktioniert soweit. Allerdings hat das Ganze einen kleinen Schönheitsfehler: Vor der Anmeldung ist keine Netzwerkkonnektivität möglich. Nach der erfolgreichen Anmeldung meistens ok. Ich habe auf dem Client die beiden Zertifkate installiert. Eines ist unter "Vertrausenswürdige Stammzertifizierungsstellen" sichtbar, das andere unter "Eigene Zertifikate". Der Client hat Win XP. In der LAN-Verbindung unter dem Reiter "Authentifizierung" habe ich folgende Methode ausgewählt: Smartcard oder anderes Zertifikat. Habe ich noch irgendwo einen Haken vergessen oder etwas grundsätzliches verkehrt eingestellt? Falls noch irgendwelche Config-Einstellungen des Radius-Servers o.ä. notwendig sein sollte, dann poste ich das noch. Wollte nicht alles hier aufschreiben.

Danke für die Info.

Also kein Exchange und SQL. WSUS ist im Einsatz. Sonst ist auf dem IIS nichts anderes eingerichtet.

Hallo, ich habe vor eine komplette Windows AD-Umgebung, bestehend aus 2 DCs, ein paar Servern und deren Clients in ein andeers Subnetz zu setzen. Ich denke, ich müsste nur die Firewall, DHCP und DNS neu anpassen. Könnten da größere Probleme auf mich zukommen? Oder gibt es da vorher etwas zu beachten?

@ nurmalso: Hast Du das mit einem PC realisiert oder wie auf der Seite beschrieben, das mit dem Alix-Mainboard?

Ein Resetknopf existiert. Jedoch macht er nur einen normalen Neustart. Aber in der Doku habe ich gelesen, dass man den Switch während er bootet, abbrechen kann. Mit ein paar Kommandos kann man dort z.B. die IP-Adresse setzen. Jedoch macht mich dort einiges stutzig: Zeige ich mit "sysconf view" mir die Daten an, dann steht der Switch angeblich auf seine default-IP-Adresse. Ein Ping oder ein Zugriff per http ist jedoch nicht möglich. Mit dem Befehl "sysconf set" kann man die IP-adresse ändern. Das habe ich auch gemacht, jedoch auch hier ist keine Erreichbarkeit gegeben. Ich suche nochmal in der Doku, vielleicht fnde ich dort noch einen Hinweis. Tja dann hätte ich wohl diese Probleme nicht. Mit einem besseren, modernen Switch hätte die 802.1x Authentifizierung sicherlich geklappt. Das hatte ich ja schon festgestellt.