thebackroomtech » Groupwise

Groupwise GWcheck Error: Mailbox/library maintenance can not be executed because a duplicate request is running

admin — Thu, 27 Aug 2009 13:00:26 +0000

I received the following message when attempting to run the standalone GWcheck today:

Mailbox/library maintenance can not be executed because a duplicate request is running

To resolve my issue (Groupwise 7.0.3HP2), I renamed the ngwcheck.db file in the post office directory. Worked like a charm.

Fix: Groupwise Login Failed Login Rejected (8219)

admin — Thu, 18 Jun 2009 10:43:53 +0000

Specific Error Message shown in the Groupwise 7.0.3HP2 WebAccess log file:

Login Failed: User PO5 Groupwise login rejected (8219)

Two of my post offices could be accessed via WebAccess, while four could not. I was pretty sure the problem was with domain or post office links. I doubted the problem was with the domain links, since one of the post offices that could be accessed through WebAccess was in the same secondary domain as three post offices that could not.

The solution was to edit the Groupwise WebAccess object’s post office links in ConsoleOne. All six of my post office access mode links were set to Client Server only.

For the four post offices I could not access through WebAccess, I changed the links to Use Current Post Office Address, restarted WebAccess, and verified I could login to each of the problematic post offices.

I then changed the links from Use Current Post Office Address back to Client Server only, restarted WebAccess, and verified I could login to each post office. My 8219 errors were no longer listed in the WebAccess log file.

Fix: Groupwise alarms not working

admin — Mon, 13 Apr 2009 09:46:45 +0000

I had one user who was not receiving Groupwise calendar alarms. Groupwise backend is version 7.0.3HP2, user’s client is GW656UP3. The problem was observed from different machines for this user. Other user’s could login to the affected Groupwise client and were able to receive alarm notification, so we knew the problem was with this user’s mailbox.

I had previously run GWcheck’s on the user’s mailbox, first with Analyze/Fix Databases Structure, then Analyze/Fix Databases with Contents, but this did not resolve the problem. Here’s how I ultimately resolved her issue:

1. Run a Gwcheck on the user mailbox with Structure and Fix Problems selected. Run until zero errors are reported.

2. Run a Gwcheck on the user database. This is the userxxx.db file, where xxx is the account’s three letter FID. Uncheck Structure, select Contents. Do NOT select fix problems. On the MISC cab, enter DELSUBSCRIBERECORDS.

3. Run a Gwcheck on ther userxxx.db database. Uncheck Structure, select Contents. This time, select Fix Problems. On the MISC cab, enter DELSUBSCRIBERECORDS.

4. One more time, run a Gwcheck on the userxxx.db file. Uncheck Structure, select Contents. Do NOT select Fix Problems. On the MISC cab, enter DELSUBSCRIBERECORDS.

5. Finally, I had to re-setup the user’s notification list. To do this, in the Groupwise client go to Tools > Options > Security > Notify. Add the user to the notification list, and then select the two boxes to subscribe to Alarms and Notifications.

According to TID 10074300, running gwcheck with the DELSUBSCRIBERECORDS without fix problems does something different that running it with fix problems selected. The TID specifically states:

If fix problems is not selected, it removes problem subscription records from the users database that have been know to cause problems with alarms. With the fix problems selected, it removes a different type of problem records that cause problems with Notify. It might be helpful to run it both ways.

This was the first time I had heard of running DELSUBSCRIBERECORDS without Fix Problems selected actually removing subscription records.

Fix: 8209 error when attempting to create an archive from a restored Groupwise post office mailbox

admin — Wed, 25 Mar 2009 13:29:40 +0000

I recently restored a Groupwise 7.0.3HP1 post office from a daily differential backup. After logging into a newly restored mailbox, I received a Path not Found [8209] error when attempting to create an archive from within the Groupwise client.

The reason for the 8209 error ended up being that the daily differential backup did not capture the ngwguard.dc file located in the root of the post office directory. Once I copied this file from the live post office to the restore location, I was able the create the archive. I also could have copied the file from the po directory in the Groupwise software distribution directory.

For additional details, see Novell TID 10052390

FIX: Faulting application gwpoa.exe, version 7.0.3.1068, faulting module gwwww1a.dll

admin — Mon, 23 Mar 2009 13:14:32 +0000

I sure hope I don’t jinx myself for considering this issue resolved…

My five Windows 2003 R2 SP2 / Groupwise 7.0.3HP1 servers have each been receiving the following errors since they were migrated from the Netware operating system back in December of 2008:

Event ID: 1000 Source: Application Error

Faulting application gwpoa.exe, version 7.0.3.1068, faulting module gwwww1a.dll, version 7.0.3.1068, fault address 0x000b2379.Event ID: 1004 Source: Application Error

AND

Event ID: 1004 Source: Application Error

Reporting queued error: faulting application gwpoa.exe, version 7.0.3.1068, faulting module gwwww1a.dll, version 7.0.3.1068, fault address 0x000b2379.

The event 1000 would result in the POA service stopping. I was able to temporarily minimize the impact of the POA stoppage by running the POA as a service and having it’s recovery options set to restart the service ater the failure was detected by the OS.

I noticed that the Groupwise 7 SP3 Hot Patch 2 contained an updated gwwww1a.dll, but this particular issue was not listed as a fix in the change log. I had been hesitant to apply GW703HP2 because it caused a great headache when I applied it to my GWIA server. I finally decided to try HP2 on my post office servers, and was plesantly suprised to find it (seemingly) has resolved my POA crash issue! I’ll post back if I find varied results, or new issues caused by this hot patch.

Groupwise Appointments are off by one hour after Daylight Savings Time change

admin — Tue, 10 Mar 2009 11:07:45 +0000

We have five Groupwise post offices running Groupwise 7.0.3 HP1. Four servers are in the Eastern time zone, one is in the Central time zone. After this past Sunday’s change to Daylight Savings Time, some users are reporting their appointment times are off by an hour.

We verified the servers, post offices, consoleone, and workstations all had the correct time zones set. Groupwise saves appointment information in UTC, then coverts to local time via the workstation clock, so we figured the problem had to with a local computer setting.

On the workstation of an affected user I downloaded Microsoft’s TZedit.exe utility and manually inspected the start and end dates for DST. The start date was set to first Sunday in April, and the end date was set to last Sunday in October, which were the old start/end dates.

I used TZedit.exe to change the start date to second Sunday of March, and the end date to first Sunday in November for each applicable time zone. This corrected the problem for all new appointments, but does not correct pre-existing appoinments inside the change window. These appointments need to be adjusted manually, or an administrator can use Novell’s Groupwise DST Adjuster Tool to adjust the majority (but not all) affected appointments.

For more Groupwise specific DST information see Novell TIDs 3802376 and TID 3094409. For detailed information on how to adjust the Windows workstation time zone definitions and TZedit.exe see Microsoft KB 914387.

Fix: Cannot find Groupwise users to add to the Blackberry Enterprise Server

admin — Thu, 12 Feb 2009 13:20:14 +0000

A user was recently having issues with his Groupwise email on his Blackberry, so our BES admin planned on removing him from BES, then re-adding him. Removing the user was no problem, but the admin was quite suprised to find out he could not re-add the user. When searching for the user to add, the user was not found.

I found RIM KB12111, which describes running GWSystemAddressBookSync.exe manually to resynchronize the Blackberry Configuration Database with the Groupwise System Address Book. By default this process runs every 12 hours.

The user in question was not a new user, but running the manual synchronization allowed the BES admin to find the user and re-add him onto BES.

By default you can find the GWSystemAddressBookSync.exe program in the C:\Program Files\Research in Motion\Blackberry Enterprise Server directory on the BES server. Run the .exe from the command prompt and wait for the process to finish.

My BES is version 4.1.14 with 180 users, and my Groupwise System is version 7.0.3 hot patch 1 with 2600 users, and the sync process took about 14 minutes to complete when run during production hours.

After upgrading to BES 4.1.3 or higher for Groupwise, excessive GWXMLData::ContactSyncRecordToXML warnings appear in the Windows Application log

admin — Wed, 11 Feb 2009 09:45:44 +0000

Blackberry KB15941 exlains that starting with BES 4.1, additional warnings are logged to the Blackberry Messaging and Windows Application log. These warnings are informational in nature, and do not indicate a problem.

If you’d like to reduce or eliminate these messages, KB04342 says to edit the EventLogLevel DWORD value of the appropriate BES service located at :

HKEY_LOCAL_MACHINE\Software\Research In Motion\Blackberry Enterprise Server\Logging Info

DWORD values and Event Types correspond as follows:

0 = Disable all event logging

1 = Errors

2 = Warnings

3 = Information

4 = Debug

5 = Other

Unforturnately, I was unable to determine which service was generating these excessive GWXMLData warnings, so I had to contact RIM directly. Their response was that the Mailbox Agent service needs to have it’s EventLogLevel changed to 1, which would log errors only.

I made this change on my BES server, and the event logs are now much slimmer!

Novell TID 3801441 Is Wrong! – How to create a GroupWise user with a specific File ID (FID) for accessing an archive, or restoring a deleted user

admin — Tue, 27 Jan 2009 13:54:34 +0000

I was trying to re-create a Groupwise account this morning, and was having great difficulty in changing its FID per TID 3801441. Here’s what Novell’s instructions are as of today, January 27 2009:

Follow these steps to create a new user with a specified FID number.

First you will need to create a new user account in GroupWise using any user name / user ID you choose. You may already have the NDS user account and do not have to delete this account but rather just add a GroupWise account to it. If the NDS user already has a GroupWise account you can either disassociate the GroupWise account from it of delete just the GroupWise account from the NDS user.

Do not log in to the account via the GroupWise client. Follow the steps below before allowing the user to log in to GroupWise in order to change the FID of the existing user to a specified FID

To change the FID for the user:

1. Open the properties of new GroupWise users account in ConsoleOne, click the arrow on the GroupWise tab and choose account, note the users current FID in the middle of the GroupWise account page. Click on the ‘Page options‘ button in the lower left hand corner.

2. In the “Tabs and Pages” window expand the ‘GroupWise‘ heading and choose Account. Highlight account and click the Disablebutton. Save the setting and exit the GroupWise users account by selectingOK/OK. This disables the GroupWise account Tab and moves the GroupWise information to the Other Tab where we later are able to modify the FID.

3. Close the GroupWise users account (Cancel or X) and then re-open it. Go to the Other Tab and the GroupWise attributes are listed as ‘Leftover attributes that are not handled by custom pages‘.

4. Click On the NGW: File ID attribute and Edit it to the specified FID / three unique characters / letters or numbers and then save by clicking ok.

5. Now go back in to the ‘Page options‘ button in the lower left hand corner from step #1 and enable the GroupWise account options you previously disabled.

6. Close and re-open the GroupWise users account and note the FID on the GroupWise account tab has been changed to the FID you specified.

The directions are ALMOST correct, except step #2 states that after disabling the Account tab, you should be able to modify the FID by viewing the NGW: File Attribute on the Other tab, under Leftover attributes that are not handled by custom pages. This is not correct!

You have to disable the Identification tab, not the Account tab, in order to view and modify the NGW: File Attribute, aka FID. Only took two hours out of my day to figure that out. I thought the problem was with my ConsoleOne or Groupwise snapins. I can’t believe this TID has been around since 8/22/2007 and has not been corrected.

FWIW my environment is Groupwise 703HP1 with ConsoleOne 1.3.6f.

Incorrect time stamp on Groupwise email messages after migrating to new server

admin — Mon, 26 Jan 2009 12:31:02 +0000

Last weekend I migrated a Groupwise 7.0.3HP1 post office, it’s POA, it’s domain and MTA from Netware 6.5.5 to Windows 2003 R2 SP2. The migration was smooth, one I’d performed several times before.

All of a sudden, some of our users in a different time zone were reporting that certain (but not all) incoming email messages were timestamped one hour in the future. We did some basic troubleshooting, and found the following to be the case:

1. Appointments always showed the correct time, no matter what time zone they originated from.

2. All affected users were on one server. These users were all physically located in the Central Time Zone (CST).

3. Other users physically located in CST with mailboxes on different post office servers were not experiencing issues with incorrect time stamps on messages.

4. All Groupwise post office servers are physically located in the Eastern Time Zone (EST).

Further troubleshooting showed that this problematic post office was configured in ConsoleOne for CST at both the Post Office and Domain level. Client workstations were configured to use CST. The time zone setting in WebAccess was ruled out since all affected users were using the thick Groupwise client.

TID 3218634 goes into great detail explaining all the locations that can affect time settings. In the end, I just changed the time zone from EST to CST on the affected Windows post office server.

I did not need to restart the POA for the change to be implemented – email time stamps were once again back to normal for CST users.

thebackroomtech » Groupwise

Groupwise GWcheck Error: Mailbox/library maintenance can not be executed because a duplicate request is running

Related Posts

Fix: Groupwise Login Failed Login Rejected (8219)

Related Posts

Fix: Groupwise alarms not working

Related Posts

Fix: 8209 error when attempting to create an archive from a restored Groupwise post office mailbox

Related Posts

FIX: Faulting application gwpoa.exe, version 7.0.3.1068, faulting module gwwww1a.dll

Related Posts

Groupwise Appointments are off by one hour after Daylight Savings Time change

Related Posts

Fix: Cannot find Groupwise users to add to the Blackberry Enterprise Server

Related Posts

After upgrading to BES 4.1.3 or higher for Groupwise, excessive GWXMLData::ContactSyncRecordToXML warnings appear in the Windows Application log

Related Posts

Novell TID 3801441 Is Wrong! – How to create a GroupWise user with a specific File ID (FID) for accessing an archive, or restoring a deleted user

Related Posts

Incorrect time stamp on Groupwise email messages after migrating to new server

Related Posts