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.

Oft bringen virtuelle Devices (wie z.B. Slysoft Clone Drive), manchmal aber auch grosse Hardwarehersteller einen Treiber mit, der so erst einmal nicht auf einem Windows 7 System installiert werden kann, da das verwendnete Zertifikat nicht bekannt ist. Um hier Abhilfe zu schaffen, kann dass im Treiber enthaltende Zertifikat in die lokalen Trusted Publisher eingetragen werden und anschliessend erst die Installation der eigentlich Software/Treiber gestarten werden. Um an das Zertifikat zu kommen und dieses silent auf das System zu bringen, sind folgende Schritte durchzuführen:

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.

Mit der Umstellung seiner Serverlandschaft auf aktuellere Betriebsysteme wie Windows Server 2008 R2 mit SQL Server 2008 R2 oder Austausch von Serverhardware steht man auch vor dem Umzug seiner Datenbanken. 

Anders als bei der DSMDB gibt es bei der Discovery Datenbank einige Punkte zu beachten um einen reibungslosen Umzug zu gewährleisten.

Der Folgende Artikel beschreibt die nötigen Schritte die beim Umzug der Discovery Datenbank beachtet werden müssen.

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.

Oft werden Pakete in die Paketierung gegeben, für die der Paketierer weder technisches noch fachliches KnowHow besitzt. Um die Paketierungszeit auf ein möglichstes zu verringern, wird speziell in grösseren Unternehmen eine fachlich verantwortliche Person definiert, die dafür zuständig ist, die Anwendung im Unternehmen zu betreuen (2nd/3th-Level Support).
Diese fachlich verantwortliche Personen sind Experten in dem Bereich der Anwendung. Sie kennen die grundsätzliche Konfiguration der Anwendungen, die verwendeten Backendserver und welche Unternehmensbezogenen Erweiterungen notwendig sind.

Mit DSM 7 besteht die Möglichkeit, seine Citrix Farm(en) komplett automatisiert zu betreiben.

Dazu gibt es das Modul „DSM Citrix Support“. Dieses Modul muss extra lizensiert werden.

Ich möchte heute das Publishen von Applikationen zeigen. Als Beispiel nehme ich mal die Software Ultra VNC. Diese wird erst mal als normales DSM Paket auf dem Server installiert. Jetzt geht es darum, einem bestimmten Benutzerkreis die Anwendung als Published Application zur Verfügung zu stellen.

Anwender von OSD in Enteo v6 oder DSM 7 kennen das Fenster des Windows PE Binary Clients, in dem dieser seine Aktionen protokolliert.

Abhängig vom Loglevel, das ja über den Eintrag InfoLevel im Abschnitt [enteoconfig] der OSDCLNT.INI eingestellt werden kann, sind diese Informationen durchaus umfangreich und gerade bei Problemen auch wertvoll für das Troubleshooting.

Allerdings kann man aus dem Fenster des Binary Clients keine Einträge herauskopieren und für die spätere Analyse wegsichern. Außerdem verschwindet das Fenster nach dem Auftreten eines Fehlers häufig viel zu schnell, sodass man die enthaltenen Meldungen oft garnicht vollständig lesen und analysieren kann.

Was wenig bekannt (da meines Wissens nach auch nicht dokumentiert) ist, ist dass seit DSM 7 der Windows PE Binary Client diese Meldungen nicht nur in seinem Fenster ausgibt, sondern standardmäßig auch in ein Logfile schreibt.