ThinApp SDK: Recursive ThinReg

ThinApp SDK: Recursive ThinReg

Recursive registration of ThinApp packages

Usage: RecursiveReg.vbs <FolderName>

RecursiveReg will register all ThinApp entry points in FolderName and in any subfolders The registration will be per-user. Any entry points to which the user no longer has access (because of the PermittedGroups setting) and which are already registered will be automatically unregistered.

Since this is based on the ThinApp SDK you'll obviously need ThinAppSDK.dll/ThinAppSDKSrvr.exe present and registered (using regsvr32) on the system.

License: do whatever you like with it, but don't blame me or VMware. More formally: VMware Contributed Sample Code.pdf

Tags (2)
Attachments
Comments

Hi,

I've tried the script, but run into an issue with system folders. We store all thinapps into subfolders on a drive d:\. Because of system folders like "recycler" and "system volume information" the script breaks. To avoid that, we modified the script with a simple if-condition for the subfolder attributes:

' Now do the sub folders

Dim SubFolder

For Each SubFolder in Folder.SubFolders

' Change DCasota 29.11.2010

if not SubFolder.Attributes AND 4 then

ProcessFolder SubFolder, TAManagement

end if

Hi,

I came up with almost the same script, but I have a problem when I run it, everytime the "Package.Register 1" line is executed, the desktop flashes (I guess to reflect the possible addition/removal of icons).  With over 100 ThinApp packages, this flashing get very annoying...  Do you have the same problem at your place ?

Thanks, Yves

Yes, that's rather annoying. In the next release, we've added a "Don't refresh the desktop" flag for the Register method (numeric value 32) so you can fix this when that next release becomes available (sorry, I'm not allowed to talk about release dates in public) by using "Package.Register 33".

Hi

We have had the same problem, so I'm glad to hear that there will be soon an update for the desktop refresh after each package registration. We implemented a workaround by hiding the desktop until the registration finished.

A bigger problem is that the register process takes too long. Users don't want to wait more than 1 minute for the whole login process and they don't care about that the package repository contains hundred thinapps. They only see their own 5 apps. We try to avoid longer login times by registering common and pool-specific thinapps (vmware view) by using post-sync skripts and by detecting during the login process in which thinapp AD permission groups the user is. This improves the login time if the user has much less thinapps to register as the whole repository contains.

I agree that registering 100 apps or more takes a long time, but if the desktop does not flash, you won`t need to display anything on screen while registering the apps.  So no matter how long it takes, the user won't notice.  He can start using his workstation WHILE you're still registering the apps (except for a new app of course).  If you want to be sure you don't slow him down, you can even put a short delay between each registration to free up the CPU (and without the desktpo flashing, app registration might be much faster).

Sorry, I should explain our customers business case:

We have 80% floating desktops in 3 pools, 20% physical clients and a roaming profile solution (flex profiles) in combination with folder redirection. There are some obstacles in such business cases:

Folder redirection is perfect to minimize the profile size, however in combination with thinapp packages we have to manage the dynamically created startmenu, programs menu, quicklaunch bar and desktop icons placement. In short: users want to place their icons where they want. So a technical obstacle with recursive thinapp registration is the menu order and icon placement preservation. We try to manage that by waiting until all thinapps have been registered and recover afterwards placement and order settings. That's the reason why we don't display the screen already because users complain that the icons don't appear where they expect.

Another obstacle is - we call it "cross client functionality" - if a user is roaming from a virtual desktop  to physical client with not the identical software base (native installed and thinapps).

To manage that we deregister thinapps on logoff (so folder redirection won't carry those settings to a physical client). The menu order and icon placement preservation should be stored client specific ( but actually this doesn't work as expected...).

How do you guys manage those things? Are there any out-of-the-box solutions?

And here you can find an updated version of the script that includes the thinreg utility to aviod the flashing desktop.

http://automatethecloud.blogspot.com/2012/01/recursive-thinreg-with-no-desktop.html

Hello AutomatetheCloud,

We tried the script but it failed to start..

Line 85 char 1

Error: The handle is invalid
Code: 80070006
Source: (null)

It looks like we get an access denied when using wscript.stdout.writeline

If we replace wscript.stdout.writeline with wscript.echo the script is running.

But this results in pressing manually OK a couple of times for every folder the script finds and also not all thinapps get registered.

We are going to continue troubleshooting..

We found the error.. you also need to set quotes for the foldername(FileName). (otherwise the Thinreg.exe command failes when using spaces in the file and foldername).

Change:

MyThinReg = "thinreg " & FileName & " /nodesktoprefresh"

To:

MyThinReg = "thinreg " & Chr(34) & FileName & Chr(34) & " /nodesktoprefresh"

Cheers,

Dennis

Version history
Revision #:
1 of 1
Last update:
‎10-06-2010 01:18 AM
Updated by: