by adrien » Dec 03 11 8:47 am
Hi
I'm sorry you're having such troubles with the upgrade. If you let us remotely assist you, I'm certain we could solve these issues you are seeing.
In the picture you show of group membership showing "windows IDs". These are WinGate SIDs. WinGate 7 stores group membership as SIDs. When you open a group, and navigate to the members tab, it initially shows the SIDs, then it queries the username for that SID from WinGate. When the result of that search comes back it replaces the SID in the dialog with the user name, or leaves the SID if it doesn't find it. How many users do you have in this group? Maybe it takes too long to find the user details and send them back to the user interface.
This is how the OS does permissions etc - if you grant a permission to a user on a file, then delete the user account, the SID will show instead in the file permissions.
When you add a new group, it shouldn't become a member of any other group. If that's happening randomly, it sounds like the new SID of the new group is wrong, and is an existing one that is a member of some other group. I'll have a look for a bug there.
With the policy issue, it sounds like the SIDs are getting messed up somehow. That definitely sounds like a bug, but we haven't seen it before.
whenever any new object (user or group) is created, it gets a SID based on an internal base plus a RID. This is stored and updated in the regsitry under
HKEY_LOCAL_MACHINE\Software\Qbik Software\WinGate\Users\WinGateProvider\Settings\NextRID
If this value gets messed with or reset, then new SIDs could be created that conflict. This could possibly happen if that value gets cleared somehow?
If you like, you can email us your registry, and we can do a migration for you and send you back the new user registry. That will also allow us to find / fix bugs.
Regards
Adrien de Croy