Advertisements

Archive

Archive for March, 2010

Exchange Server ActiveSync error message with HTTP status code 409

March 23, 2010 1 comment
  • System Notes: Exchange 2003 Enterprise

After migrating accounts from an Exchange 2003 Standard server to an Exchange 2003 Enterprise server recently, one particular user account kept generating Event ID 3005 error messages in the Application log. The full text of the error message went as follows: “Event Type: Error, Event Source: Server ActiveSync, Event ID: 3005, Description: Unexpected Exchange mailbox Server error: Server: [server1] User: [user1] HTTP status code: [409]. Verify that the Exchange mailbox Server is working correctly.” This message would appear several times a day.

The user in question had no problems with his e-mail account via Outlook or OWA. However, when attempting to use his Palm Pre smart phone, he could see and read his e-mails, but he could not delete them or reply to them, nor view any Contacts or Calendar information. We have at least 10 other user accounts that were migrated in the same way, and were using various types of smart phones, including two other Palm Pres. None of them had this problem.

After much searching on the web, I ultimately determined the only way to correct this problem would be to delete the user mailbox and recreate it. Once scheduled with the user, I backed up the mailbox to a PST file, then used the Exchange Tasks wizard to Delete Mailbox. I forced the cleanup agent to run with the Run Cleanup Agent from the Exchange System Manager, then purged the mailbox from the server.

After re-creating the mailbox, anyone who e-mailed the user was getting SMTP 5.1.7 errors (“The e-mail address could not be found. Perhaps the recipient moved to a different e-mail organization, or there was a mistake in the address. Check the address and try again.”). Something was obviously wrong with the mailbox, so I deleted it a second time following the steps above. I then ran the Exchange Task “Remove Exchange Attributes,” and again recreated the mailbox. This time, no problems with e-mails going to or coming from the mailbox.

I had the user remove and re-add his Exchange account information on the Palm Pre, and everything then worked correctly. No more errors from Exchange in the Application log.

Advertisements

Vipre Enterprise 4.0 and Kiwi Syslog Server (Daemon) not compatible

March 15, 2010 Leave a comment
  • System Notes: Dell PowerEdge 2650, Windows 2003 Standard

Vipre Enterprise 4.0 (by Sunbelt Software) was released earlier this year, and we were planning to migrate from 3.1 to 4.0 as soon as possible. We have had very good luck with Vipre, and are very happy with it for our anti-virus/anti-malware needs. Initial testing was done on several non-production virtual servers and workstations, corresponding with each of the server and workstation types we currently run in production. All tests were positive, no conflicts found.

It turns out that one program we did not initially test with, Kiwi Syslog Server, has serious conflicts with Vipre 4.0. The server in question was already running Kiwi Syslog Server 8.3.40 and Vipre Enterprise 3.1 with no issues. Once we upgraded the system to Vipre Enterprise 4.0, the Kiwi Syslog Server refused to start or run in any way (it is installed in “service” mode and uses the Local System account to run). I didn’t notice this at first, and it wasn’t until my daily status reports turned up missing that I found out about the conflict.

Initially, I thought that upgrading to the latest release of Kiwi Syslog Server, version 9.0.3, would take care of the problem. No such luck. In looking at the Errorlog.txt file in the main Syslogd program folder, the software was throwing “*** INTERNAL PROGRAM ERROR – Please contact ***” every second that it was trying to start up.

I then confirmed this issue on one of my virtual servers used for testing, by installing the Kiwi Syslog Server on that system, which was already running Vipre Enterprise 4.0. The same problem existed.

I contacted Sunbelt Software support and opened a case. We have tried downgrading to Vipre Enterprise 3.1, as well as adding the Syslog program directory (C:\Program Files\Syslogd) to the “Always Allowed” list.

Resolution found, courtesy of the SolarWinds thwack forums: link (4/14/2010).