Apologies if this is too far off-topic, but I've been running Pegasus Mail in "standalone mode" for hundreds of users for many years. Works great!
I just set the location of PMAIL.INI and friends to a mapped network drive, that is individually mapped at network login time to each person's private "home" folder.
So, winpm-32.exe lives in P:/CURRENT/PMAIL, along with the various .fff files and similar customizations we have in place, and PMAIL.CFG (in the same share) tells Pegasus to find its other files in H:/PMAIL.
When I upgrade pegasus, I install the new version on the P: network share and test it for a while, figuring out the new capabilities and making sure there aren't any bugs that would impact my users, and once that's done I just move the new version to /CURRENT.
There are some additional bells and whistles - for instance, the /CURRENT directory is actually a symbolic link on the host side, so I can switch versions on the fly rather easily, and we dynamically generate registry hacks, policies, and login scripts from a perl script that runs on the server at network login time - but I think I hit the high points.
Since the location of a mail directory is a mapped drive, it's easily moved about, as long as the mapping resolves to the new location. We're completely IMAPped now, too, so the individual PMAIL directories only hold personal settings and cache info.
Oh, and don't do this technique on a dial-up link if you are using POP or any other mail storage method that will require Pegasus to open bazillions of files on the H: share. It will become so slow as to be unuseable with relatively few messages - this isn't really Pmail's fault, it's because SMB is a grossly inefficient protocol and Pegasus was orginally developed on the relatively snappy IPX stack. You're still OK with IMAP though, even on a slow link.
<p>Apologies if this is too far off-topic, but I've been running Pegasus Mail in "standalone mode" for hundreds of users for many years.&nbsp; Works great!
</p><p>I just set the location of PMAIL.INI and friends to a mapped network drive, that is individually mapped at network login time to each person's private "home" folder.</p><p>So, winpm-32.exe lives in P:/CURRENT/PMAIL, along with the various .fff files and similar customizations we have in place, and PMAIL.CFG (in the same share) tells Pegasus to find its other files in H:/PMAIL.
</p><p>When I upgrade pegasus, I install the new version on the P: network share and test it for a while, figuring out the new capabilities and making sure there aren't any bugs that would impact my users, and once that's done I just move the new version to /CURRENT.</p><p>There are some additional bells and whistles - for instance, the /CURRENT directory is actually a symbolic link on the host side, so I can switch versions on the fly rather easily, and we dynamically generate registry hacks, policies, and login scripts from a perl script that runs on the server at network login time - but I think I hit the high points.</p><p>Since the location of a mail directory is a mapped drive, it's easily moved about, as long as the mapping resolves to the new location.&nbsp; We're completely IMAPped now, too, so the individual PMAIL directories only hold personal settings and cache info.</p><p>Oh, and don't do this technique on a dial-up link if you are using POP or any other mail storage method that will require Pegasus to open bazillions of files on the H: share.&nbsp; It will become so slow as to be unuseable with relatively few messages - this isn't really Pmail's fault, it's because SMB is a grossly inefficient protocol and Pegasus was orginally developed on the relatively snappy IPX stack.&nbsp; You're still OK with IMAP though, even on a slow link.</p>
