wciibb

Ja, ich habe die NIC einmal als Device komplett im BIOS deaktiviert. Glücklicherweise habe ich ja im Augenblick noch meinen WLAN-Adapter mit dem ich ins LAN komme. Sobald ich aber, bei im BIOS deaktiviertem NIC-Adapter, auch wieder versuche irgendwie den Teil der virtuellen Switche aus dem Hyper-V zu entfernen treffe ich immer wieder auf den Fehler. Ich werde jetzt wohl einmal komplett neu installieren und direkt nach dem obligatorischen Patches und Updates die Hyper-V-Rolle drauf ziehen. Ich gehe davon aus dass meine Handlungsweise - obgleich mir nach dem Warten von knapp 30 Minuten keine andere Alternative einfallen würd' - das Notebook komplett hart aus- und wieder einzuschalten den ganzen Krempel in einem korrupten nicht mehr, mit normeln Mitteln repariebaren, undefinierbaren Zustand hinterlassen hat. Also, meine Empfehlung falls jemand das Gleiche macht .. besser zweiten PC zum weiterarbeiten daneben stellen und warten .... ;-)

Ja die Treiber waren aktuell und ich habe das komplette Treiberpakte von FSC (ist'n Fujitsu) neu heruntergeladen und angewendet. Aber die Systemwiederherstellung - natürlich an die habe ich ja garnicht mehr gedacht .. ;-) danke, da werde ich mal gleich schauen. Melde mich wieder - hoffentlich ;-) Ok, beim ersten Punkt vom 16.01. war ich mir nicht ganz sicher ob vorher oder nachher, beim zweiten vom 14.01. schon mehr, beim dritten vom 13.01. definitiv sicher dass er vor der Installation von Hyper-V war ... Jedes mal kann er die Systemwiederherstellung nicht erfolgreich ausführen. Die Datei (C:\Users\.....\AppData\Local\Packages\Microsoft.windowscommunicationsa konnte nicht aus dem Wiederherstellungspunkt extrahiert werden. Unbekannter Fehler bei der Systemwiederherstellung. (0x8007045b) Dann kommt noch ein Hinweis dass man es zur Not mit der "erweiterten Wiederherstellung" - sprich Neuinstallation - versuchen könnte. Gibt es noch andere Ideen? :-)

Hallo, ich hoffe jemand hat noch eine Idee für mich. Also, was habe ich gemacht: Nach der Neuinstallation meines Laptops mit 8.1 Enterprise dachte ich mir es sei mal eine gute Gelegenheit das neue Feature Hyper-V auch auf meinem Laptop zu nutzen. So installierte ich die komplette Rolle mit allen Features was auch problemlos funktioniert hat. Da eine Test-VM ohne echten Netzwerkzugriff natürlich keinen Spaß macht habe ich vor dem Anlegen einer neuen VM natürlich erst einmal den Manager für virtuelle Switches bemüht und wollte einen neuen virtuellen Switch vom Typ Extern erstellen. Hierbei wählte ich als Netzwerkadapter die LAN-Schnittstelle des Laptops und setzte den Haken für die "gemeinsame Verwendung ... für das Verwaltungsbetriebssystem zulassen" - da ich ja auch weiterhin diesen Adapter für die Kommunikation meines Hosts benötige. Soweit so gut, nun kommt mein Fehler ;-) Nach dem bestätigen der Schaltfläche "Anwenden" kommt ja so ein nettes Fenster "Anwenden der..." mit einem Fortschrittsbalken der munter durchs Fenster läuft. Nach dem dann dieser "Lauf" über 25 Minuten dort stand, dachte ich mir, ok ist nicht gut und habe versucht das Ganze irgendwie ordentlich zu beenden was natürlich nicht geht. Ein verzweifelter Versuch des killen der Tasks über den Taskmanager funktionierte natürlich auch nicht mehr. Ich weiß nicht was es da solange machte. Schlussendlich betätigte ich den Netzschalter - also die rabiatere Methode. Nach dem Neustart des Laptops war jetzt natürlich meine LAN-NIC irgendwie "defekt". Sie erschien zwar noch als Adapter, aber hier war nur das Hyper-V-Protokoll aktiv und jegliche Änderung dieses Zustandes (IP4 anhaken oder Speed ändern) schlägt fehl. Auch lässt sich der virtuelle Switch im Manager für virtuelle Switches nicht mehr entfernen oder ändern, hier kommt immer die Fehlermeldung "Fehler beim Entfernen des virtuellen Ethernet-Switchs. .... Das Gerät erkennt de Befehl nicht. (0x80070016) Der virtuelle Switch selbst wird als "Privates Netzwerk" angezeigt - sollte also eigentlich mit der NIC nicht mehr viel zu tun haben. Aber wie gesagt er lässt sich nicht entfernen oder sonst wie ändern im Manager. Auch der Versuch der Manipulation des virtuellen Switches mit Hilfe des "Hyper-V Network VSP Bind Application"-Tools nvspbind.exe von MS schlägt fehl mit der Meldung "applying changes .... could not Apply, hr=8007000D". Nun kam ich auf die Idee einfach die Hyper-V Rolle zu deinstallieren, diese Änderungen werden aber nach dem Neutstart mit dem lapidaren Satz " .. Änderung des Features können nicht durchgeführt werden. Änderungen werden rückgängig gemacht." quittiert mit der Folge dass ich die Hyper-V Rolle auch nicht runter bekomme. Nach dem letzten Versuch jetzt einfach mal die LAN-NIC aus dem Gerätemanager zu werfen, in der Hoffnung dass eine Karte die es nicht mehr gibt auch nicht die Änderung oder Deinstallation verhindert kann, führte natürlich auch nicht zum Erfolg. Die LAN-NIC wird zwar sofort wieder erkannt, aber sie wird im Gerätemanager mit dem Fehler "Das Gerät kann nicht gestartet werden. (Code10) angezeigt. (Treiber de-/Installation & neu Installation erfolglos!) Und Hyper-V ist mit seinem "kaputten" virtuellen Switch nach wie vor da und lässt sich nicht entfernen. Nu bin ich mit meinem Latein erst einmal am Ende ... vielleicht hat ja jemand von Euch noch ein paar Tips wie ich das wieder in Ordnung bekomme, am besten natürlich ohne "Neuinstallation" ;-) Bin gespannt auf Eure Vorschläge. Ach so - nach dem rabiaten Neustart war natürlich kein "Hyper-V Switch" unter Netzwerkadapter weit und breit zu sehen ...

Hallo, ich habe hier ein seltsames Phänomen bei der Anlage von AD-Benutzern. Wir haben auf einem freigegebenen Share eine Ordner angelgt und beim Anlegen der Benutzer setzen wir das Homedir so, dass es einmal per UNC-Pfad angelegt werden soll also \\SRV\Ordner\Abteilung\%username% und als Laufwerk H:\ verbunden wird. Bei vielen Benutzern funktioniert dieses wunderbar so dass sich in dem Ordner ..\Abteilung\ die entsprechenden Benutzerverzeichnisse m.mueller, m.meier, etc... wiederfinden. Ab und zu jedoch scheint das Ganze nicht so sauber zu funktionieren, da in letzter Zeit direkt unter ...\Abteilung\ immer mehr Ordner mit dem Namen "Eigene Dokumente" auftauchen. Navigiert man in diese hinein und klickt anschließend in die Adresszeile wird der Ordner plötzlich in der Adresszeile als ...\Abteilung\m.meier aufgelöst. Das Ganze führt dazu, das im zusammenspiel mit der Ordnerumleitung die Eigenen Dateien auf dem Desktop natürlich nach \\SRV\Ordner\Abteilung\m.mueller zeigen das Ding aber in Wirklicheit \\SRV\Ordner\Abteilung\Eigene Dokumente heißt und der Zugriff somit fehlschlägt. Der Zugriff über den Laufwerksbuchstaben H:\ funktioniert hingegen problemlos. Irgendwie habe ich den Verdacht, dass da beim Anlegen der Benutzer unter Verwendung der Variable %username% irgendetwas schief geht ich erkenne aber kein Muster darin. Weder komplizierte Benutzernamen noch Umlaute (DC ist 2003 R2 engl.!) da wir die Benutzer ohne Umlaute anlegen. Hat jemand auch schonmal das Phänomen gehabt das bei der Anlage der Homedirs manchmal ein korrekter Ordner zustande kommt und manchmal nicht? Hoffe jemand kann mir die richtige Richtung zeigen, da die Benutzer immer wieder eine Fehlermeldung bekommen wenn sie statt über H:\ auf "Eigene Dateien" klicken. Gruß

Hallo Nils, danke für die Antwort. Das dachte ich mir auch schon dass dies nicht so einfach - bzw. "supported" garnicht möglich sei. Das Problemist das die Gruppe der Orga-Admins nicht unter meiner Kontrolle wären sondern von einer anderen Instanz gepflegt und auch gefüllt würde. Gruß

Hallo ich habe eine etwas kniffelige Aufgabe: Ich habe eine Root-Domäne (2003 R2) unterhalb derer ein paar Subdomains erstellt wurden. Nun möchte ich den Mitgliedern der Gruppe der Organisations-Admins Rechte an der Verwaltung der Subdomain entziehen. Ein Ogra-Admin soll zB. nicht in der Lage sein Objekte o.ä. im AD der Subdomain zu erstellen. Wie beschränkt man die Rechte der Orga-Admins in einer darunter liegenden Subdomain und was kann man alles beschränken - falls es möglich ist? Im Prinzip soll für die Orga-Admins gelten "nur gucken, nicht anfassen!" Geht das?

Hallo, ich benötige von Euch mal eine Idee .... ;-) Ich habe hier das folgende Problem: (Alles 2003 Std.Srv - DC und Member) Ich habe einen Server der, wenn ich ipconfig /all eingebe, mir sagt dass er zwei Einträge in der DNS-Suffixsuchliste besitzt. Nur eines ist natürlich in der Mitgliedschaft der Domäne begründet. Ich will das zweite Suffix nicht haben und frage mich wo kommt es her? Was habe ich bis jetzt gemacht bzw. wo habe ich bis jetzt gesucht: 1. In der DDF ist es nicht konfiguriert. 2. Es gibt keine lokale Richtlinie. 3. Ich habe eine Policy auf dem DC erstellt und den Eintrag mit nur dem einen (Domänen-) Suffix überschrieben. gpresult->Policy wird angewendet aber trotz alle dem hat der Server zwei Suffixe. (Es werden auch nur die manuelle und die DDF gezogen!) 4. In dem LAN-Adapter habe ich kein Suffix manuell konfiguriert. Preisfrage: Wo kommt das zweite Suffix her? (Ideen willkommen ;-) Und wie bekomme ich es weg? Ich hoffe Ihr habt da eine Idee für mich ... ;-)

Hi das sieht doch schon besser aus! 000151: Mar 25 13:08:02: ISAKMP: encryption 3DES-CBC 000152: Mar 25 13:08:02: ISAKMP: hash MD5 000153: Mar 25 13:08:02: ISAKMP: default group 2 000154: Mar 25 13:08:02: ISAKMP: auth XAUTHInitPreShared 000155: Mar 25 13:08:02: ISAKMP: life type in seconds 000156: Mar 25 13:08:02: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B 000157: Mar 25 13:08:02: ISAKMP0:0:N/A:0):atts are acceptable. Next payload is 3 -> atts are acceptable heißt das sich die beiden auf jeweils passende Attribute einigen konnten. 000200: Mar 25 13:08:03: ISAKMP0:1:SW:1):Old State = IKE_P1_COMPLETE New State = IKE_XAUTH_REQ_SENT -> Hier gibt er uns Nachricht, daß IKE-Phase 1 abgeschlossen ist und er nun die Benutzerauthenitfizierung XAUTH beginnt. Die Benutzerabfrage im VPN-Client. 000201: Mar 25 13:08:08: ISAKMP0:1:SW:1): retransmitting phase 2 CONF_XAUTH -455795250 ... 000202: Mar 25 13:08:08: ISAKMP0:1:SW:1):incrementing error counter on sa: retransmit phase 2 000203: Mar 25 13:08:08: ISAKMP0:1:SW:1):incrementing error counter on sa: retransmit phase 2 000204: Mar 25 13:08:08: ISAKMP0:1:SW:1): retransmitting phase 2 -455795250 CONF_XAUTH 000205: Mar 25 13:08:08: ISAKMP0:1:SW:1): sending packet to 212.152.242.200 my_port 4500 peer_port 4500 ® CONF_XAUTH -> Hier taucht ein Fehler in Pahse 2 "IPSec" auf. mach mal einen undeb crypto isakmp und stattdessen ein debug crypto ipsec um das debugging der phase 2 zu bekommen. Gruß $

Kannst Du mal anstatt eines "debug crypto isakmp error" ein "debug crypto isakmp" machen? Dann bekommen wir nicht "nur" die Fehler sondern auch den Rest der ISAKMP-Kommunikation!

Wie sieht denn jetzt die aktuelle Config aus? Da sich die Kommunikationspartner scheinbar immer noch nicht auf die passenden Attribute einigen können könntest Du vielleicht mal mehrere Policies im Router konfigurieren. Also zB. md5+des, md5+3des, sha+des, sha+3des und das Ganze noch mit unterschiedlichen DH Groups. Wie ist denn der VPN-Client konfiguriert?

Welchen von beiden Kommands hast Du eingegeben? Wann genau "crasht" der Router? Kann das IOS des Routers 3DES, oder nur DES? Gruß $

Der Kommand für die Policy lautet: encr 3des oder encr des ! Gruß $

Hallo Klaus, die ISAKMP-Meldung "atts are not acceptable" bedeutet, daß sich die beiden nicht auf die richtigen Attribute für die Phase 1 Verschlüsselung/Authentifizierung einigen konnten. Die nächste Meldung "Encryption algorithm offered does not match policy!" sagt dann das der vom Client angebotene Verschlüsselungsalgorithmus nicht den Policyeinstellungen Deines Routers entspricht. Im Abschnitt "crypto isakmp policy 3" sind auf Deinem Router die entsprechenden Angaben definiert. Dort taucht allerdings kein Verschlüsselungsalgorithmus auf sondern nur der Authentifizierungs Hash MD5 und die Diffie-Hellman-Group 2! Erweitere die Policy 3 mal um eines der beiden Verschlüsselungprotokolle DES oder 3DES, dann sollte, zumindest was die Phase 1 betrifft, die Kommunikation weitergehen. Gruß $

Ok dann hast Du ja fast alles was Du benötigst, viel Spaß damit! schöne Ostern!

Ja es wird nur der PTR-Eintrag des im MX-Record angegebenen Namens überprüft und mit dem verglichen der diese Email gerade delivert! Da also im Prinzip für jede Email ein Connect gemacht wird bei jeder Email. Bezogen auf die Email wird dann höchstens noch die Empfängerdomain überprüft wegen des Relay. Gruß$