Parallels very slow too start - not the VM, just the Parallels UI
- Thread starter AveryS
- Start date
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...
MarkusF2 wrote:
FYI: I installed the latest Parallels update and it replaced prl_ls_users, so I had to re-rename it.
"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.
Last edited:
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.
MichaelB53
Bit poster
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.