For security reasons, the IT Policy assigned to a device cannot be removed, even if the device is wiped. It is like a permanent tattoo. Like tattoos, however, they can be removed with a long and painful procedure. At least that is the way it used to be, nowadays we have more options. Let's go over them.
1) Wipe the device. Although the IT policy still exists on the device, the wipe process opens a "window" where an activation against another corporate BES server can overwrite the IT Policy with the new one. So for moves between organizations, you can only replace one policy with another, you cannot overwrite. For people who purchase previously corporate BlackBerry's on EBay for personal use this has been quite a hassle, as they are stuck with the old corporate policy which may be locked down significantly.
Which leads to...
2) Use the policy.bin file to clear the policy. This is a long and messy procedure (which I will not get into here) which mostly gets rid of the old policy, using the pre 4.0 method of a policy.bin file and Desktop Manager. I don't like this method because of the time it takes, and the lack of being in a known consistent state at the end. It is not really "just like new" when this is done, but can be enough for most people.
3) This is a new one. With a device OS later than 4.2.2, you can use the "Remote Wipe Reset to Factory Defaults" procedure documented in an older post here:
http://besdomino.blogspot.com/2007/10/remove-it-policy-new-feature-of-41-sp4.html
4) This is also a new method, which does not require an IT Policy assignment or a BES server at all, just the Javaloader utility in the RIM developer tools download. Note that an OS of 4.3.0 or higher is required, and the Javaloader utility itself must be the latest version.
Strangely, the utility does not list version numbers, so you just have to look for the available option:
resettofactory
Reset IT policy to factory settings
...when you run the executable without parameters to see if it supports it. If it does, then this command will wipe the IT Policy right off, and set it back to default:
c:\javaloader -u resettofactory
The future of IT policy removal is a bright one, indeed.
Friday, March 28, 2008
Friday, March 21, 2008
Multiple BlackBerrys per Mailfile?
Answer: Yes with some caveats.
First, you need to have fully separate BES environments, i.e. at least 2 SQL back end databases. This is easy for us as we have an EU BES environment on it's own SQL database.
If we need to set up an additional handheld for an end user, whether they need it temporarily for an assistant, or need to test a new device, then we add their account to the other BES environment and activate their device as normal. Since BlackBerrys are international devices there is no problem getting back to the device here in the U.S to finish activation.
Notes:
1) BlackBerry activation can take considerably longer due to the WAN if you are using another continents environment like we are. Don't freak out if it takes a few hours.
2) If you are doing OTA activation, temporarily disable the original BES account as it might pick up the activation email and discard it, leaving your remote BES server waiting forever. [BES servers are selfish and will NOC-block you if you let them. :)]
3) If these requests becomes common, you might want to think about a secondary local BES environment, perhaps running with an integrated MSDE, to support this service. Of course you need an additional SRP to do this.
4) Remember that these accounts cannot be failed/moved over to other local BES servers in a DR scenario, as they are on a separate database.
5) Don't forget about these "ex-pat" accounts if on a foreign BES server. The local admins may not ever delete them b/c they don't know who they are. So you should keep track of them and delete them when it looks like the service was cancelled or otherwise abandoned.
Other than these caveats, I have not seen any issues with this in our environment.
First, you need to have fully separate BES environments, i.e. at least 2 SQL back end databases. This is easy for us as we have an EU BES environment on it's own SQL database.
If we need to set up an additional handheld for an end user, whether they need it temporarily for an assistant, or need to test a new device, then we add their account to the other BES environment and activate their device as normal. Since BlackBerrys are international devices there is no problem getting back to the device here in the U.S to finish activation.
Notes:
1) BlackBerry activation can take considerably longer due to the WAN if you are using another continents environment like we are. Don't freak out if it takes a few hours.
2) If you are doing OTA activation, temporarily disable the original BES account as it might pick up the activation email and discard it, leaving your remote BES server waiting forever. [BES servers are selfish and will NOC-block you if you let them. :)]
3) If these requests becomes common, you might want to think about a secondary local BES environment, perhaps running with an integrated MSDE, to support this service. Of course you need an additional SRP to do this.
4) Remember that these accounts cannot be failed/moved over to other local BES servers in a DR scenario, as they are on a separate database.
5) Don't forget about these "ex-pat" accounts if on a foreign BES server. The local admins may not ever delete them b/c they don't know who they are. So you should keep track of them and delete them when it looks like the service was cancelled or otherwise abandoned.
Other than these caveats, I have not seen any issues with this in our environment.
Subscribe to:
Posts (Atom)