webbies

auf dem Server, auf dem es nicht geht, ist die Richtlinie "Administratorgenehmigungsmodus für das integrierte Administratorkonto" aktiviert und ausgegraut, auf dem anderen Server ist es nicht definiert.

das ist mir bekannt, allerdings verstehe ich nicht, warum sich das so anders verhält bei zwei frisch aufgesetzten Systemen, bei denen einfach nur die Remoteverwaltung aktiviert wird.

Hallo zusammen, ich habe ein Problem auf einem Server, dass ich bei keinem anderen habe. Ich habe die Remoteverwaltung auf dem Server aktiviert, bekomme jedoch trotzdem den Fehler, dass der Zugriff verweigert wird. Folgendes Script nutze ich zum Testen: $securePassword = ConvertTo-SecureString "xxx" -AsPlainText -force $credential = New-Object System.Management.Automation.PsCredential("yyyy.local\administrator", $securePassword) $session = New-PSSession -computername zzz.yyyy.local -credential $credential Invoke-Command -Session $session -ScriptBlock { Get-WmiObject Win32_ComputerSystem } wenn ich die Powershell allerdings mit administrativen Rechten ausführe, klappt es einwandfrei. Also habe ich auf einem Servern nachgesehen und festgestellt, dass dort die Powershell standardmäßig mit administrativen Rechten gestartet wird, sobald ich die Remoteverwaltung aktiviere. Hat jemand eine Idee, wie ich das zum Laufen bekomme? Vielen Dank und Grüße webbies

ok, danke für eure Einschätzung, dann wird das Ding geplättet

der Screenshot ist nicht manipuliert, das ist tatsächlich so. Es ist auch kein RDS Server sondern ein Hyper-V Server, auf dem eigentlich nichts los ist. Der Server ist mit dem Internet verbunden, aber Schadsoftware kann ich keine ausfindig machen. Die GPO habe ich lokale auf dem Server eingerichtet.

Hallo zusammen, auf einem 2012 R2 Server habe ich das Problem, dass dort permanent Sitzungen von Benutzern erstellt werden, die niemals enden. Das sorgt dafür, dass ich mich als Admin irgendwann nicht mehr anmelden kann und nur noch ein Neustart hilft. Ich habe bereits eine GPO eingestellt, die inaktive Sitzungen automatisch beendet, aber das hilft nicht. Windows scheint diese Sitzungen auch gar nicht richtig zuordnen zu können. Habt ihr eine Idee, was es damit auf sich haben könnte?

Sorry, da das Thema für uns leider noch immer nicht abshließen zufriedenstellend gelöst ist, hatte ich noch nichts geschrieben. Ich kann aber berichten, dass die Performance durch die Festplatte mit der höheren Drehzahl in den Keller ging. Die Festplatte mit der höheren Blockgröße hat im Performance Test keinen Unterschied gemacht. Die vermurkste Installation ist aber nach wie vor ein Thema :)

hmm, da sind extrem viele Logs, auch viele mit verbose ... aber keiner der API Call heißt

Das Dokument 1014806 habe ich für die VMs durchgearbeitet, ist dies auch für den Host erforderlich? Die Energieoptionen stehen alle auf Höchstleistung. Die BIOS Einstellungen prüfe ich, wenn ich die Platte austausche. Mir ist aufgefallen, dass die VM mit den Daten eine Warnung ausgibt: Für die folgende Komponente wurde durch Ihren Systempartner/ technischen Ansprechpartner oder DATEV Support eine Protokollierung aktiviert. Diese Einstellung weicht vom Standard ab und kann zu Performanceproblemen führen. Aktuelle Protokollierungsebene: Verbose Komponente: API Call Anwendung: C:\PROGRAM FILES (X86)\DATEV\PROGRAMM\INSTALL\DATEV.INSTALLATION.SYNCHRONISATION.HOST.EXE Wie kann man das auf die empfohlene Einstellung ändern? In der TracingError Datei steh folgendes [14.12.2017 09:02:46, Datev.Installation.Synchronisation.Agent.exe] Information: TraceLevel set from Error to Verbose by component API Call Datev.Installation.Synchronisation.Agent.Program : Void Start(). [14.12.2017 09:02:47, Datev.Installation.Synchronisation.Agent.exe] Warning: There is no mapping for the category 'Datev.ConfigDB'.

danke, das ist ein guter Hinweis

nein, es wurde nicht gebraucht gekauft, es ist ein Server, der aber schon entsprechend lange anderweitig im Betrieb ist und nun zusätzlich auch Datev bereitstellen soll :) Haben noch refurbished HDDs bei Also zu dem Modell gefunden, die werden wir jetzt erstmal verbauen um das Thema HDDs schonmal ausschließen zu können

ja, es ist Hyper-V :) Ich habe die "Laufzeitfaktoren" im Servicetool laufen lassen und dort ist alles grün. Remotedesktopdienste sind auf dem Server installiert. Wenn meine Recherchen stimmen und im install mode Registry Einträge unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install zu finden sein müssten, dann wurde Datev nicht im install mode installiert, denn hier ist nichts zu sehen. Zum Thema Netzwerkkarten: Der Befehl Get-NetAdapterVmq –Name * liefert mir keinerlei Ergebnisse

auch ein zweiter Durchlauf ist genauso langsam. Datev wurde von einem Datev Mitarbeiter installiert, wir haben nur zwei VMs zur Verfügung gestellt. Ob die Installation im TS Installationsmodus durchgeführt wurde kann ich leider nicht sagen ... will ich doch mal schwer hoffen, wenn man auf einem TS installiert. Outsourcing kommt leider nicht in Frage. Im Servicetool ist bis auf Excel Makros alles grün. Wie/wo stelle ich Leistungsdaten im Servicetool ein?

der steht leider an einem anderen Standort ... aber ich werde mich darum kümmern

ach du meintest die physische Zuordnung ... die weiß ich ehrlich gesagt gar nicht. Die Zuordnung, die ich geschrieben hatte, war die der VMs