In vielen Umgebungen gibt es Standorte mit wenigen Clients. Oftmals werden dort keine eigenen DSM Server eingesetzt. Die vorhandenen Clients sollen aber mit Software versorgt werden. Wenn die WAN Verbindung nicht die allerbeste ist, kann es bei größeren Paketen schnell zu Problemen kommen, da jeder Client seine Massendaten einzeln über die Leitung beziehen muss. Wenn z.B. auch Citrix und VOIP die WAN Verbindung nutzen und priorisiert sind, kann sich so eine Installation unnötig in die Länge ziehen, und die Leitung stark belasten. Hierfür bieten sich NAS-Boxen als eigene Depots an.

Der Vorteil ist, dass die Massendaten nur noch einmal übertragen werden müssen. Die Clients bedienen sich dann von der vor Ort stehenden Quelle. Eine NAS-Box benötigt auch wenig Platz und Strom. Eine eigene Windows Server Lizenz wird dadurch auch eingespart.

Aber auch NAS Boxen haben Ihre Nachteile. Der größte dürfte sein, dass diese keine Dienste zur Verfügung stellen können. Somit benötigt man einen entfernten Distributionsdienst, der im Push Verfahren die Massendaten auf die NAS-Box befördert. Jedoch hat NetInstall bzw. DSM schon immer ein Work und ein Install Verzeichnis mit Massendaten, die bei der Distribution berücksichtigt werden müssen. Somit wäre es rein theoretisch nötig, beide Verzeichnisse über die WAN-Leitung zu übertragen, da es keinen lokalen Distributionsdienst gibt.

Da in diesen Standorten jedoch ausschließlich Softwareverteilung genutzt werden soll, benötigt man nur das Install Verzeichnis. Mit einem kleinen Trick, kann man dafür sorgen, dass auf das Depot auch nur das Install Verzeichnis distribuiert wird.

Für den Standort wird eine eigene Site benötigt. Jede Site benötigt auch immer ein Depot. Für die Grundkonfiguration kann man ein bestehendes Depot angeben. Entweder das Org-Master Depot, oder ein Depot mit der für den Standort günstigsten Anbindung. Wichtig ist hier die Pollingintervalle für dieses bereits verwendete Depot zu deaktivieren!

Und jetzt kommt unsere NAS Box ins Spiel. Hierbei ist ein hoher Durchsatz wichtig, um eine möglichst gute Performance zu erreichen. Wichtig ist natürlich auch eine AD-Integration für die NTFS-Berechtigungen. Gute Erfahrungen habe ich mit Qnap und Synology gemacht. Die NAS-Box wird über ein Webinterface konfiguriert. Beim Anlegen des Shares kann man diesen auch verstecken. Da als Betriebssystem jedoch immer Linux verwendet wird, ist kein „$“-Zeichen zum verstecken des Shares möglich. Der Share wird also mit \\%CurrentServer%\dsm angesprochen, und ist trotzdem versteckt. Auf der neuen Site wird jetzt ein zusätzliches Depot angelegt und die NAS-Box angegeben. Da es das zweite Depot dieser Site ist, wird dieses als reines Verteildepot eingerichtet. Dadurch gibt es nur noch die Install-Replikation. Sie werden danach auch kein Work-Verzeichnis auf diesem Depot finden. Somit spart man sich die für diesen Fall unnötige Work-Replikation.

Damit aber auch alle Clients an diesem Standort auf die NAS-Box zugreifen, muss der Zugriff auf das Master-Depot der Site verhindert werden. Ansonsten würden sich die Clients die Daten auch wieder über die WAN-Verbindung holen. Dazu gibt es in der ICDB (Infrastruktur) auf der Ebene der zwei Depots unterhalb der neuen Site den Punkt „Depot-Eigenschaften\Lastverteilungsfaktor für dieses Depot“. Auf dem ersten Depot, welches es bereits gibt, trägt man eine „0“ ein. Auf dem Depot der NAS-Box trägt man eine „100“ ein. Somit wird der Zugriff für Clients nur noch auf das Verteildepot zugelassen. Hier sollten auch die Pollingintervalle etwas höher gesetzt werden, wenn das Master Depot mehrfach verwendet wird. Dadurch wird der entfernte Distributionsdienst geschont.

Und schon kann die NAS-Box für kleinere Standorte mit einer optimierten Distribution eingesetzt werden.