Die zu einem IT-Asset verfügbaren Shares in der Datenbank persistent (quasi als Sub-Asset) vorhalten, somit könnte im Rahmen einer Dokumentation auch ein "fehlender" Share (und somit ggf. eine ungewollte Änderung der Systemlandschaft) erkannt werden. Wir haben dies derzeit in einem Customizing zu Testzwecken gelöst, es wäre schön, wenn dies eine Aufnahme in den Standard finden würde.
ja, das geht in Richtung CMDB. DocuSnap "vergisst" ja die zu einem System vorhandenen Shares bzw. nach einer gewisen vorhaltezeit und man kann dann im nachgang ggf. nicht mehr feststellen welche Shares bzw. Dienste auf einem System aktiv sind. Wird durch ein Applikationsupdate oder durch eine versehentliche Änderung ein Share oder ein Dienst gelöscht und das erst zu spät festgestellt sind dise Informationen nicht mehr verfügbar. Durch mein "Applikations-Customizing" entstand die Notwendigkeit eben diese Informatinen vorhalten zu können um hier im Fehlerfalls schnell nachvollziehen zu können ob alle Dienste und Shares noch vorhanden und aktiv sind. Das ganze habe ich dann noch um die Pfade zu den Binaries der Services bzw. die Namen der Shares erweitert und erhalte somit ein (für meine Bedürfnisse) vollständiges Abbild einer Applikation. Gelöst ist dsa mit einer Handvoll Hilfstabellen und Trigger, hier sind ja die Windows- und Linux-Systeme getrennzu zu betrachten, die Linux-Systeme bringen ja auch drei verschiendene Arten von "Diensten" (hier richtigerweise Dämonen) mit. Innerhalb des "Applikations-Customizings" kann ich dann bei den entsprechenden Shares und Diensten einfach "abhaken" was benötigt wird, mittels Trigger auf der dahinterliegenden Hilfstabelle kopiere ich dann die vollständigen Informationen über Share bzw. Dienst in eine weitere Tabelle und persistiere diese Informationen. Durch einen "Report" kann ich dann die Aktualität nachvollziehen und bekomme Änderungen binnen 24 Stunden automatisiert mitgeteilt.
Hier ein Screenshot zur Verdeutlichung: