zahni

Steckt da "vernünftiger" RAM in der Kiste? Also Reg. DDR4 DIMMs mit ECC? Sind alle Bänke korrekt bestückt?

Ja, Fiddler kann auch mit Client Zertifikaten. Der sagt dann, wo er es haben will...

Schau doch einfach auf den DCs nach, wer da Konto immer wieder sperrt. Dann löst Du dieses Problem.

Ich vermute, dass MS das wohl auch an der Hardware und dessen Alter fest macht. Ich hatte hier 2 Notebooks nebeneinander am DSL-Anschluss. Der ganz "Neue" hat es fast sofort geladen, dem "Alten" musste manuell geholfen werden.

Hört sich eher nach einem Defekt an. Mal mit https://www.hpe.com/us/en/product-catalog/storage/storage-software/pip.hpe-library-and-tape-tools.406729.html testen.

Für Vsphere: Ihr solltet vor den ESXI-Updates erst das VCenter Updaten. Sonst kann es passieren, dass VMotion nicht mehr funktioniert. Grund ist ein weiteres CPU-Feature, dass an die VMs durchgereicht wird: In einem EVC-Cluster wird es erst dann auf allen Hosts aktiv, wenn alle Hosts gepacht sind. Neue Hosts ohne den Patchlevel können nicht mehr hinzugefügt werden. https://kb.vmware.com/s/article/52085

Ich bin jetzt eher auf dem Trichter gewesen: Nicht gültig signiert, oder so...

Lt. Dem Blog Blog nur, wenn der Schutz gegen "untrusted code" aktiviert ist. Leider schweigt sich MS darüber aus, was genau "untrusted code" ist und wie man den erkennt.

Vmware veröffentlicht u.a. Microcode-Update: ID: ESXi550-201801401-BG Impact: Important Release date: 2018-01-09 Products: embeddedEsx 5.5.0 Updates esx-base VIB ID: ESXi600-201801401-BG Impact: Important Release date: 2018-01-09 Products: embeddedEsx 6.0.0 Updates esx-base, vsan, and vsanhealth VIBs ID: ESXi600-201801402-BG Impact: Important Release date: 2018-01-09 Products: embeddedEsx 6.0.0 Updates cpu-microcode VIB ID: ESXi650-201801401-BG Impact: Important Release date: 2018-01-09 Products: embeddedEsx 6.5.0 Updates esx-base, esx-tboot, vsan, and vsanhealth VIBs ID: ESXi650-201801402-BG Impact: Important Release date: 2018-01-09 Products: embeddedEsx 6.5.0 Updates cpu-microcode VIB Siehe auch https://www.vmware.com/security/advisories/VMSA-2018-0004.html Da steht auch was zum "Guest-OS". Für das VC gibt es auch Updates.

Die Fa. hat gute Tools für alle PDF-Lebenslagen: http://www.pdf-tools.com Wenn man etwas programmieren kann: https://www.aspose.com/

Apple hat soeben IOS und Macos Updates veröffentlicht...

Der MicroCode kann auch per Software-Update verteilt werden. Wurde auch schon in der Vergangenheit gemacht. 80% der "normalen" PC-User werden eher selten das BIOS updaten. Es sei denn, der Hersteller hier irgendeinen Automatismus implementiert. Und in großen Firmennetzen: Wer hat das am Client mal ernsthaft probiert?

Interessanter Thread bei Reddit https://www.reddit.com/r/vmware/comments/7nvc7s/re_intel_vulnerability_anyone_know_if_vmware_is/

Halllo und willkommen im Forum, Google ist voll davon, z.B. https://social.technet.microsoft.com/Forums/sqlserver/en-US/72fbd726-730b-4aef-9db1-aeb8bfb5d334/sql-2012-setup-issues-hexadecimal-value-0x00-is-an-invalid-character?forum=sqlsetupandupgrade Stichwort: Uralte MSDE Instanz...

Ich hoffe, Du hast dass mit Deinem AG abgesprochen. Bei uns hätte das ernsthafte Konsequenzen. Ansonsten: VPN Client mit Split Tunneling benutzen.

Hier mal an das Ende scrollen: https://www.ip-phone-forum.de/threads/eigene-dns-server-per-fritzbox-vpn-nutzen.283573/

Nach Deiner Edtih ja. Ich war schneller...

Cool, dann wird der Editor vielleicht auch auf dem Ipad angezeigt.

prüfe mal, ob beim Shutdown ein BSOD auftritt. Sowas habe ich auch schon bei NT4 gesehen...

Die FB gibt den DNS bei VPN vor. Wenn man den in der FB Config anpasst, sollte es klappen.

Man kann in der FB irgendwo den verwendeten DNS-Server eingeben. Hier könntest Du mal Deinen DC eintragen. Am DC-DNS musst Du nun einen geeigneten Internet-DNS als Weiterleitung eintragen (nicht die Fritzbox) oder Du verlässt Dich auf die Root-Hints.

Das Web-Gedöns ist nur per https erreichbar. Macht auch irgendwie Sinn, oder?

Probiere es mal remote und nicht lokal.

Kerberos funktioniert nicht mit IP-Adresse. Damit kann der SPN nicht lokalisiert werden. Und wenn es doch geht, hat der Client ein Fallback auf NTLM gemacht.

Das meine ich nicht. So eine Netapp hat oder sollte 2 mindestens 2 Cluster-Nodes (HA) verwenden. Mach mal LACP zu einer 2-Node Netapp... Schaue Dir pNFS mal genauer an. Mal am Beispiel mit FC: - Du hast mehr als ein Volume bzw. LUNs - Die Volumes sind auf deine Nodes verteilt (Aggregate = Node) - Du hast 2 Nodes und vier Pfade. - Jede LUN ist über 4 Pfade erreichbar, davon sind aber nur 2 "Optimal" Es kommt darauf an, dass VmWare die LUN über die "optimalen" Pfade erreicht. Du möchtest Dich als Admin nicht damit beschäftigen. Daher haben sich schlaue Jungs und Mädels (?) das ALUA-Protokoll ausgedacht. Sowohl für FC als auch für ISCSI Wann sind Pfade nicht optimal? Wenn auf die LUN über einen anderen Controller als den "Heim-Controller" zugriffigen wird. Dann geht es nämlich intern über den Cluster Interconnect. pNFS hat ähnliche Funktionen implementiert: https://whyistheinternetbroken.wordpress.com/tag/pnfs/ Unsere kleine Netapp hat u.a. je Node 2 10G-Ports, die per LACP am Switch hängen. Aber nur wegen der Ausfallsicherheit auf Netzwerk-Ebene (jeder Link geht auf einen anderen Switch). Ansonsten noch FC-Karten. Im HA-Fall werden die entsprechenden lokalen LIFs auf die Ports den anderen Nodes migriert. LIFs sind immer Node-Lokal. Hier wird derzeit nur CIFS/SMB gemacht. Da das normale SMB (nicht SMB 3 für Hyper-V Cluster) kein Multipathing kann, gehen die SMB-Verbindungen bei einem HA-Failover kurz verloren. Da hilft auch kein LACP. Das wollen wir halt bei pNFS, ISCSI und FC vermeiden. Kannst Du ausprobieren: Wenn bei einem cDot-Update im Betrieb (funktionierender HA-Cluster) die VMs nichts mitbekommen (keine DISK-Errors) und nur das VC was von Path Down labert, ist alles in Ordnung.