Squidly_Man's Posts

Thanks!!! Awesome write-up! Dean Flaming | 253.256.DEAN | 253.256.3326 | DFlaming@vmware.com vmware | ThinApp & Horizon Global Product Specialist ThinApp Documentation - http://pubs.vmwar... See more...
Thanks!!! Awesome write-up! Dean Flaming | 253.256.DEAN | 253.256.3326 | DFlaming@vmware.com vmware | ThinApp & Horizon Global Product Specialist ThinApp Documentation - http://pubs.vmware.com/thinapp4/help/ Horizon Documentation - http://pubs.vmware.com/horizon-administration-help/index.jsp ThinApp Info Smartphone App - http://wbxapp.com/thinapp-info (browse here on your smartphone!)
Please see the below mentioned blog posting for enabling SEND AS.  The blog posting is centered around Office 2007 but others have tested for Office 2010 and it does work so long as the registry ... See more...
Please see the below mentioned blog posting for enabling SEND AS.  The blog posting is centered around Office 2007 but others have tested for Office 2010 and it does work so long as the registry value(s) mentioned are modified to accommodate Office 2010 products. Enabling "Send As Email Attachment" in ThinApp packages when Outlook is installed natively
Make sure sandboxes are deleted and you are testing on a fresh system because a leftover sandbox will cause false results.
Essentially what is happening is these are the roughly 30 or so Class IDs associated to various different installs of MS 2010 products such as Office Standard, Office Pro Plus, Office Home and St... See more...
Essentially what is happening is these are the roughly 30 or so Class IDs associated to various different installs of MS 2010 products such as Office Standard, Office Pro Plus, Office Home and Student, Office Pro, Project Pro, Project Std, Visio Pro, and individual app installs such as Word, Excel, Outlook, PowerPoint, and Access. Very basically, if what is installed natively doesn't match with what is packaged with ThinApp, then there are license activation issues. Since ThinApp runtime loads the reg hives from top to bottom, deleting everything up front (at the top of the Local Machine registry hive) allows for the ThinApp package to only see just what it needs and none of the native settings which may interfere (as there are invariably going to be a couple of these further on down in the Local Machine hive for your ThinApp package of whatever MS 2010 product you are packaging - meaning ThinApp will load these as needed). In short, by adding these values to the HKEY_LOCAL_MACHINE.TXT registry hive file, you are helping ThinApp properly isolate the MS 2010 app in question from whatever native settings in order for the ThinApp package to load and work correctly. Hope this helps explain what is going on here.
Thanks for posting the pics!  The weird thing is I'm not able to recreate this in my lab. Can someone share their capture environment config?
Can someone post a screen shot of the symptoms/issue? I assume this is what we are discussing (below link) but I want to be sure. http://blogs.vmware.com/.a/6a00d8341c328153ef0133ef1f3bdd970b... See more...
Can someone post a screen shot of the symptoms/issue? I assume this is what we are discussing (below link) but I want to be sure. http://blogs.vmware.com/.a/6a00d8341c328153ef0133ef1f3bdd970b-pi
That is a great question.  And there are usually two schools of thoughts: Virtualize just your pain points or virtualize all apps in hopes of making a truly dynamic desktop where the apps are mod... See more...
That is a great question.  And there are usually two schools of thoughts: Virtualize just your pain points or virtualize all apps in hopes of making a truly dynamic desktop where the apps are modular. There is nothing wrong with either method except when one or the other causes you more work than necessary to achieve your IT goals. I am more of a "virtualize your pain points" kind of person so I typically recommend virtualizing apps to resolve the following: App Conflicts, App Deployment and App Update issues/struggles, App Support issues, and when legacy apps such as IE6 are needed on newer systems. Outside of these 5 areas, virtualization of applications (in my opinion) tends to be more work and effort than the gain received...so having a valid business case for virtualizing the app is key.  If the app is something which everyone gets (such as an Office suite), is it easier to place this in the Desktop Gold image?  Especially when MS Office gets its updates through the same mechanisms as the Windows OS? Many have found it's often enough to just solve the painful app issues, allowing the move of IT resources to more pressing matters and obtaining a flexible AND stable environment since there are no longer app conflicts between native and virtual apps and updates are not as big an issue. My 2 cents...
See http://blogs.vmware.com/thinapp/msi/ for additional ThinApp MSI documentation.
See http://blogs.vmware.com/thinapp/scripts for some VB Script examples. With those, you should be able to extrapolate for PowerShell.
Don't forget File System/Folder Isolation can come into play here.  If the destination folder exists within the project, the folder should definitely be set to merged isolation and probably be em... See more...
Don't forget File System/Folder Isolation can come into play here.  If the destination folder exists within the project, the folder should definitely be set to merged isolation and probably be empty (other than the ##ATTRIBUTES.IMI file).  If the destination folder doesn't exist in the project then its parent folder (or the project as a whole) should be set to merged isolation.  Don't forget, changes to folder isolation can also be done on the fly with scripting.  Check out the ThinApp Bootcamp session on scripting which releases in the next day or so.  http://vmware.com/go/thinappbootcamp -Dean F.
Updating the file in the sandbox externally (from outside the ThinApp package) is not recommended as the ThinApp runtime keeps track of the files and settings and changes with them and this could... See more...
Updating the file in the sandbox externally (from outside the ThinApp package) is not recommended as the ThinApp runtime keeps track of the files and settings and changes with them and this could potentially cause instabilities in the package. For files which need to be updated from time to time where the desire is not to rebuild the ThinApp package (and redeploy), it's recommended to leave the file native and set the folder isolation to MERGED.  Other files in the same folder which exist virtually will remain virtual and not get written to native.  Any other new files in the same folder will be created natively. For a refresher of Isolation Modes, see Peter Bjork's video on ThinApp Isolation Modes Explained. Another way to do it is create a script which checks for any updated versions of the file in question and embedd said script into the ThinApp package so the update is done on the fly.  This will conduct the update to the file in question without requiring additional rebuilds.  For additional information on scripting, see the ThinApp Blogs Scripting section. -Dean F. ThinApp Pubs
Please contact VMware Support and request licensing support if you are unable to obtain an eval license.  VMware support can be contacted on the web at http://www.vmware.com/support or by phone a... See more...
Please contact VMware Support and request licensing support if you are unable to obtain an eval license.  VMware support can be contacted on the web at http://www.vmware.com/support or by phone at 1-877-4-VMWARE (1-877-486-9273) or 1-650-475-5345. -Dean F.
Peter is correct on all accounts. However, on the off chance running a ThinApp packaged app which was captured on a clean Capture and Build VM which has a C: drive ends up failing when running... See more...
Peter is correct on all accounts. However, on the off chance running a ThinApp packaged app which was captured on a clean Capture and Build VM which has a C: drive ends up failing when running on a Windows OS which doesn't have a C: drive (as in your case), then you can always remap the root drive of the Clean Capture and Build VM prior to doing your ThinApp Prescan/App Install/Postscan/Build. I believe Citrix's DRIVEREMAP.EXE tool still resides on the XenApp/MetaFrame/Presentation Server install cd.  Just copy that to your clean Capture and Build VM and run it on there as it shouldn't be Terminal Server OS specific. Hope this helps. -Dean F http://pubs.vmware.com/thinapp4/help/
To clarify, the issue I am speaking of occurs when one captures with ThinApp 4.6.1 and the builds with ThinApp 4.6.0 or earlier without modifying the PACKAGE.INI settings mentioned above.  An exa... See more...
To clarify, the issue I am speaking of occurs when one captures with ThinApp 4.6.1 and the builds with ThinApp 4.6.0 or earlier without modifying the PACKAGE.INI settings mentioned above.  An example would be, you capture on one system and then copy the project out to a network share and use ThinApp on another system to build that project into a package (not realizing the ThinApp version used to build is an older version). As for your issue, I went back and looked at the PACKAGE.INI file and your entry points which are enabled do not have an ending ".EXE" in the section title.  This is needed. Your Entry Point: [Analysis Tools] Source=%ProgramFilesDir%\SysTrackTools\Analyze.exe Shortcut=SysTrack Admin Tools.dat workingDirectory=%ProgramFilesDir%\SysTrackTools\ Shortcuts=%Desktop%;%programs%\Systrack What it should be: [Analysis Tools.exe] Source=%ProgramFilesDir%\SysTrackTools\Analyze.exe Shortcut=SysTrack Admin Tools.dat workingDirectory=%ProgramFilesDir%\SysTrackTools\ Shortcuts=%Desktop%;%programs%\Systrack NOTE:  I bolded and change the color to red on the one change I made (adding the ".exe" in the entry point name). To read more on entry points and how they work, see the ThinApp Blogs article "ThinApp Data Containers, Entry Points, and DATs - Oh My!". Also see the Online Pubs article "Defining Entry Points as Shortcuts into the Virtual Environment" -Dean F. http://pubs.vmware.com/thinapp4/help/
Please check the version of ThinApp you are building with.  You captured with ThinApp 4.6.1 but if you are building with an earlier version of ThinApp, you need to change the ReadOnlyData to bin\... See more...
Please check the version of ThinApp you are building with.  You captured with ThinApp 4.6.1 but if you are building with an earlier version of ThinApp, you need to change the ReadOnlyData to bin\Package.ro.tvr in order to build with older versions (4.6.0 or earlier) of ThinApp. -Dean F. http://pubs.vmware.com/thinapp4/help/
A "How To" on packaging MSDE can be found here. http://blogs.vmware.com/thinapp/2009/03/how-to-thinapp-msdesql-2005-express.html -Dean F. http://pubs.vmware.com/thinapp4/help/
While Peter is correct about 32-bit vs 64-bit, in this case with drivers it is important to note no true app virtualization solution will virtualize drivers as drivers are communications with log... See more...
While Peter is correct about 32-bit vs 64-bit, in this case with drivers it is important to note no true app virtualization solution will virtualize drivers as drivers are communications with logical or physical devices and are controled by the OS. You'll need to ensure the drivers are installed natively on those systems in order to for Windows to utilize and the app to integrate with them. While we're on that topic, you'll need to ensure your drivers for your application will work on a 64-bit system as well...so the question you'll want to answer for yourself is, can the application be installed natively along with the drivers and work correctly on a 64-bit system??  If so, then your drivers just need to be registered natively.  If not, then you'll need to have the developers create 64-bit compatible drivers for the application to utilize on a 64-bit system. Hope this helps! -Dean F. http://pubs.vmware.com/thinapp4/help/
I know the documentation says VMware still supports it but too my knowledge I believe VMware stopped supporting NT4 with ThinApp 4.6.0. I just tested this yesterday and ThinApp 4.6.0 still wor... See more...
I know the documentation says VMware still supports it but too my knowledge I believe VMware stopped supporting NT4 with ThinApp 4.6.0. I just tested this yesterday and ThinApp 4.6.0 still works on a cleanly built NT4 SP6a system so you can still use that. I didn't test the install of ThinApp 4.6.0, just the Setup Capture.  If the install fails, you can always use the command line switches to extract it out of the EXE and MSI and then manually place it on the system.  Use a "/?" on both the EXE and on MSIEXEC.EXE to see their respective helps for extracting their contents. -Dean F. http://pubs.vmware.com/thinapp4/help/
i think i spoke too soon.  it appears a ThinApp package of Mathematica will only work on Win 7 when the ThinApp package (EXEs and DAT) is copied to the desktop (and by that I mean the actual user... See more...
i think i spoke too soon.  it appears a ThinApp package of Mathematica will only work on Win 7 when the ThinApp package (EXEs and DAT) is copied to the desktop (and by that I mean the actual user's Desktop folder) and executed directly from the desktop. Troubleshooting continues... -Dean F. http://pubs.vmware.com/thinapp4/help/
I've been able to ThinApp Mathematica 8.0.0 on XP and get the package working on Win 7.  The weird thing about getting it to work on Win 7 is I could not leave the ThinApp package on the network ... See more...
I've been able to ThinApp Mathematica 8.0.0 on XP and get the package working on Win 7.  The weird thing about getting it to work on Win 7 is I could not leave the ThinApp package on the network share (a Server 2008 R2 share).  I had to copy the package local to the Win 7 32-bit local hard drive and then it would run.  The package would run fine on XP 32-bit from the Server 2008 R2 and would also run fine from a 32-bit share on the Win 7 OS so I'm guessing it's something specific to Mathematica 8, Win7, and the 64-bit share - but that's just a guess. Above all, I would say it's absolutely a need to capture on a clean capture and build system (XP Pro, no IE updates - just IE6, no .NET, no Java, nothing except SP3 and VMware Tools - assuming it's a VM) and then follow the ThinApp Troubleshooting Methods for testing. The only other thing I did was use ThinApp 4.6.1 to build the package and edit the PACKAGE.INI and add ProcessExternalNameBehavior=Original. Hope this helps, Dean F. http://pubs.vmware.com/thinapp4/help/