Ich habe der W2kR2-VM (VMware) nun 16 GB RAM und 2 CPU-Kerne zugewiesen. Nun gibt es keine "SSL-Fehler" mehr, wenn man sich mit einem Client verbindet und die SOC-GUI ist nun in einer RDP-Session auf dem W2k auch flüssig zu bedienen.
Aber es kann doch nicht die Lösung sein, die SOC mit virtueller Hardware zu erschlagen ;-) Ich muss doch hier irgendwas noch falsch gemacht haben.
Ich habe auf einem nackten, frisch installierten und durchgepatchten W2kR2
* DotNET 4.5 installiert, durchgebootet, Updates nachgezogen und nochmal durchgebootet
* eine Vollinstallation von SOC V2.5.2 per Doppelklick gestartet und durchlaufen lassen
* die Windows Firewall abgeschaltet
Zusatz-Frage in die Experten-Runde: Ist DotNet4.5 in diesem Fall nicht abwärtskompatibel zu 3.5?
Das würde ja bedeuten, dass ich den SOC zwingend auf einer dedizierten System laufen lassen muss.
Ich habe
* eine W2k8R2-VM mit 8GB RAM und 1vCPU
* das SOC und DotNet4.5 deinstalliert ( und rebootet)
* Updates installiert
* DotNet3.5 und Updates installiert
* das SOC neu installiert
Nun tritt der SSL-Fehler nur noch sporadisch auf - Verbindungen von einem Client sind nun in der Mehrheit der Fälle möglich.
Allerdings ist die Bedienung im Client und auf dem Server sehr schleppend.