Blog Entry

Submitted by Mike (not verified) on 12 June 2007 - 2:40pm.

I'm impressed with the response and quick fix to the issues here. It's important to assure that these products are reliable.

Submitted by M (not verified) on 14 June 2007 - 6:34am.

We have the MTA, GWIA and WebAccess Agent on one server - the application server exists separately. When I applied the HotPatch to the MTA WebAccess stopped working, giving users the error "There is a version mismatch between this webaccess agent and the post office you are trying to access. Please contact your system administrator." I had not updated the WebAccess agent, but I'm wondering if it has shared nlm's with the MTA.

My understanding is that we update the MTA, then POA's and then other agents (I.E., WebAccess.) We have ~80 Post Offices at remote sites, which will make it someone difficult to do this quickly. Is there something I am missing or is WebAccess simply going to be broken while we update each of the post offices?

Submitted by Dana Palmer (not verified) on 17 June 2007 - 7:26pm.

Webaccess acts like the GW client when connecting to the Post Office, so you will see problems accessing a Post Office until the POA has been updated.

Submitted by Berndt Waltje (not verified) on 18 June 2007 - 1:09am.

we updated to HP1a - and now there is the following bug: when a user answers an internet mail with answer to all, then the CC-addresses are broken (not all CCs are listed, and the listed ones have only the name-part, not the domain-part)

Submitted by M (not verified) on 18 June 2007 - 6:31am.

Even if the 'client' (WebAccess Agent) hasn't been updated and is still running 7.0.1?

Submitted by Alex Evans (not verified) on 25 June 2007 - 1:37pm.

Well, the engine (gwenn5) is shared so in effect you have partially updated the WebAccess agent. You need to either back rev everything on that server or run the MTA and WebAccess from different folders and in protected memory.

Submitted by Alex Evans (not verified) on 25 June 2007 - 1:37pm.

This is not the first time I have heard this - do you have internet addressing enabled in your system?

Submitted by Michael Gorn (not verified) on 27 June 2007 - 2:45pm.

HotPatch 1a isn't so hot either. I wonder why new QA processes that were put in place didn't catch these newly created bugs:

1. When we do a reply in HTML mode, the font becomes TIMES NEW ROMAN size 12. New emails are using the
correctly set system font.
2. When we forward a message, the cursor doesn't appear in the "To:" field but in the message body.

Any ETA on HotPatch1b or HotPatch2 that fixes these bugs?

Submitted by Michael Gorn (not verified) on 27 June 2007 - 2:50pm.

Also the British pound symbol gets changed to an asterisk when sent to an external email address.
The Mac client doesn't work on Mac OS X 10.3.9

Submitted by Berndt Waltje (not verified) on 2 July 2007 - 4:53am.

In a former version we had configured the GWIA-agent with the startup-switch "/dia" which disabled the internet-style addressing. That caused the problem. We removed the switch - and we had to remove it from gwia.cfg, too, not only in ConsoleOne. After that the problem was resolved.

Submitted by Ray Robertson (not verified) on 7 August 2007 - 3:53pm.

This font issue of always using Times New Roman (12 point) in Replies is very frustrating.
It also happens when you Forward too.

I spent quite a while trying to force GW 7.0.2 HP (6-6-2007) build 562, to accept another font as default, and then correctly use it in Replies.

The same, or a closely related, issue is that GW 7.0.2 also screws up other font/formating information in the reply too.
This is especially true when a chain of replies is involved or you add any new lines in the body of the reply.

Similarly, my signature frequently comes out with strange, inconsistent, & undesired sizing changes.

Even if you select everything and try to force the entire document to your preferred font, once you hit send, what actually gets sent, may or may not, resemble the formating you applied.

The behavior is even more frustrating and bizarre, if you try to use "Plain Text" as your default.

Since we received the installation files CD from our umbrella IT organization, I do not know if the CD we used to install with was a full version of 7.0.2, or if it had the patch mentioned above applied before they burned the CD.

As Mr. Gorn noted, the correct font IS applied in new emails.

I have used "Set Current Font as Default," "Set Windows Font as Default," and all permutations of settings in the Tools \ Options \ Environment setting I can think of.

Does anybody have a solution for this?

Submitted by jen (not verified) on 13 August 2007 - 9:26am.

After 7.02hp email shows pending in email properties but was actually processed and received. Noticed this post the most current GW 7 service pack when sending to another GW system outside our system. That system was not at the current SP. They now are and are experiencing the exact same thing..Wondering if the MTA is not receiving info from the GWIA to indicate successful send..or maybe the POA and MTA are having a moment...thoughts, suggestions appreciated.

Submitted by Dave Dabinett (not verified) on 15 August 2007 - 11:47pm.

This is frustrating as this has never been the case before.

Submitted by Lisa R (not verified) on 16 August 2007 - 12:16pm.

We are having the same problems:

1. When we do a reply in HTML mode, the font becomes TIMES NEW ROMAN size 12. New emails are using the correctly set system font.
2. When we forward a message, the cursor doesn’t appear in the “To:” field but in the message body.

Submitted by Sam (not verified) on 6 November 2007 - 11:49am.

We are experiencing the same thing now, after hot patch updates... any solution to this?

Submitted by Wayne (not verified) on 19 February 2008 - 3:25am.

I also had to deal with the extremely annoying problem of the cursor not appearing in the "To:" field when I wanted to forward a mail. The problem with the fonts that is mentioned in the previous posts also had me somewhat frustrated. Thankfully though, I downloaded and installed "fgw702HP2r1cus.exe" and low and behold - the problem, she is gone.
Thanks for the fix! Hopefully this post will help someone else.