Velius

Ich habe die Größer der neunen und 2ten Festplatte nicht erwähnt, die hat einen TB:) :sorry:

Kein Problem, alle Vorschläge zählen, und der von LukasB gefällt mir IMO am besten.;)

fat32 ist ja wegen der 4gb beschränkung nicht allzu toll

Da bist du aber etwas falsch informiert. Fat32 Partitionen können locker mehrere 100 GB gross sein, nur das Windows Format Utility wurde absichtlich auf IIRC 32 GB limitiert.

Das boot Volume kann sicher 8 GB gross sein unter FAT 32 (64 Bit Cluster Grösse, oder war das NTFS 4....;)).

Die IP pingen und dann arp -a - vorausgesetzt die IP liegt im selben Subnetz.

....ps: Hab vergessen, arp -a von der Komando Zeile aus:rolleyes:;)

Off-Topic:

Zu schnell ist auch nicht immer gut! ;):D

Also wenn's nur daran liegt, es gibt Softies, die können von FAT32 zurück auf NTFS - einfach google bemühen. Eloquent genug?:cool:

 

 

EDIT: Okay, da war ich vielleicht etwas zu langsam.

Kommt vor.:D

Team Adapter à la HP und Konsorten brauchen keine IPs auf den einzelnen NICs. Dort ist das TCPIP Protokoll auch gar nicht aktiv, nur auf dem virtuellen Team Adapter.

Keine Ahnung aber wie das mit CLustern zusammen spielt.

Das Warum muss schon der Programmierer der Software oder des Dienstes in seinem Error-Handler abfangen. Wenn der das nicht macht kann das Niemand.

eine Lösung hat noch keiner gefunden?

Rein analytisch: Wenn das Problem nach SP2 auftritt, deinstallier SP2 und das Problem ist gelöst!

Alles andere, inkl. sich an HP/MS direkt wenden wurde schon mehrmals erwähnt.

Pack Win auf 'ne FAT32 und gut is.;)

Hmm da kommen wir wieder in den Bereich Kanonen und Fliegen.....;)

Wieso? Man kann auch local storage und ein starter Packet nehmen - da braucht's nicht immer gleich (redundante) SAN(s) für.;)

 

wenns um performance geht, ist hyper-v die falsche wahl - xen ist da deutlich schneller.

Oder ESX...:wink2:

@pairosilva

Entweder nach Double Take oder Neverfail googeln, die helfen bestimmt.;)

 

In dem Link von Dir, habe ich jetzt keine Aussage zu DC´s in Virtuellen Umgebungen gesehen...

Kurz gesagt: Keine vmdk/vhd Snap shots von DCs machen! Ein ordentliches NT Backup und gut ist!:cool:

@Velius:

Der 1.0.4er hatte diese Begrenzung noch fix implementiert. Weiß nicht wies mit dem 1.0.5er aussieht.

Ok, aber dann müsste das ja auch bei einem Linux als Host sein, oder ist das etwa nur bei den Windows Binaries von Vmware der Fall?:suspect:

Ich selber tentiere auch sehr zu dem VMWare Server.

Welchen würdest Du verwenden? 1.0.5?

Je, definitiv. Keine Beta im produktiv Betrieb. Egal ob VMware oder sonst wer. Ausser es ist 'ne Spielwiese.

Ja, meiner Meinung nach geht es, aber nur wenn die PowerShell auf dem Zielsystem installiert ist und psexec verwendet wird. Sonst fällt mir keine andere Lösung dazu ein.

Klingt sauber die Sache.

Aber man muss entweder auswerten (Perfmon, Power Recon, usw.) oder beobachten und ergänzen.

SQL muss nicht ein Problem sein, kommt auf die Nutzlast und die User an.

Ich würde zu VMware tendieren, aber das ist meine persöhnliche Vorliebe.

Achten solltest du auf das Disksubsystem. RAID10 ist, vor allem wenn nicht ESX zum Zuge kommt, sehr empfehlenswert. Auch der RAID Controller sollte wenn möglich so gegegen 512 MB haben, Battery Backed Cache zwingend.

–

SQL und Exchange auf nem DC ist nicht so schön...

 

Yup. sollte man vermeiden.

Wenn Du die freie Version verwendest, würde ich ganz unten ein Linux installieren, damit Du auch mehr als 10 Interfaces anlegen kannst.

?? Windows kennt auch keine Limitierung diesbezüglich. Und dediziert 10 Interfaces verwenden macht kaum einer.

vielleicht nochmal zum Verständniss weiß ich machen möchte:

 

von einem Rechner remote auf einem Server ein PowerShell Script ausführen. Der Server hat PowerShell nicht installiert. Ob und wie dieses möglich ist.

Das hättest du auch früher sagen können - das geht nicht!:wink2:

Und auf dem Remote Rechner befindet sich dieser Ordner/diese Datei:

c:\scripts\RemoteDir.ps1 ?

Ähh??

Leute, das ist doch nicht kompliziert. Einfach

psexec \\[i]Rechner[/i] "powershell.exe –noexit c:\scripts\test.ps1"

Ausführen

Oder ich mache es häufig so:

psexec \\[i]Rechner[/i] cmd.exe

Und hab dann effektiv eine Remote Shell. Wenn man psexec so ausführt wird nur der Prozess, in diesem Fall die CMD.exe, nicht lokal sondern remote ausgeführt.

Ps: Du musst die Poweshell Befehle schon in ein Script packen. Der default Command Prompt kann logischerweise nichts anfangen mit den erweiterten Powershell Commands.

Das war mehr eine Frage oder Anregung so in den Raum geschmissen.

Ich dachte da an sowas, nur in Verbindung mit psexec:

Running Windows PowerShell Scripts

cheers

Velius

PSexec und das cmdlet aus einer cmd starten?:suspect:

Der Startparameter muss weg.

Der kann, sobald der Dienst im Servcie Control Manager sichbar ist, im Feld 'Startparameter' der Diensteigenschaften angegeben werden.

#edit

wobei mir grad einfällt, dass das bei der nutzung eines vpn's nicht helfen würde...

 

Darum wäre RPC-over-HTTPS gut: Auf deiner Seite kannst dann alles dicht machen ausser SSL.

Was für 'ne Firewall ist es denn? Es gibt welche, da kannst du nach den GUIDs der RPC-Calls filtern ohne Ports dicht/auf zu machen, und auch innerhalb VPN. Das wäre dann wieder was, sollte dir das andere Netz zu unsicher sein.