[Baggarly]

We just upgraded to BES 5.0.2 (Groupwise) and seem to have some issues with the transporter tool migrating calendar issues over with the device from the 4.0.7 server. I am thinking that maybe it would be better to just wipe the device and activate it on the new server to eliminate any issues. Is there any other ideas regarding this issue out there? I hate to gather all devices to do a manual activation if not needed!

[jsconyers]

I think running 4.0.7 is your issue. Taken from the following KB article

Note: BlackBerry Enterprise Server database schema 4.0 SP7 for Novell GroupWise can be upgraded as well, but it should be upgraded to BlackBerry Enterprise Server databse schema 4.1 SP7 for Novell GroupWise first, and the system should be allowed to finish processing any pending or current transactions before proceeding with the database schema upgrade to BlackBerry Enterprise Server 5.0 SP1 for Novell GroupWise.

KB20798-Supported upgrade paths to BlackBerry Enterprise Server 5.0 SP1 for Novell GroupWise

Also, is 5.0.2 available for GroupWise?

[Baggarly]

Thanks for the reply JS. Sorry but I am at 4.1.7. I'm still in weekend mode! And yes BES 5.0 sp1! Should have called in sick today! We have not loaded MR1 though. Would that make a difference?

[jsconyers]

Which transporter tool are you using?

The supported version for use in migrating users between BlackBerry Domains is BlackBerry Enterprise Transporter 5.0 SP2 (5.0.2.3). This tool is part of the BlackBerry Enterprise Server Resource Kit 5.0 SP2. For more information, review the following link:

BlackBerry - Enterprise Server Resource Kit

KB24579-Environmental considerations when upgrading to or installing BlackBerry Enterprise Server 5.0 SP1 for Novell GroupWise

[Baggarly]

That's what I have. 5.0.2.3.

[jsconyers]

I am not sure, if this is only one user, try deleting and re-activating. Either that or call RIM support.

I have yet to move to 5.0.1, going to do the move next week. Reading this thread makes me a little hesitant because I have a LOT of heavy calendar users.

[Baggarly]

Yeah we do too. 4.1.7 gave us plenty of issues as well though, so really didn't have a choice. Our issues seem to be sporadic though. Today could be my device having issues, and tomorrow yours for no specific reason? But what are the alternatives right! Best of luck to you with your upgrade....

[jsconyers]

What were you issues with 4.1.7?

I am running 4.1.7 mr1 (need to update the signature, but too large and need a mod to do it) with GroupWise 8.0.2 hp2.

We had issues on 8.0.2 hp1 which was not and will NEVER be supported by RIM, but since going to hp2, things have smoothed over.

[Baggarly]

We were using 8.0.2 hp1 and having issues with semiphores. We just upgraded gw to 8.0.2 hp2 over the weekend. I am wondering if this will make a difference.

[jsconyers]

I think it should. There were lots of issues with hp1. RIM would not support it with BES 4.1.7 or 5.0.1. They will never support it according to both RIM and Novell. That is why Novell rushed to get hp2 out. RIM tested it and certified it almost immediately for 5.0.1. They certified it about a week later for 4.1.7.

[Baggarly]

Nice to know. My management is really doubting RIM and blackberry at this time to the point we have been drafting guidelines for iphones and droids. I could care less what device users want to go with, but the blackberry seems quite a bit easier to lo,ck down as far as aps and such go. Thanks again and I will keep you posted as to how it runs over the next couple of days or so.

[jsconyers]

We were/are in the same boat. Novell and RIM are in a finger pointing contest with no one winning and our department losing, lol.

I have Droids and iPhones deployed (personal devices) on Novell Datasync. It is a free product, well it is included with your GroupWise licenses. So, no additional costs, other than the server it will be running on. We also have a NotifyLink server, which supports iPhone, Droid, and BlackBerry devices as well. Notify allows some of our users to have a second GroupWise account on their BlackBerry.

The downside of Datasync at this point is no HTML email support. The next release (scheduled for June) will fix this. Notify rectifies that issue for us in the meantime and we can then migrate users over to Datasync to cut costs of Notify licensing fees.

[Baggarly]

So did you do your upgrade JS? I was going to load MR2, but some of the supervisors are leary of doing so with all the vacationers that could possibly lose service IF they have the blackberry with them. I was asked to upgrade our 4.1.7 server to 5.0.1 MR2 and put some test devices on and see how it goes. I guess a snapshot of the server isn't good enough anymore!

[jsconyers]

I did install 5.0.1 MR1 a little while ago and moved a group of 16 users over using the transporter tool. There were some discrepancies in the address books of 10 of those 16 users. This is a known issue in MR1 and is corrected in MR2. Once installing MR2, all the issues were cleared up.

Some FYI's for you that I haven't found documented anywhere from Novell or RIM in regards to using BES 5.0.1. BES 5, as you're aware, uses only the SOAP protocol, it no longer relies on the GW client. Sending an item from the BlackBerry on BES 5 will show the email address of the user in their Sent Items folder on the GW client

For example if I send an email to on BES 4.1.x, in the Sent Items folder on GW it would show as Scott Smith. When on BES 5.0.1 it shows as

Also, I don't know how many of your users use categories, but when a user is added to the BES 5 server it adds categories to their GW client.

See image:


If you delete these categories from the client, they come back down again. I have a ticket open with RIM on this. It is not a major issue, but I have some users that heavily rely on categories and these cause clutter and the users yell at me.

One more issue is when a user accidentally moves their mailbox folder to the Calendar or Contacts folder in the folder list and then moves it back, the BES either doesn't receive the SOAP event or doesn't process it. Thus causing the mailbox to be missing from their folder redirection list and leaving the user to not receive mail. You can correct this by restarting the services. I have done a WireShark trace to see where the issue lies, if the BES isn't getting the SOAP event, or not processing it.

I will attach a document I typed up with more information on these steps.

These are not deal breakers, but things I wish I was aware of when I moved these users over. Most of our users are still on BES 4.1.7 mr1, but will be moved over shortly.

[jsconyers]

This is the response I received back from RIM in regards to the mailbox moving issue:

Upon reviewing the case I have found that this is by design. When moving a folder under a subfolder that is not setup for redirection by the BlackBerry Enterprise Server(BES), it essentially now becomes an unsubscribed folder. This in turn tells the BES that the item(folder) and its containing items (messages) are to be hard deleted. The result of this, is that the BES will now delete those items from the folder on the handheld. In this instance it would mark all the messages as hard deleted, delete those messages from the handheld and also orphan those REF IDs to GUIDs in the database. When you move the folder back to an area that the BES can see, in this case the Mailbox to the root of the Folder list, the BES will not see it until the controller service(CTRL) is restarted. The CTRL service will restart the Groupwise SOAP Connector(GWSC) which in turn will login and send a request to get the folder list. The BES then re-subscribes to the userxxx8217;s mailbox and new messages will come to the handheld. The only way to get the older email would be to remove, readd and Enterprise Activate the user again to start pre-population.

[jsconyers]

If you haven't upgraded and transported users yet, don't until you add MR2.

There is an issue with the encryption key during the transport, this is fixed in MR2. Basically, the when the encryption key expires, there is nothing to regenerate as the field in the database is null and the user will manually have to regenerate the key.

in MR2, the field is populated and there is no issue.