[fadmin]

Are all services running on the server you are moving users to? Can you ping it etc.

[mgarber]

Server A was our primary. Server B is the newer server we just brought online. All services are running on Server A and can be pinged from Server B. In fact, when I move users from Server B to Server A, although it give me that warning, it still proceeds to move the user. The user is then on Server A and everything works for the user.

[hdawg]

Originally Posted by kapasaca

why do you have two BES and one DB?
i prosume they both have the same SRP id and SRP auth key? (otherwise you wouldn't be able to move users without re-activating them again)
and if you do have the same SRP and using the same DB, why would you want to move the users in the first place??

You don't seem to understand the concept of using a shared configuration database.

2 SRPs / 2 BES / 1 BESMgmt DB ... if one fails you drag and drop users from one to the other and their mail flow resumes after they get new service books.

[kapasaca]

well, just tell me, are both BES' connected to the exact same DB (BESMgmt)?
because this just isn't possible.
The same SQL server or instance is possible, but not with the same DB name.

when you move a user within the same domain to another BES it will automaticly re-activate the user and so this isn't as simple a appears.

Keeping up a mirror BES is far easier.

[Dunks]

Originally Posted by mgarber

Server A was our primary. Server B is the newer server we just brought online. All services are running on Server A and can be pinged from Server B. In fact, when I move users from Server B to Server A, although it give me that warning, it still proceeds to move the user. The user is then on Server A and everything works for the user.

Are they running the same software revision?

[hdawg]

Originally Posted by kapasaca

well, just tell me, are both BES' connected to the exact same DB (BESMgmt)?
because this just isn't possible.
The same SQL server or instance is possible, but not with the same DB name.

when you move a user within the same domain to another BES it will automaticly re-activate the user and so this isn't as simple a appears.

Keeping up a mirror BES is far easier.

Again, you're incorrect. Most environments I work in have multiple BES servers (same version) sharing the same configuration database.

This minimizes user impact when there are extended maintenance windows / outages of a server ... it also lets you share CALs.

Keeping up a mirror BES may be easier to some; but definitely not always.

[fadmin]

Originally Posted by kapasaca

well, just tell me, are both BES' connected to the exact same DB (BESMgmt)?
because this just isn't possible.
The same SQL server or instance is possible, but not with the same DB name.

when you move a user within the same domain to another BES it will automaticly re-activate the user and so this isn't as simple a appears.

Keeping up a mirror BES is far easier.

Have you ever tried it man? I have couple of dozens servers all connected to a same SQL DB and all have different SRP (of course). If they are not connected to a same DB how would you move user and "automatically activate" as you say? Stop confusing other people if you are not sure how all of it works...

[mgarber]

Dunks - Yes - same software version.

hdawg - You are correct. This is exactly how we set our environment up per your recommendation a few months ago.

[Dunks]

I have seen this error before where the server was running different maintenance releases and where the user making the changes didn't have sufficient privilages over the BES. Check all local permissions, including Admin Group the boot and braces User Rights Assignments, reboot and try again.

You may also want to check for gpo's, in case they are interfering with the local rights assigned.

[kapasaca]

Originally Posted by hdawg

Again, you're incorrect. Most environments I work in have multiple BES servers (same version) sharing the same configuration database.

This minimizes user impact when there are extended maintenance windows / outages of a server ... it also lets you share CALs.

Keeping up a mirror BES may be easier to some; but definitely not always.

i'm sorry to those who might get confused.
i work on many servers and do installations as well, but never encountered this setup.
i've asked RIM to elabored on this setup for me, because i sure delieve you when you say it's possible and have it like this.

-----------------
edit

I found the following.

1. Identify the name of the centralized BlackBerry Enterprise Server database computer: _________________.
2. On the BlackBerry Enterprise Server computer that you want to consolidate, open the BlackBerry Enterprise Management console.
3. On the left pane, click BlackBerry Server Management.
4. On the Action menu, click Properties. The BlackBerry Server Management Properties window appears.
5. Click the Database tab.
6. In the Database Server field, type the name of the computer that you identified as the centralized BlackBerry Enterprise Server Management database server.
7. Click OK.
8. Close the BlackBerry Enterprise Server Management console.
Note: You must restart the BlackBerry Enterprise Server Management console (close and reopen the console) for the change to take effect.
9. On the centralized BlackBerry Enterprise Server Management database server, open the central BlackBerry Enterprise Server Management console. The Tree view expands automatically and displays a list of BlackBerry Server site/routing groups.
10. Click the plus sign next to a BlackBerry Server site/routing group to expand the item and view its servers, if any exist.
11. Right-click and select New BlackBerry Server. The BlackBerry Enterprise Server System Info window appears.
12. Add the BlackBerry Enterprise Server that you want to consolidate by entering the appropriate values in the Server Name, SRP Identifier, SRP Authentication Key, Host routing Information (if provided on the CD), and Administration Mailbox fields. Verify that the SRP Identifier and SRP Authentication Keys are unique to this BlackBerry Enterprise Server.
After adding the BlackBerry Enterprise Server to the centralized database, to avoid passing conflicting data between the two databases, do not run the BlackBerry Enterprise Server Management Software against the old database. Examples of conflicting data are IT policy information and peer-to-peer key data.


So this actually means that ONE BBserver defines the DB and all other BBservers point to that BBserver?

[mgarber]

I checked all permissions and everything looks right.

Both servers are running 4.1.4 - same software on both.

The only thing that is different is server A is Windows 2000 server and server B is Windows 2003 server. Could this be causing the issue?

[fadmin]

They are both in the same domain?

[mgarber]

yes - same domain.

[siemp]

"it still proceeds to move the user" No worries then .

Apart from the message is there anything to be found in the log's?

Do you get the same message on both servers? That is when moving users from B to A?

[mgarber]

Great question. Nothing in the logs.

When I am on server A and move users from server B to server A, I get no warning\error.

When I am on server B and move users from server B to server A, I get the warning\error.

When I move users from server A to server B, no errors at all.

[bbxpert]

To mgarber : If you create a new user on Server B and move them to A, do you get the error, or does it only happen with existing users?

Are you logged into Server A or Server B when you do this? Does the error happen from both servers?

To kapasaca :
How to install the BlackBerry Enterprise Server using a shared database
BlackBerry Search Results

Its not just done for fail over, its also done for load balancing and easy of management.