schmimla21

Korrekt, das Skript wird durch eine Automatisierungslösung alle 60 Sekunden ausgeführt. Das Ganze ist ein relativ komplexes Gebilde: Die Automatisierungslösung startet einen Dienst, der die Datenfiles eben öffnen und analysiert, und die Daten dann in entsprechende Datenbanktabellen schreibt. Die "Automatisierungslösung.exe" schreibtim Grunde eine xml-Datei, in der z.B. der Connect-String der Datenbank (über eine ODBC-Konfiguration) oder das "Abfrageintervall" angegeben wird. Der Dienst wird auf dem alten System wie auch auf dem neuen System mit dem lokalen Systemkonto gestartet. Was mir dabei noch als Unterschied beim alten und neuen System noch auffällt: Auf dem alten Server haben nur die Benutzergruppen "System" und "Administratoren" Vollzugriff auf die Automatisierungslösung. Bei den Berechtigungen auf dem neuen Server sind dagagen noch die Gruppen(?) "ALLE ANWENDUNGSPAKETE" und "ALLE EINGESCHRÄNKTEN ANWEDNUGSPAKETE" mit lesendem Zugriff aufgelistet. Ist dies vielleicht noch wichtig?

Ergebnis im Log: 21.08.2019 12:04:36 Reason : Info Creator : EXCEL [EXCEL] Message : Import.CS:: Scripting Standard Output: Microsoft (R) Windows Script Host, Version 5.812 Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. Excel-Datei: \\...\...\...\...\...\...\...\import_excel_test\21_08.xlsx CSV-Datei: \\...\...\...\...\...\...\...\import_excel_test\21_08.csv Datei auffindbar: Wahr Excel gestartet... 21.08.2019 12:04:36 Reason : Info Creator : EXCEL [EXCEL] Message : Import.CS:: Scripting Standard Error: C:\Program Files (x86)\...\...\xls_zu_csv.vbs(61, 3) Microsoft Excel: Microsoft Excel kann auf die Datei '\\...\...\...\...\...\...\...\import_excel_test\21_08.xlsx' nicht zugreifen. Dies kann mehrere Grnde haben: Der Name des Dokuments oder der Pfad ist nicht vorhanden. Das Dokument wird von einem anderen Programm verwendet. Der Name der Arbeitsmappe, die gespeichert werden soll, ist identisch zu dem Namen eines anderen Dokuments, welches schreibgeschtzt ist. Okay, das Problem liegt bei Excel. Wenn ich die Datei im Explorer unter demselben Benutzer auf dem Netzwerkpfad öffne, bekomme ich keine Fehlermeldung. Abspeichern kann ich das testfile auch....

Da fehlen noch einige Einzelheiten, weil sie ursprünglich nicht von Interesse waren: Der Pfad soll zyklisch überwacht werden, ob neue Dateien vorliegen, und diese sollen dann automatisch umgwandelt werden. Auch bei einer frisch lokal angelegten Datei auf dem neuen System tritt das Problem auf. Ja, irgendeine lokale Gegebenheit wird es sein - ich bin nur weiterhin ratlos welche...

So was hatte ich auch vermutet. Allerdings habe ich dasselbe Problem, wenn ich die .xls auf der lokalen Festplatte speichere und die Datei von dort aus geöffnet werden soll... Das man Excel auf dem Server einsparen könnte ist natürlich ein interessanter Punkt, von daher würde ich das in Zukunft in Betracht ziehen. Auf die Schnelle habe ich die Konvertierung aber jetzt mit diesem Modul noch nicht hinbekommen, und ich würde trotzdem gerne erst mal beim "gewohnten" Workflow bleiben. Gibt es vielleicht noch weitere Ideen?

Hallo zusammen, bei uns soll mit folgendem (uralten) Code ein Excel-Sheet geöffnet werden und als eine gleichnamige csv-Datei im gleichen Netzwerkpfad abgespeichert werden. Option Explicit main sub main ' Deklaration der Variablen dim fso dim app dim xlsfile Dim csvfile Set fso = CreateObject("Scripting.FileSystemObject") ' Abfrage der Kommandozeilenargumente If WScript.Arguments.Count <> 2 Then exit sub End If on error goto 0 xlsfile = WScript.Arguments(0) csvfile = WScript.Arguments(1) ' bestehende Dateien werden NICHT �berschrieben ' So wird gewährleistet dass bestehende Dateien zunächst verarbeitet werden if fso.FileExists (csvfile) Then exit sub end if set app = CreateObject("Excel.Application") WScript.echo "Excel started..." app.Workbooks.Open xlsfile, false, true app.ActiveWorkbook.SaveAs csvfile, 6,,,false,false,,,false,,,true app.ActiveWorkbook.Close false WScript.echo "Workbook closed..." app.Quit WScript.echo "Excel closed..." End Sub ' main Die weiteren Einzelheiten, wie und warum das Script aufgerufen wird, spare ich an dieser Stelle zunächst mal aus. Ich habe den Code nicht erstellt und habe auch keine Ahnung :) Das Ganze dient letztendlich dazu, Werte aus diesem generierten .csv-File über eine Schnittstelle in eine Datenbank zu schreiben. Dies lief bislang auf einem System mit Windows Server 2008R2 und darauf installiertem Excel 2010 problemlos. Allerdings muss jetzt auf Windows Server 2016 mit Excel 2016 migriert werden. Bei der Ausführung auf dem alten System sieht das bei der erfolgreichen Ausführung im Logfile so aus: 15.08.2019 12:57:07 Reason : Info Creator : EXCEL [EXCEL] Message : Import.CS:: Scripting Standard Output: Microsoft (R) Windows Script Host, Version 5.8 Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten. Excel started... Workbook closed... Excel closed... Auf dem neuen System wird keine csv-Datei generiert. Im Log sieht das dann so aus: 16.08.2019 15:34:32 Reason : Info Creator : EXCEL [EXCEL] Message : Import.CS:: Scripting Standard Output: Microsoft (R) Windows Script Host, Version 5.812 Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. Excel started... 16.08.2019 15:34:32 Reason : Info Creator : EXCEL [EXCEL] Message : Import.CS:: Scripting Standard Error: C:\Program Files (x86)\xyz\xyz\xls_zu_csv.vbs(58, 3) Microsoft Excel: Microsoft Excel kann auf die Datei '\\xyz\xyz\test.xls' nicht zugreifen. Dies kann mehrere Gr�nde haben: � Der Name des Dokuments oder der Pfad ist nicht vorhanden. � Das Dokument wird von einem anderen Programm verwendet. � Der Name der Arbeitsmappe, die gespeichert werden soll, ist identisch zu dem Namen eines anderen Dokuments, welches schreibgesch�tzt ist. Zeile 58 ist die Zeile mit der Funktion app.workbooks.open. Ich bin mir eigentlich ziemlich sicher, dass das neue System auf die Datei zugreifen kann, daher frage ich hier, ob das Problem vielleicht im Script und der Verbindung mit dem neuen System liegen kann. Wie gesagt, das alte System findet mit identischer Konfiguration der Schnittstelle den Pfad, kann die App öffnen usw, und auch die Einstellungen hisichtlich Benutzer, Excel Trust-Center (Pfade im Netzwerk als vertraunswürdig eingestuft z.B.) sind eigentlich identisch. Ich wäre für alle Anregungen sehr dankbar, was hier das Öffnen des Arbeitsblattes unterbinden könnte!

Hallo, ich habe den Abschnitt "Überprüfen, ob Anwendungen mit DPI-Werten kompatibel sind" aus dem Artikel mal noch ausgeführt, um die Bestätigung zu haben, dass der Status der "DPI-Awareness" = "Unaware" ist. Das habe ich soeben getestet: Auch bei einer lokalen Installation und der Skalierung auf 125% herrscht ein unscharfes Schriftbild. Auch die Optionen im Kontextmenü der .exe unter "Verhalten bei hoher DPI-Skalierung überschreiben" (Reiter Kompatibilität) bringen dann keine Besserung. Die beiden anderen Punkte haben dann dazu geführt, dass ich mal ein Ticket beim Hersteller eröffnet habe, auch wenn die Aussicht auf Erfolg hier äußerst bescheiden zu sein scheint. Vielen Dank für die bisherigen Antworten!

Hallo zusammen, ich habe schon viel rumprobiert, aber habe bislang keine Lösung gefunden. Folgendes Problem: Wir verteilen einige Anwendungen, die per Sammlung auf einer Windows 2012R2 Server-Farm bereitgestellt werden, als RemoteApp. Wenn ein Nutzer nun auf seinem Client die Anzeige eines Monitors auf 125% stellt, wird diese RemoteApp auf diesem Bildschirm unscharf dargestellt. Weder auf der Cleint-Seite (z.B. bei den RDP-Parametern in der .rdp-Datei), noch auf der Server-Seite habe ich Einstellungen gefunden, die hier Abhilfe schaffen. Auch die ClearType-Einstellung bewirkt hier nichts zum Positiven. Wir haben momenten noch Windows 1709 im Umlauf, und ich habe gesehen, dass es ab 1803 bei den Anzeigeeinstellungen "erweiterte Skalierungseinstellungen" geben soll. Hier soll Windows automatisch erkennen können, wann eine App unscharf dargestellt wird, und diese dann selbsständig korrigieren können. Ich kann mir irgendwie nicht vorstellen, dass das klappen soll, aber vielleicht hat dieses Feature hier ja schon mal jemand getestet und kann berichten. Anonsten wäre ich für weitere Denkanstöße und Hinweise sehr dankbar!

Danke für eure Antworten! ChrisRa: Wir haben in der Tat mal darüber nachgedacht, das ganze auf Citrix umzustellen. Das würde allerdings noch eine ganze Weile dauern, und bis dahin muss dieses System hier weiterlaufen. randy: Welches Problem meinst du, dass das Desktop-Fenster mit der Remote-App sich einfach so ohne Fehlermeldung schließt? Da wäre es für mich sehr hilfreich, wenn du dich noch an ein paar mehr Details erinnern könntest! Und über welche event-ID bist du drauf gekommen?

Hallo, ich hole das Thema nochmal hoch. Leider existieren die Probleme immer noch. Mittlerweile passiert es auch oft, dass das Desktop-Fenster der Remote-App sich einfach komplett ohne Fehlermeldung schließt. Dahingehend fallen mir folgende Ereignisse in der Ereignissanzeige immer wieder auf: Einmal die Information mit der Ereignis-IDs 9009: (Der Desktopfenster-Manager wurde mit dem Code 0x400110004 abgebrochen; Quelle Desktop Window Manager), und die Warnung mit der ID 1530 (Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u.U. nicht mehr ordnungsgemäß. ; Quelle User Profile Service) Diese beiden Ereignisse korrelieren zeitlich miteinander. Ich habe schon probiert, ob vielleicht mit der Deaktivierung der Aero Oberfläche auf den Windows 7 Clients Besserung eintritt, leider ist dies nicht der Fall. Ich könnte mir allerdings vorstellen, dass der Fehler mit dem Desktop Window Manager zu tun hat, wenn das Fenster einfach so ohne Fehlermeldung oder sonstiges geschlossen wird, oder? Kennt dieses Verhalten vielleicht jemand, und kann mir Tips zur Besitigung des Fehlers geben?

Danke erstmal für die Rückmeldung. Das ist ein Windows Server 2008 R2, der auf ner virtuellen Maschine läuft. NIC Treiber und so habe ich natürlich auch von gelesen. Der ist aber sowieso immer aktuell. Der Fehler tritt af jeden Fall an den unterschiedlichen Standorten mit unterschiedlicher Häufigkeit auf (Hier sind die Fehler zu ~70% auf einen Standort verteilt). Allerdings arbeiten da aber eben auch die meisten Leute mit dem System. Ich weiß echt im Moment nicht weiter. Wir versuchen jetzt erst mal eine konkrete Umgebung hinzubekommen, in der wir den Fehler wenigstens regelmäßig reproduzieren können.

So, da bin ich nochmal. Leider drehe ich mich im Kreis. Nach Konvertieren von HRESULT ZU NTSTATUS sind letze Woche die folgenden Fehlermeldungen aufgetreten: 0xC00A0032 STATUS_RDP_PROTOCOL_ERROR The RDP protocol component %2 detected an error in the protocol stream and has disconnected the client. 0xC000020D STATUS_CONNECTION_RESET The transport connection has been reset. 0xC00000B5 STATUS_IO_TIMEOUT {Device Timeout} The specified I/O operation on %hs was not completed before the time-out period expired. 0xC00A0006 STATUS_CTX_CLOSE_PENDING A close operation is pending on the terminal connection. 0xC00002D0 STATUS_DS_CANT_MOD_PRIMARYGROUPID Cannot change the primary group ID of a domain controller account. Wobei der erste Fehler am häfigsten auftritt und immer zusammen mit dem Id 50 Fehler auftritt. Die anderen Fehlermeldungen treten immer nur einzeln auf. Durchschnittlich arbeiten während der Kernarbeitszeit so 30 bis allerhächstens 50 Leute auf dem Remote-Server. Der TermDD Id 56 Fehler ist alleine letzte Woche ca. 50 mal aufgetreten. Leider ist es allerdings so, dass anscheinend gar nicht alle Abbrüche geloggt werden. Ich kann zum Beispiel den Fehler bei mir am PC nachstellen, nur eine entsprechende Meldung im Serverprotokoll sehe ich nicht immer. Im zweiten Link, den pharao gepostet hat sind ja eventuelle konkrete Lösungsansätze beschrieben, ich möchte aber eigentlich nicht auf geratewohl irgendwelche Lösungen ausprobieren, sondern lieber das Problem - wenn möglich - weiter eingrenzen. Hat noch jemand Ideen?

@ Sunny61: Entschuldige, ich dachte die Screenshots sind vielleicht übersichtlicher und verdeutlichen den Kontext noch etwas. Naja, hier sind die Logs dann nochmal Protokollname: System Quelle: TermDD Datum: 08.09.2015 10:34:27 Ereignis-ID: 56 Aufgabenkategorie:Keine Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: xyz Beschreibung: Von der Terminalserver-Sicherheitsschicht wurde ein Fehler im Protokollablauf erkannt, und die Clientverbindung wurde getrennt. Client-IP: 10.200.164.113. Ereignis-XML: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="TermDD" /> <EventID Qualifiers="49162">56</EventID> <Level>2</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2015-09-08T08:34:27.484538000Z" /> <EventRecordID>740783</EventRecordID> <Channel>System</Channel> <Computer>xyz</Computer> <Security /> </System> <EventData> <Data>\Device\Termdd</Data> <Data>10.200.164.113</Data> <Binary>0000040002002C000000000038000AC00000000038000AC00000000000000000000000000000000032000AD0</Binary> </EventData> </Event> Protokollname: System Quelle: TermDD Datum: 04.09.2015 12:11:29 Ereignis-ID: 50 Aufgabenkategorie:Keine Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: xyz Beschreibung: Die RDP-Protokollkomponente X.224 hat einen Fehler im Protokollablauf festgestellt und die Clientverbindung getrennt. Ereignis-XML: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="TermDD" /> <EventID Qualifiers="49162">50</EventID> <Level>2</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2015-09-04T10:11:29.693338700Z" /> <EventRecordID>737410</EventRecordID> <Channel>System</Channel> <Computer>xyz</Computer> <Security /> </System> <EventData> <Data>\Device\Termdd</Data> <Data>X.224</Data> <Binary>0001240002004C000000000032000AC00000000032000AC000000000000000000000000000000000270000000300002002F08064000A03EB701212001700F303EA0301000001040024000000</Binary> </EventData> </Event> @ pharao: Vielen Dank für den Hinweis, werde mir das Morgen durchlesen!

Hallo, Zum ersten beschriebenen Fehler werden in der Ereignisanzeige des clients keine Fehler protokolliert, auf dem Server habe ich folgendes verdächtiges gefunden: Das würde ja ganz gut zum ersten Fehler passen, oder? Ich habe dann mal mit der betreffenden Person hinter dem Client telefoniert, und diese Person hat mir bestätigt, dass es immer wieder zu diesen Verbindungsabbrüchen kommt. Dies kann allerdings auch schon mal nach 10. Minuten stattfinden, oder eben auch mal nach 30. Minuten...ist wohl ganz unterschiedlich. Ich hier an meinem Standort kann es auch reproduzieren, jedoch erst nach mindestens 30 Minuten Leerlauf... Unter Anwendung habe ich dies hier gefunden: Das wiederrum würde wahrscheinlich ganz gut zum 2. Fehler passen, oder?

Hallo liebe Community, ich habe mich soeben neu hier im Forum angemeldet, da ich über die Suchfunktion nichts passendes gefunden habe, und ich auch sonst leider keine Antwort auf eine Frage erhalte: Folgende Situation/Fragen: Ich verbinde mch mit einem Windows 7 client über eine RDP Verbindung zu einem Windows Server 2008 R2. Mit mstsc.exe übergebe ich im zugehörigen RDP-File mit "alternate shell" einen Programmpfad, da innerhalb dieser Remote-Verbindung nur das eine Programm laufen soll und auch sichtbar sein soll. remoteapplicationprogram, remoteapplicationname und remoteappicationcmdline sind ebenfalls gesetzt. Dieses Programm läuft dann als RemoteApp. Das Problem ist, dass die Verbindung zum Server nun mit verschiedenen Fehlerbildern abbricht. Es gibt z.B. die Situation, dass die Verbindung nach ca 30 Minuten Leerlauf einfriert, und die Sitzung dann nach 20-30 Sekunden komplett geschlossen wird, obwohl die Konfiguration auf dem Server dies eigentlich ausschließt. Energieoptionen und Bildschirmschoner o.ä ist sind auch deaktiviert. Verwendetes RDP ist 7.1. Weiss hier jemand Rat? Darüber hinaus kann man auch den im Anhang genannten Fehler provozieren, wenn man innerhalb des laufenden Programms eine bestimmten Arbeitsschritt durchläuft. Da sich der Fehler wirklich an einer bestimmten Stelle im Programm reproduzieren lässt (nur komischerweise nicht immer) vermute ich mal, dass irgendein Fehler innerhalb des Programms dieses selbst zum Absturz bringt, und da nun eben das Programm nicht mehr läuft, entsteht ein Protokollfehler (da das Programm, dass in der alternate shell eben übergeben wurde, abgestürzt ist). Ist das richtig? Hoffentlich ist alles verständlich, ich kenne mich in der Marterie nämlich bisher so gut wie garnicht aus. Vielen Dank im Voraus und Grüße!