Oct 23 2020 05:28 AM
having an issue with Sage 200 trying to write a file into FSLogix profile disk so moved file using redirection.xml to local_username\appdata\local\ and it has successfully writes the folder structure there however intermittently it will fail on one file stopping the program open, logging users off and onto a different VM intermittently works, not sure if its an FSLogix issue or a WVD issue as dont have the issue on standard rdp with old UPD's or on on prem windows 10 machines. anyone seen similar
Nov 18 2020 12:25 PM
@StevenR we are also experiencing the same issue, we are using WVD and FSLogix but not the redirections.xml. We have found that the issue moves between users after reboots and after using process monitor we established the issue arises when Sage/.NET attempts to rename/merge the user.config. This stackoverflow displays the same issues but using Citrix:
His work around was to not use FSLogix, but this is far from ideal. Hope you find the extra information useful (or at least interesting).
This article suggests a development solution, which I am going to forward to our Sage support tomorrow. Fingers crossed they can ask Sage to implement a fix.
Nov 18 2020 12:33 PM
Hi @brmmmm78 , well all the redirections didn't help basically "clickonce" installers are not supported on VDI's/Roaming profiles and since Sage use that then there in lies the issue, Unless Sage are prepared to change to another type of installer this issue wont go away.
Basically FSLogix's uses a driver to obscure the path of where config file actually exists and whether you exclude from the disk or not .net still needs to run through that driver, Perhaps FSLogix may improve that driver over time but right now its doesn't work 100% of the time.
However I would be very interested to here how you get on with your Sage support, as for now I have had to move the sage user away from WVD for now and hope this is resolved later on. Hope you have more luck
Nov 18 2020 12:44 PM
Hi @StevenR, Im not going to hold my breath with Sage, but our accounts team is quite small so we are just join to create a host-pool with a single host and disable FXLogix for the sage users. Not ideal but a solution for the time being.
Thanks for the info and good luck to you also.
Feb 07 2021 12:50 PM
Feb 08 2021 12:20 AM
@accounts2021 Hi, unfortunately I haven't I hit a brick wall of support from vendor as Sage do not support VDI environments, however that appears to be more of an issue with using "ClickOnce" installers as thats a limitation of that and until that changes.
What I haven't tested mostly due to time, is mounting the FSLogix accounts in Azure Files rather than direct on a fileserver in azure.
With another WVD deployment I ran into performance issues/limitations of locating them on a fileserver then the bottleneck of access becomes the singulare fileserver, whereas if they were in Azure Files it is far higher and the bottleneck becomes the higher spec'd WVD that is trying to connect to it.
I have another project to deploy and will be using this method instead hopefully with better results.
Feb 08 2021 12:55 AM - edited Feb 08 2021 12:58 AM
@StevenR we think we have found a solution, it seems the problem is related to the UAC virtualization. If you disable the UAC virtualization and restart the host it seems to work.
Feb 08 2021 01:01 AM
Feb 23 2021 03:32 AM
Feb 23 2021 03:52 AM
@dmidec For me I haven't actually tried it as I had to migrate off but I will be bearing in mind for the future.
Feb 23 2021 04:03 AM - edited Feb 23 2021 04:06 AM
It does seem to be working, however we did not disable UAC V on the entire server.
We did not install our sage200 client using the click once installer, but instead have a single installation location for all users. This meant that in theory we only need to create a "Sage200Desktop.exe.manifest" file and set the correct "requestedExecutionLevel", but found that Sage had already generated one but renamed it to "Sage200desktop.manifest.manifest" (this is from memory so it might be named something else). We simply renamed this file and restarted the WVD host, its worked ever since.
We are are not sure why Sage had chosen to rename the manifest file, but so far we have not noticed any unexpected behavior.
Feb 23 2021 04:13 AM
@brmmmm78 Ah, that's useful. We too are running using the RDS installation method, so I'll look for the file!
Mar 24 2021 06:39 AM
Mar 24 2021 07:32 AM
Mar 24 2021 07:53 AM
May 11 2021 05:24 AM
We have been following this forum and also the suggestions made within to get sage 200 working with FSLogix and WVD
Our FSLOGIX is in azure premium storage and we have 2 servers that never have this issue. we have tried with and without UAC virtualisation and still receive the error writing the user.config file. as others have mentioned we see the folder structure be created for the user but just not the file. I could delete the file on 2 other servers and it immediately recreates it and runs with no issue yet other servers always present this error.
I am looking at this manifest file and have as instructed renamed the file and copied the entire install directory to a local drive c:\program files (x86)\sage200\
I run the Sage200desktop.exe application from here and still it will write this user.config file
I have edited the manifest file as follows
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<!--
UAC Manifest Options
If you want to change the Windows User Account Control level replace the
requestedExecutionLevel node with one of the following.
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
If you want to utilize File and Registry Virtualization for backward
compatibility then delete the requestedExecutionLevel node.
-->
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
I presume the <!-- is the beginning of a comment-out statement and that I merely needed to take one of these statements and place it at the bottom.
Others have stated when you use require administrator that it changes the icon but I'm not seeing this behavior.
I am unsure if it is in fact even referring to the manifest file at all.
I'm puzzled as to why on some of my WVD servers I have no issue and yet others i always get the problem.
I have checked the .net versions and they are all correct. I have checked c++ and they also are correct
the version of windows is all the same and yet some machines refuse to write to this location at all.
Any clarity of any sort as to the specifics around the manifest file would be appreciated
Jun 02 2021 08:31 AM
Jun 22 2021 07:16 AM
We are using the local Program Files (not click-to-run) version and have updated the manifest file but are still experiencing the issue for some users.
It's really odd - is anyone else continuing to have problems?
Jun 22 2021 07:28 AM
Jun 22 2021 07:41 AM