With all your help I am getting there. I went through all again and really it turned out to be a mistake in the UNC path. there was a little "l" missing for the drive on the server where mercury and pmail reside, which obviously goes away if you map drives.

Sending is working all well now, after I updated the gateway via pconfig with the right information.

Now I learned as well that I have to create a fsynonym database, as this was handled by netware in my case... 

 :-), Thanks again to everybody who looked into it,

Dieter

Guys,

I am looking for a hint, thinking all the way around without getting forward.

Situation:

Win 7
Mercury 4.80 standalone on a harddisk called L:
Pmail installed on same drive L:

Pmail via WSetup installed on same machine C: drive

All works perfect... Any given username will send and receive emails properly. There are anyone only 3 testusers. Sending works to internet email addresses!

Accessing the the server machine via LAN to drive L: (mapped)

Any of the 3 users will see his mailbox and receive all emails. Sending works from to local usernames.
Sending does not work to any internet email address. Just a spinning wheel when pushing send button. After few seconds message stays on screen but does not send.

Using UNC pathes does not change anything, same effect.

Can't sense why it does work on local = server machine, but not when accessed from LAN, and problem only for sending to email addresses?

I hope that some of you having experience on this can please hint me to a solution. Thanks in advance,

Dieter

The set-up you describe is a common one that is in use in lots of installations, so it should be straightforward to fix.

Please tell us which Mercury modules you are using and post a session log of MercuryC or MercuryE. (Don't forget to remove any Auth passwords before posting.)

Thanks for offering help.

MercuryE & Mercury B are switched off, all other modules on.

MercuryC works finem which I can tell, as it is forwarding emails to outside which are set by a forwarding file and all those transactions are going well.

So it is not a Mercury problem to my view.

Pmail is the problem, it does not want to place internet type of emails into the queue if started not local on the server machine. On the server machine it does however. If it wouldn't work at all, but it is capable to place message by user name into the right "other users" directory. So this does not invoke Mercury at all, right?

If I start pconfig, I can see however the Mercury queue name in PMGATE.SYS (again the strange thing pmail on the server machine works, it is placing internet messages into the mercury queue.) Not if on another machine though.

Should this placing mails into the mercury queue directory a Pmail function which should work even if at this minute mercury is not running at all, and I let mercury process it later. (just for testing amd understanding I mean ).

??

Regards

Hi,

Why you are using different Pmail installations, one on your server machine (drive L:) and additional ones at the user machines? We have also installed Mercury and Pmail together at one drive on our server only where every user is starting its own Pmail session from by a simple desktop link. The advantage is, that you have to adjust and maintain only this one Pmail installation at the server. Nevertheless each user could use its own settings because the user settings are being saved in the single user mailboxes. Works great since many years.

Back to your problem. Did you ever re-create the pmgate.sys by Mercury? Don't know what all have to be changed when coming from Novell, but this would be my thirst attempt.

Cheers

Joerg

It is a single installation, and it is a new setup altogether. I just had a similar installation before on a Novell machine, where this one on a Windows 7 machine is new to me.

All workstations I tried the way you suggest, with Wsetup.exe doing the job for me. So no Pmail on any machine itself, all on a separate drive on the server.

On the server it is however also possible to create a link with wsetup and get Pmail run there, which should be similar then on any other workstation.

With this receiving emails works similarly well as expected everywhere.

Sending emails is working by using user names... but any internet email adress is already not going out from Pmail, it is spinning the circle and goes then back to the unsent message. Expcept on the server machine, if I run pmail there via the created link to pmail on that particular drive, there it works to send any message.

I hope that explains the problem better.

Thanks,
Dieter

[quote user="IMTREX"]

Thanks for offering help.

MercuryE & Mercury B are switched off, all other modules on.

MercuryC works finem which I can tell, as it is forwarding emails to outside which are set by a forwarding file and all those transactions are going well.

So it is not a Mercury problem to my view.

Pmail is the problem, it does not want to place internet type of emails into the queue if started not local on the server machine. On the server machine it does however. If it wouldn't work at all, but it is capable to place message by user name into the right "other users" directory. So this does not invoke Mercury at all, right?[/quote]

You should use Mercury for all mail, not just the external ones.

[quote]If I start pconfig, I can see however the Mercury queue name in PMGATE.SYS (again the strange thing pmail on the server machine works, it is placing internet messages into the mercury queue.) Not if on another machine though.[/quote]

Use UNC paths and ensure each user machine has write access to the queue directory.

OK!

I am not sure how I cannot or I can invoke Mercury for all mail. I did a standard installation of Mercury and Pegasus on the same drive, not knowing what I perhaps I have perhaps switched off by mistake.

How can Pmail be told to deliver to system registerd users, which can be searched within pmail, with or without mercury and what can prevent it from using Mercury? Mercury is asking at installation if Pmail is to be used....

I did use pathes which mercury and pmail suggested at setup, and changed to UNC in Pconfig. Should I better reinstall it alltogeher? But there should be a way to make it work. Write access is all there, I opened it to everybody in full for the whole drive, not to run into those issues. And it was my plan to restrict it just if all works well, so I can try the proper restriction... but now the whole drive is open full access to all intended email users.

Did you create your single user mailboxes by using the Mercury "Create Local User" functionality? If so, Mercury has created single folders for each local user.

Further, when istalling Pmail, it asks whether it should be a stand alone installation or network installation. If choose "Network", the setup process would like to know where the mailboxes are installed (formerly created by Mercury)

Then, on each start of Pmail, you have to enter which user's mailbox Pmail should connect to.

 Did you done it in a similiar way?

Yes, I can confirm all of it:

 I also created a fourth test mailbox with a random user name to see if the creation process works. Network intall and I am asked when starting Pmail which user to be.

 Obviously all looks ok! What can hinder/stop placing an email into the queue, if e.g. from the same workstation I can create and save a txt file into the queue directory?

There should be both PMAIL.CFG and PMGATE.SYS files in the Pegasus Mail program folder.  They are created by the pconfig program, but it seems like there is something wrong with your gateway definition.