Optimize SID resolution when viewing mappings in PI System Explorer
In PI System Explorer → File → Server Properties, the Mappings tab loads much more slowly than the other tabs when you have a slow connection to the PI servers and the domain controller.
In tech support case 00589952, I found that the loading time of the Mappings tab was roughly the same as the total time from running the "net user /domain" command for each mapping. This 1-by-1 approach is not efficient. Note that in my case, I had a mix of local accounts on the PI AF server and AD accounts.
Please consider some of the following optimizations:
• If possible, for each computer that has at least 1 account that is used in a mapping, resolve all of its SIDs in a single call.
• Reuse previous SID resolutions. The same account can appear in multiple mappings and the same AD-connected computer can appear in multiple mappings, where it will appear at least once for each of its local accounts.
• Resolve the SIDs in parallel where possible.
• Request only the needed information in the SID resolution. That is, do not use a convenient function that returns excessive information and then cherry-pick from the result.
In response to Kenneth Barber, "I don't do this often, and when I do, I ..."
Thank you for your feedback.
Kenneth Barber commented
I don't do this often, and when I do, I need to wait nearly 4 minutes. Because I am a PI administrator, I have the luxury of being able to remotely log into a computer that has a faster connection to the PI servers and the domain controller, so I can avoid this issue as long as I remember it.
Of course, not everyone is in my situation. Some people might not have the patience to wait out the 4 minutes and just assume that "it froze", or they might have to wait longer than 4 minutes due to having more mappings, or they might not have access to computers with faster connections.
The issue will essentially affect any PI consultant, since PI consultants often work remotely and will probably need to configure a few mappings at some point but may not have access to the customer's computers for a faster connection.
In my opinion, the issue is disruptive but not critical, but I don't think that it should be ignored indefinitely. Keep in mind that there is a tendency to look at each minor issue in isolation, and then determine that each issue has a negligible decrease on product quality, and so each minor issue is ignored. The more minor issues there are, the more likely it is that the user will stumble across at least 1 issue. Also, if a program has many minor issues, the combined decrease in product quality becomes significant and there will be no low-hanging fruit to solve for a quick win.
I bring this up because it seems to be the approach that OSIsoft takes. I like what OSIsoft's programs try to achieve, but I am constantly encountering issues, usually minor ones, with the programs and almost always have at least 1 tech support case open.
Can you help me understand how often you do this and how important this is to your work? Trying to gauge relative priority compared to everything else in the current backlog.