Separate names with a comma.
Discussion in 'General Questions' started by AveryS, Aug 14, 2018.
Good call, Michael. Until Parallels gets its act together, this is going to be my future answer!
Yes, thanks you so much for the idea to just rename 'prl_ls_users', this totally fixes it. I don't understand while Parallels needs to query every single user. While out servers are pretty fast, it takes 10-15 minutes for probably 100k+ users... (yes, big company). I remember this from 15 years ago, when an AudioUnit thought it is a good idea to scan the whole filesystem down from / on a local drive - ignoring that in a corporate environment there can be NFS mounts. The file system scan took almost 20 minutes...
"I don't understand while Parallels needs to query every single user."Exactly. What is the purpose of Parallels scanning our LDAP user bases like that? It's like quantum mechanics, because it's spooky interaction at a distance.
FYI: I installed the latest Parallels update and it replaced prl_ls_users, so I had to re-rename it.
THANK YOU, Michael. this has been a time suck for months. It would be helpful if Parallels fixed this issue. I doubt that our security people would be happy if they new that this was happening. I'll quietly let other users know about the fix.
For those who use Parallels Desktop 14 please try to update to 14.1.0. I hope this issue is fixed there.
I suspect they're doing this because Parallels has an option to share a virtual machine across a network. They're probably pinging everything on the network to try and find shared virtual machines. Must be pretty badly implemented though is the LDAP scan gates the launch of the entire application AND that there is no option for "Don't look for shared VM's". Also the issue of why the hell are you scanning my company's network in the first place? Is that info staying local or are you sending it somewhere.
On Parallels Desktop 13.3.1 and 13.3.2, renaming "prl_ls_users" fixes the problem.
On Parallels Desktop 14.1, the problem doesn't happen.