We’re running a vCenter Server 4.1 environment with Windows XP SP3 linked clones. By default our users are not administrators on their virtual desktop. We’ve created a ThinApp version of Adobe Acrobat X Professional with a volume license key.
When the ThinApp is run it returns the license error number: 213.22
However if we make the user an administrator on the virtual desktop then it works fine. I’ve compared the log files for users with and without administrator privileges and the differences are as follows...
User With Administrator Privileges:
2011-12-21 08:31:34 [2972] SLCoreService: Found client mkey
2011-12-21 08:31:34 [2972] SLCoreService: Loading license references
2011-12-21 08:31:34 [2972] SLCoreService: Found 0 license file(s)
2011-12-21 08:31:34 [2972] SLCoreService: License store synchronization took 1733.1 ms and succeed
2011-12-21 08:31:34 [2972] SLCoreService: Query license: type = 0, duration = 0 days, remaining = expired
2011-12-21 08:31:34 [2972] SLCoreService: Adding a new license file
2011-12-21 08:31:34 [2972] SLCoreService: Loading serialization grace SLR took 104.8 ms and succeed
2011-12-21 08:31:34 [2972] SLCoreService: Updating license file
2011-12-21 08:31:34 [2972] SLCoreService: Loading license from product config succeed
2011-12-21 08:31:34 [2972] SLCoreService: Query license: type = 2, duration = permanent, remaining = permanent
2011-12-21 08:31:34 [2972] SLCoreService: Updating license file
User Without Administrator Privileges:
2011-12-21 08:51:00 [1432] SLCoreService: Couldn't reset perms on license file
2011-12-21 08:51:00 [1432] SLCoreService: Couldn't update the perms on the machine key
2011-12-21 08:51:00 [1432] SLCoreService: Could not load machine key
2011-12-21 08:51:00 [1432] SLCoreService: License store synchronization took 916.0 ms and return "License Store Access Failure: File/directory permissions cannot be updated (213:22)"
2011-12-21 08:51:00 [1432] ALM: _time_: (func: ALM_License_SilentValidate, duration: 1.047 sec)
2011-12-21 08:51:00 [1432] ALM: _info_: ALM_License_SilentValidate return license status: Invalid and error: 213 : 22
2011-12-21 08:51:00 [1432] ALMService: ERROR: License_Check error 213:22. (Errno = 2)
2011-12-21 08:51:00 [1432] AMT: Deactivation or denial grace expiration of serial [970780619580968654114973]
2011-12-21 08:51:00 [1432] AMT: Application licensing status has changed to unlicensed
2011-12-21 08:51:00 [1432] AMT: ERROR: ALM failed to initialize and read trusted storage, hence no license
2011-12-21 08:51:00 [1432] AMT: Calling AUM API to create scheduler entry to be used by updater
I’ve followed the steps in the following Adobe knowledge base article: http://kb2.adobe.com/cps/896/cpsid_89617.html and confirmed that the ThinApp is allowing the user read/write access to the necessary directories regardless of whether they're an administrator.
Has anyone else been able to create a ThinApp of Adobe Acrobat X Pro? Any thoughts on what else we could try?
Any help would be greatly appreciated.
Thank you.
What is the ThinApp captured OS and deployment OS?
Similar thread that you may try:
After several months of trying we abandoned virtualization of Acrobat X and Acrobat 9. Here's why:
I guess if you don't care about the most significant and frequently used features of Acrobat then it's a great candidate for application virtualization. Please note hints of bitterness and sarcasm.
If you can get Acrobat to 'be Acrobat' and not 'Acrobat Lite' with ThinApp, please let us know.
As for licensing, I use the Acrobat Customization Wizard to create my installer, I bake in our corporate serial, turn off registration and activation by users, accept the license agreement, and install to C:\AAXPRO or C:\AAXSTD, depending on if the version is Pro or Standard. We aren't doing VDI yet, so I can't comment on View issues at this time.
Good luck.
Thanks for your feedback.
We're capturing on a Windows XP SP3 OS and the deployment OS is likewise. I've tried the recommendations in the external thread above for Adobe Acrobat Version 9 but the result was the same.
At this point we're looking at abandoning the idea of using ThinApp for Adobe Acrobat and simply creating a new template with it already installed for those users that require it.
This problem has been addressed.
Here is a short description of what you might be facing:
The problem lies in Adobe setting restricted DACLs on license folders. The runtime interprets this and sets the DACLs on the sandbox. Now, when a file needs to be extracted to the license folder, this fails and causes adobe to hang and at times crash.
Follow the steps for getting this resolved:
Build a batch file using the following template and copy this into %drive_c%
@echo off
if exist "c:\Program Files (x86)\Common Files\Adobe\Test" goto second
move "c:\Program Files (x86)\Common Files\Adobe\Adobe PCD" "c:\Program Files (x86)\Common Files\Adobe\Adobe PCD 2"
move "c:\Program Files (x86)\Common Files\Adobe\Adobe PCD 2" "c:\Program Files (x86)\Common Files\Adobe\Adobe PCD"
mkdir "c:\Program Files (x86)\Common Files\Adobe\Test"
goto second
This will copy all the contents into the sandbox.
Now, in package.ini add and entry point to this batch file and you are done.
[LaunchAdobe.bat]
Source=%drive_c%\launch adobe.bat
Shortcut=Adobe Acrobat 9.dat
Disabled=0
This should most definitely address your issue.
-Neeraj
I had this issue to and fought it for hours. After working with VMware support, I figured out the issue was with our Adobe license and the Sandbox location. We were originally running the sandbox to our CIFS share at the full UNC path \\server\sandbox\%username%. After trying several things including the batch file solution above, I moved the sandbox to the local user profile %userprofile%\Sanboxes in the package.ini file and rebuilt the application. After that I was able to run Adobe X Standard without error under an administrative account. We use Persona Managment so the sandbox will be uploaded to the profile share and will therefore be backed up and transferred between virtual desktops.
I still have some testing to do with regular users and still don't know why Adobe puked. It must be a lack of the volume license or something. However I wanted to post to just maybe save people hours of work.
Unfortunately, for us, too much time spent troubleshooting explorer shell integration, Office macro integration, and Distiller issues, meant that sticking with native Acrobat and Office is still a necessity.
I had a similar problem with this at first, what I ended up doing was adjusting the permission settings to the program files folder and adobe folder that had all the contents for Acrobat X. Basically modify permissions need to be allowed for users and system. By default they were disabled in my case. Once I enabled these and recaptured the application the license issue went away. This helped me figure it out... http://forums.adobe.com/message/4162697
@griakul i've tried the same, but i still get a license error with useres without admin priveleges. Wich system did you use for capature? This system domainmember? Did you allow "Domain-User" or "Local-User" modify rights?