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

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 alarms not working

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

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, faulting module gwwww1a.dll

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, faulting module gwwww1a.dll, version, fault address 0x000b2379.Event ID: 1004  Source: Application Error 



Event ID: 1004 Source: Application Error
Reporting queued error: faulting application gwpoa.exe, version, faulting module gwwww1a.dll, version, 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

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

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.