GE fails to restore the permissions after restoring the roles and users from sdf backup;
Hi All,
Despite the fact that I successfully restore all roles and users after reinstalling GE, it fails to restore the permissions that was previously applied for the same site (attached).
What might be the issue here?
Best,
Lubna
0
-
Hi Lubna,
If you click the "Show Permission Entries" link in the security page (the one you can see in your last screenshot), do you see any orphaned permissions? It sounds like your users and groups may have migrated, but your old permission entries are still around.
Thanks!
Danny0 -
I expect that there should be an easy way to transfer user, roles, permission settings from machine to another. From my attempt, it appears that copying the site and the sdf file stored in the locations below respectively is not sufficient to resolve the issue
C:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\Default\REST Elements\Sites
"C:\Program Files (x86)\Latitude Geographics\Geocortex Identity Server\Web\App_Data\IdentityServerUsers.sdf"
Your inquiry is still valid, how one can transfer a site from a machine to another without losing any component amongst users, roles and permissions0 -
Hi Danny,
How “permissions entries” are transferred when transferring a geocortex site and sdf file from a machine to another?
0 -
Hi Jamal,
The site permissions are stored in the site.xml file, and are "tagged" with the issuer seed of the identity server that set them. If you have 2 identity servers (one on each Essentials server), and one has an issuer seed of "12345", and the other server has an issuer seed of "67890", the permissions will be orphaned when they move from one server to the other, even if the usernames (which are stored in the IdentityServerUsers.sdf file) are identical.
From your screenshot, it looks like the permissions are not orphaned. It sounds like there may be something else going on there. Although migrating the user store (IdentityServerUsers.sdf), should work, I'm not sure that it has actually been tested/is fully supported.
I would suggest reaching out to your local reseller or to our support team so we can help you work through this over a screen sharing session.
I hope this helps!
Thanks,
Danny0 -
Thank you Danny for the help,
The issue is still there. There is no such good plan to transfer the geocortex from one machine to another without losing any data\settings\tools\behavior.0 -
Hi again Danny,
After copying the site folder from the source to destination machine, I have been advised to replace the idp code in the Site.xml generated by the geocortex in the source machine with the idp code generated by geocortex in the destination machine. This should restore the permission settings.
0 -
Hi Jamal,
It's worth a try, however changing the Issuer Seed is typically a fix you would apply to fix orphaned permissions. I'm not sure it applies here, since your permissions are not orphaned (per your previous screenshot).
Please let me know if it works!
Thanks,
Danny0 -
Danny,
I have Orphaned Permissions but am security provider is Windows Integrated. I have moved my site from a public.dmz server to a server in my trusted network. I am hoping that I can do a find and replace or each permission to change the Group Name that the permissions pertain to. Is this possible?
Bobby Jo0 -
Hi Bobby Jo,
Are your 2 servers members of different domains? Usually you should not need to reset Windows permissions when moving from server to server.
Thanks,
Danny0 -
Dear Danny,
After traying to copy the site folder from source to destination machine and replace the idp code in the site.xml generated by the Geocortex in the source machine with the idp code generated by Geocortex in the destination machine. Its worked fine with me, but am wondering what is the orphaned permission and what might be the difference between “orphaned permission” and “Geocortex Identify Server permission”
Thanks in advance,
Noor0 -
Hi Danny,
I would like to add that the method I tested works fine at new version"4.9.1", unless you press apply changes then save site for all roles found in the site, what do you think about? why we should save changes to site despite the face that the permission transferred successfully.(attached)
Thanks,
Noor0 -
Hello Noor,
If the orphaned permissions are gone it should be safe to apply the changes and save the site. Orphaned permissions will usually show up as a yellow caution triangle in the top left corner or they can also show up as a separate category when clicking the "Show Permission Entries" link on the Permissions page. An orphaned permission means the site.xml has a permission entry for a specific user but the Identity Server ID cannot be found. When you corrected the IDP numbers you fixed the issue.
As with any change like this, I would make sure you take a backup copy of the site.xml file before making any changes and saving them.
Regards,
Wayne Richard
Latitude Geographics Group Ltd.
Head Office: 300 – 1117 Wharf Street Victoria, BC Canada V8W 1T7
Tel: (250) 381-8130 | Fax: (250) 381-8132 | wrichard@latitudegeo.com
Developers of Geocortex web-based mapping software | www.geocortex.com
An Esri Platinum Business Partner0 -
I’m not sure why replacing the idp of source machine with the idp of the destination machine at the level of site.xml file is not sufficient to resolve the issue.
Do we really need to visit all roles from the manager and press apply changes\save site?
0 -
Hi Wayne,
Thanks for reply, I noticed that the orphaned permission appears when the idp for transferred site didn’t change to the new idp that related to the new machine (attached).
Thanks,
Noor0 -
Hi Daniel and Wayne,
I would love if you recommend us the best practice to transfer a Geocortex site from a machine to another.
Thanks
Jamal0 -
Hi Jamal,
While the information provided by Daniel and Wayne is accurate, there can be other factors at play in your security store and configuration. We recommend support assistance in migrating Identity Server - it's not a simple process. I would suggest contacting your local reseller to assist in analyzing what is missing and how to complete the migration successfully.
Thanks,
Aaron Oxley0 -
Hi Aaron,
We have been practicing transferring Geocortex sites from a machine to another in case of failure with the technique below:
1.Copy the site and viewer folder from the source machine to the destination
C:\Program Files (x86)\Latitude Geographics\Geocortex Essentials\Default\REST Elements\Sites
2.Copy the sdf file from the source destination to the destination
IdentityServerUsers.sdf
C:\Program Files (x86)\Latitude Geographics\Geocortex Identity Server\Web\App_Data
3.Open the site.mxl and replace the idp of the source machine by the idp of the destination machine
4.Any Geocortex file that has been edited at the level of Windows wwwrot needs to be rest
C:\inetpub\wwwroot
With this approach, nothing will be missed or lost when
Do you have any other better practice?
0 -
Hi Jamal,
All steps are correct and there is no need to visit all roles from the manager and press apply changes\save site
Best,
Lubna0
Please sign in to leave a comment.
Comments
18 comments