Re: Problem viewing messages generated with OWA on Groupwise web c



I changed the UseRegionalCharset to 0 and restarted the Exchange and IIS
services. Indeed now examining the headers of the from OWA clients are
now different and encoded as

Content-Type: text/html;charset="UTF-8"

Content-Transfer-Encoding: base64

But the problem still perists while viewing the Groupwise web message with
IE--you still have to manually change the encoding to view, but not in
Firefox.

Note that this rendering issue does not happen with messages sent from
yahoo.mail to Groupwise web mail, but it does with messages sent from our
Exchange/OWA clients to Groupwise web mail.

Am I missing something here? I've tried changing encoding types and
character sets on the Internet Message Format for the domain to Site #2 in
ESM but nothing makes a difference, unless of course I set it to plain text.



"John Fullbright [MVP]" wrote:

" UseRegionalCharset set as 1 "

should be 0. UseAltRegionalCharset can optionally be set to 1


"EdGreen" <EdGreen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0C204474-DA4C-4EFC-BBDC-C54B35F0C2D6@xxxxxxxxxxxxxxxx
Thanks John,

But, I had already looked at the reg key-- we've had UseRegionalCharset
set
as 1 (and no UseAltRegioalCharset ket defined) long before this problem
surfaced.

Further clarification: When I access the Groupwise web mail and open up a
message sent to me from Site #1 OWA Exchange, the message is not viewable
unless I right-click and change the encoding from within IE--just about
any
selection for charset will work.

That is assuming I am using IE 6 or IE 7.

However, when I use Firefox and I open the web mail message as just
described, it is viewable without having to change the encoding. The
default
encoding in Firefox set at UTF-8, but I can change it to just about
anything
else and it still works.

The easiest solution is to tell the users at Site #2 to use Firefox when
using their Groupwise Web client, but I really need to find a solution on
the
Exchange/OWA end that can fix this--without resorting sending as plain
text.
And so far, I've only seen this problem with messages generated from from
our
Exchange/OWA.


Thanks


"John Fullbright [MVP]" wrote:

It's the same game you play with dcbs language support or browsers that
don'tt understand UTF-8. iso 8859-1 (western europe is the character
set
used if a client does understand UTF-8. ascii is sent if a client does
not.
Ascii goes through andbut 8859 does not in your case, so the assumption
is
the GW client does not understand UTF-8. In this case, you coud simply
set
UseAltRegionalCharset to 0 (this sends Windows-1252 for western europe,
or
set UseRegionalCharset to 1, or both. This requires a restart if the IS
and
W3SVC to take effect.


"EdGreen" <EdGreen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C50990D6-2E72-47C0-AEBD-38411925292E@xxxxxxxxxxxxxxxx
Site #1:

Exchange Server 2003 SP2
Spam Firewall 300

Site#2:
Novell GroupWise 7.0 Web mail

Problem:

Overview-- Users using GroupWise Web mail at Site #2 cannot read
messages
generated from our OWA clients (Site #1) without having to change the
default encoding to render the messages properly.

Details-- When I send email from Site #1 using Outlook 2003 SP2 client
via
Exchange server to site #2, the message is viewable with the GroupWise
Web
Client.

However, when I send email from Site #1 using OWA to Site #2, the
message
is
not rendered properly-although if I change the character set encoding
in
the
browser, the message is readable.

From Site #1, the messages sent from Outlook via Exchange server are
Content-Type: text/plain; charset="us-ascii"

And the messages sent from Outlook Web Access via Exchange server are

Content-Type: text/plain; charset="iso-8859-1"

The GroupWise Client at Site #2 appears to be UTF-8 by default.

Question, is there a way to change the default character set for OWA
clients
on the Exchange server such that the messages get encoded in a default
readable format for users at Site #2.

I have tried to assign different encoding sets for the specific domain
(Site
#2) via ESM/Global Settings/Internet Message Formats on the Exchange
server.
However, this did not seem to make a difference as the message encoding
remains unchanged for outbound messages to Site #2. Perhaps there is a
setting that is overriding this, but I cannot find it.

Any help with this would be very appreciated.







.

Relevant Pages

  • Re: Problem viewing messages generated with OWA on Groupwise web c
    ... message properly in IE without manually changing the encoding. ... yahoo.mail to Groupwise web mail, but it does with messages sent from our ... used if a client does understand UTF-8. ... Exchange Server 2003 SP2 ...
    (microsoft.public.exchange.admin)
  • Re: Problem viewing messages generated with OWA on Groupwise web c
    ... it is viewable without having to change the encoding. ... using their Groupwise Web client, but I really need to find a solution on the ... used if a client does understand UTF-8. ... Exchange server to site #2, the message is viewable with the GroupWise Web ...
    (microsoft.public.exchange.admin)
  • Re: Problem viewing messages generated with OWA on Groupwise web c
    ... I'm guessing at this point that there is a similar setting in groupwise ... I changed the UseRegionalCharset to 0 and restarted the Exchange and IIS ... IE--you still have to manually change the encoding to view, ... used if a client does understand UTF-8. ...
    (microsoft.public.exchange.admin)
  • Re: best way to recreate a mailbox
    ... >> some changes in PSS recently, so please take advantage of any request to ... I exhausted what I could do by phone and told the client, ... data loss can occur from running utilities against your Exchange ... >>> There is also a problem, likely related, with Backup Exec. ...
    (microsoft.public.windows.server.sbs)
  • Re: AD Site Topology
    ... authenticating with a domain controller in a different physical ... to a GC outside of it's physical location resulting in Outlook ... local infrastrcuture i.e. DC's/F&P but not exchange. ... client side is a good point though although I thought MS improved the ...
    (microsoft.public.win2000.active_directory)
Loading