[kjarrodc]

I'm pretty sure I know the answer, but I just have to verify ...

In our environment, we essentially have two BES servers each having it's own database. One of the BES servers (BES01) is a virtual machine with it's database sitting on a separate SQL cluster having 1.2k users. The other (BES02) is a rickety old machine having about 200 users. Needless to say, I'm very concerned about BES02; There's no hardware or SQL fail over. As such, I'd like to move the 200 users to my BES01 setup.

Is there any way to perform this without having to wipe/reactivate all 200 users?

There appears to have been a database merge utility: http://www.blackberryforums.com.au/f...098-post1.html. I contacted RIM about this and they said it had been removed because of problems experienced in the past.

As an alternative suggestion, RIM suggested that I could perform the following steps to accomplish the same:

-Record the SRP, Authentication key, and CALS.
-Stop SQL
-Rerun the 4.1.6 setup and point the server to the BES01 database.
-During the install, specify the CALS, SRP, etc from BES02.
-Re-add the users manually.

When asked how this could work, the representative explained that the BES creates a hidden blackberryhandheld folder on the individuals exchange account. After re-addig the user, the mail agents read the hidden folder and magically creates the link between exchange and BlackBerry device again.

So, I setup a test environment and have tried several incantations of these procedures, but it's not quite working. However, and I've done this twice to confirm, if I simply point BES02 to the BES01 database and re-add the user to BES01, the mail agent successfully reads the hidden folder and links up the device again. I can send/receive mail, but the IT policy is rejected by the device. I've tried matching the policies exactly on both servers, but this continues to happen.

Your thoughts?

[rsk]

interesting, I have a procedure from RIM for merging databases that may help...

Originally Posted by rim

Legend
BES A with database A xxx8211; Destination for consolidation
BES B with database B xxx8211; Database that will be migrated from and users moved off of this server
BES C added to database A xxx8211; Swing server that will end up being production
Instructions
BES B offline while move occurs

Pros: Ease of moving back to BES B quickly should you need to as we never edit the database or remove the users.
Cons: Likely will be done during the night or weekend. This could result in longer period of outage for the users.
Prep work
1. Using SQL, export all user email addresses and corresponding IT Policy. This will be the basis of the input file needed to add multiple users to the BES using the BRK. You will need to break this file into smaller files for the actual addition of users. The IT Policy that the user currently has will tell you what will be needed to be in place in the destination database A for IT policies before the moves will be done. You can export the needed policies from the BES B and import them into the BES A domain to make life easier when performing the migration.
select mailboxSMTPAddr as EmailAddress, 'Server moving to' as DestinationServer from UserConfig left outer join ServerConfig on serverConfigId = ServerConfig.id
where ServiceName = 'current server'
Save the output as a text file and you can use this as the input file for the BRK. You can even add in the ITPolicy that you want assigned into this script if needed. If you do not specify a policy, the default policy will be applied automatically.
2. Backup the database A and then run the ITPolicyKeyMapping.sql script on the database that will be the destination database for the consolidation.
3. Add BES C to database A using the change database wizard. This will be referred to as the swing server. All users for BES B will be moved to this BES.

Migration steps
1. Shut down BES B and set all services to manual
2. Backup database A.
3. Run the following SQL query on the database from BES B to get the public and private IT Policy keys. These will be needed for step 4 to enter into database A.
select PolicyPublicKey, PolicyPrivateKey from GlobalSettings

4. Run the following insert statement on database A. Make sure to take the public and private key values from step 3 and substitute them for <public key value> and <private key value> below.

insert into GlobalSettings (Container,PolicyPublicKey, PolicyPrivateKey) values ('site 1', <public key value>, <private key value>)
The name xxx8220;site 1xxx8221; can be changed to anything you wish it does not matter. You may want to substitute the old BES name where the keys came from instead of site 1, site 2 etc.
5. Using the BRK and the input files created from the prep work section, add 1 set of users at a time while monitoring the SQL performance to ensure you are not overworking it. SQL will spike to 100% (or high CPU) during the bulk addition of users but will tail off quickly. Before adding the next set of input files, make sure CPU is within tolerances on the SQL server and BES C (swing server). This can be taxing on the BES and therefore you want to start the entire process by adding fewer users and expanding the subsequent input lists until you find a sweet spot. Please start with no more than 100 users first to test the load that will be created. This is similar to performing an Enterprise Activation and our documentation states not to add more than 200 users at a time but this may be different from environment to environment.
Besuseradminclient.exe xxx8211;add xxx8211;i users.txt xxx8211;p <password>
6. Users once added will be sent new service books and the BES will start a slow synchronization with each user device added.
7. Once all users are moved, you can use BES B as the next swing server by running the change database wizard to add the server to BES A database and repeat the process.
Notes:
- Make sure you are not using any policies that are in the server exclusivity group as this will cause issues for the migration that will be very noticeable to the users. Duplications and inability to reply to old email were encountered when using these policies through testing.
- Through testing we have simplified the number of steps down to what is contained in this document.
- Devices prior to 4.0.2 will not work using these migration steps and will need to be wiped and reactivated.

hope it helps.

[Jadey]

Originally Posted by kjarrodc

I can send/receive mail, but the IT policy is rejected by the device. I've tried matching the policies exactly on both servers, but this continues to happen.

Are you using a customised policy?

I would try sending the DEFAULT policy to the device you are testing on BES2 before you add it to BES1. Then from BES1, once device attached, resend the custom policy.
Obv this assumes you are testing with non-default policies.

[kjarrodc]

Great suggestion!

@Jadey

I tried your suggestion first. I set the user account to the default policy, pointed the BES02 environment at BES01's database, and re-added the user. Like we saw before, email processing works! (somehow...), but unfortunately, the IT policy continued to be rejected.

Take a gander at this KB:
IT Policy Error status

I think this article confirms that even if the policy names are the same, this won't ever work because the BES signs the IT policy using the keys in the GlobalSettings table. As stated - "These keys let the device confirm that the policy key came from its database."

@rsk

I can't find the ITPolicyKeyMapping.sql script anywhere. If you google for it, the results are this thread. The BTSC has no information on it whatsoever. Also, I can't seem to find the script searching through the install files on the BES. Might you have it? I'd like to look at the script to see exactly what it's doing.



However, I was able to use a modified procedure based on your and Jadey's suggestion - and IT WORKS!

Here's the steps I took:
1) Backed up both servers databases - for good measure.

2) Record the public and private keys from BES02's database.
-select PolicyPublicKey, PolicyPrivateKey from GlobalSettings

3) Pointed BES02's database at BES01's database using the Change Database wizard in the BlackBerry Server Configuration.

4) Inserted the public and private keys from BES02 into BES01's database.
-insert into GlobalSettings (Container,PolicyPublicKey, PolicyPrivateKey) values ('site 1', <public key value>, <private key value>)

5) Added the user from BES02 back to BES02 in the BlackBerry Manager

The BES appears to have read the hidden folder for this account on exchange and this can be confirmed because shortly after adding the account, the device PIN populates in BlackBerry Manager - without doing anything on the device. Messaging continued to work and the IT policy was successfully applied.


I know RIM doesn't support making any changes to the database, but I think I'll call them and see their thoughts on this procedure.

I've noticed that the after inserting the new record into the GlobalSettings table that may parameters were automatically entered - i.e. 'NextExternalServicesPort', 'MDSPushMessageMaxAge', etc... However, some other settings inserted nulls - i.e. 'HandheldMgmtConfigProperties', 'ContentProtectionPublicKeys','ContentProtectionPr ivateKeys'.

It makes me concerned if there will be any problems with content protection - which is a mandatory requirement in our organization. Also, does it matter that there's two records in the GlobalSettings table?

If a process like this works, I'm surprised the RIM doesn't have anything formal on it - or do they? It seems to me that having the ability to consolidate databases would be a relatively common task.

[Jadey]

OK, one other thought then. Rather than changing the keys etc (as this seems quite intrusive to BES functions) have you tried doing all the steps, and having the policy fail. THEN once user on BES2, generate an EA password and reactivate the device. The mail etc should all synch up fine, and you DON'T need to wipe the device to force an EA. What it should do though, is sort out the keys and policies. Yes, it is an extra step as users would need to EA again, but they would not lose any data, and it saves making unsupported changes to BES.

This might not work, but I had the idea last night (how sad am I, thinking about BES fixes on a Sunday night?!!!) and thought I'd post. I have a good feeling about this solution, I think running an EA after devices moved across BES servers would sort the few remaining probs.

[kjarrodc]

Thanks again for your comments Jadey.

I agree - it is possible that performing an EA would get the user up and running with the new policy. However, I was unable to test your suggestion - I apologize.

I contacted RIM yesterday and I feel more confident about these procedures after discussing the matter with them. Halfway explaining the scenario with the representative, he asked if I was having problems with updating the IT policy. Quickly proceeding, he provided me with an internal, non-public KB that Rsk's suggestion was an obvious adaptation of.

My environment actually consists of 3 BES servers each having their own database (in my defense, I'm picking up where a previous BES admin left off), so I'll end up performing these steps twice. This afternoon I moved a one of our less occupied BES servers over to our new production environment and it has gone well. I ran across one snag but it was easily resolved. Oddly, after pointing the BES that I was performing the migration on to the new database, the MDS service would not start up. Reinstalling the BES and rebooting resolved the problem.

In summary, these are the steps I performed. These are a very slight modification of the internal KB from RIM. Hopefully this will be of assistance for anyone else having to ... clean up.


1 - Backup SRP, Authentication Keys, and CAL's

2 - Backup Databases on both servers.

3 - Get a list of the users on the servers database you're migrating - somehow - export it to excel, use the BRK, etc.

4 - Retrieve the public and private keys out of the database you'll decommission.
-select PolicyPublicKey, PolicyPrivateKey from GlobalSettings
5 - Insert the keys into the database you'll be migrating the users to.
-insert into GlobalSettings (Container,PolicyPublicKey, PolicyPrivateKey) values ('site 1', <public key value>, <private key value>)

6 - Stop the database you'll decommission.

7 - Using the wizard in the BlackBerry Server Configration utility, point the BES to the database you'll be migrating the users to.

8 - Ensure all the services have started.

9 - Configure any necessary settings for the BES including LDAP, proxies, etc. This may be a good time to add your CAL's back again.

10 - Add 1 users - wait for the BES mail agent to read the individuals exchange hidden folder. You should see their PIN pop up in the BlackBerry Manager.
- I should note here - If you have to point the BES back at the original database for whatever reason, it appears you'll have to wipe and reload this user. I ran across this situation at least twice - hence the suggestion of adding only one user.

11 - Verify everything is working - mail, calendar, address book, notes, tasks, pin, office communicator, web, pin (for good measure), pushing service books and of course, push the IT policy.

12 - Add the rest of your users.

[Jadey]

Thanks for sharing, and well done for getting it sorted!