Post-scripts in VMware Mirage

For many operations VMware Mirage allows to run so-called post-scripts.
Post-script are scripts that run on the endpoint after one of the following operations is completed:

  • Windows migration
  • Base layer provisioning
  • Base layer assignment
  • App layer deployment

A post-script allows you to run scripts and programs and do customisations.

Practical use cases are:

  • Delete the Windows.old directory after a Windows migration
  • Customise configuration files based on computer name
  • Install OEM software based on the specific hardware type
  • Deploy applications that are not yet compatible with app layers
  • and many more

All post-scripts are located under %ProgramData%WanovaMirage Service and need to be included in the base layer respectively in the app layer in case of the post-app layer deployment script.
Below you find an overview of the different script names that are used.

Script file name Execution time
post_migration.bat Post-Windows migration
post_provisioning.bat Post-Base Layer Provisioning
post_core_update.bat Post-Base Layer Assignment
post_layer_update_*.bat Post-App Layer Deployment

By default the post_migration.bat and a file called post_bi_update.bat are located inside the %ProgramData%WanovaMirage Service directory. While you can freely modify the post_migration.bat to execute programs and scripts after a Windows migration it is highly recommended not modify the post_bi_update.bat script. The post_bi_update.bat script is more or less just a wrapper for the post_provisioning.bat and post_core_update.bat.

So, if you want to run scripts after a base layer provisioning or assignment you first have you create the corresponding script (post_provisioning.bat or post_core_update.bat) inside the %ProgramData%WanovaMirage Service directory. Those two script are call by the post_bi_update.bat so there is no need to modify this file directly.

Inside the scripts you can basically do whatever you want you just have to be aware of the following:

  1. The scripts and therefore everything you do inside the scripts are executed in the context of the system account
  2. Make sure your script returns a proper error code. Return a zero (0) if the script execution is successful. Everything else is interpreted as an error and logged as such in the Mirage event log.
  3. By default there is a 300 second (5 minute) time out for post-scripts. If the script isn’t finished during this timeframe Mirage will no longer wait for the script and proceed.

MiragePostScriptErrorMiragePostScriptTimeout
The screenshots above showing a post-script error and time out message in the Mirage event log.

While most scripts are placed inside the base layer the post-app layer deployment script needs to be included in an app layer. During the app layer recording process create a file called post_layer_update_.bat in the folder %ProgramData%WanovaMirage Service. Of course you need to replace the asterisk () with a unique name. You have to make sure that each app layer has a unique script name.

Example: post_layer_update_firefox22_0485345.bat

Unfortunately troubleshooting post-scripts can be bit cumbersome as you have no chance to see the script execution interactively. Therefore it is recommended to implement logging functionalities in your script so that each step is recorded in a log file. A perfect location for log files created by post-layer scripts is the Mirage service log directory located at %Program Files%WanovaMirage ServiceLogs. Just make sure you choose a unique log file name.

What’s new in VMware ThinApp 5.0 (Tech Edit)

Today VMware made ThinApp 5.0 generally available. While there is a lot of information out there on what’s new spread across multiple announcements, release notes and blogs I want to summarize the most critical information on what’s new in VMware ThinApp 5.0 from a technical point of view.

End-of-availability canceled

Even if this isn’t a technical point it is still pretty important to know. With the announcement of the VMware Horizon Suite it was also announced that after December 15th, 2013 ThinApp would not be available as standalone product anymore. Shortly after this announcement was made is was pretty clear that our customers where not amused and VMware clearly had underestimated on how many customer count on ThinApp – one of the leading application virtualization products – as a standalone product.

Therefore with the announcement of ThinApp 5.0 VMware also announced that the end-of-availability is canceled. This means VMware will continue to offer ThinApp as a standalone product and you will be able to get at least five more years of service and support for ThinApp.

Re-architecture

In version 5.0 much was changed on the internal plumbing of ThinApp. From a very technical point of view VMware is moving away from import address table hooking of Win32 API to inline hooking of the Windows Native API (NTDLL.dll). As you can see in the figure below this hooking takes place in a much earlier stage and therefore increases the overall application compatibility.

Image source: http://technet.microsoft.com/en-us/library/cc768129.aspx
Image source: http://technet.microsoft.com/en-us/library/cc768129.aspx

Also it greatly reduces the number of hooked API. Because instead of hooking all the high-level Win32 API functions ThinApp now hooks low-level functions of the Windows Native API, which are also used internally by all the Win32 API functions.

The following screenshots are showing the DLLs used by a virtualized instance of Notepad++. As you can see there are a lot more DLLs in play with ThinApp 4.7.3 as  there are with ThinApp 5.0.

HookedDLLsThinApp

All in all the number of of hooked APIs are reduced from about 600 to 200. Which results in a much smaller code base of ThinApp 5.0 and therefore decreases the number of potential bugs. Also, as already mentioned, it should boost the already very good application compatibility of ThinApp to a new level.

64-bit support

ThinApp always supported 64-bit operating systems and was always able to run virtualized 32-bit applications on top of Windows 64-bit versions. But with ThinApp 5.0 finally the virtualization of 64-bit applications is  possible. This was one of the most requested feature by our customers.

The ability to virtualize 64-bit applications opens up many new use cases, i.e. the virtualization of 64-bit version of Office and Internet Explorer but also the virtualization extensive CAD/CAM applications.

The following tables shows the supported capture and deployment scenarios of ThinApp 5.0.

As you can see ThinApp supports pretty much every available scenario with the exception of the following two:

  1. ThinApp 5.0 does support capturing 32-bit applications on top of 64-bit operating systems but only if you build and deploy it to 64-bit machines only. If you want to run a 32-bit package on top of 32 and 64-bit operating systems you need to create the package on top of a 32-bit operating system.
  2. ThinApp still supports the virtualization of 16-bit applications on top of 32-bit operating systems but does not and never will support 16-bit applications on top of Windows 64-bit. You can blame – or in my opinion thank – Microsoft for that. See 64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications

VMware supports the following operating systems for running virtualized 64-bit applications:

  • Windows 7 64-bit
  • Windows Server 2008 R2
  • Windows 8 64-bit
  • Windows Server 2012
  • Windows 8.1 64bit
  • Windows Server 2012 R2

Not supported are:

  • Windows XP 64-bit
  • Windows Server 2003 64-bit
  • Windows Vista 64-bit
  • Windows Server 2008 64-bit

ThinApp 5.0 of course still support these platforms for running virtualized 32-bit applications on top of them. And of course all other 32-bit platforms (like Windows XP, Vista, 7 and so on) are still supported.

Office 2013 and Internet Explorer 10 support

With ThinApp 5.0 you can virtualize the latest Microsoft applications like Office 2013 and Internet Explorer 10. While Office 2010 was a pain to virtualize in prior version of ThinApp, ThinApp 5.0 includes many fixes to make packaging much more reliable. Also VMware provides official packaging guidelines for Office 2010 (See KB 1022287) and 2013 (See KB 2062691).

Unfortunately support for both products is limited at the moment. While virtualizing Internet Explorer 10 with ThinApp 5.0 is supported up to Windows 8 (but not 8.1), virtualizing Office 2013 is only supported up to Windows 7 (but not Windows 8 / 8.1).

This is likely to change within a future version of ThinApp.

Compatibility

One big advantage of ThinApp’s agent- and client-less architecture is that you are able to run multiple versions of the ThinApp runtime at the same time. Therefore integrating a new version of ThinApp is easy as pie. Still there are some things to consider when bringing ThinApp packages in version 5.0 in to an existing ThinApp environment.

AppLink: with ThinApp 5.0 we support linking ThinApp 5.0 packages with ThinApp 4.5 (and later) packages. There is only one gotcha: The parent package always has to be packaged with ThinApp 5.0. So if you for example have Mozilla Firefox virtualized and several AppLink packages like Flash and Java connected you first have to update the Mozilla Firefox package to ThinApp 5.0 in order to update any linked package (Flash or Java) to ThinApp version 5.0.

In-place update: With ThinApp it was always possible to update current ThinApp packages to a newer version of the runtime or the application it self by copying the new package side-by-side with the old package and adding integer at the end of the package.

For example: If the user is currently using Notepad++ 6.0 as a ThinApp package called Notepad++.exe and you want to deploy Notepad++ 6.5. Just copy the new ThinApp package as Notepad++.exe.1 side-by-side to the original Notepad++.exe ThinApp package and as soon as the user launches or relaunches (yes, you can do this while the user is using the application) he will get the new Notepad++ 6.5 package.

When doing an in-place update to a 5.0 package that contains the new .alt file this file should be named as *.n.alt where n is the integer you choose for the base .dat or .exe file. In this case it would be Notepad++.exe.1.alt.

AppSync: Of course you can also update your applications using the AppSync mechanism but only 32-bit packages. Also see the following article: When you perform Appsync from 4.7.2 to 4.7.3. AppSync displays the following error message “The operating system cannot run”.

MSI: Updating ThinApp packages from prior versions of ThinApp to version 5.0 is done the normal way. (See Upgrade a deployed ThinApp package with the help of MSI) There are no special considerations necessary.

Sandbox: It it worth mentioning that the sandbox (if the sandbox names are identical) will be reused during an upgrade. So if you updating your packages to ThinApp 5.0 all application settings are available after the update. Please keep in mind that updating to a newer version of an application or even a different application bitness (32-bit vs. 64-bit) may result in loss of the application settings as they are probably  saved in a different location in the registry. In this scenario it would be advisable to use a new sandbox and not to reuse the existing sandbox.

ThinDirect enhancements

ThinDirect in ThinApp 5.0 was update to support newer browsers like Internet Explorer 10 and also 64-bit versions of Internet Explorer.

Also the ThinDirect policies – that controls which URL should be opened in which virtual browser – are now available as ADMX template.

Updated SDK

The ThinApp SDK was also updated with version 5.0. It now includes a separate 64-bit DLL (ThinAppSDK64.dll) and therefore eliminates the need of the ThinAppSDKSrv.exe on 64-bit operating systems.

You can use the new SDK and all your scripts/programs without any change with existing ThinApp packages prior version 5.0. If you want to enable your scripts/programs to support ThinApp 5.0 packages you actually have to change them.

Have a look at the release notes to get more details on this particular point.

VMware Horizon View and Workspace integration

ThinApp is an integral part of VMware Horizon View, Workspace and Mirage. While you can start using ThinApp 5.0 in your Mirage deployments right away as there is no direct link between Mirage and ThinApp you have to be aware of some limitations when it comes to the View and Workspace integration.

The current releases of Horizon View will support ThinApp 5.0 32-bit packages out of the box. Support for 64-bit ThinApp 5.0 packages will be introduced in future version of Horizon View. Horizon Workspace 1.5 does not support ThinApp 5.0, neither 32-bit nor 64-bit.

In regards to Horizon View you of course have always the possibility to use ThinReg or the SDK to register ThinApp 5.0 64-bit packages using a logon script or deploy them via MSI. This is fully supported and this way you can enjoy 64-bit ThinApps from day one.

For more information see the official knowledge base article: Horizon View and Horizon Workspace support for ThinApp 5.0 applications

AppSense Environment Manager integration

While it was always possible to manage the personality of a ThinApp package using Environment Manager from AppSense by copying the sandbox at logon and logoff. With VMware ThinApp 5.0 the Environment Manager from AppSense can actually look into the sandbox and therefore do all the amazing cross-application personalization stuff. So you can for example configure your local Office 2010 on your laptop and when you connect to your virtual VMware View desktop you have the same settings in your Office 2010 ThinApp package.

More information on the integration can be found in the following blog post by AppSense: AppSense Environment Manager Integrates with VMware ThinApp 5.0

As you can ThinApp 5.0 contains many major improvements and new features. I hope you will enjoy working with ThinApp 5.0 as much as I do.

Release Notes | Documentation | Download

ThinApp Scripting: Launch virtual application only if a specific process is not running

In my daily life as Consultant for VMware I implement a lot of customer specific scripts using the ThinApp scripting engine and I just thought: Why not share these scripts?

The following script can be used if a ThinApp application can or should not be launched if a specific process is already running. In this particular case a virtualized instance of SAP should only be able to launch if no native instance of SAP is running already.

<

p class=”lang:vb decode:true crayon-selected”>

' Run script if an entry point is launched<br>Function OnFirstParentStart</p>
' Initialize variables
Dim objWMIService, objWMIProcess, objShell
Dim colWMIProcess
Dim strTitle, strMessage, strComputer, strProcess
Dim intButton

' Set computer to localhost
strComputer = "."
' Set process to check
strProcess = "saplogon.exe"

' Set error message
strTitle = "VMware ThinApp"
strMessage = "The process " & strProcess & "is already running!" & Vbcrlf & "Please close the process and then try again."
intButton = 48

' Connect to WMI service
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colWMIProcess = objWMIService.ExecQuery("Select * from Win32_Process Where Name='" & strProcess & "'")
If colWMIProcess.Count > 0 Then
' Display message box
Msgbox strMessage, intButton, strTitle
ExitProcess 0
End If

' End of OnFirstParentStart Function
End Function

To implement this script in your ThinApp project just save the code above as .vbs file in your ThinApp projects folder und customize the variable strProcess. Just enter the process you want to check and you are ready.
You can also customize the error message the user gets by modifying the variable strMessage.

ThinApp Scripting with VBScript

Most of the times when I talk to our customers they want some functionality in ThinApp which isn’t offered out of the box.  For example:

  • Allow to run a virtualized application only until a specific date.
  • Update a configuration file every time the applications is launched.
  • Allow an application only to be executed when user is inside the corporate office.
  • Messure the usage of an application.
  • Enforce licensing restriction.
  • And so on…

While such functionalities aren’t offered by ThinApp out of the box there is something else much more powerful available. With ThinApp you have a fully fledged scripting engine available in each and every ThinApp package. This allows you to implement advanced functionalities like the examples mentioned above.

ThinApp supports running VB-based scripts out of the box. Just place your .vbs files side by side to the package.ini, run build.bat and you have successfully integrated your script in your ThinApp package. While it is really that simple there are some very helpful things you should know about.

Functions

The ThinApp script engine natively supports VBScript. Besides the whole spectrum of VBScript functionalities the ThinApp script engine itself provides some additional functions. For example:

  • ExpandPath
    This function allows us to convert a macro folder to a system folder.
  • ExecuteExternalProcess
    With this function it is possible to launch a process outside the virtual environment.
  • GetBuildOption
    GetBuildOption lets us look inside the package.ini file.
  • GetFileVersionValue
    With this function we are able to check if a file has for example a specific version.
  • GetCommandLine
    This option show the command line argument a entry point was called with.
  • GetCurrentProcessName
    Show the name of the current process which triggered the VBScript launch.
  • SetRegistryIsolation
    With the help of this function you can change the registry isolation mode for a specific key during the runtime.

These are just a few examples of functions the ThinApp script engine supports. All of them are documented in the ThinApp User’s Guide. Using a bit of VBScript and some of the specific ThinApp functions you could for example implement your own little help function to your ThinApp packages which works as follows:

Launch your ThinApp entry point with the parameter -thinstallhelp.
ThinAppHelpCommand

And as a result you see a message box with some helpful information about your ThinApp package.
ThinAppHelpMessage

Here is the code realizing this little helper.

Function OnFirstParentStart</p>
' Check command line input for help parameter (-thinstallhelp)
If InStr(GetCommandLine(), "-thinstallhelp") Then

' Get current entry point / process
strCurrentProcess = GetCurrentProcessName

' Get build options from package.ini
strInventoryName = GetBuildOption("InventoryName")
strSandboxName = GetBuildOption("SandboxName")
strCaptureRuntime = GetBuildOption("CapturedUsingVersion")
strOptAppLinks = GetBuildOption("OptionalAppLinks")
strReqAppLinks = GetBuildOption("RequiredAppLinks")

' Set message box title
strTitle = "ThinApp Help"

' Compose output
strMessage = "Current entry point / process: " & strCurrentProcess & Vbcrlf & Vbcrlf & "InventoryName: " & strInventoryName & Vbcrlf & "SandboxName: " & strSandboxName & Vbcrlf & "Capture Runtime: " & strCaptureRuntime & Vbcrlf & "Optional AppLinks: " & strOptAppLinks & Vbcrlf & "Required AppLinks: " & strReqAppLinks

' Display message box with Ok button and title
Msgbox strMessage, 0, strTitle

' Exit process as we just want to show the help message
ExitProcess 0

End If

End Function

Callback functions

As soon as you add a VBScript to your ThinApp package the script gets executed every time a process gets launched within your ThinApp package. This equally applies to manually launched entry points and automatically launched child processes. As you can imagine this isn’t a very good behavior performance wise. For this reason the ThinApp scripting engine includes so-called callback functions. Callback functions help to control when and how often your VBScript code is executed.

For a better understanding which function is called when try the following example. Just save the code below as example.vbs file in your ThinApp project directory, rebuild your application and start using it. The example script displays a pop up message with the name of the function currently executed and the name of the process triggering the function.

Function OnFirstSandboxOwner

strMessage = "OnFirstSandboxOwner: " & GetCurrentProcessName
MsgBox(strMessage)

End Function

Function OnFirstParentStart

strMessage = "OnFirstParentStart: " & GetCurrentProcessName
MsgBox(strMessage)

End Function

Function OnFirstParentExit

strMessage = "OnFirstParentExit: " & GetCurrentProcessName
MsgBox(strMessage)

End Function

Function OnLastProcessExit

strMessage = "OnLastProcessExit: " & GetCurrentProcessName
MsgBox(strMessage)

End Function

strMessage = "OnEveryProcess: " & GetCurrentProcessName
MsgBox(strMessage)

.vbs files

As you may have discovered in your own testing you can add more than one script (.vbs) file to your project directory. If you add multiple scripts every script gets executed in alphanumerical ascending or descending order. The callback function OnFirstSandboxOwner is using an ascending order while all other callback functions are using a descending order. Have a look at an example using two scripts called A.vbs, B.vbs and C.vbs and the callback functions OnFirstSandboxOwner and OnFirstParentExit:

Execution order OnFirstSandboxOwner: Execution order OnFirstParentExit:
  • A.vbs
  • C.vbs
  • B.vbs
  • B.vbs
  • C.vbs
  • A.vbs
  • As you see it is a bit chaotic and I strongly advice only to work with one VBScript file.

    AppLinks

    Also if you are using AppLinks and you linking two or more ThinApp packages each containing VBScripts you have to be aware of the following circumstances. Let’s suppose you have two ThinApp packages each containing a bunch of scripts. ThinApp package 1 contais A.vbs, B.vbs, D.vbs and Z.vbs while ThinApp package 2 contains A.vbs and C.vbs. ThinApp package 1 has ThinApp package 2 configured as an AppLink. What do you think happens now? Here is an example when the scripts are executed in the callback function OnFirstParentStart:

    1. A.vbs (from ThinApp package 2)
    2. B.vbs (from ThinApp package 1)
    3. C.vbs (from ThinApp package 2)
    4. D.vbs (from ThinApp package 1)
    5. Z.vbs (from ThinApp package 1)

    As you can see the order is still the same as discussed in the .vbs file section with one exception. As both packages contained the A.vbs file only the A.vbs file from the second ThinApp package is executed. This behavior is anticipated as files from a child AppLink package (in this case ThinApp package 2) are always overwriting files from its parent AppLink package (in this case ThinApp package 1).

    Conclusion

    You now know that ThinApp has an integrated script engine which natively supports VBScript, callback  and some addition function. You also know how the ThinApp script engine works. With these insights you should now be able to realize some if not all of the missing functions you always wanted ThinApp to have – assumed you have a little bit of know how in the VBScript corner.

    Getting started with ThinApp SDK and PowerShell

    With the recently leased version of the ThinApp SDK I though it was time to give a brief introduction on how to install the ThinApp SDK and how to use it with PowerShell.

    First you need to download the ThinApp SDK from VMware.com. You need a free My VMware account to access the SDK download page.

    Download: http://bit.ly/ThinAppSDK

    To prepare your environment extract the ThinAppSDK.dll and ThinAppSDKSrvr.exe to a permanent location. This location has to permanent as you will register the ThinApp SDK from this location. The SDK only works if both files are available on the specified location.


    To register the ThinApp SDK you have to run the following command from an elevated command promt:

    regsvr32.exe C:PathToMyThinAppSDK.dll

    After that you can start using the SDK. As the SDK is a COM object you can basically use it with any scripting or programming language you want. I am myself a big fan of PowerShell and think it is easy to use so I am going to use PowerShell for all of my examples.

    What doe the ThinAppSDK.dll and the ThinAppSDKSrvr.exe do?
    ThinAppSDK.dll is the DLL that implements the ThinApp SDK objects like ThinApp.Management. It is a 32-bit DLL, if you create a ThinApp.Management object from a 32-bit process Windows will load ThinAppSDK.dll into that process (if the DLL was registered correctly with regsvr32). However, it’s not possible to load a 32-bit DLL into a 64-bit process. So if you try to create a ThinApp.Management object from a 64-bit process, ThinAppSDK.dll cannot be loaded directly into that process.
    That’s where ThinAppSDKSrvr.exe comes in. Windows will detect this situation and will automatically launch ThinAppSDKSrvr.exe. Since ThinAppSDKSrvr.exe is a 32-bit application, it can load ThinAppSDK.dll just fine. Windows will then “forward” ThinApp SDK calls (e.g. the GetThinAppType method call) from the 64-bit process to ThinAppSDKSrvr.exe, which will in turn forward it to ThinAppSDK.dll. The result will be passed back from ThinAppSDK.dll to ThinAppSDKSrvr.exe via Windows to the 64-bit application. This might sound complicated, but it all happens behind the scenes, you shouldn’t have to worry about it.
    Source: http://communities.vmware.com/message/1595702#1595702|

    Now we need to start PowerShell, if you haven’t PowerShell installed yet grab it here. After PowerShell is launched we can create a connection to the ThinApp SDK COM object, which is called ThinApp.Management.

    $ta = New-Object -ComObject ThinApp.Management

    With this command we create a new object called $ta. Please note that name $ta, and all of the following $-variable names in this guide, are choosen by me. You can name the variables whatever you want to. To see what we can do with this object we can list all methods and properties using the following line:

    $ta | Get-Member

    As you can see there are three methods available:

    • GetThinAppType
    • OpenPackage
    • RefreshDesktop

    GetThinAppType
    With the method GetThinAppType you are able to check if a file is ThinApp package and what type of package. You have to specifiy the file you want to check inside the brackets.

    $ta.GetThinAppType("Z:ThinAppAppsMozilla Firefox.exe")

    As result you get a number that describes the type of package.

    ThinApp package types:
    0 – not a ThinApp package
    1 – ThinApp main data container
    2 – ThinApp entry point
    3 – ThinApp MSI
    4 – ThinApp compressed MSI
    5 – ThinApp legacy MSI

    RefreshDesktop
    The RefreshDesktop method is needed when you register a ThinApp package using the SDK. If a ThinApp package contains file type associations a refresh of the desktop is needed for the associations to be applied.

    $ta.RefreshDesktop()

    There is no parameter needed to execute the desktop refresh. Just launch the method without any parameter.

    OpenPackage
    OpenPackage is the most powerful method of the bunch. With this method you can open a ThinApp package. To open a package just specify the ThinApp package you want to open inside the brackets.

    $ta.OpenPackage("Z:ThinAppAppsMozilla Firefox.exe")

    When you run the command you get the InventoryName, MainDataContainer, MSIVersion, ThinAppType and ThinAppVersion of the specified ThinApp package.


    While these information itself are also helpful you can do much more when you create a new object based on your ThinApp package. This can be done using the following command while specifying your ThinApp package in the usual manner:

    $tap = $ta.OpenPackage("Z:ThinAppAppsMozilla Firefox.exe")

    When you just run $tap on your PowerShell command line you see the same information as you have seen just opening the package. To see what the object $tap now can do just run:

    $tap | Get-Member

    Which results in:

    As you can see there are many methods which can be used with our new ThinApp package object.

    • AppSync – Start AppSync process
    • AppSyncUpdateAvailable – Check if an AppSync update is available
    • GetOptionalAppLinks – Search a path for optional AppLink packages which are used within the loaded Thinapp package
    • GetOptions – Get settings out of the package.ini, like CompressionType, Sanboxname, AppSync and so on
    • GetRequiredAppLinks – Same as GetOptionalAppLinks but for required AppLink packages
    • GetShortcutList – Get a list of entry points
    • GetVFileSystemObject – With this method you can access the virtual file system
    • GetVRegistrySystemObject – With this method you can access the virtual registry
    • Install – Install the ThinApp MSI package on the local machine
    • MacroToPath – Show the real folder (C:Program Files) behind a macro folder (%ProgramFilesDir%)
    • PathToMacro – Check if local folder (C:ProgramData) is represented by a macro folder (%Common_AppData%)
    • Register – Register the ThinApp package on the local machine
    • RetriveIcon – Extract an icon out of an entry point or data container
    • Uninstall – Uninstall the ThinApp MSI package on the local machine
    • Unregister – Unregister the ThinApp package on the local machine
    • UnregisterEx – Undocumented

    Covering every single one of these methods would go beyond the scope of this article. But I’ll give you two examples:

    Example 1: Retrive AppLink configuration
    The first example will show you how to retrive the configured AppLinks for your ThinApp package.

    $ta = New-Object -ComObject ThinApp.Management
    $tap = $ta.OpenPackage("Z:ThinAppAppsMozilla Firefox.exe")
    $tap.GetOptions() | Where-Object {($_.Name -eq "OptionalAppLinks") -or ($_.Name -eq "RequiredAppLinks")}

    We are creating our ThinApp object (line 1), loading our package as additional object (line 2) and then retrive the AppLink configuration using the GetOptions method. With the Where-Object statement I filter the results so that just the optional and required AppLink options are listed (line 3).

    Example 2: Force an AppSync update
    In this example I will show you how to trigger an AppSync update without starting the application itself.

    $ta = New-Object -ComObject ThinApp.Management
    $tap = $ta.OpenPackage("C:ThinAppNotepad++.exe")
    $tapAppSyncUrl = ($tap.GetOptions() | Where-Object {$_.Name -eq "AppSyncURL"}).Value
    $tapAppSyncUpdate = $tap.AppSyncUpdateAvailable("$tapAppSyncUrl")
    if ($tapAppSyncUpdate -ne $null) { $tap.AppSync(1,"$tapAppSyncUrl") }

    As usual we create our two object (line 1 and 2). Then we get the AppSync URL out of the options and save it in a variable (line 3). Thereafter we check if an AppSync update is available (line 4) and if this is the case we update the package (line 5).

    I hope with this introduction I could provide a taste of the things possible with the ThinApp SDK in combination with PowerShell. If you want to learn more download the ThinApp SDK and get started with it. After downloading and extracting the SDK you will also find a PDF documentation on the SDK called ThinAppAPI.pdf – give it a look.