Start Arbeitsplatz und Erstellen Dokument extrem langsam seit Win10

[#1]

Hallo zusammen,

aktuell werden unsere Arbeitsplätze von Win7 Pro (mit Office 2013) auf Win10 (mit Office 2016) umgestellt (keine Upgrades, sondern Neuinstallationen).

Auf Windows 10 nun ganz schlechte Performance beim Starten des Arbeitsplatzes (Dauer ca. 1,5 Minuten) und Erstellen eines Dokuments aus einer Vorlage (DokOrg)(Dauer hierbei ca. 2 Minuten). Auf Win7 mindestens doppelt so schnell (Start AP ca. 30-40 Sekunden und Erstellen eines Dokuments ebenfalls).

Leistungsindex Rewe zeigt für Win7:

Für Win10:

Beide Systeme sind virtuelle Maschinen (auf VMware ESX) und haben 16 GB RAM und 2 vCPUs.

Performance habe ich soweit wie möglich überprüft (Service-Tool "Leistungsprüfung", pingfile u.a.). Alles in Ordnung. Ein Office-Programm für sich alleine startet z.B. innerhalb von 1-2 Sekunden.

esxtop zeigt alles im grünen Bereich. Hier die CPU-Auslastung:

Netzwerk kann kein Bottleneck sein, da SQL-Server ebenfalls eine VM auf demselben ESX-Host ist.

Keine erhöhten %RDY-Values, Datastores ohne Latency. Kein Memory-Overcommitment.

Ressourcenmonitor in Windows 10 zeigt keine hohe Auslastung.

VM Tools aktuell, virtual HW aktualisiert.

Wir haben eine Peer-to-Peer-Umgebung. SQL-Server läuft ebenfalls auf Win7 Pro (seit einigen Jahren nun). Dort sind ebenfalls alle Leistungsdaten top. Ich glaube aber nicht an ein Netzwerkissue zwischen Win10 und Win7 (RSS oder so). Und wie gesagt, auf den Win7-Arbeitsplätzen ist alles im grünen Bereich.

Prinzipiell glaube ich momentan nicht an fehlende HW-Performance. Der ESX-Host ist zwar schon etwas älter, aber wie oben zu sehen ist, sind die Leistungsdaten immer noch sehr gut und für uns ausreichend. Natürlich würde alles vermutlich mit der neuesten HW besser laufen. Aber evtl. auch nicht, daher wäre die Anschaffung neuer HW momentan mehr eine Aktion "ins Blaue hinein".

Würde mich über Ideen und Vorschläge sehr freuen.

Vielen Dank im voraus.

[#2]

Wir haben eine Peer-to-Peer-Umgebung. SQL-Server läuft ebenfalls auf Win7 Pro (seit einigen Jahren nun). Dort sind ebenfalls alle Leistungsdaten top. Ich glaube aber nicht an ein Netzwerkissue zwischen Win10 und Win7 (RSS oder so).

Und wieso nicht? Glauben ist nicht wissen. Und wenn es vorher unter Win7-Client > Win7-SQL-Server alles lief und es jetzt mit Win10-Client > Win7-SQL-Server nicht mehr läuft?!

Und mal noch was anderes: Sie klingen sehr technisch und nicht auf die Nase gefallen, haben einen ESXi, 10VMs und installieren DATEV als Peer-to-Peer? Gibt es keine AD bei Ihnen? Glaube nicht, dass es daran liegt aber Peer-to-Peer ist ja eher eine Notlösung um mal eben schnell günstig einen zusätzlichen Client anzubinden.

[#3]

Danke für die Antwort. Geplant ist, dass ich den Win7-Server auf Win2016 umziehe.

Werde ich dann vermutlich am Wochenende in Angriff nehmen und hoffen, dass es wieder schneller wird.

Ich dachte nur daran, ob es evtl. an dem Datev-AP auf Win10 liegt. Aber gefunden habe ich dazu nicht wirklich irgendetwas in KBs, Community etc.

Testweise werde ich die Clients auch noch mit diesem Tool "VMware Optimization Tool" (VMware OS Optimization Tool) hoffentlich verbessern.

[#4]

Hallo Herr Schmidt,

hier ein Auszug aus dem Info-DB-Dokument 1080080 :

• Zurzeit werden uns verstärkt Performance-Probleme unter VMware vSphere 6 gemeldet in Verbindung mit dem vmxnet3 Ethernet Adapter mit neuer Server-Hardware (Netzwerkkarten). Die Probleme treten z. B. bei Kanzlei-Rechnungswesen auf. Beim Starten hängt das Programm ca. 1 - 2 Minuten beim Punkt Initialisiere Mandant.
  VMware hat das Problem erkannt und löst es mit dem Update 2 (KB2129176). Hintergrundinformationen zum KB2129176 finden Sie bei VMware: kb.vmware.com/kb/2129176​​.
  Prüfen Sie auf allen virtuellen Maschinen, ob RSC (Receive Side Coalescing) aktiviert ist:
       netsh int tcp show global
  Prüfen Sie, ob unter „Zustand der Empfangssegmentzusammenfügung=RSC“ die Angabe disabled angezeigt wird. Wenn ja, aktivieren Sie RSC mit folgendem Befehl:
       netsh int tcp set global rsc=enable
• Die Auswahl und Aktualität der Netzwerkkartentreiber kann entscheidenden Einfluss auf die Gesamt-Performance haben. Achten Sie daher darauf, dass die Treiber immer aktuell sind. In Hyper-V-Umgebungen muss nur der Treiber der physischen Netzwerkkarte im Host aktualisiert werden. Bei VMware empfehlen wir für bestmögliche Performance den Einsatz des Netzwerkadapters "VMXNET3", speziell beim Einsatz aktueller Hardware und eines modernen Betriebssystems. Treiber werden über die aktuelle Version der VMware Tools installiert.

Beste Grüße

Andreas Briefs

[#5]

Danke für die Antwort und den Vorschlag.

Passt leider nicht, da ich noch auf ESX 5.5 bin (allerdings mit den aktuellsten Treibern und auch mit den neuesten VM-Tools). Aber auch da überlege ich aktuell, ob ich mal auf 6.5 U2 hochziehe. Außerdem laufen die Win7-Clients auch mit vmxnet3.

Dennoch vielen Dank. Bin für jeden Vorschlag dankbar.

Aktuelle Planung:

- ESX auf 6.5 U2 hochziehen

- SQL-Server von Win7 auf WinSrv2016 migrieren

- SQL-Datenbanken optimieren/reorganisieren (im SQL-Manager)

[#6]

- SQL-Server von Win7 auf WinSrv2016 migrieren

Wie schon geschrieben, ist das die beste Möglichkeit vom Peer-to-Peer auf AD inkl. DNS umzusteigen inkl. zentraler Benutzerverwaltung.

Ist ja alles als Feature / Rolle im Server 2016 kostenlos aktivierbar. Lokale Benutzerkonten und die DATEVUSER Gruppe würde ich am Server 2016 nie ohne AD anlegen. Ist so ein Prinzip von mir. Geht sicherlich technisch auch anders aber würde ich persönlich nie machen.

- SQL-Datenbanken optimieren/reorganisieren (im SQL-Manager)

Kann man machen aber daran liegen die Performanceprobleme nicht.

[#7]

So. Habe jetzt die letzten 3 Tage Troubleshooting betrieben, bin aber leider noch zu keiner Lösung gekommen. SQL-Server wurde von Win7 auf Windows Server 2019 umgezogen. Hatte da leider ein paar Stunden Probleme, die Clients mit SQL zu connecten. Erst als ich die Firewall auf dem Server deaktiviert habe, ging es sofort.

Leider performen die Win10-Clients mit dem Server 2019 auch nicht schneller. Ist also kein Server-Issue. Aktuell sieht es so aus, dass der Datev-Arbeitsplatz auf den Win7-Clients in ca. 35 Sekunden startet, auf den Win10-Clients dauert es 2 Minuten. Hardware ist absolut identisch, da es ja virtuelle Maschinen sind (mit gleichen Settings).

Task Manager, esxtop, Ressourcenmonitor, Benchmarks usw. usw. sehen alle grün aus. Ist mir schon klar, dass die letzte State-of-the-Art-HW das ganze vermutlich beschleunigen würde. Aber der Resourcenindex bei Win7 ist bei 6,5, der bei Win10 liegt bei 20!!! Das kann ja jetzt nicht alles an der HW liegen.

Falls jemand noch mal schauen, möchte, habe ich ein PDF angehängt (oh, sehe gerade, dass ich hier kein PDF anhängen kann). Hier ist alles, was ich gemacht habe (Benchmarks, pingfile usw. usw.). Habe auch mit dem Sysinternals-Process Monitor versucht, ein Delay zu erkennen. Aber bei ca. 800000 Zeilen Tracing (nur beim Start des Arbeitsplatzes), taten dann doch irgendwann die Augen weh.

Und wenn man sich diesen Thread (leider ohne Lösung) anschaut, war dort das Problem dasselbe: Re: Performance DATEV- Anwendungen

Allerdings ging es hier nicht um Win7 oder Win10, sondern generell um schlechte Performance (auch 2 Minuten Startzeit) trotz neuester HW.

Habe jetzt eben einen Fall bei der Datev eröffnet. Ich hoffe, dass man sich dort mit dem Issue ein wenig beschäftigt und nicht einfach sagt: Kauf neue HW ("Totschlagargument").

metalposaunist​andreas_briefs​

frank.pfeiffer​ (habe ich mal getagged, in der Hoffnung, dass er zu seinem damaligen Problem eine Lösung gefunden hat)

[#8]

Danke für die Info. Welcome to Windows 10 and Server 2016/2019 .

Hatte da leider ein paar Stunden Probleme, die Clients mit SQL zu connecten. Erst als ich die Firewall auf dem Server deaktiviert habe, ging es sofort.

Das kann ja ehrlich gesagt auch nicht des Rätsels Lösung sein?! Es gab' mal bei 2012 R2 das Problem, dass die Clients den LiMa nicht finden konnten, weil der LiMa in der Firewall bzw. dessen Port geblockt war und bei der Installationsroutine der DATEV nicht automatisch geöffnet wurde. Ggf. auch hier wieder das Problem? Bleiben die Clients bei "LiMa wird gesucht" hängen?

Zum Rest: Absolut keine Ahnung. Würde da genauso im Neben stochern und testen, bis ich was hätte.

Neukaufen ist ja keine Option. Wenn, dann einmal statt Peer-to-Peer und alle Produktivmaschinen virtualisieren, einmal alles neu machen inkl. AD und DNS.

Aber: Seit Windows 10 gibt es auch nur noch Bananenprodukte. Egal ob Server, PC, Notebook, Switch, VMware ...

Nur mal Offtopic: Neue Dell Latitudes E5590 bestellt. Windows 10 frisch drauf inkl. Updates und allen Programmen. Das Teil geht einfach so ohne Eingabe in den Zustand, dass es an ist, die LED leuchtet aber Bildschirm aus und es reagiert auf nichts mehr. Lösung: BIOS fehlerhaft > Update. Ebenso brauchen die USB-C Dockingstations ein Firmwareupdate, sonst gibt es mit externen Monitoren und Co. Probleme.

Früher: auspacken, Windows 7 drauf, Updates installiert, in die Dockingstatation geklemmt - läuft! Mit Windows 10 brauchen selbst die älteren Dockingstations ein MST-Hub Firmwareupdate, sonst kann man nur 1 Bildschirm nutzen.

So viel zu neu ist besser ...

[#9]

Verdacht auf Netzerk- Fehlkonfiguration:

Bei jedem Server- Zugriff wird erst einmal abgecheckt, ob das WWW nicht ein besseres Ergebnis liefert.

Testweise IP6 deaktivieren...

PS: der DAP ist her auf einem neuen Clienten bei uraltem Server in 15 Sec arbeitsbereit (IP6 nicht deaktiviert)

Folgende Einstellung an allen Win10- Clienten löste hier oben beschriebene Performance- Probleme:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"Dhcpv6DUID"=hex:00,01,00,01,23,ba,70,2b,0c,9d,92,78,08,5d
"DisabledComponents"=dword:ffffffff

[#10]

irgendwas stimmt mit der plattenkonfiguration nicht, würde ich vermuten. teste mal die iops und vergleich das mit ähnlichen systemen. evtl auch treiberprobleme etc.

lt index hat sich der test auch um faktor 4 verschlechtert

[#11]

Die HD- Werte sind völlig OK, während die 0,3 sec zu niedrig sind. (Cache)

Beim Start der Anwendungen gibt es wohl einen Netzwerk- bedingten time out, denn selbst auf einer alten Gurke mit eiserner HDD sind die Anwendungen in 8,5 sec. gestartet.

[#12]

kann auch sein. aber kann man doch über dauerping rausbekommen. oder lima-anfrage oder oder. falls alles schon getestet, iops..

[#13]

Yes, Yes, Yes....

Sieht so aus als hätte ich das Problem gelöst.

Habe gestern noch einmal das Dokument 1070544 durchgearbeitet.

Und dann gerade eben auf den Clients die hosts-Datei konfiguriert. Also einfach den Namen des SQL-Servers mit IP-Adresse eingetragen. Ich habe kein DNS, aber die Namensauflösung funktioniert auch so ohne Probleme. Außerdem hatte ich die lmhosts bereits konfiguriert (wie auch bei den Win7-Clients).

Die hosts-Datei habe ich nicht konfiguriert bei Win7. Die VMs haben netzwerkmäßig zwei "Beinchen", eines zum internen vSwitch und eines zum externen vSwitch (für das Internet). Aber das ist bei den Win7-Clients nicht anders. Von der Namensauflösung her sind Win7 und Win10 also identisch gewesen.

Aber jetzt ist die Performance viel besser. Und auf einmal startet der DAP in ca. 20 Sekunden (ohne hosts ca. 100 Sekunden). Und der Leistungsindex steht jetzt auf 7,9 (bei Win7 auf 6,7). Anwendungsstart-Test geht runter von 15 auf 3 Sekunden. Ist jetzt noch keine weltbewegende Performance, aber das reicht erst einmal locker - bevor ich komplett neue Hardware anschaffen muss.

Ich habe keine Ahnung, warum sich Win10 (und insb. die Datev-Programme) hier anders verhält und eine hosts-Datei benötigt. Nun ja, es steht ja auch in dem Dokument 1070544. Aber das es so einen Unterschied macht. Unglaublich.

Es kann natürlich sein, dass dieser Hinweis das Problem beschreibt:

Verdacht auf Netzerk- Fehlkonfiguration:

Bei jedem Server- Zugriff wird erst einmal abgecheckt, ob das WWW nicht ein besseres Ergebnis liefert.

Testweise IP6 deaktivieren...

Da werde ich auch noch mal die Registry-Einträge rauswerfen.

Folgende Einstellung an allen Win10- Clienten löste hier oben beschriebene Performance- Probleme:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"Dhcpv6DUID"=hex:00,01,00,01,23,ba,70,2b,0c,9d,92,78,08,5d
"DisabledComponents"=dword:ffffffff

IPv6 ist aber deaktiviert auf allen Clients. Am Server habe ich das jetzt auch noch nachgezogen.

Ich danke Euch allen für die Unterstützung. Den Case habe ich bei der Datev auf "On hold" gesetzt. Werde noch weiter testen und optimieren. Aber jetzt sieht es erst einmal gut aus.

Das hat mich jetzt ein ganzes Wochenende gekostet (inkl. kurzer Nächte).

Evtl. für andere, die ähnliche Probleme haben, hier was ich alles abgearbeitet hatte (ohne Erfolg):

• - Verschiedene Anzahl vCPUs wurde getestet
• - Alle VMs gestoppt, außer Server und einen Test-Client
• - Server-Plattform Windows 7 und Windows Server 2019 zeigen dasselbe Verhalten
• - Firefalls, AV-Programme und Defender deaktiviert
• - Performance-Optimierung der VM mit Vmware Tools (https://labs.vmware.com/flings/vmware-os-optimization-tool).
  Alle unnötigen Dienste und Programme wurden in der VM gestoppt.
• - Sämtliche Datenbanken wurden geprüft, optimiert und verkleinert.
• - RSC deaktiviert und aktiviert getestet (netsh int tcp set global rsc=enable/disable) in der Client VM
• - Durchgearbeitet: https://www.datev.de/dnlexom/v2/content/files/st36028802750895755.pdf
• - Energie steht bei allen VMs auf Höchstleistung
• - BIOS im ESX-Host steht auf „Static High Peformance“. Kein Power Saving benutzt.
• - Durchgearbeitet: http://www.datev.de/lexinform-infodb/1080080 und http://www.datev.de/lexinform-infodb/0908365
• - Kein Overcommitment der VMs (Memory, CPU), kein Swapping
• - Abgearbeitet: https://www.datev.de/web/de/m/ueber-datev/datev-im-web/datev-von-a-z/net-netzwerk-und-performance-datev-abhilfen-bei-systemnahen-problemen/?stat_Mparam=int_url_datev_systemkomponenten
• - Abgearbeitet: https://apps.datev.de/dnlexka/#/document/1036440
• Service-Tool Leistungsfaktoren geprüft
• dstool verwendet
• pingfile-Tests (zum Server und zur lokalen Platte)
• Passmark-Benchmarks
• Performance-Analyse ESX-Host mit esxtop
• Process Monitor-Tool von Sysinternals.

Geholfen hat dann letztlich, die Namensauflösung optimal zu konfigurieren (da kein DNS vorhanden, Datei "hosts" konfiguriert).

[#14]

Was ich aber noch nicht testen konnte (da jetzt alle User arbeiten und die Arbeitsplätze belegt sind), ist das Erstellen von Dokumenten mit Dokorg. Ich hoffe, dass dies jetzt auch schneller geht. Werde später berichten.

[#15]

Erstellen Dokumente auch wesentlich schneller. Alles läuft sehr performant.

Lag an der Namensauflösung. Da die meisten vermutlich eh AD und DNS haben, ist es dort kein Problem.

Da wir jedoch eine Peer-to-Peer-Umgebung haben (1 Server und 6 Arbeitsplätze), verwenden wir kein DNS.

Aber evtl. hilft diese Info ja dem einen oder anderen, dass eine saubere Namensauflösung (zumindest bei mir) die Performance doch deutlich beeinflusst.

[#16]

Da die meisten vermutlich eh AD und DNS haben, ist es dort kein Problem.

Späte Erkenntnis ...

Da wir jedoch eine Peer-to-Peer-Umgebung haben (1 Server und 6 Arbeitsplätze), verwenden wir kein DNS.

Sorry, aber was ist das für ein vorgehaltener Grund? Das bringt mich zum Rasen aber an allem ist Windows 10 und DATEV Schuld .

Und weil ich zu Hause nur 3 Laptops habe, lasse ich auch DHCP und DNS weg, damit ich nicht www.google.de eintippen brauche, sondern 172.217.16.67 - oder was?

Wirklich sorry, aber DNS hat keinem, aber auch wirklich gar keinem Netzwerk geschadet. Egal ob es sich um 1 Client oder 5000 handelt.

[#17]

metalposaunist​

Ich finde den Kommentar ehrlich gesagt ein wenig überzogen. Natürlich nutzen wir DNS-Server, aber eben nur für den Internet-Zugriff. Und hier hat die DATEV-SW (der DFL-Service) vermutlich immer erst einmal gesucht, um den Namen des SQL-Servers aufzulösen.

Und was soll denn heißen "Das bringt mich zum Rasen aber an allem ist Windows 10 und DATEV Schuld"? Hat doch gar keiner behauptet. Ich habe doch nur die Unterschiede dargestellt - so gut und ausführlich wie möglich. Und festgestellt, dass ich ohne DNS gravierende Performance-Probleme habe. Und das auch nur seit Umstellung auf Win10.

Warum kein DNS? Nun ja, jeder zusätzliche Service frisst Ressourcen. Und wenn man ihn normalerweise nicht benötigt, warum soll ich ihn betreiben und administrieren? Dasselbe gilt für AD. Bisher waren sie nicht nötig in unserer Umgebung und Peer-to-Peer-Netzwerke sind supported. Da unser Server ein "Quasi-Server" unter Win7 Pro war (lief, wie gesagt, seit vielen Jahren ohne Probleme), konnte ich dort auch kein AD, DNS, DHCP usw. betreiben.

Hinterher ist man natürlich immer schlauer, wenn man die Ursache gefunden hat.

Ggfs. werde ich aber einen DNS-Server installieren und einen Forwarder setzen für die Namensauflösung im Internet. Prinzipiell macht es ja Sinn, in 99% der Umgebungen ein AD mit DNS, DHCP usw. zu betreiben. Bei uns in der Kanzlei (die sehr statisch ist) war es, wie gesagt, bisher nicht notwendig und daher haben wir es auch nicht genutzt.

[#18]

Über die Ansichten des Metalposaunisten kann man unterschiedlicher Meinung sein - über die Frage AD vs. Peer-to-Peer eher nicht. Unter Win2000 hatte ich das auch einmal für 2 Arbeitsplätze, genau 1,5 Jahre. Danach kam der erste Server mit Server 2000.

Ich werfe nur eine Frage in den Ring:

Für die Zeit, die benötigt wurde die falsche Konfiguration zu bereinigen hätte auch ein AD mit Terminalserver aufgesetzt werden können. Der Erfolg wäre eine vereinfachte Verwaltung in der Zukunft gewesen.

Im Übrigen muss ich aufpassen, dass mein DC (also der Server, der die Dienste DNS, DHCP etc. betreibt) nicht an Langeweile stirbt. Wenn der mal so richtig gefordert wird nimmt er sich 1,5 GHz Prozessorleistung vom Host. Im Normalbetrieb zeigt der Host um die 500 MHz oder weniger. Da brauche ich nicht zu knausern.

[#19]

Nunja, ob man jetzt über den Ausdruck "zum Rasen bringen" diskutieren will überlasse ich Ihnen.
Aber im eingangspost haben Sie schon geschrieben, dass Hardwareseitig kein Problem bestehen könnte. Auch Softwareseitig Win7/10 vom Prinzip kein Problem darstellen.

Dies lässt nur noch den Schluss offen, dass Datev "Schuld" an den Problem ist. Man könnte natürlich darüber streiten, dass Datev gerne eine AD/DNS Grundlage hätte. Aber ich sehe das wie Herr Bohle. Beides Rein und gut. Ich setze auch auf Clients (größer ThinClients) die Defrag auf mtl. .Wenn ich da schon sage das frisst Ressourcen, dann ist dass Gesamtwerk zu knapp bemessen.

Und wenn man nach 18 Minuten schon einen entsprechenden Tipp für diese Richtung gibt... Sollte man evtl. auch diesen in betracht ziehen.

[#20]

Ja. Das sehe ich inzwischen auch so. Was lange Jahre gut funktioniert hat, muss ja nicht ewig weiter funktionieren.

Alles ist ausgerichtet auf AD, DNS usw.

Für die Zeit, die benötigt wurde die falsche Konfiguration zu bereinigen hätte auch ein AD mit Terminalserver aufgesetzt werden können. Der Erfolg wäre eine vereinfachte Verwaltung in der Zukunft gewesen.

Ja. Anstatt Peer-to-Peer (was bei 5 Arbeitsplätzen völlig ausreichend und voll supportet ist) habe ich jetzt "testweise" auf Windows Server 2019 umgestellt. Und dennoch jetzt festgestellt, dass es nicht am Server-OS lag, sondern an der simplen Namensauflösung (weil die Datev-SW erst einmal im Internet nach dem lokalen SQL-Server sucht). Aber ich denke, ich werde da jetzt ggfs. auch AD und DNS aktivieren.

Natürlich, hätte man vorher gewusst, dass es daran lag, hätte ein DNS das Problem nicht erst auftreten lassen. Und sich ein Wochenende Troubleshooting gespart. Aber es ist auch ein Kostenunterschied, ob ich Peer-to-Peer mache oder eine Serverlizenz kaufe.

Hinterher ist man immer schlauer. Ich arbeite selbst seit 20 Jahren im Support und weiß am Ende auch (nach teilweise tage- oder wochenlangem Troubleshooting) mehr als vorher und die Lösung erscheint im Nachgang simpel.

Und dieser Thread kann ja anderen evtl. auch helfen.

[#21]

Wie gesagt, dieselbe Umgebung funktionierte unter Win7 Peer-to-Peer ohne Probleme.

Es wurden nur einige Clients auf Win10 umgestellt. Namensauflösung war identisch wie vorher.

Server war Win7 "Quasi-Server". AD/DNS konnte ich dort nicht aktivieren.

Und dass der Leistungsindex von 7 auf 22 hochgeht, weil kein DNS existiert (der ja vorher auch nicht da war)...na ja.

Aber egal. Ich habe was gelernt und evtl. kann der eine oder andere davon ebenfalls profitieren.

Danke auf jeden Fall an alle für Tips, Vorschläge und Hilfestellungen.