zahni

PSEXEC kann Consolen-Ausgaben nach stdout auf den Remote-PC umleiten. Interaktion ist aber nicht möglich.

Danke für die Rückmeldung. Das ist übrigens ein Grund, warum ich einen Server niemals ohne guten Hardware-Raid Controller und ECC-Speicher betreiben würde. Defekte HD's sind dann i.d.R. kein Problem mehr. RAM-Fehler werden von der Hardware erkannt.

Die normalen SCSI-Controller von HP sind von LSI. Die sollten funktionieren.

Diese Controller sind für den Betrieb in einem HP-Server bestimmt. Die funktionieren auch nur dort richtig.

Frage doch einfach Dein Systemhaus.

http://technet.microsoft.com/en-us/library/dn303411.aspx

Hä ? auf dem PC ? Ich meine nicht den Server.

Also: Das Boot-Image muss im WIM-Format vorliegen. Dann muss Du noch dafür sorgen, dass Du das richtig PXE-Boot-File lädst. Die sind normalerweise im PE-Image ( irgendwo im Windows-Folder) enthalten. Ob es generell ohne WDS geht, kann ich Dir nicht sagen. Dein Blick sollte in Richtung Syslinux gehen: http://www.syslinux.org/wiki/index.php/WDSLINUX

Hinterlege den Domänen-Namen in den erweiterten Computer-Einstellungen, da wo man den Computernamen ändern kann. Alternativ: DNS-Suffix in den TCP-Einstellungen der NIC eintragen.

Bei 3 Servern muss man u.U. an die Einschalt-Reihenfolge denken... Das kann bei Vsphere u.U, ein Problem werden, wenn man einen DNS-Server braucht und der nur virtuell läuft....

Bitte deinstalliere Intel Proset. Verwende nur die NIC-Treiber. Teaming nur im Hyper-V einrichten Siehe Blog. Hyper-V unterstützt keine fremden Teaming-Treiber. Ähm, Du hast doch Probleme, oder ?

Vom direkten "Durchschleifen" einer Hardware-Komponente sollte man Abstand nehmen. Dass kann den Betrieb des ganzen Hosts stören. Technisch ist dies möglich mit VmWare ESXi, bei Verwendung einer aktuellen CPU und der Funktion "Direct Path I/O" bzw VMDirectPath . Ob es mit der konkreten ISDN-Karte funktioniert, ist aber nicht garantiert. Die werden auch von VMWare nicht offiziell supported.

Ich hoffe, Du hast in der Parent-Partition nicht die Teaming-Software von Intel installiert. Die ist unsupported. Siehe dazu http://blogs.technet.com/b/keithmayer/archive/2012/10/16/nic-teaming-in-windows-server-2012-do-i-need-to-configure-my-switch.aspx#.UrKwebCA2Hs Die Meldung im Eventlog sind, spontan vermutet, auf Deine Registry-Änderungen zurückzuführen. Hast Du irgendwas "optimiert", gleich nachdem Windows 8.1 installiert wurde ? Oder schon unter Windows 8 ? Weil es z.B. so irgendwo im Internet stand ?

Dann dürften überhaupt keine Computerrichtlinien angewendet werden oder erst nach der Anmeldung des Users. Ist verständlich, oder ? Es sollte hier eigentlich ein paar Einträge im Eventlog geben.

Vielen Dank für die Rückmeldung. Ein paar weitere Angaben im Vorfeld (z.B. diese Sophos-Geschichte) hätte Dich vielleicht schneller zum Ziel geführt.

Was steht im Eventlog zu dieser Uhrzeit ? Gibt FM's im Eventlog der Server ?

Prüfen, ob der aktuelle Update-Agent und ein aktueller MSI-Installer installiert sind. Das mit dem Update-Agenten passiert automatisch. Könnte aber sein, dass irgendein "Optimierungs-Programm" da rumgepfuscht hat.

Vielleicht greift der User per VPN auf einen Drucker am internen PC zu ? Details erfährst DU, wenn Du mal Netmon oder Wireshark auf dem betroffenen internen PC laufen lässt.

Wozu solltest Du Netzwerkkonfigs sichern, die von einem DHCP gesetzt worden sind ? Bei HP-Tools schaust Du am Besten mal im Tool nach. Besser wäre es, die Einstellungen aufzuschreiben...

Dann öffne nur die Ports, die im Internet benötigt werden. Im Zweifel nur SMTP(S)

Hängt der Server am Internet ? Dann brauchst Du Dich nicht zu wundern. Die Script-Kiddies probieren alles Mögliche. Es könnte ja immerhin doch ein HTTP auf dem SSL-Port laufen ;) Schaue mal in der HTTP-Logs vom IIS.

Das gibt es viele Möglichkeiten, z.B. http://eventid.net/display-eventid-36888-source-Schannel-eventno-10545-phase-1.htm

Benutze mal die Suche im Forum, z.B. http://www.mcseboard.de/topic/161083-64-bit-druckertreiber-auf-einem-32bit-drucker-server-bereitstellen/

Vom Umbenennen einer AD-Domäne sollest Du Abstand nehmen. Die Internet-Domäne zu ändern ist deutlich schmerzfreier ;) Ich würde einfach den Internetauftritt ändern (lassen), damit der Zugriff auch mit www. klappt.

Wie geschrieben: die IE verhält sich korrekt und die anderen beiden Browser nicht. Zertifikate für IP-Adressen sind ungültig, da der "Eigentümer" einer IP-Adresse i.d.R. nicht verifiziert werden kann. Die "gehören" ISP's. Falls das ein Self-Signed Zertifikat ist, musst Du es per GPO im richtigen Truststore (k.a. welcher) verteilen. In deinem Fall scheint aber die FW mit seiner ausgedachten Root-CA ein Cert erstellt zu haben. Das würde ich nicht machen. Hier solltest Du eine richtige eigene CA bereistellen. Alternativ das Root-Zertifikat der FW per GPO in die vertrauenswürdigen Stammzertifizierungsstellen importieren Ich bin mir sicher, dass die genaue Vorgehensweise in der Doku der FW steht.