[tdigitee]

Hi all,

We are planning to upgrade our BES 4.1.0.40 server (for MS Exchange, MSDE DB) to SP2 this weekend and I'm trying to make certain we go about the process correctly, paying especial attention to potential user impact. Looks like we'll need to first back up the DB/SRP/auth key/server instance, then update to SP1 and finally to SP2.

Assuming all that goes smoothly (and please let me know if you have any caveats), we hope users won't have any issues. However, we have a mix of BB devices being used, from OS 3.7 up to 4.1 (all Cingular devices, 7280-7290-8700c-7130c), many of the newer using OTA Enterprise Activation but some via wired connection and Desktop Manager. <None of our users use wireless PIM sync except for Calendar>. The SP2 upgrade guide makes reference to 4.0 devices being forced to go through a wireless sync (page 13 of Upgrade_guide.pdf) and this is what concerns us.

RIM KB article KB-04295 (sorry, not allowed to post URLs yet), referenced by that page in the Upgrade Guide, suggests that the wireless sync will only occur on OS 4.0 or newer running Desktop Manager post-3.6.3.
I asked RIM about this and they say that if users have already completed an EA on their device (whether OTA or via wired connection which apparently performs some variant of an EA, as described on p. 45 of the BES for Exchange Admin Guide) they will not have to do it again.

So for those of you who have bravely soldiered through all this text (thank you!), my question is whether anyone who's upgraded to SP2 - whether from 4.0.0.x or other versions - has heard users reporting unexpected EAs or other behavior. Any feedback you can provide would be most appreciated so we can properly prepare ourselves and our users for what to expect.

Thanks for your help!

cheers /td

[kthome]

Originally Posted by tdigitee

Hi all,

We are planning to upgrade our BES 4.1.0.40 server (for MS Exchange, MSDE DB) to SP2 this weekend and I'm trying to make certain we go about the process correctly, paying especial attention to potential user impact. Looks like we'll need to first back up the DB/SRP/auth key/server instance, then update to SP1 and finally to SP2.

Assuming all that goes smoothly (and please let me know if you have any caveats), we hope users won't have any issues. However, we have a mix of BB devices being used, from OS 3.7 up to 4.1 (all Cingular devices, 7280-7290-8700c-7130c), many of the newer using OTA Enterprise Activation but some via wired connection and Desktop Manager. <None of our users use wireless PIM sync except for Calendar>. The SP2 upgrade guide makes reference to 4.0 devices being forced to go through a wireless sync (page 13 of Upgrade_guide.pdf) and this is what concerns us.

RIM KB article KB-04295 (sorry, not allowed to post URLs yet), referenced by that page in the Upgrade Guide, suggests that the wireless sync will only occur on OS 4.0 or newer running Desktop Manager post-3.6.3.
I asked RIM about this and they say that if users have already completed an EA on their device (whether OTA or via wired connection which apparently performs some variant of an EA, as described on p. 45 of the BES for Exchange Admin Guide) they will not have to do it again.

So for those of you who have bravely soldiered through all this text (thank you!), my question is whether anyone who's upgraded to SP2 - whether from 4.0.0.x or other versions - has heard users reporting unexpected EAs or other behavior. Any feedback you can provide would be most appreciated so we can properly prepare ourselves and our users for what to expect.

Thanks for your help!

cheers /td

I second this request peeps. We are going to go from 4.0 to 4.1 then SP2. Anyone see any troubles with needing to re-EA any devices with this scenario. Exchange use MSDE DB as well...

Thanks all!

[|||||||]

No need to EA any handhelds. The pre 4.0 handhelds may need to be cradled.

[tdigitee]

Thanks! Do you know under what circumstances those older OS users may need to recradle? RIM seemed to suggest that they would not if they had the newer Desktop Manager builds (post-3.6.2) as their previous wired syncing would be akin to a wired EA.

Back in the older BES days I don't recall users having to recradle when we installed a new SP. But maybe that is a change in BES 4.x?

Also, is the proper path to do SP1 and then SP2 or is the latter a rollup?

Thanks!

[|||||||]

Just stick SP2 on there.

I wouldn't worry about which users need to cradle I doubt any of them will.

[gfisher99]

I just upgraded my 4.1.0.40 Lab BES straght to SP2... No need to install SP1 first. My Lab BES is working fine. I didnt have to re-cradle or anything. I have a 957 with 2.7a OS that Im using.. And thats only because MS Virtual Server doesnt have USB Support

Point being, I have an old OS running on a 957 and I didnt have to re-cradle. You should be all set. Let us know how it goes. Im about to upgrade our production BES from 4.0.3 to 4.1.0.40 then to SP2... Would like to know how it goes for you!

Thanks
Greg

[|||||||]

2.7 HH code is the same, feature wise as 4.0

By older code I mean 3.8 or earlier or on the C++ Handheld, 2.6 or earlier.

[tdigitee]

Thanks all for your help. Am going to upgrade to SP2 tomorrow and will report back next week with how it went.

I posted this in another thread as apparently there is a known issue in some cases with the SP2 upgrade - hope it is helpful (and that I don't run into it!):

Problem
You try to upgrade the BlackBerry Enterprise Server to software version 4.1 Service Pack 2 and the upgrade fails. The reason for the failure may vary (for example, the Transaction Log is full). When the original failure condition is corrected and you try to upgrade again, the BlackBerry Configuration Database upgrade fails. The DB_Install.log file displays the following:

[10000] (09/13 23:14:07.682):{0x1878} SQL Error Message from CBESDBInstaller::ExecuteSql.executeDirect: SQLSTATE: 42000 Native error: 3725 Message: The constraint 'PK_MDSConfig' is being referenced by table ' ', foreign key constraint 'FK_RelationSCMDS_MDSConfig'.
[10000] (09/13 23:14:07.682):{0x1878} SQL Error Message from CBESDBInstaller::ExecuteSql.executeDirect: SQLSTATE: 42000 Native error: 3727 Message: Could not drop constraint. See previous errors.

Workaround
To successfully upgrade the BlackBerry Enterprise Server, complete the following steps:

If you are running Microsoft SQL Server 2000 with SQL Query Analyzer

Click here to obtain the 103302.sql file.
On the SQL Server, open SQL Query Analyzer.
Select the BlackBerry Configuration Database name (for example, BESMgmt) from the drop-down list.
Open the 103302.sql file and run it.
If you are not running Microsoft SQL Server 2000 or do not have SQL Query Analyzer

Click here to obtain the 103302.sql file and save it on the BlackBerry Enterprise Server (for example, save the file to C:\Program Files\Research In Motion).
On the computer running SQL Server 2000 or Microsoft Data Engine (MSDE), open a command prompt.
Type the following command:
osql -d <database_name> -i <path>\103302.sql -E

where <database_name> is the name of the BlackBerry Configuration Database (for example, BESMgmt) and <path> is the path to the SQL file (for example, C:\Program Files\Research In Motion\103302.sql).

Note: The -E flag uses the permissions for the account currently logged in to Microsoft Windows® to access the SQL Server or MSDE database. If you do not have sufficient Windows permissions, or need to use a SQL Server account to log in, replace -E with the following:

-U <account_name> -P <password>

where <account_name> is the SQL login name, and <password> is the password of that account.

Press ENTER.
When the script has finished running, close the command prompt.

[tdigitee]

Following up, the upgrade to SP2 went fine. I'd back up the DB, CALs, SRP info beforehand per RIM's recommendations, and the upgrade itself was simple.

I hadn't realized each user would have IT policy reapplied (and thus get the "Policy settings have changed" popup) but that is pretty minor. Also, we don't use any MDS so was a little suprised to see the MDS_CS (MDS connection service) added in the left pane of the Manager but just disabled and stopped the service.

A number of user handheld transactions were queued due to reboots (SP2 upgrade as well as application of latest MS patches) which made bunches of application log events (errors and mostly warnings) but they went away eventually.

thanks again for everyone's feedback!

[tankee531]

thanks for sharing your experience

how long did your upgrade took?

[SteveA]

I upgraded from 4.1 (Exchange) straight to SP2. Took less than 20 minutes, including reboots. Just make sure you have a backup before proceeding.

It's all very, very straightforward. All of my devices are at least 4.0 OS and in some cases, I resent the Service Book if a user complained. Mind you they were on the other side of the country.

Steve

[Inphektion]

Originally Posted by tdigitee

I hadn't realized each user would have IT policy reapplied (and thus get the "Policy settings have changed" popup) but that is pretty minor.

There's actually a policy setting so that users don't get that popup as none of mine did.

[HaTaX]

Originally Posted by gfisher99

I just upgraded my 4.1.0.40 Lab BES straght to SP2... No need to install SP1 first. My Lab BES is working fine. I didnt have to re-cradle or anything. I have a 957 with 2.7a OS that Im using.. And thats only because MS Virtual Server doesnt have USB Support

I was a MS Virtual Server user until VMWare released their Server application free of charge.. You can patch through USB along with serial and so on. Nice slick interface, although the MS web interface is far superior, fast and easy to use with good support tools and execellent reliability.

Just voicing my experiance with my experiance with those products.

Also on that note my BES 4.1 server is in a VMWare virtual server. It's really nice to be able to go into it and take a snapshot, perform the upgrade recklessly, and if there are problems encountered, just roll back to the previous snapshot.. No harm no foul and I can get it back exactly how it was.

Finally some tools for admins that are affordable (Read: Free) that make our jobs alot easier and effcient.

[cecenst]

Need Help!!!! We just upgraded to 4.1.2 from 3.1 - well needless to say we have issues. We have about 230 BES users and about 40 of them did not complete. The devices are either showing Activation 0% or enter a email and password for activation.

Anyone with any suggestions on how to get the enterprise activation to the devices without have to touch each one?

[gfisher99]

I didnt even know it was possible to upgrade from 2.1 to 4.1.2??

I thought the minimum level was 4.0.3 to go straight to 4.1.2...?

I dont know what to tell you, mate...

[Inphektion]

i think unless you know a lot of mysql your only option is to delete the users, delete them from the db then readd. They shouldn't lose much of anything if it stayed sync'd with outlook.

[mole2384]

Has anybody got the 103302.sql file available?

[mole2384]

For anyone after the file:

/*+---------------------------------------------------------------------------
 *  Support Script: 4.1.2 Upgrade failure
 *  Created: 09/18/2006
 *  Tracked via : SDR103302
 *  Description: This script will fix the error in upgrading your database for the following failure:
 *	[10000] (09/13 23:14:07.682):{0x1878} SQL Error Message from CBESDBInstaller::ExecuteSql.executeDirect: SQLSTATE: 42000 Native error: 3725 Message: The constraint 'PK_MDSConfig' is being referenced by table ' ', foreign key constraint 'FK_RelationSCMDS_MDSConfig'. 
 *	[10000] (09/13 23:14:07.682):{0x1878} SQL Error Message from CBESDBInstaller::ExecuteSql.executeDirect: SQLSTATE: 42000 Native error: 3727 Message: Could not drop constraint. See previous errors. 
 *
 *  Instructions for running script:
*	1.  Backup database
*	2.  Paste the following code into Query Analyzer
*	3.  Select your BESMgmt Database and then run the code
 *+--------------------------------------------------------------------------*/

/* it is possible there may be a 4.1.2 Version row in ServerDBVersion Table */ 
delete from ServerDBVersion where CurrentVersion = '4.1.2'
go

/* it is possible there may be orphaned MDSConfig rows so let's get rid of them */ 
delete from MDSConfig where serverconfigid is null
go
 
/* Drop objects in case this is a rerun to avoid problem dropping PK_MDSConfig */
IF EXISTS (SELECT name FROM sysobjects WHERE name = 'RelationSCMDS' AND type = 'U')
begin
    drop TABLE dbo.RelationSCMDS
end
go
 
if exists (select name from sysobjects where name = 'FK_MDSminuteStat_MDSConfigId' and xtype = 'F')
begin
    alter table MDSminuteStat drop CONSTRAINT FK_MDSminuteStat_MDSConfigId
end
go