dalmatino

Ich hatte bereits einen Versuch mit "select-xml" und "x-path", falls du wen Weg meinst. Da ja meine Schleife an sich nicht funktionierte, habe ich mich dann wieder auf die "einfachere" Variante gestürzt :) Naja, von können kann noch nicht die Rede sein :D

Hi und danke für die richtigen Gedankengänge! @daabm: Warum muss ich? So scheint es zu funktionieren: cd d:\check $source = "d:\check\*.xml" $srcstrg = gci $source $destination = "d:\check\move\" $uhrzeit = get-date -Format 'HH:mm' $CC1 = "<CompCode>1001</CompCode>" $CC2 = "<CompCode>1019</CompCode>" foreach ($file in $srcstrg) { $result = Get-ChildItem $file | Select-String -pattern "$CC1" if ($result -Match "$CC1") {move-item $file $destination} else {write-host "nothing to do"} } Jetzt taste ich mich langsam ran, dies Zeitabhängig zu machen. Werde bestimmt wieder auf euch Cracks zurückkommen :)

Richtig wäre dann also "foreach ($file in $string)" ? Als Ausgabe kommt dann nur noch "einmal, "wird verschoben". Was jetzt in diesem Fall richtig ist, da es nur in einer Datei drin steht. Aber ich bin jetzt eigentlich davon ausgegangen, dass für die anderen drei Dateien dann die andere Ausgabe kommt. Bin gerade Mega verwirrt.

Hi Leute, ich versuche mich gerade mit Powershell und stehe etwas auf dem Schlauch. Brauche etwas Unterstützung bzw. eure Fachkompetenz. Folgendes Szenario: In einem Ordner liegen mehrere XML-Dateien. In diesen Dateien gibt es das Element CompCode. Anhand der CompCode-Nummer (1001 oder 1019) soll die Datei entweder in einen anderen Ordner verschoben werden oder nicht. Das Ganze soll dann auch Zeitabhängig geschehen. Für die CompCodes gibt es unterschiedliche Verarbeitungszeitspannen. (Soweit bin ich aber noch nicht. Ich versuche Stückweise meinem eigentlichen Ziel näher zu kommen.) Ich möchte also in die Dateien gucken und herausfinden, welcher CompCode drin steht. Wenn jetzt z.B. 1001 drin steht, soll diese in den Ordner "Move" verschoben werden, wenn nicht, soll sie bleiben wo sie ist. In meinem Ansatz, werden alle Dateien verschoben... Damit ich testen kann, habe ich jetzt anstelle des move Befehls eine Textausgabe erstellt. cd d:\check $source = "d:\check\*.xml" $srcstrg = gci $source $destination = "d:\check\move\" # $uhrzeit = get-date -Format 'HH:mm' $CC1 = "<CompCode>1001</CompCode>" $CC2 = "<CompCode>1019</CompCode>" $string = Get-ChildItem $source | Select-String -pattern "$CC1" foreach ($file in $srcstrg) { if ($string -Match "$CC1") {write-host "wird verschoben"} else {write-host "wird nicht verschoben"} } wird verschoben wird verschoben wird verschoben wird verschoben Man sollte meinen, es ist eine simple Aufgabe, aber ich breche mir gerade ziemlich einen ab :( Bin für jeden Tipp dankbar! Grüße

Die Knoten verfügen über zwei NICs. 1x Cluster, 1x Domänennetz. Beide Netzwerke sind im HVC konfiguriert. Wie bereits erwähnt, die Installation/Konfiguration wurde nach MS-Leitfaden durchgeführt. Edit: Quelle: http://technet.microsoft.com/de-de/library/cc732181(v=ws.10).aspx Wie ich auch bereits erwähnt habe, hat die Konfigurationsüberprüfung keine Fehler oder Warnungen ausgegeben.

Was ist denn, wenn es zu einer temporären Störung der Heartbeat-NIC kommt? In dem Fall würde auch sofort ein Failover passieren...

Hi Norbert, was soll ich überprüfen? Der Cluster-Überprüfungsassistent zeigt keine Fehler. Die HVC ist nach MS-Leitfaden installiert und eingerichtet.

Ja, das ist mir schon klar. Aber wie gesagt, bin ich eigentlich davon ausgegangen, wenn die Knoten angehalten sind, dass er nicht verschieben kann. Deswegen ja auch die Frage, wie ich es verhindern kann bzw. die Toleranzzeit ändern kann. Wie gesagt, es kann ja auch durchaus mal sein, dass kurzzeitig ein Switch die Grätsche macht. Und trotz voll funktionsfähiger VMs, der Failover eingeleitet wird. Ich will keinen automatischen Failover.

Hallo liebe Community. Ich hab mal eine Verständnisfrage zur allgemeinen Wartung bzw. zum Failover-Vorgang. Bisher bin ich eigentlich davon ausgegangen, wenn ein Knoten angehalten wird, dieser keinen Failover ausführt, auch wenn er kurz die Netzwerkverbindung verliert. Zitat Technet: Folgendes ist gestern passiert: Wir haben kurz, um einen Switch zu tauschen, das Netzkabel eines Knotens abgezogen und in den neuen Switch gesteckt, der auch im Netz hing. Der Gedanke war, dass die VMs weiterlaufen, da diese ihre eigene Netzanbindung auf einem anderen Switch haben und die Verbindung zum Storage via FC angebunden ist. Die VMs sind auch nicht alle abgestürzt (2-3 Maschinen waren offline), wurden aber sofort auf den anderen Knoten verschoben. An sich, wurden beide Knoten angehalten. Nach dem Kappen der Netzverbindung hat der Knoten 1, trotzdem ein Failover auf den angehaltenen Knoten 2 gemacht. Warum? Im Zitat oben steht ja eindeutig, dass keine Ressourcen online geschaltet werden können. Wie kann man verhindern, dass ein Failover automatisch ausgeführt wird? Es kann ja auch durchaus sein, dass ein Knoten kurz die Verbindung (Heartbeat) zum Cluster verliert, aber die restlichen anderen Verbindungen dennoch voll funktionsfähig sind. Der Failover legt in diesem Fall ja unnötigerweise die VMs lahm. Ich habe nirgends die Einstellungen gefunden, wie man die "Empfindlichkeit", der Heartbeat-Anwortzeit ändern kann. Danke! PS: 2 Knoten HV-Failover-Cluster mit FC-Storage. VMs haben eigenes Netzwerk.

Was wäre dein Tipp, wie soll ich das am Besten testen?

Es laufen derzeit 8 Stück. Wohingegen 5 Stück davon im Betrieb benötigt werden. Diese sind auf den Knoten verteil... also 4 und 4 und eine Test-VM ist ausgeschaltet.

Warum ist die Rate dann denn höher, wenn beide VMs auf dem gleichen Knoten liegen?

Es war eine Empfehlung von Fujitsu, für jede virtuelle Maschine eine LUN anzulegen. Da es so "performanter" wäre. Ich habe z.B. vom Knoten1 eine Setupdatei mit 1,6GB auf eine VM kopiert (100MB/s). Dann das gleiche mit irgendwelchen Ordnern, aber halt vielen Dateien. Würde sagen, im Schnitt 1MB. 340 Dateien, Übertragungsrate 12MB/s. Wie es auch scheint, ist die Geschwindigkeit bei den gleichen Dateien bei einer von VM zu VM-Kopie höher. EDIT: Was mir gerade aufgefallen ist, wenn die beiden VMs auf dem gleichen Knoten liegen, ist der Kopiervorgang wie gewohnt performant. Liegen die VMs auf unterschiedlichen Knoten, geht die Rate extrem runter.

Die Host haben jeweils eine Netzwerkkarte nur für das ISCSI. Also eigenständiges Kabel. Das ISCSI-Netzwerk ist auch in einem anderen IP-Bereich. An dem Switch hängen die beiden Knoten und das Storage. Sowohl das "normale" Netz als auch das ISCSI Netz gehen über diesen Switch.

6x 450GB 1500er SAS Platten im RAID5 Verbund. Eine Platte davon als HotSpare RAID Level RAID5 Total Capacity (MB) 1676288 Total Free Space (MB) 560240 Disk Status Capacity Speed (rpm) Usage Type Mirroring Pair CE-Disk#0 Available 450GB 15000 System 3.5" SAS CE-Disk#1 Available 450GB 15000 System 3.5" SAS CE-Disk#2 Available 450GB 15000 Data 3.5" SAS CE-Disk#3 Available 450GB 15000 Data 3.5" SAS CE-Disk#4 Available 450GB 15000 Data 3.5" SAS EDIT: Volume List (DX60) No. Name Status Type Capacity (MB) Encryption RAID Group Formatting Progress Migration Progress 0 Witness Available Open 1000 No 0:Raid5 - - 1 LUN1 Available Open 160000 No 0:Raid5 - - 2 LUN2 Available Open 420000 No 0:Raid5 - - 3 LUN3 Available Open 120000 No 0:Raid5 - - 4 LUN4 Available Open 120000 No 0:Raid5 - - 5 LUN5 Available Open 30000 No 0:Raid5 - - 6 LUN6 Available Open 90024 No 0:Raid5 - - 7 LUN7 Available Open 60024 No 0:Raid5 - - 8 LUN8 Available Open 35000 No 0:Raid5 - - 9 LUN9 Available Open 80000 No 0:Raid5 MS ISCSI Initiator mit MPIO

Hallo Leute, folgendes Problem wo ich ein wenig Denkunterstützung brauche. Wenn in den VMs viele "kleine" Dateien kopiert werden, geht die Übertragungsgeschwindigkeit massiv in die Knie. Große Dateien werden mit ca. 100MB/s kopiert. Wenn es jedoch ein paar hundert Dateien sind, geht die Rate auf ca. 10 MB/s runter. Dass sie runter geht ist klar, aber so massiv, finde ich, ist schon komisch. Wenn ich mich recht entsinne, war das vorher auch nicht der Fall. Irgendwo scheint sich hier eine I/O Bremse eingeschlichen zu haben. Bei dem System handelt es sich um einen 2-Knoten Hyper-V Failover Cluster. OS: Server 2008 R2 aktueller Updatestand Fujitsu RX300S6 - mit einer 1GBit ISCSI Anbindung. Storage ist eine Fujitsu DX60 mit 2x 1GBit ISCSI. Die Netzwerklast auf dem jeweiligen Knoten (bei den Tests) liegt laut Taskmanager für die ISCSI-Karte zwischen 10 und 50%. Liegt es vllt. am Switch, am Storage, an der VM-Konfiguration für die VHDs (IDE/SCSI -> VHD),... Habt ihr eine Idee woran es liegen könnte bzw. wie ich am Besten herausfinden kann, was diese Performanceeinbuße verursacht? Stehe gerade ein wenig auf dem Schlauch und bin für jeden Anhaltspunkt oder Tipp sehr dankbar. Im Voraus vielen Dank!

Werde ich tun, wenn ich vor Ort bin. Verwunderlich ist es trotzdem, dass der "Fehler" in so großen, regelmäßigen Abständen erfolgt. Da ich es bisher nie live miterlebt hab, kann ich mich jetzt auch nur auf die Aussage verlassen. Was unter Umständen ja nicht heißen muss, dass das Stecker ziehen wirklich erforderlich ist. Das ist ja auch das, was mir die Fehlersuche zudem erschwert. Gruß

System: Intel Server, Xeon L5410, 4GB RAM MS SBS 2003 - aktueller Updatestand. HW-Treiber, aktuellsten die es gibt. Hallo Leute, ich habe mal wieder ein seltsames Problem. Und zwar habe ich einen Server, der in regelmäßigen Abständen einfach herunterfährt bzw. Neustartet. Alle 4-5 Tage. In der restlichen Zeit läuft dieser Fehlerfrei! Die Logs sind keine Hilfe, dort sieht alles i.O. aus bzw. lässt sich nichts auf den Grund zurückführen. BlueScreen ist auch auszuschließen, da Neustart bei Fehler deaktviert ist. Er geht einfach aus. Ab und an muss man sogar den Netzstecker ziehen, damit er wieder angeht. Die Logs der Intel Server Management Software protokollieren auch nichts, was einen Anhaltspunkt geben würde. Fehler tritt mit und ohne USV auf (USV-Mgmt-Software deaktiviert!). Das Netzteil halte ich auch nicht für den Übeltäter, da der Fehler ja ansonsten öfter auftreten müsste. Unter den Geplanten Tasks ist auch nichts verdächtiges. Es scheint irgendein Ereignis, welches alle 4-5 Tage startet, dieses Fehler zu verursachen. Allerdings habe ich keine Ahnung, wie ich herausfinden soll, welches es ist. Bin auch leider nicht vor Ort und kann nur über Fernwartung gucken, wenn's wieder passiert ist. Irgendeine Idee, wie ich den Fehler weiter analysieren könnte? Für einen Tipp wäre ich echt dankbar!

Du könntest aber den User auch temporär zu den lokalen Admins hinzufügen, installieren und ihn dann wieder degradieren.

Generell sollte sich dann ein Login-Fenster mit "Anforderung/Aufforderung für erhöhte Rechte" öffnen, wo du dann den Admin-User mit PW angeben kannst, um das Setup zu starten....

Installation unter dem Benutzer mit als "Administrator ausführen" sollte doch klappen?

Problem gelöst. In der Reg. waren unter den anderen ControlSet's auch noch die Serial Einträge drin. Vermutlich hat er nach dem Neustart, die Einträge wieder ins "Current..." geschrieben. Nach dem ich alle entfernt hab, kommt keine unbekannte Hardware mehr. Gruß

Hi, leider nein. Hatte den Gerätemanager schon im erweiterten Modus mit "versteckter Hardware" am Laufen. Dort taucht die Karte nirgends auf. Hatte im Vorfeld auch schon die Treiber und Software für die Karte entfernt.

Hallo allerseits, habe folgendes Problem. Ein Rechner wurde von einer alten Hardware mittels Backup und Reparaturinstallation auf eine neue Hardware umgezogen. Alles wunderbar geklappt. Rechner läuft. Alles Updates und aktuellen Treiber drauf. Allerdings hat er im Gerätemanager 2x Unbekannte Hardware. So wie es aussieht, sind diese zwei Geräte, zwei Ports von der alten ISA-Schnittstellenkarte, die in dem Alt-System drin war. Laut Registry COM5 und COM6. Die Karte ist aber nicht mehr vorhanden. Trotzdem werden diese jedes mal neu erkannt! Habe auch schon versucht manuell die Reg.-Einträge zu löschen. (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\Serial\0000) Funktioniert auch soweit. Werden dann nicht mehr im GM angezeigt. Ein Neustart, alles wieder beim alten... :( Jemand einen Tipp? Vorab vielen Dank.

Ich hab zu danken! ;-)