Wer sich schon einmal in DSM mit Installationsparametern beschäftigt hat, wird diese sicherlich sehr zu schätzen wissen und regelmäßig verwenden. Es gibt eine zugegebenermaßen etwas unbekannte aber dennoch nette Möglichkeit Abhängigkeiten von Installationsparametern zu definieren. FrontRange verwendet diese z.B. auch bei den PrePackaged Apps für Citrix XenApp. Wenn hier bei der Zuweisung der Wert „Neue Citrix Farm anlegen“ bei „Citrix Farm Selection“  gewählt wird, erscheint ein vorher nicht sichtbarer Installationsparameter. Dieser würde bei einem Farm Join auch keinen Sinn machen. Diese Abhängigkeiten können über die Konsole (stand Heute) nicht definiert werden. Mit ein klein wenig Fleißarbeit ist dies aber relativ leicht realisierbar.

Die UMTS Karten in HP Laptops (mein aktuelles Beispiel ist ein HP Elitebook 2540p mit einer Qualcomm un2420 Karte) haben einige Besonderheiten, die die Integration in DSM besonders erschweren.

• Das "unbekannte Gerät" im Gerätemanager hat eine andere Hardware-Id als das Gerät nach der manuellen Installation des Treibers. Dadurch kann nicht einfach der Treiber via DSM vom Gerät abegzogen werden, da dann im DSM Paket andere Hardware-Ids referenziert sind, als das "unknown device" auf einem frisch installierten Win7 Client hat.
• Das Gerät ist während der Installation eines Laptop ggfs. ausgeschaltet (Hardware-Schalter).
• Das Treiberpaket liegt nur als MSI File vor. Dieses MSI Setup lässt sich aber nur installieren, wenn das Gerät eingeschaltet ist.

Nun kann aber wie folgt vorgegangen werden, um dieses Device trotzdem sauber einzubinden:

Kürzlich hatte ich bei einem Kunden zwei Probleme:

Eins war schon unter DSM 7 RTM vorhanden, nämlich dass einige Admins beim Versuch mit der DSMC zu arbeiten, diesen unbekannten SOAP-Fehler #607 erhielten. Bei anderen Admins lief aber alles problemslos und wir konnten uns keinen wirklichen Reim auf das Verhalten machen.

Nachdem wir dann kürzlich auf DSM 7 Service Pack 2 aktualisiert hatten (und dabei auch gleich die PowerShell Extensions auf den aktuellen Release upgegradet haben), liefen auch einige Funktionen der PSX nicht mehr. Es wurde schon auf einen Bug in den PSX getippt, aber ein kurzer Test zeigte, dass die entsprechenden Funktionen in meiner Testumgebung problemlos funktionierten. Erstaunlicherweise konnte der Kunde die gleiche Funktion, die bei ihm über PSX Probleme machte und einen Fehler zurücklieferte, über die DSMC problemlos ausführen.

Mein Entwickler-Kollege kam dem Problem dann auf die Spur...

Um die Client-Server Kommunikation zu verschlüsseln, gibt es die Möglichkeit, die DSM Webservices (Client Webservice / Admin Webservice) über HTTPs laufen zu lassen.

Um die HTTP/HTTPs Funktionalität nutzen zu können, benötigen Sie zwingend die „DMZ Management Pack“ Lizenz.

Zusätzlich wird ein SSL Zertifikat benötigt. Dieses können Sie durch eine eigene CA erstellen lassen oder von einer der bekannten Zertifizierungsstellen kaufen.

In NetInstall 5.x war es durchaus üblich, eine Site zu definieren die immer am Ende der Infrastruktur stand (z.B. durch den Namen zzAusfallsite) und diese mit einer * - Definition zu versehen. Dadurch konnten alle Clients, die sich keiner Site zuordnen können, die aktuelle NCP vom Orgmaster holen. Speziell bei grösseren Umstrukturierungsmassnahmen war man auf diesem Wege immer sicher, dass die Clients bei einem versehentlichen Ausschluss immer wieder eine neue NCP ziehen konnten und somit zurück in die Sitestruktur fanden.

Nach dem Dokument zur Paket-Anforderung und den Paketierungschecklisten folgt nun das dritte Dokument in der Reihe der Packaging.Docs: Das Package Approval. Nachdem das die Applikation nun fertig für die Freigabe ist, muss eine inhaltliche Prüfung des Dokumentes erfolgen. Der Paketierer kann allzu häufig leider nicht sagen, ob die Anwendung jetzt korrekt paketiert ist oder nicht. Aus diesem Grund wird das Paket nun die Prozedur der Fachabnahme überführt. Diese Fachabnahme kann durch völlig verschiedene Personen erfolgen. Das kann der Endanwender sein der die Anwendung letztendlich nutzen soll, oder es kann sich um den Entwickler der Anwendung (oder einer abhängigen Anwendung) handeln, oder den IT-Verantwortlichen der Anwendung. Bei sehr grossen Projekten (SAP GUI) kann die Rolle der Fachabnahme auch auf mehrere Personen verteilt sein. Bei all diesen Personen ist das subjekte Empfinden über die Aussage "die Anwendung funktioniert" sicherlich völlig unterschiedlich. Abhilfe soll hier das Package Approval Document schaffen.

Es werden alle wichtigen Daten über die Anwendung abgefragt und darüber sichergestellt, dass die Testperson in einer Umgebung arbeitet, die dem tatsächlichen Einsatzort bestmöglich nachempfunden ist. Wie auch schon zuvor, wurde darauf geachtet, das eine weniger technisch versierte Person den WOrtlaut des Dokumentes versteht und in der Lage ist, ein Maximum der Informationen zu hinterlegen. Letztendlich wird über dieses Dokument am Schluss die Abnahme erteilt, worauf die Anwendung nun in den Rollout übergeben werden kann.

Als Viewer empfehle ich einen alternativen freien PDF Reader, da der Adobe Reader nicht in der Lage ist, ein PDF Formular inklusive seiner Formularinhalte zu speichern (Adobe setzt hier die Nutzung der kostenpflichtigen Vollversion voraus). Persönlich habe ich sehr gute Erfahrungen mit dem Foxit Reader gemacht.
Änderungswünsche, Positive Kritik aber auch Auswirkungen beim Einsatz dieser Liste sind mir immer als Anhang an diesem Blogeintrag oder als Mail sehr willkommen. Neuere Versionen werden ebenfalls in Rahmen dieses Blogeintrags veröffentlicht.

Die Liste als PDF kann im Donwload-Bereich unter PDF-Pool -> Services -> Paketabnahme heruntergeladen werden. Eine Anmeldung ist notwendig.

In speziellen Situationen kann es vorkommen, dass der Stand des Metadatencaches auf den Clients nicht mehr zu dem Stand der Informationen in der DSM Datenbank passt (z.B. beim Reciver eines Backups). Um dieses Problem zu lösen, müssen 2 Dinge durchgeführt werden:

1. Die CMDB-Guid in der Tabelle CMSY_LOCALCONFIG in der Datenbank wird verändert.
2. Ab diesem Schritt kann kein Client mehr mit der DB syncen. Um dann die Clients zu zwingen, Ihren Cache zu erneuern, wird der folgende Registrykey Clientseitig eingetragen:

HKEY_LOCAL_MACHINE\SOFTWARE\NetSupport\NetInstall\CMDBCache

CacheReset [DWORD] = 1

Der Wert wird nach dem Beenden und erneuten Starten des Core Dienstes automatisch wieder auf „0“ gesetzt. Die Schwierigkeit ist natürlich, diesen Registrykey bei einer deaktivierten Softwareverteilung auf die Clients zu bringen. Da ein Logon Script aufgrund fehlender Berechtigungen ausfällt, empfehle ich den Einsatz einer Startup GPO.

Ab und wann entsteht mal die Situation, dass die NCP Dateien der NI/enteo/DSM Infrastruktur auf allen Clients aktualisiert werden muss. Dieser Fall kann beispielsweise durch eine falsche Konfigurationseinstellung, falsch konfigurierte Virenscanner, Festplatten-/ Verschluesselung oder Komprimierung entstehen.

Wie viele andere meiner Kunden, würde auch ich gerne die DSM Eigenschaft "CurrentComputer.Computer.ComuterType" dafür nutzen, verschiedene Zuweisungen (wie z.B. VPN Client) zu steuern. Leider gibt es mit dieser Eigenschaft verschiedene Probleme, die eine sinnvolle Nutzung verhindern:

• Einmal gesetzte Computertypen werden i.d.R. nicht wieder verändert.
• Nicht alle virtualisierten Systeme werden als solche erkannt.
• Blades & Server werden zumeist gar nicht als solche erkannt.
• Ein Server kann auch gleichzeitig ein virtuelles System sein.
  
  

Mit DSM 7 haben auch die ODS Variablen Ihren Einstand gefeiert. Diese sind, im Gegensatz zu den benutzerdefinierten Variablen, nicht mehr siteabhängig, sondern hängen direkt am Client, egal wo dieser sich befindet.

Ein Vorteil gegenüber einer Schemaerweiterung ist die Vererbung. Ein gesetzter Wert wird von jeder Ebene aus nach unten weiter vererbt. Diesen Vorteil kann man sich beim JoinDomain zu Nutze machen.

Da Clients z.B. je nach Standort oder Typ im AD in unterschiedlichen OU´s verwaltet werden, benötigt man auch in der unattend.xml unterschiedliche LDAP Pfade.