Closed RicLund closed 6 years ago
I've reproduced the issue and found it was due to missing file permissions on the App_Data
folder. The Self-hosted_Installation_Guide_for_Portals.pdf
file from Microsoft does mention steps to secure this folder, but doesn't specify exactly what the permissions to use are supposed to be, I've had success with assigning these permissions to the IIS_IUSRS group on the following folders:
On the root of the site or a parent folder:
On the App_Data folder itself:
If this solves the issue for you I'll add a page to the wiki with this information.
Thanks Alan. I’m actually not sure it was this- pretty sure that permission has to be there for the CRM settings file to get written? What does seem to have solved it (just noticed on Friday) is getting the cache invalidation working - haven’t looked at the code but could it be incorporated in there?
Rich
On Mar 3, 2018, at 5:52 PM, Alan Mervitz notifications@github.com wrote:
I've reproduced the issue and found it was due to missing file permissions on the App_Data folder. The Self-hosted_Installation_Guide_for_Portals.pdf file from Microsoft does mention steps to secure this folder, but doesn't specify exactly what the permissions to use are supposed to be, I've had success with assigning these permissions to the IIS_IUSRS group on the following folders:
On the root of the site or a parent folder:
Read & execute, List folder contents, Read
On the App_Data folder itself:
Modify, Write
If this solves the issue for you I'll add a page to the wiki with this information.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Updating the search index after it's been created requires file deletion permissions, which the second set of permissions listed grant. Having the web notification plugin registered properly is also required but updates to the existing search index will not take effect if a cache invalidation request processed by the portal runs without the listed permissions in place. The search index update logic creates a write.lock file in the Adxstudio.Xrm.Search folder that also needs to get deleted and without the permissions listed it fails to delete the file.
That all makes sense to me and aligns with my experience of it. Some info in the wiki would be a great idea.
Rich
On Mar 3, 2018, at 7:00 PM, Alan Mervitz notifications@github.com wrote:
Updating the search index after its been created requires file deletion permissions, which the second set of permissions listed grant. Having the web notification plugin registered properly is also required but updates to the existing search index will not take effect if a cache invalidation request by the portal is received without the listed permissions in place, because the search indexing logic creates a write.lock file in the Adxstudio.Xrm.Search folder that also needs to get deleted.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
This information has been added to the File System Permissions wiki page.
Is there caching of content used in search? It seems like it and I can't figure out how to get the cache to refresh - specifically I am keyword searching with words I know are in knowledge articles and getting only old results.
I have WebNotification.axd being called on entity change - does something else control the cache of search information? I notice that the files in App_Data\Adxstudio.Xrm.Search are old - are these cache files? Deleting them made the site unhappy....