jm12

@ von einer VM kommst du nie auf Ressourcen des Hosts Einen Weg gibt es, soviel ich weiß. Der "5Nine-Manager" bietet so ein Feature. Wolfgang Sommergut hat dazu vor längerer Zeit einen Artikel geschrieben. Siehe hier: http://www.windowspro.de/tool/hyper-v-2008-r2-bis-2012-r2-dem-kostenlosen-5nine-manager-verwalten

Hi Doso, Danke für die Infos. Ich habe dazu inzwischen auch noch einiges gelesen. Ist bzw. wird sicher noch ganz spannend. Für Leute, die gern die GUI der Remoteverwaltung (z.B von einem W8-Host aus) verwenden, bleibt ein Problem mit Blick auf die VMs jedoch: Dass dort (im Dropdown-Feld) nämlich nicht der Name der Verbindung sondern die (Device-)Description angezeigt wird. Die wiederum ist versteckt in einem Registry-Eintrag (namens FriendlyName) unterhalb der PCI-Einträge des ControlSets. Dazu hier ein interessanter Artikel aus dem TechNet https://social.technet.microsoft.com/Forums/de-DE/6121de30-7f68-4162-8ed8-d71b458e00cc/rename-network-adapter-in-win-2k8-r2-sp1?forum=winserverNIS Aber so spannend das ist - es bring mir leider noch keine Antwort auf die ursprüngliche Frage nach der Abweichung bei den Indizes ;) Hast Du da vielleicht noch eine Idee für mich??

Ich habe mal einen Blick in die Registry geworfen. Unter dem Schlüssel HKLM\Software\MS\WindowsNT\CurrentVersion\NetworkCards stehen bei mir (erwartungsgemäß) sechs Einträge. Diese tragen als Namen Nummern, die man zunächst einmal als Index-Nummern interpretieren könnte. Diese Werte liegen genau zwischen denen, die ich via CMD bzw. via SCONFIG sehe. Also konkretes Beispiel: Der Reg-Eintrag mit dem Wert "12" wird via CMD mit dem Index "13" angezeigt und via SCONFIG mit dem Index "11". Und so weiter ... Ist das bei Euch nicht so? Oder hat das nur noch nie einen interessiert? Es ist ja auch bei mir nicht so, dass irgendeine funktionelle Einschränkung erkennbar wäre. Es hat mich eben einfach nur verwundert und ich wollte gern verstehen, warum das auftritt ;)

Hi Dunkelmann, Danke für den Link - aber da fand ich keine ANtworten. Ich habe eine jungfräuliche Installation. Bei mir ist IPv6 nicht abgeschaltet und auch ansonsten nichts "verbogen". @ Mit Power Shell 'Get-NetAdapter' und 'Rename-NetAdapter' geht es auch. Habe ich nicht ganz verstanden?! Ich will nichts umbenennen - wie das geht, weiß ich. Ich möchte gern verstehen, weshalb es eine Differenz der Indizes gibt. Hi Doso, Du hast sicher Recht, dass diese Funktion eine Vereinfachung im Handling bringen kann. Aber ist nicht "Consistent Device Naming" eine Funktionalität, die sich eher auf die Konsistenz der Bennenung von Hardware zu VMs bezieht? Ich habe ja aber zunächst einmal noch garkeine VMs. Ich habe eine völlig jungfräuliche Installation. Und auf der eine Differenz zwischen den Indizes, die via SCONFIG bzw. via CMD angezeigt werden. Hi Nils, @ heute in Bad Homburg gewesen? ;) Sorry - verstehe nicht?!

Hallo zusammen, mich beschäftigt eine Frage bei der Einrichtung eines Hyper-V 2012 R2 (Core). Ich habe dort: - eine IPMI (exclusiv), - zwei Onboard-NICs - zusätzliche Intel-PCI-Karte mit 4 NICs. Diesen ganzen NICs wollte ich zunächst Namen geben, die ich später noch verstehe. Dazu habe ich mir mit "netsh interface ipv4 show interface" die Indizes anzeigen lassen. Die Indizes erscheinen hier ja in der linken Spalte. Dann zum Lokalisieren Patchkabel ans erste Port. Nun wird eine Karte als aktiv und die anderen 5 als ncht verbunden angezeigt. Die aktive wird mit dem Index 13 angezeigt. Wenn ich auf der Serverkonfiguration (also "die blaue Konsole" des Hyper-V) die Netzwerkeinstellungen aufrufe, wird folgerichtig ebenfalls nur eine aktive Karte angezeigt. Diese hat hier jedoch den Index 11. Das habe ich dann durch alle Ports durchgetestet. Der von der SCONFIG angezeigte Index liegt jeweils zwei Zähler unterhalb der der Konsole. Kann mir jemand sagen, was der Grund hierfür ist? Dank vorab für Eure Hinweise.

Hier der zweite Teil dazu: AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates. 2011-04-21 16:55:47:320 1092 c78 Report REPORT EVENT: {41FCD55E-CFA7-4853-818A-FF33E888FF83} 2011-04-21 16:55:47:304+0200 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status. 2011-04-21 16:55:47:320 1092 aa8 AU ######### 2011-04-21 16:55:47:320 1092 aa8 AU ## END ## AU: Search for updates [CallId = {1C20AE5D-556F-4425-A662-5549BD9B3149}] 2011-04-21 16:55:47:320 1092 aa8 AU ############# 2011-04-21 16:55:47:320 1092 aa8 AU Featured notifications is disabled. 2011-04-21 16:55:47:320 1092 aa8 AU AU setting next detection timeout to 2011-04-21 15:48:26 2011-04-21 16:55:47:320 1092 aa8 AU Setting AU scheduled install time to 2011-04-22 01:00:00 2011-04-21 16:55:47:382 1092 c78 Report Uploading 2 events using cached cookie, reporting URL = http://LOFMDC01:8530/ReportingWebService/ReportingWebService.asmx 2011-04-21 16:55:47:398 1092 c78 Report Reporter successfully uploaded 2 events.

So, jetzt der erste Teil-Auszug aus dem Log. Ist übrigens die Kiste, auf der gerade die ersten sieben Updates installiert wurden. Er zeigt wiederum "Null" Updates an. So war es bis heute morgen auch ... Warum die sieben vorhin plötzlich doch angezeigt wurden, kann ich nicht erahnen, da ich heute definitiv nichts an den Maschinen gemacht habe. Nichts am Server und nichts an den Clients ... Naja - vielleicht könnt Ihr ja aus dem Log was erkennen, was ich nicht sehe ;) 2011-04-21 16:55:21:072 1092 c78 Report Uploading 2 events using cached cookie, reporting URL = http://LOFMDC01:8530/ReportingWebService/ReportingWebService.asmx 2011-04-21 16:55:21:088 1092 c78 Report Reporter successfully uploaded 2 events. 2011-04-21 16:55:33:875 1092 7b0 AU Triggering AU detection through DetectNow API 2011-04-21 16:55:33:875 1092 7b0 AU Triggering Online detection (non-interactive) 2011-04-21 16:55:33:875 1092 7bc AU ############# 2011-04-21 16:55:33:875 1092 7bc AU ## START ## AU: Search for updates 2011-04-21 16:55:33:891 1092 7bc AU ######### 2011-04-21 16:55:33:891 1092 7bc AU <<## SUBMITTED ## AU: Search for updates [CallId = {1C20AE5D-556F-4425-A662-5549BD9B3149}] 2011-04-21 16:55:33:891 1092 c78 Agent ************* 2011-04-21 16:55:33:891 1092 c78 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates] 2011-04-21 16:55:33:891 1092 c78 Agent ********* 2011-04-21 16:55:33:891 1092 c78 Agent * Online = Yes; Ignore download priority = No 2011-04-21 16:55:33:891 1092 c78 Agent * Criteria = "IsHidden=0 and IsInstalled=0 and DeploymentAction='Installation' and IsAssigned=1 or IsHidden=0 and IsPresent=1 and DeploymentAction='Uninstallation' and IsAssigned=1 or IsHidden=0 and IsInstalled=1 and DeploymentAction='Installation' and IsAssigned=1 and RebootRequired=1 or IsHidden=0 and IsInstalled=0 and DeploymentAction='Uninstallation' and IsAssigned=1 and RebootRequired=1" 2011-04-21 16:55:33:891 1092 c78 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed 2011-04-21 16:55:33:891 1092 c78 Agent * Search Scope = {Machine} .... hier habe ich mal etwas gekürzt ... 2011-04-21 16:55:33:954 1092 c78 Setup * IsUpdateRequired = No 2011-04-21 16:55:34:548 1092 c78 PT +++++++++++ PT: Synchronizing server updates +++++++++++ 2011-04-21 16:55:34:548 1092 c78 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://LOFMDC01:8530/ClientWebService/client.asmx 2011-04-21 16:55:36:439 1092 250 AU Triggering AU detection through DetectNow API 2011-04-21 16:55:36:439 1092 250 AU Piggybacking on an AU detection already in progress 2011-04-21 16:55:38:503 1092 7b0 AU Triggering AU detection through DetectNow API 2011-04-21 16:55:38:503 1092 7b0 AU Piggybacking on an AU detection already in progress 2011-04-21 16:55:41:551 1092 250 AU Triggering AU detection through DetectNow API 2011-04-21 16:55:41:551 1092 250 AU Piggybacking on an AU detection already in progress 2011-04-21 16:55:46:460 1092 c78 PT +++++++++++ PT: Synchronizing extended update info +++++++++++ 2011-04-21 16:55:46:460 1092 c78 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://LOFMDC01:8530/ClientWebService/client.asmx 2011-04-21 16:55:47:304 1092 c78 Agent * Found 0 updates and 50 categories in search; evaluated appl. rules of 726 out of 1399 deployed entities 2011-04-21 16:55:47:304 1092 c78 Agent ********* 2011-04-21 16:55:47:304 1092 c78 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates] 2011-04-21 16:55:47:304 1092 c78 Agent ************* 2011-04-21 16:55:47:320 1092 aa8 AU >>## RESUMED ## AU: Search for updates [CallId = {1C20AE5D-556F-4425-A662-5549BD9B3149}] 2011-04-21 16:55:47:320 1092 aa8 AU # 0 updates detected 2011-04-21 16:55:47:320 1092 c78 Report REPORT EVENT: {7C4A3CFE-F338-4B72-95DD-87A23C605AB0} 2011-04-21 16:55:47:304+0200 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0

Jetzt wird es noch wunderlicher :confused: Jetzt haben alle drei VMs plötzlich einheitlich 7 Updates gefunden. Die hab ich auf der ersten VM auch erst einmal installiert, dann ein detectnow und ein reportnow hintendran und prompt werden auf WSUS-Server auch exakt sieben weniger angezeigt. Aber auf dem Client werden die restlichen (noch) nicht angezeigt ... @necron Um den Log-Auszug kümmere ich mich gleich

Zunächst mal Dank für die turboschnellen Antworten!!!! @Necron Die VM (bzw. insgesamt drei Stück) wurde sauber installiert auf einem Hyper-V-Server - nicht geklont. Und ja, natürlich sind die Updates alle genehmigt. @wilgin Ja, die Info kommt aus dem WindowsUpdate.Log. Detectnow und reportnow habe ich schon unzählige Male gemacht. Ich habe auch nicht sofort die Geduld verloren, sondern erst nach ca. 48 Stunden. Auch ein GpUpdate /force habe ich gemacht, da ich davon ausgegangen bin, dass mit der Installation des SP2 vom WSUS auch die betreffenden Policies geändert wurden. Das hab ich dann wiederum mit RSOP auf den Clients geprüft und es kommt auch alles korrekt an. Die laut WSUS-Server benötigten Updates sind 63. Hier habe ich zum Testen dann mal ein Update über die Update-Seite von MS installiert und prompt wurde auf dem WSUS-Server auch ein benötigtes Update weniger angezeigt. Deinen Tipp mit dem /resetauth.. werde ich jetzt sofort ausprobieren.

Hallo Leute, ich habe auf einer VM (XP unter Hyper-V) das Problem, dass das System keine Updates findet. Der WSUS (3.0 SP2) auf dem DC (SBS2k8) hat aber einen Report des Clients bekommen und weist auch aus, dass der Client diverse Updates benötigt. Nur der Client selbst logt regelmäßig, dass "Null" erforderliche Updates gefunden wurden. Bei physischen Clients in der Domain hab ich die Probleme nicht, nur bei der VM. Wenn ich auf die Update-Seite von MS gehe und die VM dort suchen lasse, dann findet er die benötigten Updates. Ich schlußfolgere daraus, dass es keine grundsätzlichen Probleme mit dem Update-Dienst gibt. Aufgrund eines anderen Beitrags hier im Forum hab ich aber den Dienst auch schonmal komplett neu installiert - hat aber auch nicht zu einer Veränderung geführt. Hat jemand nen Tipp für mich?!

Hallo Leute, habe folgende Konfig: - SBS2K8 Premium auf komplett neuer Hardware aufgesetzt - Auf dem DC ist u.a. standardmäßig SQL Server 2005 am laufen - auf der zweiten Maschine läuft SQL Server 2008 (x64). Soweit die Vorrede ... Problem ist, dass ich auf beiden Maschinen für den SQL-Server-Dienst eine Inanspruchnahme des Speichers von ca 5 - 6 GB im Taskmanager angezeigt bekomme und die Kisten (gefühlt) auch etwas lahm sind. Hardware ist aber eigentlich m.E. ausreichend ausgelegt; je 12 GB; je 2xQuad-CPU (E5520). Auf einer annähernd baugleichen Konfig habe ich diese Erscheinungen nicht. Im SQL-Server-Management-Studio hab ich keinerlei EInstellungen verändert - alles noch auf Installationsniveau. Ist eigentlich auch noch vollkommen jungfräulich - noch keine Datenbanken drauf (außer die systemeigenen des SBS). Kennt jemand diess Phänomen? Hat jemand nen Tip, wo ich suchen kann? Oder kann es eine BIOS-Einstellung geben, die da eine Rolle spielt. Dank vorab für Eure Hinweise!

Hi Necron, okay - hab ich mir schon gedacht. Aber mit dem Tipp fühl ich mich wohler ;) Warum die Clients es allerdings nicht selbst schaffen, ist mir nicht ganz klar. Sowohl XP-Clients, als auch weitere Server haben hier keinen "Zugang" zu den Reverse-Einträgen gefunden ... die Forward-Einträge waren jederzeit okay. Aber durch das Fehlen der Reverse-Einträge (bzw. das Ausbleiben der Aktualisierung) kam es zu Abweichungen, die mir nur durch Zufall aufgefallen sind, weil die Auflösung vorwärts etwas anderes ergab, als rückwärts ... Kann das etwas mit dem IP V6 zu tun haben? Und macht es überhaupt Sinn, den DHCP-Server auch IP V6 machen zu lassen? Ich muss ganz offen zugeben, dass ich dem V6 bislang noch vollkommen ahnungslos gegenüber stehe :( Hab nochmal Dank für die Hilfe!

Hi Necron, zunächst Dank für Deine Hilfe. Zu Deiner Frage nach den Einstellungen auf dem DHCP-Server: 1. Register Allgemein (Eigenschaften des IP V4-Bereichs) - Bereichsname = Domänenname - Start-IP 192.168.xxx.1 - End-IP 192.168.xxx.254 - Leas-Zeit 8 Tage 2. Register DNS (Eigenschaften des IP V4-Bereichs) - wie bereits beschrieben; nix angeklickt (also keine dyn. DNS-Aktualisierung) 3. Register Netzwerkzugriffsschutz (Eigenschaften des IP V4-Bereichs) - deaktiviert 4. Register Erweitert (Eigenschaften des IP V4-Bereichs) - nur DHCP Als IP V4-Bereichsoptionen sind der Router, der DNS-Server sowie die DNS-Domain eingetragen. Entsprechende Ausschlüsse für Router und DNS-Server (hier der DC) sind ebenfalls angelegt. Bei IP V6 wiederum ist in den Eigenschaften die dynamische DNS-Aktualisierung aktiviert. Ich habe das bei früheren Installationen grundsätzlich aktiviert (da gab es ja früher nur V4) - war mir aber hier eben nicht sicher ... daher meine Frage, ob das nicht vielleicht schon "des Rätsels Lösung" ist. Zu Deiner Frage nach den Einstellungen auf der Reverse-Zone: Was willst Du genau wissen? Es sind die obligatorischen 4 Zonen (0.in-addr ... 255.in-addr ...) angelegt und überall steht der DC als NS bzw. SOA eingetragen - also so, wie ich es auch erwartet hätte. Grundsätzlich habe ich bei der Installation bzw. danach keinerlei Anpassungen vorgenommen; hab die Install. quasi ohne Eingriffe durchlaufen lassen und auch danach so belassen, da ich vorher noch keinen SBS2008 installiert habe und nicht "stumpfsinnig" meine 2k- bzw. 2k3-Erfahrungen übertragen wollte. Zu Deiner Frage nach den Ereignisprotokollen: Im Prot. des DNS-Servers gibt es keine negativen Einträge und auf Seiten der Clients im Systemprotokoll auch keine ... Aber wie gesagt - Forward funktioniert ja auch problemlos. Also wenn Du auch keine Aspekte siehst, die dem entgegenstehen, dann würde ich zunächst mal einfach die dynamische Aktuialisierung auch für IP V4 aktivieren. Ich wollte mit meiner Frage eigentlich nur ausschließen, dass ich hier irgendetwas übersehe oder es ggf. irgendwelche mir nicht bekannten Features gibt, die dem entgegenstehen?! Kurz gesagt: Ich wollte es nicht verschlimmbessern ;)

Hallo Forum, hab eine Frage zum DNS unter SBS2k8. Habe bei nachträglich (also einige Wochen nach Installation des SBS) eingetretenen Domänenmitgliedern den Effekt, dass keine Einträge in der Reverse-Zone auftauchen. Und das, obwohl bei den Forward-Einträgen jeweils "Entsprechenden Zeigereintrag (PTR) aktualisieren" standardmäßig angehakt ist. Alle direkt nach der Installation eingetretenen Domain-Member sind in beiden Zonen ... Nach kurzer Suche im DHCP habe ich dann festgestellt, dass hier unter "DNS" das Feld "Dynamische DNS-Aktualisierungen ..." nicht angehakt ist. Diese Einstellung ist von mir nach der Installation aber nicht geändert worden. Ich hätte allerdings erwartet, dass die dynamische Aktualisierung standardmäßig nach der Installation auf "aktiv" steht. Ist das Häkchen in den DHCP-Einstellungen schon die ganze Lösung des Problems, oder funktioniert im SBS2008 noch irgendetwas anders als unter SBS2003? Dank vorab für Eure Hinweise

... das verstehe ich!!! Es ist oft so, dass eine Neuinstallation schneller geht, als die Suche nach einem solch ominösen Fehler. Allerdings lernt man bei solcher Fehlersuche immer ne Menge ;);)