Ich denke das Problem zum nächsten Update gelöst zu haben - Falls dies also jemand der betroffen war noch einmal probieren kann, wäre dies sehr cool!
paresy
Aus Sicht eines Systemadministrators ist die Variante die Daten im Programm-Ordner abzulegen grundsätzlich falsch und problematisch. Für den Einzelplatz mit Imagesicherung wahrscheinlich OK, aber dennoch nicht richtig. Für Netzwerksysteme ist es völlig falsch. Da gehören Benutzer-Daten in keiner Form auf das Systemlaufwerk.
Das Programm selbst gehört nach Microsoft Empfehlungen in den Ordner „ProgramFiles“ (liegt nach der Migration immer noch auf meinem Netzlaufwerk). Die vom User erzeugten Daten gehören entweder in den User Ordner oder bei Netzwerksystem in eine Freigabe. Im ProgramData Ordner gehören nur die Einstellungen zu dem Programm, also z.B. die Einstellungsdateien in denen z.B. steht, wo das Programm seine Daten zu finden hat.
Daten die Nutzer anlegen gehören nie in den ProgramData-Ordner, das ist definitiv von Microsoft so nicht gewollt.
Vorher war das sicherlich auch nicht korrekt, dass die Daten und das Programm in einem Ordner liegen müssen, jetzt ist es aber definitiv noch schlimmer. Aus administrativer Sicht chaotisch.
Normalerweise müsste der Installer bei der Installation abfragen wo man das Programm installieren möchte und wo man die Daten ablegen möchte. Diese Information würde dann im ProgramData-Ordner abgelegt werden.
Ich wäre sehr verbunden, wenn das noch mal überdacht werden würde, weil ich eigentlich auf meinem 2019er Server keine Daten im Systemlaufwerk haben möchte.
So sehe ich das auch, vielleicht wird ja noch mal über den Ort der Daten nachgedacht bevor die 5.3 als final Release erscheint. Für mich persönlich macht das so in der jetzigen Form bei der 5.3 keinen Sinn.
+1
Das sind auch keiner (Windows)Benutzer Daten. Diese würden ja in den Roming oder Local gehören.
Es sind Programdaten, welche keinem (Windows)User zugeordnet sind.
Korrekt, da landet es auch. Bei einer neuen Installation.
Es handelt sich hier aber nicht um Daten welche einem ‚Windows‘-User gehören.
Symcon ist ein Systemdienst.
Definition MS:
Das Verzeichnis, das als allgemeines Repository für programmspezifische Daten verwendet wird, die von allen Benutzern verwendet werden.
Also alles korrekt.
Für Windows-Benutzer auf jeden Fall korrekt. Aber Symcon wird ja von keinen (Windows)User benutzt. Es ist noch immer ein reiner Dienst.
MS gibt den Entwicklern die passenden Werkzeuge um die Daten in den korrekten Bereichen abzulegen.
Das MSDN gibt Auskunft darüber.
Und hier ist das ‚CommonApplicationData‘ zu benutzen. Da der Dienst nur auf dieser Maschine, ohne Benutzerkontex läuft.
Michael
Moin,
was ich persönlich sehr störend finde und das damals auch bereits kundgetan habe ist dies
Ich habe jetzt alles umgestellt und es kann passieren, dass man eventuell alles neu installieren muss. Da man dann ja eine außergewöhnliche Situation hat muss man auch noch alles checken, da nun die Verzeichnisse andere sind :mad:
Das halte ich auf keinen Fall für zu Ende gedacht auch wenn es ja „nur“ das Programmverzeichnis ist was sich ändert 
Ich würde lieber jetzt alles neu installieren (auf dem Entwicklungssystem) und dann später das Produktivsystem nachziehen. Wo bekomme ich denn die Basis für die Neuinstallation her?
Gruß
Hans
Das ist ja nicht ganz richtig. Jegliche Änderungen im Programm, wie ein hinzugefügtes Modul, welches dann an meine Hardware angepasst wurde, oder ein Skript um eine Lampengruppe zu schalten, landen in ProgramData und entzieht sich damit der Sichtbarkeit. Dies sind dann persönlich erzeugte Daten die irgendwo auf einem System liegen.
Auf einem Serversystem gehört sowas einfach dort nicht hin. Das sind dynamische Daten, die werden von Usern erzeugt und nicht vom Dienst als solches.
Dies hier ist jedenfalls für mich ein sehr bedenklicher Rückschritt. Es werden Daten in einem für normale User nicht sichtbaren Bereich gespeichert und auf eine integrierte Backupfunktion wird hier verzichtet (wäre supereinfach mit IPS selbst machbar). Zudem gibt es in der Anleitung bisher keine korrekte Anleitung zur Backuperstellung.
Hat man den ProgramData Ordner aktuell nicht gesicht und nur den in der Anleitung erwähnten IPS-Ordner, hat man halt nix mehr.
Hallo Dirk,
hast du irgendwo einen MSDN Link wo deine bevorzugte Variante erklärt wird? Wir nutzen aktuell den Pfad der hinter CSIDL_COMMON_APPDATA steckt. Dieser ist eben genau dafür gemacht, dass Programme die für alle Nutzer sind (hier eben der Systemdienst) ihre Daten speichern können. Ich bin auch der Meinung, dass es keine offiziell von Microsoft kommunizierte andere Lösung gibt. Falls doch - immer her damit. Noch können wir ja etwas ändern!
Die Dokumentation werden wir vor Release natürlich noch anpassen. Wir sind ja gerade erst in die öffentliche Beta-Phase gestartet.
paresy
Ich kann mit keinem Link dienen. Ich bin auch kein Programmierer.
Ich bin ausgebildeter Datenverarbeitungskaufmann mit regelmäßiger MCSE Schulung und Prüfung und arbeite nun seit 24 Jahren als Systemadministrator in der Dental-Branche. In den ersten Jahren in einer sehr großen Softwarefirma im Support und seit 19 Jahren als Administrator für einige 100 Zahnarztpraxen.
Ich installiere täglich Client-Server Programme in Netzwerkumgebungen. Dort gibt es nicht ein Programm, welches bei der Installation nicht fragt wo die vom User erzeugten Daten abgelegt werden sollen. Dabei spielt der Windows-User keine Rolle, weil der kann sich auf einem Server eh nicht anmelden. Aber die Netzwerknutzer können das. Und das sind die im IPS-Fall die Geräte, wie der AVR, die CCU etc. Die ändern Einträge/Variablen und das sind Daten, die von einem User angelegt worden. Die gehören doch nicht in ein Verzeichnis wo Einstellungen hinterlegt werden.
In Wikipedia steht „Contains program data that are expected to be accessed by computer programs regardless of the user account in the context of which they run. For example, an program may store specific information needed to operate DVD recorders or image scanners connected to a computer, because all users use them.“
Hier hebe ich noch mal „store specific information NEEDED to OPERATE“ hervor. Da steht nichts von Userdaten.
Wenn da auch die vom User erzeugten Daten rein sollten, würde das gegen die von Microsoft favorisierte Strategie bei einem Server widersprechen. Ich werde das bei der nächsten Serverschulung Microsoft explizit fragen, wie das so gedacht ist und wo man das nachlesen kann. Weil denen rollen sich schon immer die Nackenhaare hoch, wenn ich denen erzähle, dass die hiesigen Softwarehersteller einen SQL Server mit Instanz einfach auf C installieren. Aber die erstellen dann wenigstens Automatisch ein Backup in einem bei der Installation anzugebenden Ordner. Ich denke für die 5.3 wird die Nachfrage das zu spät sein, weil für die Zertifizierungen für den 2019er Server sind durch.
Wahrscheinlich ist es bis zur 5.3 Final nicht geplant, dass der User die Hoheit über den Speicherort seiner Daten zurück erhält, oder?
Aktuell wird dies so bleiben. Wir werden in der Zukunft jedoch beim Installer eine Option anbieten, sodass man einen eigenen Data Order auswählen kann. (Für „Profis“ dann auch entsprechend in der Registry änderbar). Dies schafft es nicht mehr in die 5.3.
paresy
Habe eben auch auf 5.3 migriert und muss mich leider den Punkten unten voll anschließen!
Hinzu kommt bei mir noch, dass ich die Logs, Module und Skripte per Cloudstation Drive auf alle meine PCs egspiegelt habe, um sie eben an allen PCs modifizieren zu können und NICHT mich jedes mal remote auf den IPS Server loggen zu müssen.
Das geht jetzt nicht mehr, da der ProgramData Ordner von der Synchronisation ausgeschlossen ist und definitiv NICHT dafür verwendet werden soll.
Skripte, Module und Logs sind für mich User spezifische Daten und keine Program-Daten, da ich sie nach belieben anpassen kann und muss.
Bitte die aktuelle Lösung überdenken!
Hinzukommt, dass das Update auch nicht direkt ging, da ich erst alle Diskstation Verknüpfungen löschen musste, damit die Ordner migriert werden konnten.
Alles leider etwas „unglücklich“.
Gruß
Maze
+1
Hi Maze,
wie schon vorher erklärt sind die Daten von IP-Symcon System-Dienst keine dem Nutzer zugeordneten Daten, sondern Daten die für „Alle Benutzer“ gelten. Tipp: C:\Users\All Users\Anwedungsdaten zeigt übrigens auf C:\ProgramData.
Das geht jetzt nicht mehr, da der ProgramData Ordner von der Synchronisation ausgeschlossen ist und definitiv NICHT dafür verwendet werden soll.
Aktuell unterstützt die MSDN von Microsoft diese Theorie nicht. Systemdienste die zu „All Users“ gehören, legen Ihre Daten in ProgramData ab - so wie wir es ab der 5.3 ebenfalls tun. Ich vermute eher, dass die Cloudstation Drive keine Daten von System-Diensten spiegelt/spiegeln kann. Warum das so ist müsstest du bei Synology nachfragen. Idee: Verlinkte doch explizit auf C:\ProgramData\Symcon irgendwo in einem von dir gebackup’ten Ordner. Dann ist es wieder mit dabei.
paresy
Hallo Paresy,
danke für die Rückmeldung. Die Idee klang erstmal nicht schlecht,
aber leider bearbeitet Synology auch Links nicht.
Ich habe folgende Einschränkungen gefunden:
Somit muss ich mir irgendwas neues einfallen lassen, da meine bisherige Arbeitsweise mit der Umstellung auf 5.3 nicht mehr funktioniert.
Auch das Backup der Datenbank (DB) funktioniert nicht mehr automatisch 
Gruß
Maze
Durch die Änderung ist bei mir auch einiges kaputt gegangen. Schade, es gibt so oft diese Fälle wo zwar technisch ganz toll schlüssig begründet werden kann warum das unbedingt geändert werden musste, aber für den User ist es letztlich nur nervig und hat keine spürbaren Vorteile. Das ist auch der Grund, warum User (ich eingeschlossen) Updates gern auf unbestimmte Zeit vor sich herschieben… wodurch sich solche breaking changes dann noch weiter akkumulieren. 
Hast du Details? Solange du Pfade nicht hart gecoded hast sondern die IPS_GetKernelDir Funktionen genutzt hast ist diese Migration sehr simpel.
paresy
Ich habe vor allem externe Skripte, die von dem Pfad ausgehen… und klar ist das alles streng genommen meine eigene Schuld, weil ich Dinge nicht 100% by the book gemacht habe. Wer noch nie was hadcoded hat, werfe den ersten Stein :o
Ich melde das Erlebnis bloß mal zurück weil man es glaube ich oft unterschätzt als Developer, der immer voll in der Materie steckt und dem so ein Schritt vollkommen logisch und sinnvoll und längst überfällig erscheint, wie sich der Effekt für den Kunden darstellt, der vielleicht alle paar Monate überhaupt mal seine Skripte anfasst: Letztlich eine nervige Schikane, die einem gewachsenen, aber bislang funktionsfähigen System gefühlt ohne Mehrwert einen Stock in die Speichen wirft.
Die Policy von IPS, immer mal wieder tiefgreifende Anpassungen des Usercodes selbst bei Minor-Versionssprüngen zu erfordern, ist mir für eine Middleware, mit der häufig eher unerfahrene Programmierer zum Teil relativ essenzielle Funktionalität in realen Gebäuden implementieren einfach zu rabiat. Das verleitet mich jedenfalls dazu, Updates viel zu oft einfach ewig aufzuschieben.
Still, 
Ich weiß, dass unserer „Upgrade“ Policy gerne mehr Aufwand bedeutet. Wir machen diese Änderungen jedoch nicht leichtfertig und wie du schon sagst war diese Änderung schon sehr lange überfällig. Insbesondere die Migration zwischen den Betriebssystemen wird nach diesem Wechsel für alle wesentlich leichter. Wenn du dein System jetzt anpasst, kannst du mit sehr wenig Aufwand auf z.B. Linux/Docker wechseln.
paresy
Oh ha, bei mir lief nach dem Update gerade gar nichts mehr, außer massenweise diese Fehler :eek:
29.11.2019, 12:05:53 | ScriptEngine | Result for Event 18865
<br />
<b>Warning</b>: require_once(C:\IP-Symcon\scriptsh04.ips.php): failed to open stream: No such file or directory in <b>C:\ProgramData\Symcon\scripts\__autoload.php</b> on line <b>3</b><br />
<br />
<b>Fatal error</b>: require_once(): Failed opening required 'C:\IP-Symcon\scriptsh04.ips.php' (include_path='.;C:\php\pear') in <b>C:\ProgramData\Symcon\scripts\__autoload.php</b> on line <b>3</b><br />
Ich habe das erst mal auf absoluten Pfad umgestellt, damit das System wieder läuft.
Keine Ahnung, warum das mit IPS_GetKernelDir() nicht läuft. Ich weiß auch nicht, wie er auf „scriptssh04.ips.php“ kommt. Das gibt es nicht und das stand auch nirgends in der __autoload. 
Hallo.
Ist den jetzt angedacht bei der nächsten Generation von IP Symcon auch den Daten Ordner vom User auswählen zu lassen?
So kann doch der User entscheiden wo er sein IP Symcon installiert haben will und wo die Daten zu speichern sind.
Ich finde es sowieso besser wenn der User viele Möglichkeiten zum ändern hat.
Danke.
BYE
Thomas