Ontrex Software Package Atelier Teamblog

Plugin für verschiedene Office Versionen bereitstellen

Stefan Hotan — Sun, 27 Jun 2010 14:03:03 +0000

Wenn immer eine neue Version von Microsoft Office verfügbar ist, kommt es vermehrt zur Situation, dass eine Installation Office Plugins sowohl für die Vorgängerversion wie auch für die aktuellste Version bereitstellen muss.

Für Administratoren die ein Office Plugin repaketieren, kommt erschwerend dazu, dass für jede Office Version die berücksichtigt werden muss, ein Snap-Shot von der Hersteller-Installation durchgeführt werden muss. Als wäre dies nicht schon genug, müssen Dateien die scheinbar die Gleichen sind auch noch Binär abgelichen werden, denn nicht selten kommt es vor, dass ein Plugin die gleiche Grösse und das gleiche Datum hat, jedoch Binär unterschiedlich sind.

Der folgende Weg beschreibt wie mann gleiche oder unterschiedliche Office Plugins mit einer Installation für verschiedene Office Versionen bereitstellt.

Sind die Dateien für die unterschiedlichen Office Versionen bekannt, dann wird für jede Office Version eine eigene Komponente erstellt. Das Verzeichnis steht nur als Beispiel, in der Praxis werden die Dateien in unterliegende Ordner wie STARTUP oder XLSTART installiert.

Beispiel Komponente für Office 12 (2007), erkennbar an der Kondition

Beispiel Komponente für Office 14 (2010), erkennbar an der Kondition

Der Haupteil der Installations-Logik, herauszufinden welche Office Version vorhanden ist, übernimmt eine CustomAction. Die CustomAction wird die auf dem Rechner vorhande Office Version anhand der Winword.exe Datei auslesen und den MajorRelease des Office Produktes in eine Public Property, in diesem Beispiel OFFICEVERSION, hinterlegen. Die OFFICEVERSION Property wird danach als Kondition weiter verwendet.

Da die Custom Action von keiner anderen Aktion abhänigig ist, wird diese im frühen Immediate Bereich der Installation ausgeführt. Zum InstallValidate Zeitpunkt wird anhand der Konditionen entschieden, welche Komponenten installiert werden.

Auszug aus dem Verbose-Log der Installation:

MSI (s) (20:44) [11:24:05:495]: Doing action: ONTXGetOfficeVersion
MSI (s) (20!44) [11:24:05:807]: PROPERTY CHANGE: Adding OFFICEVERSION property. Its value is ’14′.
(Die CustomAction erstellt die Public Property mit dem aktuellen Wert der Office Version)

MSI (s) (20:44) [11:24:07:885]: Doing action: InstallValidate
MSI (s) (20:44) [11:24:07:885]: Component: Office_Makros.dot_12; Installed: Absent; Request: Local; Action: Null
MSI (s) (20:44) [11:24:07:885]: Component: Office_Makros.dot_14; Installed: Absent; Request: Local; Action: Local
(Die InstallValidate Aktion wird mit der Action Null oder Local den Komponenten Status festlegen)

Nicht zu vergessen, die Public Property muss in die SecureCustomProperty aufgenommen werden.

Mit diesem Vorgehen steht nichts mehr im Wege die nächsten Office Plugin Installationen zu paketieren.

Install Microsoft Office 2010 Language Packs

Stefan Hotan — Thu, 10 Jun 2010 06:07:13 +0000

Das Prinzip der Office 2010 Language Packs Installation wurde von der Vorgänger Version 2007 übernommen.

Wer zum Ersten Mal eine Office 2007 oder 2010 MUL Installation automatisieren muss, dem sei mit einem Microsoft Technical Diagramm geholfen. Wohl reicht ein Ausdruck auf A3 nicht aus um alles darzustellen, jedoch gibt’s noch eine Zoom Funktion oder ein Drucker, der auf A1 oder A0 ausdrucken kann.

Mit dem ‘Deploy Language Packs for Microsoft Office 2010′ Diagramm erhält man auf einen Blick (oder auch zwei) eine Übersicht der Microsoft Office 2010 Sprachpaket-Integration.

Das Diagram zum Herunterladen

Weitere Tech-Diagramme von Microsoft die von Interesse sein können.

MSI-Logfileanalyzer 3.0 review

Stefan Hotan — Wed, 26 May 2010 15:35:42 +0000

Der MSI-Logfileanalyzer 3.0 geht in die dritte Runde. Der MSI Logfile Analyzer ist ein Werkzeug um Windows Installer Logfiles schnell, effizient, detailliert und gegliedert anzuzeigen. Nebst dem verbesserten Look and Feel gegenüber der alten Version wurden einige interessante Optionen hinzugefügt und Verbesserungen eingebraucht um mit dem Analyzer ein stabiles und robustes Programm zur Verfügung zu stellen.

Die folgende Liste enthält eine Übersicht der neuen Funktionen:

Suchfunktion
Installation, Deinstallation von Features
Export von Tabellen
Gleichzeitige Anzeige der selekieren Ressource mit dem Inhalt der entsprechenden Tabelle aus dem MSI
Ausweisen ob eine Transformation angewandt wurde, inkl. Pafd zur MST
Uebersetzungsprogramm der gepackten GUID zur Standart GUID und umgekehrt
SID Uebersetzungsprogramm
Feedback Funktion
Export der Registry Einträge vom Logfile in eine .REG Datei
Speichern der analysierten Logfiles
Es können bis zu hundert Logfiles geöffnet werden

Die aktuelle Version kann unter www.hoschi.biz bezogen werden.

.NET Installation Repaketieren

Stefan Hotan — Tue, 27 Apr 2010 08:20:41 +0000

Seit vielen Jahren gibt es Programme, welche auf das Microsoft .NET Framework aufbauen. Deren Anzahl wächst täglich und sind dabei die klassischen 32Bit Com Objekt orientieren Applikationen zu verdrängen. Dementsprechend kommt es häufiger vor, dass eine .NET Framework Applikation repaketiert wird.

Je nach Applikation kann das interpretieren der Ressourcen sehr komplex ausfallen. Speziell dann, wenn Assemblies ins Global Assembly Cache installiert, Interop Registrationen durchgeführt, Native Images erstellt, VC++ Runtimes bereitgestellt und vielleicht noch an den .NET Securities gedreht wird.

Wer .NET Applikationen repaketiert muss die Welt deren Ressourcen verstehen lernen. Eine einfache .NET Applikation aus Sicht der .NET Ressourcen ist einfach zu repaketieren, kommen jedoch weitere .NET Ressourcengebiete dazu, dann ist ohne Grundwissen ein Überblick schwer zu erhalten.

Die .NET Ressourcen können im Grossen und Ganzen in fünf Segmente unterteilt werden:

Nicht jede .NET Applikation benötigt zwangsweise eine komplexe Integration. Im besten Falle besteht die Applikation aus privaten Assemblies und benötigt keine der dargestellten .NET Ressourcen.

Die Herausforderung in der Repaketierung besteht darin, die Ressourcen anhand des Deltas dem richtigen Ressourcen-Typ zuzuordnen und die optimale Installationsmethode zu verwenden. Wir haben uns diesem Problem angenommen und diesen Teil in den ‘Wise – MSI Blackbelt III’ Kurs eingebunden. Diesen Eintageskurs führen wir 1-2 mal pro Jahr durch. Neben dem Thema .NET werden weitere interessante Themen für Fachkräfte im Bereich der Software Paketierung besprochen.

MSI Assembly Converter

Stefan Hotan — Fri, 09 Apr 2010 12:13:41 +0000

Anlässlich unserer Schwarzgurt-Paketierungsausbildung haben wir ein Tool entwickelt, dass bei repaktierten Hersteller MSI Installationen die MsiAssembly und MsiAssemblyName Tabellen in die neue Installation konvertiert. Das Tool mit der Bezeichnung MSI Assembly converter ist nun für die Öffentlichkeit freigegeben.

Download: MSI Assembly converter

Unser Konverter wird aus der Quelleinstallation alle MsiAssembly und MsiAssemblyName Einträge auslesen und diese in die eigene Installation anhand der neuen Installations-Struktur aufbereiten. Es kommt gerne vor, das die Hersteller-Installation mit GUIDs arbeitet, dessen Umsetzung in eine neue Installation sich als sehr Aufwendig erweisen kann.

Beispiel einer Hersteller MSI mit .NET Assemblies

Das Ergebnis nach der Konvertierung in die eigene Installationsdatei. Der Konverter richtet sich nach der neuen Feature und Datei-Namen der Ziel-Installation aus.

Weitere Informationen zu unserem Schwarzgurt Training und weiteren Software Paketierungsausbildungen finden Sie auf unserer Homepage: http://www.ontrex.ch

Wise Setup Capture – security restriction

Stefan Hotan — Tue, 06 Apr 2010 11:06:37 +0000

Mit der aktuellen Version des Wise Package Studios erscheint ab Windows Vista beim Setup-Capture die Meldung ‘The operating system currently has a security restriction that interferes with Virtual Capture and SmartMonitor’.

Wenn der SmartMonitor und der Virtual Capture nicht verwendet werden, also nur das klassische Snap-Shot Verfahren gebraucht wird, dann kann diese Meldung mit ‘No’ ignoriert werden.
Mit folgendem Registry-Key kann diese Nachricht unterdrückt werden:
[HKCU\Software\Wise Solutions\Windows Installer Editor\HideMessages]
“20153″=dword:00000006

Hinter dieser Option steht eine Sicherheitserweiterung, die mit der Vista Version von Windows eingeführt wurde. Wird der Hinweis mit ‘Yes’ beantwortet, so wird folgender Registry-Key geschrieben:
[HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows]
“LoadAppInit_DLLs”=dword:00000001

Die LoadAppInit DLLs ist eine Beriebsystem-Funktion, welche bei jedem Prozess zusätzliche DLL’s ladet. Wise Package Studio verwendet diese Funktion um die Datei HookDll.dll in den Speicher eines jeden Prozesses einzubinden. Damit wird es ermöglicht, einen Installationsprozess zu überwachen und dessen Vorgehen mit SmartMonitor oder VirtualCapture aufzuzeichnen.
HookDll.dll

Class IDs verification Test

Stefan Hotan — Tue, 16 Mar 2010 11:28:15 +0000

Dieser Post geht auf den Test Expert ein, welcher mit einer Wise Package Studio Quality Assurance Erweiterung oder mit der Wise Package Studio Suite Edition zur Verfügung steht.
Im Wise Test Expert existiert unter ‘Application Verification Tests’ ein Class IDs Test Case. Mit diesem Test Case lassen sich Klassen, also Registry Einträge unter HKCR\CLSID automatisch Testen, ohne die Applikation starten und alle Funktionen sowie Unterfunktionen testen zu müssen.

Dieser Test Case unterliegt der ClassID Tabelle der ausgewählten Applikation und verwendet die CoCreateInstance Funktion um die Funktionalität der Klasse zu verifizieren. Natürlich erhofft man sich bei der Verwendung des Wise Test Expert ein Erfolgs-Resultat von 100%. Die Praxis zeigt uns jedoch, dass bei den Class IDs Tests ein Resultat von 20% schon eine voll funktionierende Applikation ausweissen kann.

Der Grund für diesen Beitrag besteht darin offen zu legen, warum im Test Expert bei den Class IDs Test ein Resultat von 20% schon gut genug sein kann.

Ich habe über die Jahre alle möglichen Resulate aus dem Test Experten analysiert und eine Liste erstellt, worin zu ersehen ist, bei welchen ‘Error Numbers’ eine Installation auf Fehler zu überprüfen ist und bei welchen Nummern die Klasse als funktionsfähig einzustufen ist.

Error Number	Error Description	Real Error
0×80040154	Class not registered	maybe
0×80004002	No such interface supported	no
0×80080005	Server execution failed	no
0×80004005	Unspecified error	no
0×80040111	cannot supply requested class	no
0x8007007E	The specified module could not be found	yes
0x8000FFFF	Catastrophic failure	no
0×80040112	Class is not licensed for use	no

Die Liste zeigt auf, es gibt verschiedene Gründe, warum ein Klassen-Test fehlschlagen kann.

Bei folgenden Fehler-Nummern kann die betroffene Klasse korrigiert werden:

Class not registered: Der Test kann nochmals durchgeführt werden, nach dem die betroffene Klassen-Datei (.DLL oder .OCX) mit dem Programm regsvr32.exe registriert wurde. Sollte nach einem erneuten Test die Klasse erfolgreich gestet werden können, so kann die fehlende Klasse in die Installation eingebaut werden.

The specified module could not be found: Verwenden Sie den Dependency Walker von Microsoft um die fehlende(n) Datei(en) in die Installation einzubauen.

Bei den restlichen Fehlermeldungen liegt fast sicher kein Problem vor, oder dieser lässt sich aus Sicht eines System-Administrator nur sehr selten verbessern.

Zusammenfassend muss ich festhalten, dass ein Klassen-Test mit der CoCreateInstance Funktion keine optimale Lösung ist, um eine verlässliche Aussage treffen zu können, ob eine Klasse wirklich funktioniert. Die Test-Resulate liefern viele Error Codes zurück, obwohl die Applikation funktionieren wird. Schlussendlich hat ein Software Hersteller verschiedene Möglichkeiten eine Klasse für seine Applikation zu inizialisieren.

Zusätzliche Special Folders

Fabio Di Lorenzo — Thu, 11 Mar 2010 11:38:34 +0000

Die Windows Installer Technologie bietet bereits von Haus aus diverse Directory Properties um auf “Special Folders” Werte zugreifen zu können.

Leider gibt es jedoch immer wieder der Fall, dass man auf zusätzliche, nicht durch den Windows Installer bereits zu Verfügung gestellte Werte zugreifen muss.

Mit folgendem VBScript kann man sich diese Werte allerdings schaffen. In unserem folgenden Beispiel ermitteln wir den “Common Documents” Folder.

Folgendes Skript fügen wir als “CALL VBScript From Embedded Code” Aktion im Immediate Bereich ein:

Const CSIDL_COMMON_DOCUMENTS = &h2e
Set objShell = CreateObject(“Shell.Application”)
Session.Property(“ONTX_COMMON_DOCUMENTS”) = objShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path
Set objShell = nothing

Zu beachten ist, das wir diese Aktion vor “CostFinalize” durchführen müssen.

Um den Wert auch für Komponenten verwenden zu können, sollte man noch einen Eintrag in der Directory Tabelle erfassen:

Danach kann man das Property/Directory wie üblich verwenden.

Eine Liste aller Special Folders befindet sich im Anhang dieses Artikels.

Anhang: Liste aller Special Folders

CSLID	Hex Value	Description
CSIDL_ADMINTOOLS	0×0030	The file system directory that is used to store administrative tools for an individual user. The Microsoft Management Console (MMC) will save customized consoles to this directory, and it will roam with the user.
CSIDL_ALTSTARTUP	0x001d	The file system directory that corresponds to the user’s nonlocalized Startup program group. This value is recognized in Windows Vista for backward compatibility, but the folder itself no longer exists.
CSIDL_APPDATA	0x001a	The file system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data. This CSIDL is supported by the redistributable Shfolder.dll for systems that do not have the Microsoft Internet Explorer 4.0 integrated Shell installed.
CSIDL_BITBUCKET	0x000a	The virtual folder that contains the objects in the user’s Recycle Bin.
CSIDL_CDBURN_AREA	0x003b	The file system directory that acts as a staging area for files waiting to be written to a CD. A typical path is C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\CD Burning.
CSIDL_COMMON_ADMINTOOLS	0x002f	The file system directory that contains administrative tools for all users of the computer.
CSIDL_COMMON_ALTSTARTUP	0x001e	The file system directory that corresponds to the nonlocalized Startup program group for all users. Valid only for Microsoft Windows NT systems. This value is recognized in Windows Vista for backward compatibility, but the folder itself no longer exists.
CSIDL_COMMON_APPDATA	0×0023	The file system directory that contains application data for all users. A typical path is C:\Documents and Settings\All Users\Application Data. This folder is used for application data that is not user specific. For example, an application can store a spell-check dictionary, a database of clip art, or a log file in the CSIDL_COMMON_APPDATA folder. This information will not roam and is available to anyone using the computer.
CSIDL_COMMON_DESKTOPDIRECTORY	0×0019	The file system directory that contains files and folders that appear on the desktop for all users. A typical path is C:\Documents and Settings\All Users\Desktop. Valid only for Windows NT systems.
CSIDL_COMMON_DOCUMENTS	0x002e	The file system directory that contains documents that are common to all users. A typical paths is C:\Documents and Settings\All Users\Documents. Valid for Windows NT systems and Windows 95 and Windows 98 systems with Shfolder.dll installed.
CSIDL_COMMON_FAVORITES	0x001f	The file system directory that serves as a common repository for favorite items common to all users. Valid only for Windows NT systems.
CSIDL_COMMON_MUSIC	0×0035	The file system directory that serves as a repository for music files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Music.
CSIDL_COMMON_OEM_LINKS	0x003a	This value is recognized in Windows Vista for backward compatibility, but the folder itself is no longer used.
CSIDL_COMMON_PICTURES	0×0036	The file system directory that serves as a repository for image files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Pictures.
CSIDL_COMMON_PROGRAMS	0×0017	The file system directory that contains the directories for the common program groups that appear on the Start menu for all users. A typical path is C:\Documents and Settings\All Users\Start Menu\Programs. Valid only for Windows NT systems.
CSIDL_COMMON_STARTMENU	0×0016	The file system directory that contains the programs and folders that appear on the Start menu for all users. A typical path is C:\Documents and Settings\All Users\Start Menu. Valid only for Windows NT systems.
CSIDL_COMMON_STARTUP	0×0018	The file system directory that contains the programs that appear in the Startup folder for all users. A typical path is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. Valid only for Windows NT systems.
CSIDL_COMMON_TEMPLATES	0x002d	The file system directory that contains the templates that are available to all users. A typical path is C:\Documents and Settings\All Users\Templates. Valid only for Windows NT systems.
CSIDL_COMMON_VIDEO	0×0037	The file system directory that serves as a repository for video files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Videos.
CSIDL_COMPUTERSNEARME	0x003d	The folder that represents other computers in your workgroup.
CSIDL_CONNECTIONS	0×0031	The virtual folder that represents Network Connections, that contains network and dial-up connections.
CSIDL_CONTROLS	0×0003	The virtual folder that contains icons for the Control Panel applications.
CSIDL_COOKIES	0×0021	The file system directory that serves as a common repository for Internet cookies. A typical path is C:\Documents and Settings\username\Cookies.
CSIDL_DESKTOP	0×0000	The virtual folder that represents the Windows desktop, the root of the namespace.
CSIDL_DESKTOPDIRECTORY	0×0010	The file system directory used to physically store file objects on the desktop (not to be confused with the desktop folder itself). A typical path is C:\Documents and Settings\username\Desktop.
CSIDL_DRIVES	0×0011	The virtual folder that represents My Computer, containing everything on the local computer: storage devices, printers, and Control Panel. The folder can also contain mapped network drives.
CSIDL_FAVORITES	0×0006	The file system directory that serves as a common repository for the user’s favorite items. A typical path is C:\Documents and Settings\username\Favorites.
CSIDL_FONTS	0×0014	A virtual folder that contains fonts. A typical path is C:\Windows\Fonts.
CSIDL_HISTORY	0×0022	The file system directory that serves as a common repository for Internet history items.
CSIDL_INTERNET	0×0001	A virtual folder for Internet Explorer.
CSIDL_INTERNET_CACHE	0×0020	The file system directory that serves as a common repository for temporary Internet files. A typical path is C:\Documents and Settings\username\Local Settings\Temporary Internet Files.
CSIDL_LOCAL_APPDATA	0x001c	The file system directory that serves as a data repository for local (nonroaming) applications. A typical path is C:\Documents and Settings\username\Local Settings\Application Data.
CSIDL_MYDOCUMENTS	Use CSIDL_PERSONAL	The virtual folder that represents the My Documents desktop item. This value is equivalent to CSIDL_PERSONAL.
CSIDL_MYMUSIC	0x000d	The file system directory that serves as a common repository for music files. A typical path is C:\Documents and Settings\User\My Documents\My Music.
CSIDL_MYPICTURES	0×0027	The file system directory that serves as a common repository for image files. A typical path is C:\Documents and Settings\username\My Documents\My Pictures.
CSIDL_MYVIDEO	0x000e	The file system directory that serves as a common repository for video files. A typical path is C:\Documents and Settings\username\My Documents\My Videos.
CSIDL_NETHOOD	0×0013	A file system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Documents and Settings\username\NetHood.
CSIDL_NETWORK	0×0012	A virtual folder that represents Network Neighborhood, the root of the network namespace hierarchy.
CSIDL_PERSONAL	0×0005	The virtual folder that represents the My Documents desktop item. This is equivalent to CSIDL_MYDOCUMENTS.
CSIDL_PRINTERS	0×0004	The virtual folder that contains installed printers.
CSIDL_PRINTHOOD	0x001b	The file system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is C:\Documents and Settings\username\PrintHood.
CSIDL_PROFILE	0×0028	The user’s profile folder. A typical path is C:\Users\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. However, if you are creating a new Known Folder the profile root refered to by CSIDL_PROFILE is appropriate.
CSIDL_PROGRAM_FILES	0×0026	The Program Files folder. A typical path is C:\Program Files.
CSIDL_PROGRAM_FILES_COMMON	0x002b	A folder for components that are shared across applications. A typical path is C:\Program Files\Common. Valid only for Windows NT, Windows 2000, and Windows XP systems. Not valid for Windows Millennium Edition (Windows Me).
CSIDL_PROGRAM_FILES_COMMONX86	0x002c
CSIDL_PROGRAM_FILESX86	0x002a
CSIDL_PROGRAMS	0×0002	The file system directory that contains the user’s program groups (which are themselves file system directories). A typical path is C:\Documents and Settings\username\Start Menu\Programs.
CSIDL_RECENT	0×0008	The file system directory that contains shortcuts to the user’s most recently used documents. A typical path is C:\Documents and Settings\username\My Recent Documents. To create a shortcut in this folder, use SHAddToRecentDocs. In addition to creating the shortcut, this function updates the Shell’s list of recent documents and adds the shortcut to the My Recent Documents submenu of the Start menu.
CSIDL_RESOURCES	0×0038	Windows Vista. The file system directory that contains resource data. A typical path is C:\Windows\Resources.
CSIDL_RESOURCES_LOCALIZED	0×0039
CSIDL_SENDTO	0×0009	The file system directory that contains Send To menu items. A typical path is C:\Documents and Settings\username\SendTo.
CSIDL_STARTMENU	0x000b	The file system directory that contains Start menu items. A typical path is C:\Documents and Settings\username\Start Menu.
CSIDL_STARTUP	0×0007	The file system directory that corresponds to the user’s Startup program group. The system starts these programs whenever any user logs onto Windows NT or starts Windows 95. A typical path is C:\Documents and Settings\username\Start Menu\Programs\Startup.
CSIDL_SYSTEM	0×0025	The Windows System folder. A typical path is C:\Windows\System32.
CSIDL_SYSTEMX86	0×0029
CSIDL_TEMPLATES	0×0015	The file system directory that serves as a common repository for document templates. A typical path is C:\Documents and Settings\username\Templates.
CSIDL_WINDOWS	0×0024	The Windows directory or SYSROOT. This corresponds to the %windir% or %SYSTEMROOT% environment variables. A typical path is C:\Windows.

Wise Package Studio 8: Network Client Update umgehen.

Fabio Di Lorenzo — Mon, 08 Mar 2010 10:11:36 +0000

Nach der Migration des Wise Package Studio Servers auf die Version 8.0 ist es leider auch nötig die Netzwerk Client Installationen zu aktualisieren.

Je nach Packaging Umgebung kann dies jedoch enormen Aufwand bedeuten.

Mit folgendem Trick kann man sich diesen Aufwand allerdings sparen:

- Installiere den Network Client der 8.0 Version auf einer sauberen VM/Client

- Exportiere danach den “Wise Solutions” Registry key. In diesem Key sind die neuen Lizenzinformation drin. Ohne diese lässt sich WPS 8.0 nicht starten.

- Erstelle ein neues WiseScript und füge mittels “Edit Registry” Aktion diese Keys hinzu

- Als 2 Aktion füge eine “Run Executable” Aktion hinzu, und zeige dort auf die “PackageStudio8.exe” Executable auf dem Wise Package Studio Share.

- Kompiliere ein neues Executable und lege dies im Wise Package Studio Programmverzeichnis als “PackageStudio7.exe” ab

Nun wird bei alten Netzwerk Client Installationen die PackageStudio7.exe gestartet, welche die benötigten Registrierungsschlüssel für das Wise Package Studio 8 ins Benutzerprofil schreibt und danach die aktuelle PackageStudio8.exe startet.

Microsoft APP-V 4.6 Verfügbar

Fabio Di Lorenzo — Mon, 01 Mar 2010 15:04:41 +0000

Seit kurzem ist die Version 4.6 der Microsoft Software-Virtualisierungstechnologie (APP-V) verfügbar.

Mit der Version 4.6 findet nun auch native x64 Technologie Einzug in die Virtualisierungslösung von Microsoft.

Herunterladen lässt sich die neuste APP-V Version über die gängigen Seiten/Zugriffsmöglichkeiten:

Technet
MSDN
MVLS

Die Ontrex AG bietet umfangreiche Consulting und Paketierungs-Diensleistungen für diese Technologie an.
Weitere Informationen über unsere Dienstleistungen finden Sie auf unserer Homepage.