Packaging Error

Archived support forum for customers who once purchased a PrimalForms product license. This forum is locked.
This topic is 12 years and 6 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
User avatar
stcemail
Posts: 36
Last visit: Thu Jun 18, 2015 7:28 am

Packaging Error

Post by stcemail »




I ran some test on my end and I was unable to reproduce this error. Impersonate and RunAs worked without issue. David


That's nice. I have run, literally, hundreds of different tests now and have got it working once before in version 1.14 with an account that did not have required privileges.

So I am sure your test suite works super duper fine, but in my real world scenario it is not.
User avatar
davidc
Posts: 5913
Last visit: Mon Jul 08, 2019 8:55 am
Been upvoted: 2 times

Packaging Error

Post by davidc »

We may have found the issue. We should release a service build soon.David
David
SAPIEN Technologies, Inc.
User avatar
Alexander Riedel
Posts: 8478
Last visit: Tue Mar 26, 2024 8:52 am
Answers: 19
Been upvoted: 37 times

Packaging Error

Post by Alexander Riedel »

We have established a while ago that impersonation doesn't work in your environment, which is why we added RunAs just for you. The assumption was that the privileged account has access to everything the original user account can access.
From the error message and the fact that there is only one instance I can only deduct that this is not the case in your environment. We have taken steps to address that, but since we don't have an environment where this shows up we have no way of actually testing that.
So please download the next build, repackage and see if that make a difference.
Alexander Riedel
SAPIEN Technologies, Inc.
User avatar
stcemail
Posts: 36
Last visit: Thu Jun 18, 2015 7:28 am

Packaging Error

Post by stcemail »

We have established a while ago that impersonation doesn't work in your environment,


Actually that is not correct. And if that is the assumption you were using then that could be why subsequent changes did not work. It was established that special characters in the password was the problem. Using a different account with no special characters worked but that account did not have enough permission to run the associated commands within the executable. We were troubleshooting why it didn't work with the other account when I stumbled across the special character issue.

which is why we added RunAs just for you.

No. You did it to correct a flaw. It matters not that I found it.

The assumption was that the privileged account has access to everything the original user account can access.

The three accounts I am testing with all have the same privilege levels and are in the same security groups.


From the error message and the fact that there is only one instance I can only deduct that this is not the case in your environment. We have taken steps to address that, but since we don't have an environment where this shows up we have no way of actually testing that.
So please download the next build, repackage and see if that make a difference.


I have downloaded and tested the next build and the errors remain.

I am done attempting to make this work. I have lost dozens of hours of work production time troubleshooting this issue and I don't believe there has been any progress made nor do I see any forthcoming as other techs say "it works fine here". That does not fill one with hope that the issue is being taken seriously.

I will find another product or just use a scheduled task as this project is now 3 months behind schedule due to this issue.

Thank you and goodbye.
This topic is 12 years and 6 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.