Jump to content
Welcome to our new Citrix community!
  • 0

Permission Error since Updating to ELM 2208, ELM 2211 doesn't fix


Computer Resources

Question

Hi, 

 

Brief: I can, in a layer before finalizing, use the app and have no permission issues.  What boggles my mind is that if I (mcs)publish the published template, the app will throw an access violation trying to access or update files. 

 

Seeing a fix related to ACL permissions listed on ELM 2211, updated and it didn't fix it. We use full user layers, Windows 10 21H2 LTSC. The applayer appliance, layers, and other are all hosted on premise in the same Nutanix cluster with AHV. CVAD/WEM is hosted in the cloud and we are using VDA 2209 with wem and cqi , We updated to applayer 2208 on 9/26/2022 and suspect the ELM or the various updates have caused the issues. The desktop produced 11/23 but took a while to get to the last group, sent to users by 12/15/2022. The app throwing access violation is Priority Dispatch ProQA medical. It resides in C:\Program Files(x86)\Priority Dispatch\ProQA\Medical. The errors are listed, mostly for the proqa.ini file but I believe there are a few other files in the same directory that have errored files that come up. exe is medical.exe and the .ini file is proqa.ini. The app vendor says you must add everyone to the ProQA folder, which we do, always did and verified. The access violation on proqa.ini says cannot write to file, but we see the file date changed so we aren't sure what the trouble is. We've tried this with the proqa app version valid around 9/13/2022 and the newer version of the app. This error occurs on a version layer that was not, originally,  created on ELM 2208 but the new template was published in ELM 2208 and eventually ELM 2211. The ProQA layer update pre-dated the ELM update by a 1-2 weeks. The ProQA program is started and ended by another program onesolutioncad.exe. The new published template had many updates including Windows, Antivirus and a bunch of other applications. Error was mostly observed the first time it was closed and was repeatable in the same session. It may take several attempts to produce the error.  It could also pop the error in the background and not be observed by users causing a failure when the program starts a new record. The application is line of business and used by 911 dispatchers to provide consistent responses to medical emergencies. If the ProQA app errored in the background, a dispatcher wouldn't know until they tried to launch the medical program..then it wouldn't launch. I'm not saying this update overall went well, I've had to resolve other issues with apps this update and at least another issue still open to resolve. It's been a real challenge to chase this down and the lack of success is draining my enthusiasm. This issue has only made me cry a little.

 

This is fully repeatable. This occurs on users with old user layers, new user layers and almost every user in the group has experienced the issues. We rolled back to the original desktop from August 2022(?) with VDA 2206 this had the identical proqa version and layer on it and the issue is not occurring. 

 

We tried a lot of resolutions, most were on tried on the published image originally, then I started publishing new images. There was a lot of exclusion testing that tells me what it isn't. I've tried to document everything important. Nothing I've listed actually resolved the issues but #7 worked on a certain context. 

 

All below failed, close to in order:

 

1. Tried userlayer repair and new full user layer. 

2.

a. Verified Inherited permissions looked the same down to the medical.exe and proqa.ini permissions. (several groups and Everyone)

b. Removed all permissions, added identical explicit permissions starting at Priority Dispatch downward. 

c. removed all permissions and added explicit permissions for Everyone Only down the filepath C:\Program Files(x86)\, C:\Program Files(x86)\Priority Dispatch\, C:\Program Files(x86)\Priority Dispatch\ProQA\Medical. 

3. At some point, I realized the Priority Dispatch folder was being retained on user layers. I suspected this was carrying over the permission set. Excluded C:\Program Files(x86)\Priority Dispatch\ in AlwaysOnBoot. I did create an exclusion text file for the same and popped it in a new publish of the ProQA layer. verified it was no longer retained on user layers, cleaned up multiple users and issue still perisists.

4. a. Publish template with new revisions of the OS Layer and Platform layer running cleanup with DISM and SFC utilities. Eventually this included all new layer versions of the affected apps.

b. Ran a stripped down Only OS Layer, Platform Layer, ProQA layer in a published template. Manually installed onesolutioncad.exe

5. Published template with only OS Layer and Platform layer and installed proqa and onesolutioncad.exe manually. 

6. Seeing ELM release notes for 2211. Found: listed in What's New, Fixes: Fixed an issue causing Access Control Lists to be ordered incorrectly in newly created folders. The issue caused some entries in these folders to be ineffective. [ALHELP-1632]. Updated to 2211 on 1/16/23. Republished original template on ELM 2211. Repeated allor most of the steps 1-5. 

7. Create new revisions of proqa layer, onesolution layer, misc. layer that includes some required scripting on ELM 2211. I then published a new ProQA layer (prior to finalizing) with the OS Layer and prerequisite Platform, Misc and onesolutioncad.exe layer. THIS WORKED and I had never tried this before. It lacks some congruency with production: Using Local Administrator, no user layer, non-domain join, no gpos. Published MCS desktop made exclusively of those layers. THIS DIDN'T WORK, got error first try. 

8. We normally open the published template before MCS publishing for a few reasons but I tried it without opening the published template and get the same thing. 

9. At some point I made an entirely new ProQA layer, seeing no success I abandoned and deleted that. But I do think layer prioritization 'could' come into play during compositing. I 'could' try that again now on the new version of ELM. 

 

On #7. This inconsistency has me looking into applayering as the cause.  It works on the layer before finalizing but doesn't in the published image.  I'm a little hesitant to take this to support for Citrix, ProQA or the OneSolutionCAD vendor since it's not for sure clear which app is causing the issues. BUT it is clear, that it's coming up AFTER the desktop is MCS/machine catalog/delivery group published. Up until now, it's ONLY limited to Applayer published desktops AFTER the ELM update to 2208 and other applications. That's why I'm writing to this forum, maybe an  applayer issue? maybe the OS Layer is hosed.

 

No resolution yet. 

 

The publishing of template, particularly compositing, is indistinguishable from magic on my part. I would need to know if that production is causing a compositing conflict of sorts. Is the way to rule this out to publish a fully new ProQA layer that would put it in priority just behind the Platform layer?  I couldn't get the layer prioritization tool to work. 

 

What should I try next? Are any of these more likely than another? :


1. Entirely new app layers(I've got written recipes for everything but these are fairly involved and a heck of a cooking day). Start with new proqa layer is easiest.  Potential New Platform layer. (ALREADY TRIED SINCE this was started - UNSUCCESSFUL)
2. New OS Layer built from scratch imported into the appliance. The original OS Layer started about July 2018 but this could end up in rebuilding everything. The original OS Layer was on Windows 10 2016(1607) LTSB, then upgraded to Windows 10 2019(1809) LTSC and Windows 10 2021(21H2) LTSC. (ALREADY TRIED SINCE this was started - UNSUCCESSFUL)
3. I've wanted to try a different directory for the app. Like C:\proqa. But the file path for ProQA is specified in the OneSolutionCAD systemwide and I can't change it for two 911 centers without causing issues. I may be able to do this in the training environment though if this seems a good route. (NOT TRIED)
4. I can try rolling back to my oldest OS Layer, Apr 2022 and building up to see if the issue goes away. (ALREADY TRIED SINCE this was started - UNSUCCESSFUL)
5. Remove Full user layer option as troubleshooting step.  (ALREADY TRIED SINCE this was started - UNSUCCESSFUL)
6. Re-publish template without Platform layer. (existing Os Layer and existing 3 app layers). Install citrix components on the published image, domain join. If successful, could establish needing a new platform layer.  (ALREADY TRIED SINCE this was started - UNSUCCESSFUL)

 

See attached errors. I'm not sure if the last one with the loopback error is actually an issue with the new desktop. 

proqa_medical.exe_error.JPG

proqa_proqa.ini_error.JPG

proqa_loopback_error.JPG

Edited by Cary Jeffers
cleaned up 'Publish' as either 'Published Template' or 'Published to MCS', edits for clarity. -- 2/9/2023 Additional Updates on troubleshooting tried and outcome
Link to comment

7 answers to this question

Recommended Posts

  • 0
3 hours ago, Rob Zylowski1709158051 said:

When you look at the permissions on the files do you see an error that they are out of order.  You would if they were.  Do the permissions look correct?  Assuming you can see them. 

 

If you use a local admin account will the apps work?

 

No errors on permission now. Permissions look absolutely correct.. currently doing Inheritance since I found no issues. (will attach a picture) I do think I saw one or two incorrectly ordered on one of the directories for this app like last week before ELM2211 update. 

 

Well my one working test #7 WAS using local admin and was successful. I tried that on the gold image(not a mcs published catalog yet)  and it appears Local Admin is always working (good). Is this setup what you had in mind with 'Try Local Admin'?  I at least 3 calls, logoff/logon, at least two calls, logoff/logon, at least two calls and couldn't generate the error.

 

I found another difference that I may have not seen before... when you launch the onesolutioncad.exe it launches the proqa app, medical.exe.  Up until now,  I observed that medical.exe shows up as 'disconnected' until an actual call is made, then stayed connected thereafter.. at least in the super short duration of each session. This is along the lines of the last error pictured.. unable to connect to 127.0.0.1:4001 . Now, looking at using local admin at the gold image level, when you launch the onesolutioncad.exe it launches the proqa medical.exe and there is no disconnected message. It is connected. This is on the published template and I start it up to test Local admin.  I've verified the proqa.ini contains 127.0.0.1:4001 connection details before onesolutioncad.exe launch and after the error. Seems like this might just be a file read issue, could be the same cause I'm trying to troubleshoot with the other errors. Like it can't read that file during startup but can read it when the program is called to launch.

 

It's noted that I had also tried re-publish (to template image.. not MCS, catalog/delivery group)without user layering in the meantime and got the errors. 


 

ProQA_Permissions_on_Medical.exe.JPG

ProQA_Permissions_on_ProQA.ini.JPG

Link to comment
  • 0
On 1/26/2023 at 2:18 PM, Computer Resources said:

 

No errors on permission now. Permissions look absolutely correct.. currently doing Inheritance since I found no issues. (will attach a picture) I do think I saw one or two incorrectly ordered on one of the directories for this app like last week before ELM2211 update. 

 

Well my one working test #7 WAS using local admin and was successful. I tried that on the gold image(not a mcs published catalog yet)  and it appears Local Admin is always working (good). Is this setup what you had in mind with 'Try Local Admin'?  I at least 3 calls, logoff/logon, at least two calls, logoff/logon, at least two calls and couldn't generate the error.

 

I found another difference that I may have not seen before... when you launch the onesolutioncad.exe it launches the proqa app, medical.exe.  Up until now,  I observed that medical.exe shows up as 'disconnected' until an actual call is made, then stayed connected thereafter.. at least in the super short duration of each session. This is along the lines of the last error pictured.. unable to connect to 127.0.0.1:4001 . Now, looking at using local admin at the gold image level, when you launch the onesolutioncad.exe it launches the proqa medical.exe and there is no disconnected message. It is connected. This is on the published template and I start it up to test Local admin.  I've verified the proqa.ini contains 127.0.0.1:4001 connection details before onesolutioncad.exe launch and after the error. Seems like this might just be a file read issue, could be the same cause I'm trying to troubleshoot with the other errors. Like it can't read that file during startup but can read it when the program is called to launch.

 

It's noted that I had also tried re-publish (to template image.. not MCS, catalog/delivery group)without user layering in the meantime and got the errors. 


 

ProQA_Permissions_on_Medical.exe.JPG

ProQA_Permissions_on_ProQA.ini.JPG

 

Hi, I'm working on this again today. Any ideas on best way to resolve the issue ?

 

Up there I wrote "no errors on the permissions now"... that could be taken wrong.  The permission error still happens when launching the program as a domain user. There are no errors on the properties of the security settings indicating that they are incorrectly ordered. I did see that some time early on. 

 

Thank you, Cary

 

Edited by Cary Jeffers
Link to comment
  • 0
On 1/31/2023 at 12:44 PM, Computer Resources said:

 

Hi, I'm working on this again today. Any ideas on best way to resolve the issue ?

 

Up there I wrote "no errors on the permissions now"... that could be taken wrong.  The permission error still happens when launching the program as a domain user. There are no errors on the properties of the security settings indicating that they are incorrectly ordered. I did see that some time early on. 

 

Thank you, Cary

 

 

This still isn't fixed. I've added a few more things and believe since it's working correctly with domain users, not using applayering, that I should open a support case with Citrix.

 

10. Created fully new OS Layer from Windows ISO, imported into appliance, created the three supporting layers on the new OS Layer. published in applayer and sent to MCS, I get still the permission error (on domain users)

 

11. That same Image.. before it's imported as an OS Layer, I installed the medical.exe and required applications. Sent to MCS publish and it's working fine on domain users.  I DIDN'T get the permission error, SO IT WORKS FINE outside of App Layering. I don't know how to make it work within the applayering though.. still need help. Unsure what the applayer issue might be.

 

Opened a case with support. 

Link to comment
  • 0

This still isn't fixed and being worked by an escalation engineer. An enormous amount of time has been spent on this. To the best I am able.. I've created test machines off of the same newly built OS image.. one applayer and one not.. the issue only appears on the applayer version.

 

Will it be easier to give up on AppLayering for this application and manually build a gold image for these users THAN try to find the cause?  I'm still and even more convinced today, that it is an AppLayering application issue. I've updated the Case #81680063 with some sharing violations captured in procmon. Plausibly a fight for file control between uniservice.exe and medical.exe. I'm still not sure how to prove it though. 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...