8.0 Message Does Not Arrive

Suggested solutions are provided for the following problems:

Message Does Not Arrive in the Local Post Office

Problem: A message from user A is not being delivered to user B in the same post office. This scenario would most likely occur when GroupWise users connect to the post office using direct access mode. Direct access for clients is not recommended for GroupWise 2012.
Action: Do not use direct access for clients in GroupWise 2012.

Message Does Not Arrive between Post Offices

Problem: A message from a user in Post Office A is not being delivered to a user in Post Office B in the same domain.
Action: Answer the following question:

Can other users in Post Office A send messages to other users in Post Office B?

Yes

See Problem with an Individual User in Either Post Office.

No

See Problem between Post Offices for Multiple Users.

Don/t Know

See Problem between Post Offices for Multiple Users.

Problem with an Individual User in Either Post Office  

  1. Stop the MTA for the domain.

  2. Have the user in Post Office A send a low priority test message to a recipient in Post Office B. (It’s a good idea to test message flow using a low priority message because the low priority message queue is typically empty.)

  3. Check the post_office/wpcsin/6 directory in the sender’s post office.

    Has a new message file appeared in the post_office/wpcsin/6 directory?

    No

    The GroupWise client was unable to create the message file. The user might not have sufficient rights to the directory if using direct access mode. Correct the problem, then repeat the test.

    Yes

    The sender can successfully send messages. Continue below.

  4. Stop the POA for Post Office B.

  5. Restart the MTA in the domain. Observe the MTA server console or Web console for any sign of problems.

  6. Check the post_office/wpcsout/ofs/6 directory in Post Office B.

    Has a new message file appeared in the post_office/wpcsout/ofs/6 directory?

    No

    See Problem between Post Offices for Multiple Users.

    Yes

    The message transferred successfully between post offices. Continue below.

  7. Restart the POA for Post Office B. Observe the POA server console or Web console for any sign of problems.

  8. Recheck the post_office/wpcsout/ofs/6 directory in Post Office B.

    Has the message file disappeared from the post_office/wpcsout/ofs/6 directory?

    No

    The POA was unable to pick up the message. Correct the problem, then repeat the test.

    Yes

    The POA has successfully picked up the message. Continue below.

  9. Check the recipient’s mailbox.

    Does the new message appear in the recipient’s mailbox?

    Yes

    The POA has successfully delivered the message this time. Repeat the test with a different user.

    No

    The POA was unable to deliver the message. Continue below.

  10. Check the ownership of the recipient’s user database (userxxx.db).

    Does the ownership of the user database match the recipient’s network login ID?

    No

    Reset the ownership on the userxxx.db file, then repeat the test.

    Yes

    Continue below.

  11. Check the ownership of the message database (msgnnn.db) in the recipient’s post office that corresponds to the message database assigned to the sender in the sender’s post office.

    Is the ownership of the message database correct?

    No

    Reset the ownership on the msgnnn.db, then repeat the test.

    Yes

    Continue below.

  12. In ConsoleOne, perform maintenance to correct any problems with the databases. See Maintaining User/Resource and Message Databases in Databases in the GroupWise 2012 Administration Guide. Then repeat the test.

  13. (Conditional) If the message flow problem has not been resolved by following the above troubleshooting steps, seek assistance from Novell Support .

Problem between Post Offices for Multiple Users  

  1. Stop the MTA for the domain.

  2. Have the user in Post Office A send a low priority test message. (It’s a good idea to test message flow using a low priority message because the low priority message queue is typically empty.)

  3. Check the post_office/wpcsin/6 directory in Post Office A.

    Has a new message file appeared in the post_office/wpcsin/6 directory?

    No

    See Problem with an Individual User in Either Post Office.

    Yes

    The sender can successfully send messages. Continue below.

  4. Stop the POA for Post Office B.

  5. Restart the MTA for the domain. Observe the MTA server console or Web console for any sign of problems.

  6. Check the post_office/wpcsout/ofs/6 directory in Post Office B.

    Has a new message file appeared in the post_office/wpcsout/ofs/6 directory?

    No

    See Problem with Access to Post Office B.

    Yes

    The MTA has successfully transferred the file to the POA in the recipient’s post office. Continue below.

  7. Restart the POA for Post Office B. Observe the POA server console or Web console for any sign of problems.

  8. Recheck the post_office/wpcsout/ofs/6 directory in Post Office B.

    Has the message file disappeared from the post_office/wpcsout/ofs/6 directory?

    No

    The message transferred successfully between post offices, but the POA in Post Office B is unable to pick up the file. See Step 8 in Problem with an Individual User in Either Post Office.

    Yes

    The message transferred successfully between post offices, and the POA in Post Office B has picked up the file. If the message still does not arrive in the recipient’s mailbox, see Step 9 through Step 13 in Problem with an Individual User in Either Post Office.

Problem with Access to Post Office B  

  1. Start ConsoleOne with read/write rights to the post office.

  2. Double-click the eDirectory container where the domain is located, then select the Domain object.

  3. Click Tools > GroupWise Utilities > Link Configuration.

  4. Check the link from the domain to Post Office B.

    Does the link from the domain to the post office specify the correct IP address, UNC path, or mapped path to the post office directory for the recipient’s post office?

    No

    Correct the information. Restart the MTA. Observe the MTA server console or Web console for any sign of problems. Repeat the test.

    Yes

    The link to recipient’s post office is correct. Continue below.

  5. (Conditional) If you are using client/server access to Post Office B, check the IP address and port displayed in the Network Address box of the POA Identification page.

    Are the IP address and TCP port number for the POA correct?

    No

    Correct the information. Restart the POA in Post Office B. Observe the POA server console or Web console for any sign of problems. Repeat the test.

    Yes

    The IP address and port for the POA are correct. Continue below.

  6. Check rights for the MTA to write files into the post_office/wpcsout/ofs/6 directory in Post Office B.

    Are the network rights in the post office correct?

    No

    Reset the rights in the post office, and repeat the test.

    Yes

    Continue below.

  7. Check for available disk space in the post_office/wpcsout/ofs/6 directory in Post Office B.

    Is there adequate disk space available in the post office?

    No

    Remove unnecessary files from the server to free up disk space, then repeat the test.

    Yes

    Continue below.

  8. (Conditional) If these troubleshooting steps have not enabled the MTA to write the file into the post_office/wpcsout/ofs/6 directory in the recipient’s post office, seek assistance from Novell Support.

Message Does Not Arrive between Domains

Problem: A message from a user in Domain A is not being delivered to a user in Domain B.
Action: Answer the question below:

Can other users in Domain A send messages to other users in Domain B?

Yes

See Problem with an Individual User in Either Domain.

No

See Problem between Domains for Multiple Users.

Don’t Know

See Problem between Domains for Multiple Users.

Problem with an Individual User in Either Domain  

  1. Stop the MTA for Domain A.

  2. Have the user in Domain A send a low priority test message to a recipient in Domain B. (It’s a good idea to test message flow using a low priority message because the low priority message queue is typically empty.)

  3. Check the post_office/wpcsin/6 directory in the sender’s post office.

    Has a new message file appeared in the post_office/wpcsin/6 directory?

    No

    The GroupWise client was unable to create the message files. The user might not have sufficient rights to the directory. Correct the problem, then repeat the test.

    Yes

    The sender can successfully send messages. Continue below.

  4. Stop the POA for the recipient’s post office in Domain B.

  5. Start the MTA for Domain A. Observe the MTA server console or Web console for any sign of problems.

  6. Check the domain/wpcsin/6 directory in Domain B.

    Has a new message file appeared in the domain/wpcsin/6 directory?

    No

    The message is not transferring between domains. See Problem between Domains for Multiple Users.

    Yes

    The message transferred successfully between domains. Continue below.

  7. Restart the POA for the recipient’s post office in Domain B. Observe the POA server console or Web console for any sign of problems.

  8. Recheck the post_office/wpcsout/ofs/6 directory in the recipient’s post office in Domain B.

    Has the message file disappeared from the post_office/wpcsout/ofs/6 directory?

    No

    The POA was unable to pick up the message. Correct the problem, then repeat the test.

    Yes

    The POA has successfully picked up the message. Continue below.

  9. Check the recipient’s mailbox.

    Does the new message appear in the recipient’s mailbox?

    Yes

    The POA has successfully delivered the message this time. Repeat the test with a different user.

    No

    The POA was unable to deliver the message. Continue below.

  10. Check the ownership of the recipient’s user database (userxxx.db).

    Does the ownership of the user database match the recipient’s network login ID?

    No

    Reset the ownership on the user database, then repeat the test.

    Yes

    Continue below.

  11. Check the ownership of the message database (msgnnn.db) in the recipient’s post office that corresponds to the message database assigned to the sender in the sender’s post office.

    Is the ownership of the message database correct?

    No

    Reset the ownership on the message database, then repeat the test.

    Yes

    Continue below.

  12. In ConsoleOne, perform maintenance to correct any problems with the databases. See Maintaining User/Resource and Message Databases in Databases in the GroupWise 2012 Administration Guide. Then repeat the test.

  13. (Conditional) If the message flow problem has not been resolved by following the above troubleshooting steps, seek assistance from Novell Support.

Problem between Domains for Multiple Users  

  1. Stop the MTA for Domain A.

  2. Have the user in Domain A send a low priority test message. (It’s a good idea to test message flow using a low priority message because the low priority message queue is typically empty.)

  3. Check the post_office/wpcsin/6 directory in the sender’s post office.

    Has a new message file appeared in the post_office/wpcsin/6 directory?

    No

    See Problem with an Individual User in Either Domain.

    Yes

    The sender can successfully send messages. Continue below.

  4. Stop the POA and the MTA for Domain B.

  5. Restart the MTA for Domain A. Observe the MTA server console or Web console for any sign of problems.

  6. Check the domain/wpcsin/6 directory in Domain B.

    Has a new message file appeared in the domain/wpcsin/6 directory?

    No

    See Problem with Access to Domain B.

    Yes

    The file has successfully transferred to Domain B. Continue below.

  7. Restart the MTA for Domain B. Observe the MTA server console or Web console for any sign of problems.

  8. Check the post_office/wpcsout/ofs/6 directory in the recipient’s post office.

    Has a new message file appeared in the post_office/wpcsout/ofs/6?

    No

    See Problem with Access to the Post Office in Domain B.

    Yes

    The MTA has successfully transferred the file to the POA in the recipient’s post office. Continue below.

  9. Restart the POA for the recipient’s post office in Domain B. Observe the POA server console or Web console for any sign of problems.

  10. Recheck the post_office/wpcsout/ofs/6 directory in the recipient’s post office.

    Has the message file disappeared from the post_office/wpcsout/ofs/6 directory?

    No

    The message transferred successfully between domains and into the recipient’s post office, but the POA in the recipient’s post office is unable to pick up the file. See Step 8 in Problem with an Individual User in Either Domain.

    Yes

    The message transferred successfully between domains and into the recipient’s post office, and the POA in the recipient’s post office has picked up the file. If the message still does not arrive in the recipient’s mailbox, see Step 8 through Step 13 in Problem with an Individual User in Either Domain.

Problem with Access to Domain B  

  1. Start ConsoleOne with read/write rights to the domain.

  2. Double-click the eDirectory container where Domain A is located, then select Domain A.

  3. Click Tools > GroupWise Utilities > Link Configuration.

  4. Check the link from Domain A to Domain B.

    Does the link from Domain A specify the correct IP address, UNC path, or mapped path to the domain directory for Domain B?

    No

    Correct the information. Restart the MTA in Domain A. Observe the MTA server console or Web console for any sign of problems. Repeat the test.

    Yes

    The link to Domain B is correct. Continue below.

  5. (Conditional) If you are using TCP/IP links between domains, check the IP address and port displayed in the Network Address box of the MTA Identification page. See Using TCP/IP Links between Domains in Message Transfer Agent in the GroupWise 2012 Administration Guide.

    Are the IP address and TCP port number for the MTA correct?

    No

    Correct the information. Restart the MTA. Observe the MTA server console or Web console for any sign of problems. Repeat the test.

    Yes

    The IP address and port for MTA are correct. Continue below.

  6. (Conditional) If you are using mapped or UNC links, check rights for the Domain A MTA to write files into the domain/wpcsin/6 directory in Domain B.

    Are the network rights in the domain correct?

    No

    Reset the rights in Domain B, and repeat the test.

    Yes

    Continue below.

  7. Check for available disk space in the domain/wpcsin/6 directory in Domain B.

    Is there adequate disk space available in the domain?

    No

    Remove unnecessary files from the server to free up disk space, then repeat the test.

    Yes

    Continue below.

  8. (Conditional) If these troubleshooting steps have not enabled the Domain A MTA to write the file into the domain/wpcsin/6 directory in Domain B, seek assistance from Novell Support.

Problem with Access to the Post Office in Domain B

  1. Start ConsoleOne with read/write rights to the post office.

  2. Double-click the eDirectory container where Domain B is located, then select Domain B.

  3. Click Tools > GroupWise Utilities > Link Configuration.

  4. Check the link from Domain B to the recipient’s post office.

    Does the link from the domain to the post office specify the correct IP address, UNC path, or mapped path to the post office directory for the recipient’s post office?

    No

    Correct the information. Restart the MTA in Domain B. Observe the MTA server console or Web console for any sign of problems. Repeat the test.

    Yes

    The link to recipient’s post office is correct. Continue below.

  5. (Conditional) If you are using a TCP/IP link to the post office, check the IP address displayed in the Network Address box of the POA Identification page.

    Is the IP address and TCP port number for the POA correct?

    No

    Correct the information. Restart the POA. Observe the POA server console or Web console for any sign of problems. Repeat the test.

    Yes

    The IP address and TCP port number for the POA are correct. Continue below.

  6. (Conditional) If you are using a mapped or UNC link to the post office, check rights for the Domain B MTA to write files into the post_office/wpcsout/ofs/6 directory in the post office.

    Are the network rights for the post office correct?

    No

    Reset the rights in the post office, and repeat the test.

    Yes

    Continue below.

  7. Check for available disk space in the post_office/wpcsout/ofs/6 directory in the recipient’s post office.

    Is there adequate disk space available in the post office?

    No

    Remove unnecessary files from the server to free up disk space, then repeat the test.

    Yes

    Continue below.

  8. (Conditional) If these troubleshooting steps have not enabled the Domain B MTA to write the file into the post_office/wpcsout/ofs/6 directory in the recipient’s post office, seek assistance from Novell Support.

Message Does Not Arrive Across the Internet

Problem: A message is not successfully delivered between a GroupWise user and an email user somewhere on the Internet.
Action: Review the stages of message flow performed by the Internet to send and receive messages across the Internet. See Message Delivery to and from the Internet in Message Flow Diagrams in GroupWise 2012 Troubleshooting 3: Message Flow and Directory Structure.
Action: The most useful procedure to find the source of a problem when a message is not being sent across the Internet is to break the GroupWise send process into steps and verify that the message arrives at each destination before the next piece receives and delivers it.

If a message has Pending status in the sender’s Sent Items folder, the message is somewhere in the GroupWise system.

A message has Pending status in the sender’s Sent Items folder until it is converted and queued to the SMTP service. The message has Transferred status after the GWIA queues the message to the SMTP service. If the GWIA is unsuccessful in sending the message and gets a temporary error (for example, Host Down), it attempts to send the message according to the Retry Schedule. During this time, the message has Pending status in the sender’s Sent Items folder. If the GWIA is ultimately unsuccessful in sending the message, the sender receives an undeliverable status.

The following steps provide general guidelines for checking the message at each point in the GroupWise system:

  1. Stop the GWIA and the MTA. Send a message from GroupWise, then look in the post_office_a/wpcsin/0-7 directory for a file where the client transfers the message. If the file exists, verify the time and date stamp of the file and continue with Step 2. If the file does not exist, the client did not transfer the file into the wpcsin/0-7 directory. Verify the address of the message and send another message to someone else on the Internet.

  2. If the file does exist in the post_office_a/wpcsin/0-7 directory, then start the MTA. The MTA polls the wpcsin/0-7 directory and places the message in the wpgate/gwia/wpcsout/gwixxxx/0-7 directory. (gwixxxx is a random directory name generated from information from ConsoleOne.) If the file exists, continue to Step 3.

    If the file does not exist in the wpcsout/gwixxxx/0-7 directory, then the MTA is not processing the files. See Message Transfer Agent Problems. After the MTA is working correctly, return to Step 1.

  3. After the file is in the gwixxxx/0-7 directory, start the GWIA. The file should transfer to the gwia/send directory. If the file exists in the send directory, continue to Step 4.

    If the file does not exist in the send directory, then the error is written to the log file. Look at the log file in the wpgate/gwia/000.prc directory. Files sent from GroupWise that have been corrupted are transferred to the wpcsout/problem directory. Change the log level to Diag, then repeat Step 1 through Step 3.

  4. After the file is delivered to the send directory, exit the GWIA.

    While the GWIA is delivering a message, it builds a file in the gwia/result directory. As soon as it delivers the entire message, check the result directory.

    If the file does not exist in the result directory, then the GWIA is not working. Check the --dhome and --home switches to ensure that they are pointing to the correct directories.

    If the file does exist in the result directory, check the TCP configuration or read the file and notice the last part of the message that was sent. You should have a file that contains several lines of comments preceded by 250 (OK reply).

  5. (Conditional) If an Internet host is down or the connection is not made on the Internet, start the GWIA to place the message in the gwia/defer directory for 20 minutes. The GWIA transfers the file to the send directory for another attempt at sending to the Internet. The GWIA defers and re-queues the message according to the Retry Schedule. The GWIA makes this attempt three times in one hour and then every four hours for four days. After the four days, if the Internet host remains down, an undeliverable status is sent back to the sender.

  6. (Conditional) If the file in the result directory does not indicate an error, start the GWIA again and see if SMTP sends a message back to the sender’s post office. In the client Sent Items folder, check the message properties for the message status. At this point, an undeliverable status indicates an incorrect Internet address.

  7. Messages sent from GroupWise with a Delayed Delivery status do not go to the send directory. Instead they reside in the wpgate/gwia/gwhold directory until the date the message should be sent.

  8. (Conditional) If an Internet user receives an undeliverable message because of an incorrect address to a Groupwise user, a copy of the message from the Internet resides in the wpgate/gwia/gwprob directory.