Administratoren kennen das Problem: Roaming Profiles sind in der Größe begrenzt und die Startdauer des Systems hängt stark davon ab, wieviele Dateien sich darin befinden und wie hoch die Pingzeit ist. Viele kleine Dateien erhöhen bei hoher Pingzeit das Laden des Profils erheblich, während gleichzeitig die Profilgrenze regelmäßig von verschiedenen Applikationen gesprengt wird.

Schon immer gibt es daher die Möglichkeit, über Gruppenrichtlinien einzelne Verzeichnisse vom Roaming auszuschließen. Das Problem: Es ist nicht transparent, wo eine Applikation was für Verzeichnisse ablegt und wozu sie dienen. Das "Wo" und "Was" kann ein Paketierer noch herausfinden (was aber mit zusätzlichem Aufwand verbunden ist und daher kaum jemand tut) aber über das "Wozu" kann meistens nicht einmal der Fachanwender etwas sagen.

Und damit ist häufig der Grundstein für ein Problem gelegt, das erst viel später zum Tragen kommt und den Anwender - wenn er sich mal wieder nicht abmelden kann, da der Profilspeicherplatz überschritten wurde und das ProQuota-Tool von Microsoft noch immer keine Hilfe bei der Lösung des Problems ist, oder das Anmelden auch mal zehn Minuten dauert - an der Idee eines Roaming-Profiles zweifeln lässt. Dabei kann die Technologie nichts dafür. Sie hat sogar deutliche Vorteile:

• Daten aus dem Profil unterliegen dadurch einer automatischen Datensicherung, da sie beim Abmelden auf den Server kopiert werden.
• Bei der Anmeldung an einem anderen Computer erhält der Anwender die gleichen Daten und Einstellungen und kann wie gewohnt arbeiten.

Dennoch: Das Grundproblem bleibt.

Dabei ist die Lösung so einfach: Entwickler von Applikationen müssen die Verantwortung für ihre Software übernehmen. Nur der Softwareentwickler weiß, welche Verzeichnisse seine Anwendung anlegt, was für Dateien er darin ablegt und nach welchen Kriterien entschieden werden kann, ob diese im Roaming-Profile aufgenommen werden sollen oder nicht. Und nicht nur das. Er hat auch die Möglichkeit, seiner Anwendung die Information mitzugeben, ob ein Verzeichnis nur im lokalen Teil des Profils abgelegt werden soll oder in dem, der serverseitig gespeichert wird:

[ComVisibleAttribute(true)]
public enum SpecialFolder 

ApplicationData
The directory that serves as a common repository for application-specific data for the current roaming user.
A roaming user works on more than one computer on a network. A roaming user's profile is kept on a server on the network and is loaded onto a system when the user logs on.
 
LocalApplicationData
The directory that serves as a common repository for application-specific data that is used by the current, non-roaming user.  

Schauen wir uns nun ein konkretes Beispiel an, wie vielleicht schon bald dieses Thema gelöst sein könnte:

Dave hat soeben die Entwicklung eines neuen, quantenbasierten Funktionsplotters abgeschlossen. Während man bei entsprechend komplexen Formeln anderen Produkten bei ihrer Arbeit zuschauen kann, arbeitet QuantumPlot Zero® in annähernder Nullzeit. Für ein hohes Maß an Komfort hat Dave auch gesorgt: QuantumPlot Zero® speichert eine Historie aller genutzten Funktionen, hochauflösende RD (Reality Definition) Bilder in einer Auflösung von 21.504x18.432 und darüber hinaus auch Varianten der Funktion mit n-dimensionaler Abweichung (die es natürlich gleichzeitig berechnet hat). Während der Paketierung überlegt er sich, welche der Verzeichnisse, die seine Anwendung anlegt, Teil des Roaming-Profiles sein sollten und welche nicht.

History
Das Verzeichnis History enthält eine komprimierte Flatfile Database, die lediglich die Formeln beinhaltet. Kathy, die häufig zwischen den Arbeitsplatzrechnern wechselt, braucht die Historie, damit sie immer auf Ihre Funktionen zugreifen kann, egal wo sie sich anmeldet. Da das Verzeichnis nicht so viel Platz beansprucht, sollte es daher Teil des Roaming Profiles sein.

Dump
Im Verzeichnis Dump speichert QuantumPlot Zero® die RD Bilder aller Funktionen. Hier entsteht eine gigantische Menge an Daten, die für sich genommen auch noch recht groß sind. Im serverseitigen Profil sollten sie nicht aufgenommen werden; falls nötig können einzelne Bilder aus den Funktionen aus der History neu generiert werden

Dimensions
Die RD Bilder n-Dimensionaler Abweichungen einer Funktion müssen ebenfalls nicht serverseitig gespeichert werden. Mit der History sind alle Daten gesichert, aus denen bei Bedarf die Bilder neu generiert werden können.

Dave entwickelt daher mit InstallShield XX U-Premium folgenden Dialog:

Bob arbeitet als IT-Admin in einer Universität und hat verschiedene Tools zum Plotten von Funktionen evaluiert. Er ist dabei auf QuantumPlot Zero® gestoßen und ist begeistert. Als er noch Student war, hätte er sich gewünscht, so etwas zu haben. Jetzt muss er sich mit Studenten beschäftigen, die sich über zuwenig Profilspeicherplatz beschweren... die aber trotzdem überall den gleichen Desktop vorfinden wollen. Seit Nova-Usbekistan den Server-Speichermarkt an sich gerissen hat, sind die Festplattenpreise förmlich explodiert: Seit der Einführung der QuantumAPI von Microsoft geht zwar alles wesentlich schneller, aber wohin mit den Daten?

Doch in der Anleitung von QuantumPlot Zero® stößt er auf den Parameter QUOTADIRS und probiert ihn gleich aus.

"Genial! Warum macht das nicht jeder so?", grübelt Bob noch vor sich hin, während er bei der Konfiguration des Paketes angibt, dass nur das Verzeichnis History im Serverprofil gespeichert werden soll, Dump und Dimensions nicht.

In den Zeiten vor InnoSetup, InstallShield und Wise schrieb noch jeder seine eigenen Installationsroutinen. Die wenigstens haben sich intensive Gedanken darüber gemacht, wie die Software wieder sauber entfernt wird sondern mehr, wie sie auf die Systeme kommt. Zu der Zeit wurde der Markt von Tools überschwemmt, die den Zustand der Festplatte und der Registry vor einer Installation aufzeichneten, um diese Informationen zu einem späteren Zeitpunkt dazu zu nutzen, die Software wieder (mehr oder weniger gut) vollständig zu entfernen. Relikte dieser Technologien finden wir heutzutage nur noch in Installationssystemen wieder, die sie anbieten, um Software zu repaketieren.

Es hat zwar lange gedauert, aber heute halten sich (die meisten) Entwickler von Installationspaketen an Best Practices und nutzen die ihnen zur Verfügung gestellten Mittel, um saubere Pakete zu definieren, die ihre Anwendungen nicht nur installieren sondern auch restlos wieder entfernen. Es ist daher nicht unvorstellbar, dass in Zukunft ebenfalls ein (neuer) Standard in diesen Industriezweig Einzug hält, der es den Entwicklern von Softwarepaketen erlaubt, einfach Dialoge zur Steuerung der Roaming-Profiles zu implementieren (Hinweis: Das geht natürlich auch jetzt schon! Nur müssen die Dialoge selbst geschrieben werden...) und damit den Paketierern und Administratoren, selbige sinnvoller zu nutzen.

Für Anregungen, Kritik und Vorschläge kann gerne kommentiert werden. :)

InstallShield, Visionen installshield, roaming profile, standards, vision