Disable copy and paste or printing within your virtual application

Let me first say ThinApp is by absolutely no means a security product, it is an application virtualization product. But ThinApp, as an application virtualization product, certainly can help to make your environment more secure. For example when using ThinApp for your applications you can deploy critical patches much faster as it would be possible with traditional software deployment tool like SCCM or LanDesk.

That said customers still ask how they can disable certain functions within ThinApp to make their applications more secure. These functions are copy and past as well as cut and paste and of course printing. Obviously ThinApp can handle these requirements as one of the most versatile application virtualization solution on the market.

Disable copy and paste / cut and paste

To disable copy and paste within your virtual application you have to modify the package.ini in the [BuildOptions] section. To disable this functionality just add the following line:



If the user then tries to copy or cut and paste something he gets the following message by default.


You can change this message by adding just another line and modify the message as wanted.

DisableCutPasteMsg=Administrator has disabled Cut and Paste for application %1s

The variable %1s will be replaced by the name of the process of which you want to copy or cut content from. In this example it is firefox.exe

Disable printing

To disable printing from a ThinApp package you also have to add just another line to your package.ini build options.



When a user tries to print from the virtual application while this option is set he gets the following result.


If this tip may come in handy you should pay Christoph Harding’s (@cdommermuth) blog called That’s my view (http://www.thatsmyview.net) a visit. He brought this customer requirement to my attention.

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 Setup Capture doesn’t capture file type associations

Together with my friend Sebastian Stein (@BERSFO) from tempero.it we discovered a little problem with the ThinApp Setup Capture. When capturing an application, in our case we captures ACDSee, it may happen that the Setup Capture wizard doesn’t record the file type associations registered by the application.

You can easy fix this using the commandline tools assoc and ftype to reregister the file type associations during the capture process. For a detailed description see Sebastian’s article.

Virtualize ACDSee with ThinApp and register File Types

ThinDirect redirection message does not close automatically

Normally the ThinDirect redirection message disappears after a few seconds when a web page got redirected.


In some cases the redirection may working properly but the ThinDirect redirection message does not close automatically.


Most of the time the reason for this behavior is caused by very restrictive Internet Explorer security settings. In particular when the security setting option Active Scripting is disabled. This is the case if the standard security level High is chosen for the zone Internet where the ThinDirect add-on belongs to by default.


There are two solutions to get the redirection message to disappear again:

  1. Enable Active Scripting for the zone Internet or
  2. Add “about:internet” to the local intranet or trusted sites

Virtualize Microsoft Visio 2010 and Project 2010 while Microsoft Office 2010 is installed locally

My colleague Peter Björk (@thepeb) wrote a very helpful article on how to virtualize Microsoft Visio and Project 2010 while Microsoft Office is locally installed!

“While many are virtualizing Microsoft Office 2010 during a Proof Of Concept (POC) most companies decide to install Microsoft Office natively rather than virtualizing it. Both packaging method are valid but many times it’s easier and more efficient to have Office locally installed. That said, virtualizing Microsoft Visio and Project is a whole different ballgame. Virtualizing Visio/Project makes very much sense in many designs. There are quite a few KB articles and blog posts out there covering Office 2010 and it’s components. But so far I’ve yet to see a complete list of what is needed in order to build a Visio/Project package and have it coexist and to a certain degree integrate with native Office. So I started to collect all data I found on Internet. I ended up adding a couple thinks myself as well.”

Check out Peter’s article on the official VMware ThinApp blog.

ThinApp Microsoft Visio and Project 2010 while locally installed Microsoft Office 2010

ThinApp, OS migrations and application compatibility

Image source: http://memegenerator.net/instance/34382526

A picture is worth a thousand words.

We all know that the official support for Windows XP ends on April 8, 2014.

Therefore many customers starting to look at ways to migrate their legacy applications from Windows XP to a newer version of Windows. While many applications may run on Windows 7 (or later) without any hassle there are still some apps which aren’t working on Windows 7 out of the box. As always exactly these apps are most likely declared as business critical or at least very important.

Many people see ThinApp as the silver bullet when it comes to OS migrations and application compatibility issues. To a certain degree they are right, ThinApp can definitely help to solve many application compatibility issues and ease the pain of a Windows 7 migration. But ThinApp unfortunately can’t perform magic.

There are many reasons why applications won’t run on Windows 7. To understand if ThinApp can help or not we first have to analyse why applications may not run on a newer version of Windows.

Common Compatibility Issues
  • Deprecated .dll files, executable (.exe) files, COM objects, registry keys and application-programming interfaces (APIs)
  • Hard-coded locations (file locations, directories, registry keys)
  • User Account Control (UAC)
  • Operating System Version Changes
  • Dependencies to a specific Internet Explorer version
  • 64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications
  • Source: http://technet.microsoft.com/en-us/library/cc766242(WS.10).aspx

    Some of these issues can easily be fixed even with built-in Windows functions. For example an application may check on which operating system it is running (see Operating System Version Changes in the source link above) and refuses to run if not running on top of Windows XP. You can easily fool the application to think it is running on Windows XP even if it is really running on Windows 7 using the compatibility mode option.

    However other issues aren’t fixable at all. If an application relies on 16-bit components or is a 16-bit application itself and you want to migrate to a 64-bit version of Windows you are out of luck. The application simply will not work. You could however use VMware Workstation or View to deploy 32-bit virtual Windows machines for your legacy 16-bit applications. Another example for an application which will probably not work if it depends on APIs which are deprecated or undocumented and therefore not available or working different in Windows 7.

    Where ThinApp can’t help
  • Running applications which depend on deprecated APIs
  • Run 16-bit applications on 64-bit Windows.
  • Other reasons why an application might fail to work on Windows 7 like deprecated .dll files, hard-coded locations and dependencies to specific versions of Internet Explorer are a perfect fit for ThinApp!

    With ThinApp you are able to:

    As you can see there are many cases in which ThinApp can provide help running legacy Windows XP applications on Windows 7 even if they wouldn’t work when installed natively. However there are no guaranties this will work and it may require some effort to get it working. Still it is worth a try considering all the benefits you gain when using ThinApp especially when migrating to a newer version of Windows.

    If you want to know exactly when support for Windows XP will end you should try the official Windows XP End Of Support Countdown Gadget.

    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.


    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.

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

    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
    End Function
    Function OnFirstParentStart
    strMessage = "OnFirstParentStart: " & GetCurrentProcessName
    End Function
    Function OnFirstParentExit
    strMessage = "OnFirstParentExit: " & GetCurrentProcessName
    End Function
    Function OnLastProcessExit
    strMessage = "OnLastProcessExit: " & GetCurrentProcessName
    End Function
    strMessage = "OnEveryProcess: " & GetCurrentProcessName

    .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.


    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).


    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.

    How to check what ThinApp version a package was built with

    To check what ThinApp runtime version was used to build a single package you can use a simple command line argument.

    MyThinAppPackage.exe -thinstall


    While this is good enough to check one or two packages it isn’t very practical if you need to check a whole bunch of packages. Also the -thinstallversion command line parameter isn’t very script friendly either. But no worries the ThinApp SDK and PowerShell come to the rescue. The following script allows us to list the ThinApp runtime version of a specific file or all files in a folder (and subfolders):

    [ValidateScript({ Test-Path $_ })]
    $ThinApp = New-Object -ComObject ThinApp.Management
    $files = Get-ChildItem $Path -Recurse | ForEach-Object {$_.Fullname}
    ForEach ($file in $files)
    $ThinAppType = $ThinApp.GetThinAppType($file)
    $ThinAppType = $null
    If (($ThinAppType -lt 6) -and ($ThinAppType -gt 0))
    $ThinAppPackage = $ThinApp.OpenPackage($file)
    New-Object -TypeName PSObject -Property @{
    Name = $ThinAppPackage.InventoryName
    Version = $ThinAppPackage.ThinAppVersion
    Path = $file

    Row 1-7 is used to quiz the user for a path or a file. Then in row 9 the ThinApp com object is created and in row 10 a list of fully qualified file names (even of files in subfolders) based on the user provided path or file is created. In row 14 to 21 the script checks if it can get the ThinApp type of the current file and if not it catches the error. Within lines 23 – 30 if the current file is a valid (1-5) ThinApp package it reads out the InventoryName, file name and path and the ThinApp runtime version and creates a new PowerShell object for it.

    In action it looks like this:

    In order to use this script you have to register the ThinApp SDK (to learn how to do it visit my “Getting started with ThinApp SDK and PowerShell” article) and then just execute the script in a PowerShell console and provide a folder or file. Here are some examples:

    To check the version of a single file:

    .\Get-ThinAppVersion.ps1 -Path 'Z:\ThinAppApps\Mozilla Firefox.exe'

    To check the version of all files in the provided folder and subfolders:

    .\Get-ThinAppVersion.ps1 -Path Z:\ThinAppApps

    You can even check files and folders on a network share:

    .\Get-ThinAppVersion.ps1 -Path \\server\thinapp

    To execute this script your PowerShell execution policy need to be set to “Unrestricted” (or lower) as this script isn’t signed. More information about the PowerShell execution policy can be found via the following link: http://technet.microsoft.com/en-us/library/ee176961.aspx

    As the output is a fully functional PowerShell object you can do some cool stuff. For example you can create a CSV file listing all your ThinApp packages and the corresponding version or filter for a specific runtime version.

    To export the results to a CSV use this command:

    .\Get-ThinAppVersion.ps1 -Path Z:\ThinAppApps | Export-Csv -Path C:\temp\MyThinAppRuntimeVersions.txt

    To only list ThinApp packages which are using a specific runtime version use this command:

    .\Get-ThinAppVersion.ps1 -Path Z:\ThinAppApps | Where-Object {$_.Version -eq "4.7.0-556613"}

    Download the script using the button below: https://gist.github.com/timarenz/5318cb9fdf3d15a9ef41cdb01ffc2550

    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

    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

    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.


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

    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.

    ThinApp Factory workpool deployment fails with “OS Installation Failed”

    ThinApp Factory is an awesome tool for automating ThinApp packaging. Customers love it! Unfortuanetly with the current builds of ThinApp Factory (0.30, 0.31 and 0.32) there is a little bug when it comes to deploying workpools in combination with a localized version of vCenter.

    When trying to deploy a new workpool, no matter if it is based on an existing VM or a newly deployed VM using an ISO, the deployment fails and the workpool virtual machines are deleted immediately. As an error message you may see “OS Installation failed”.

    After some digging in the ThinApp Factory logs I found that there are some communication issues between the appliance and vCenter. When ThinApp Factory talks to the vCenter, vCenter sends back localized strings. In my case vCenter sends back the term “Geräte”, which is the german word for device. As this is a non ASCII character the appliance can’t interpret this answer and the deployment process fails. I also saw this issue with a french-localized vCenter instance.

    To solve this problem you have to force vCenter to load english language files. The following knowledge base article discribes how this is done: How to change the language of vSphere email alerts

    Another cause why the deployment could fail, especially when Windows XP is used, are missing Sysprep files on the vCenter server. Please see the following article on how to deploy Sysprep files to your vCenter: Sysprep file locations and versions