Mercury starts with the system. Loader.exe is in All Programs\Startup and maintenance is scheduled for 2am each day. Mercury is always run under the domain administrator login. The domain (and local) administrator accounts have full control over mercury\*.* and pmail\*.*. User mailboxes are nested under pmail\

It has worked fine for several years - this happened once before. It is a testament to the resiliency of Pegasus Mail and Mercury how easy it is to recover from these situations.

Today I have had to re-create five user mailboxes in Mercury. I have written this so that anyone else who experiences the same or a similar issue can quickly resolve it, or it at leasts points them to a workable solution..

Mercury is installed on a member server in a Windows Active Directory domain. All the clients access Pegasus Mail directly from a server (the program is not installed locally on the clients). Today Mercury lost user mailbox details and was unable to deliver messages to the affected mailbox accounts. These resulted in the postmaster account receiving several messages stating that the user(s) does not exist:

The attached message has failed delivery and has been referred
to you as postmaster. The following error report or reports
were given to explain the problem:

   *** <mailbox-name@domain.com>
   User <mailbox-name@domain.com> not known at this site.

In the Mercury Core Module, the following is displayed for each affected user:

To: mailbox-name [local]
*Transient error - job deferred for later processing

Pegasus Mail will display a message stating that 'The user you are attempting to 'become' (mailbox-name) does not exist on this system' when that user tries to access their mailbox.

• When I opened Configuration>'Manage local users' in Mercury, the mailbox was not listed.
• When I checked the pmail.usr file (which Mercury and Pegasus Mail get their list of users from) in the root of the folder that contains the Pegasus Mail mailboxes, the account is listed.
• When I checked the list of folders in the root of the Pegasus Mail folder, a folder named after the user's mailbox was present and all mail data was present.
• When I checked the permissions of the mailbox folder, they were correct (Authenticated Users = Write only, domain and local machine administrator accounts = Full Control, user's account = Full Control, plus any other neccessary permissions).

Please note that anti-virus on the server is configured to exclude both the Mercury folder and the folder containing the Pegasus Mail program files and user mailbox folders from on-access scanning. Also, it does not interfere with SMTP delivery.

When I tried to re-create the account via 'Manage local users' in Mercury, the system beeped and the account was not created. Mercury did not generate a failure message.

My solution was to first make a note of the security permissions of the affected folder then move the folder to another location. Next, I used 'Manage local users' to create the user's mailbox and then reset the permissions to what they were for the original folder. Finally, I copied the data from the moved folder to the new one.

I have no idea what caused this, but thankfully Mercury will try to deliver the deferred messages for a period, and in my case these succeeded immediately after Mercury was restarted.

After restarting Mercury, the pmail.usr file was re-written - my initial attempts at fixing this included creating new mailboxes with different names and the pmail.usr file was re-written to include the new mailboxes and the 'bad' ones were removed.

How are you running Mercury - command line or as a service?  What user is Mercury running as - do it have full permissions on all the mailboxes and working directories?