Do not deliver before: does not work - Outlook 2003

[Elaine]

Though I mark a message for delayed delivery using
Message Options, Do not deliver before: and specify a
date and time, that time comes and goes and the message
remains in my Out box.

We are in the midst of a conversion from GroupWise to
Microsoft Exchange 2003 Server/Outlook 2003. The
addresses are GroupWise addresses.

Any help will be appreciated!

 

[Jeff Stephenson [MSFT]]

Outlook will need to be running and will need to do a send/receive (either
timed or manual) in order for the message to be sent at the proper time.

 

[Guest]

This quickly became an issue yesterday for me. We are getting ready to go into production and start migrating some accounts to E2K3. So if am hearing correctly Exchange does not have the ability to send delayed messages UNLESS the client is running? Surely there has to be a way. What is the purpose of delayed delivery if your cliient has to be up and running. I send lots of messages delayed and also have people who setup several delayed messages for many days in the future

What I see is that Exchange is relying on the client to do the timing and when that time hits it then sends it. This is the opposite of GroupWise. GroupWise actually send the message to the recipients and the receiving post office does not display the message until the specified time. Each PO has a ngwdfr.db and both are updated when a message is sent

This may be the first feature or lack one, that I have been disappointed with so far

todd

 

[Rob Schneider]

My recollection is that there is a way to send the mail from Outlook to
Exchange, and Exchange holds it until the prescribed time. I don't have
Exchange to check. Suggest you do some experiements or read the
"help" files. Recommend you don't jump to conclusions yet.

If the user does *not* have and Exchange server, I am quite sure that
the mail won't be sent until Outlook is running *after* the prescribed time.

Hope this is useful to you. Let us know.

rms

 

[Jeff Stephenson [MSFT]]

If you're migrating between GW and Exchange, I suspect that you may have two
accounts in Outlook (one GW, one Exchange). If there's more than one
account, Outlook will hold onto the message until delivery time, because it
is not sure (at the time) with which account the message is to be delivered
(indeed, it may require both accounts to properly send the message). If you
only have a single Exchange account, and are running in online (*not*
cached) mode, Outlook will push the message to Exchange for later delivery.
In all other cases, it will hold the message until the proper time.

--
Jeff Stephenson
Outlook Development
This posting is provided "AS IS" with no warranties, and confers no rights

This quickly became an issue yesterday for me. We are getting ready to go

into production and start migrating some accounts to E2K3. So if am hearing
correctly Exchange does not have the ability to send delayed messages UNLESS
the client is running? Surely there has to be a way. What is the purpose
of delayed delivery if your cliient has to be up and running. I send lots
of messages delayed and also have people who setup several delayed messages
for many days in the future.

What I see is that Exchange is relying on the client to do the timing and

when that time hits it then sends it. This is the opposite of GroupWise.
GroupWise actually send the message to the recipients and the receiving post
office does not display the message until the specified time. Each PO has a
ngwdfr.db and both are updated when a message is sent.

 

[Guest]

There are not 2 accounts. Once the account is migrated from GroupWise to Exchange the GroupWise account is disabled and not visible.
The problem here is the caching mode I suppose. I setup the client in caching mode becuase the plans are to centralize the entire email system in the migration. I didn't want 8500+ users connecting over WAN links in online mode

I can live with that answer though. I really don't know how many users in the field use delay delivery or even know what it is for that matter. The majority of the users that would use it are located at Corp. Headquarters anyhow.