Back in October we wrote a blog post about GroupWise 7 clients with an 8.01 backend.  At the time we reported a problem about notify not working properly with older 7.x clients.

Well, as all things software, 4 months is an eternity.  I was asked today about this issue, and in the meantime we’ve found that this particular situation wasn’t as widespread as originally thought, and even at sites where the problem appeared, it was limited to specific PCs.  And indeed, since GroupWise 8, SP1HP1 was released in January, we’ve had no further reports of the problem from any of the originally affected sites.

So, if you are planning on upgrading to GroupWise 8 and keep your GroupWise 7 clients, SP1HP1 for your backend is your best bet all around anyway.  That said, the sites that did experience this found that reinstalling the GroupWise 7 client on the PCs solved the issue.  While we originally said that upgrading to the 8.01 client was the only way around it, obviously something was just “broken” (highly technical term) on those PCs, and reinstalling the 7.x client would also fix whatever the issue was that was resolved with installing the 8.01 client.

Happy Tuesday (gotta be better than Monday!)

Danita

Over the past few months, I’ve had three different instances where customers reported to me that dbcopy was moving their files from the source location to the destination location.  Since there is actually no specific switch in dbcopy to request a move, I was baffled.  However, Novell has now figured out what the issue is!

If you run dbcopy with the -h switch, you see this particular listing:

-l             Performs the GWCheck function of storelowercase only

When migrating to Linux, of course we want two things to happen:  we want to migrate all files over converting them to lowercase, and when it’s over, we want a GWCHECK run that checks the guardian database (ngwguard.db) to ensure that this database also lists all files as lowercase.  It is rare that an admin should need to run storelowercase on his/her own.  A successful run of the -m switch against a post office includes the command to run the storelowercase, and so unless something goes wrong during the copy, it’s unlikely that this switch should need to be run manually.  That said, because admins often run dbcopy -h to see what’s there, and see that lovely -l switch, it’s not totally surprising that some misunderstand the usage of this switch and decide to run the dbcopy with both -m and -l at the same time.

So, here’s the problem.  A dbcopy with the -l switch should be run like this:

dbcopy -l -p <path to post office>

A general dbcopy to copy the post office in a migration typically looks like this:

dbcopy -m <source path> <destination path>

The dbcopy -l switch is designed to scan the post office directory to make sure all files are lowercase and then perform a gwcheck storelowercase operation at the end. During this process, there is actually some renaming and manipulation of the files in the post office, and when the -l switch is presented with both a source and destination path, it gets confused. At the end of the processing of the file, rather than putting the file back in the source directory, dbcopy errantly puts the file into the target directory.

When the 8.02 dbcopy ships, there will be a warning flag if someone attempts to run these two switches together.  In the meantime, well just DON’T DO IT!

A TID is in the process of being created now, and when it is ready I will update here!

Danita

I was recently contacted by a fairly large GroupWise 8 customer about the “Auto-Accept Appointment” behavior that was added to GroupWise 8.  Prior to GroupWise 8, if I sent an appointment and included myself in the attendees, I would either have to create a rule to accept my appointment, or I would have to manually accept it myself.  With GroupWise 8, this was changed to automatically accept the appointment if I sent it to myself.

Now, while this is an okay functionality for me personally, it has caused quite a stir among some of my customers.  We’ve put together a quick poll to see what your thoughts are regarding this feature.  Please take the quick poll at http://www.caledonia.net/blog and also comment here with why you chose the answer you did.  Why do you like this?  Why do you hate this?  It’s important for you to comment, because just saying “I hate it” isn’t enough to get Novell to address the issue.  The Novell engineers will need to have a better picture of “why” this is a problem for your organization in order to possibly reevaluate this change.

My opinion remains the same:  Do not change an existing default behavior unless it becomes a selectable option.  It would have been just fine to change this if the behavior could have been managed by a simple options entry.

What do you think?

Danita

Alex Evans posted the following blog entry yesterday regarding the work being done on the “GMS Replacement”.  Right now, it looks like the GroupWise Mobility Connector will be available in only one configuration:  a 64bit SLES 11 add-on, using PostgreSQL as the backend database.

You might have seen our recent poll regarding 64bit hardware usage.  How does this change your responses (if at all)?  Are you ready for 64bit SLES 11 now?

For myself, this is not an issue.  I can put up a 64bit SLES 11 server without too much hardship.  I do have some customer sites where this will pose some problems, not only with the 64bit, but the SLES11 part.  I suspect there are many Windows GMS sites out there who were hoping to not go the Linux route just yet!

What say ye??

Danita

I was having a conversation with some colleagues today about hardware.  We all agreed that new server hardware is pretty much all 64bit now, but we questioned just what customers actually use in their environments. I know that I have many customers who “repurpose” older hardware for various things.  For example, a retiring 32bit GW server might replace a less powerful BES, and the like.  And while virtualization is becoming more widespread, it by no means seems to be the norm among my GroupWise clients at this point.

Do you purchase “new” hardware for single application type servers?  Like an Astaro Security Gateway, a Linux open source anti-spam front-end, a Blackberry Enterprise Server, GroupWise WebAccess, a GroupWise Mobile Server, etc.?  Or do you give these processes up to older hardware that still has good life in it?

It seems a given, that the larger the organization, the more likely that organization will be using virtualization (and donating their old hardware) but it’s unclear as to how many folks have actually gone “all 64bit” at this point!

We’d love to hear from you!  Feel free to give all the details in a comment here, and also please take our poll at the main http://www.caledonia.net/blog site!

Thanks.

Danita