[JRV]

BES 4.0/SP3/HF2/Exchange

We are changing providers. The new provider is furnishing new BBs. Before doing an OTA activation of the new BB, I send a Kill to the old BB and wait for it to report status. Sometimes it succeeds, sometimes not. When it fails, BB Manager Properties/IT Admin shows status of "Error" instead of "Applied Successfully" and this appears in the Policy log:

 
[40000] (01/11 08:31:26):{0x2D0} {<e-mail address>, PIN=<PIN>, UserId=70}SCS::PollDBQueueNewRequests - Queuing KILL_DEVICE_REQUEST request
[30000] (01/11 08:31:26):{0x39C} {<e-mail address>, PIN=<PIN>, UserId=70}RequestHandler::SendQueuedITAdminCommandToDevice Sending data to device, contentType=ITADMIN, size=50, RefId=0, TransactionId=-1010828059, Tag=2197
[40000] (01/11 08:31:26):{0x39C} {<e-mail address>, PIN=<PIN>, UserId=70}RequestHandler::SendToRelay - SubmitToRelaySendQ, Tag=2197
[40000] (01/11 08:31:26):{0x304} [SRP] Send data, Tag=2197, Submit=1, Size=50
[40000] (01/11 08:31:26):{0x304} [SRP] EVENT=Send_SEND, VERSION=1, TAG=2197, SIZE=50
[40000] (01/11 08:31:26):{0x3E4} [SRP] EVENT=Receive_STATUS, VERSION=1, TAG=2197, STATUS=2
[40000] (01/11 08:31:26):{0x3E4} [SRP] Received status REFUSED, Tag=2197, AckRequired=0
[30000] (01/11 08:31:26):{0x3A4} {<e-mail address>, PIN=<PIN>, UserId=70}RequestHandler::DoDeviceSentProcessing - Message returned as REFUSED - could not be delivered to device, Tag=2197, EntryId=0
[40000] (01/11 08:31:26):{0x3A4} {<e-mail address>, PIN=<PIN>, UserId=70}RequestHandler::DoITPolicyDeviceSentProcessing - ITPolicy GME Receive Ack for the command KILL_HANDHELD_COMMAND - Processing packet, Tag=2197

REFUSED??? These are BES-provisioned devices, and they've been working with BES for months. Why is it refusing this one, critical command all of a sudden?

Even more scary is that on at least one occasion, BB Manager reported the command was "Applied Successfully", but the BB was NOT killed. It was an HR BB with a lot of sensitive data on it.

[nb_mitch]

If you have the devices, why not just wipe them manually?

[JRV]

Should be obvious, but...

A. Somewhat more labor-intensive to do manually.

B. It allows me (if it works, that is) to make sure it gets done, since data security is my responsbility, but I won't be handling the BBs myself.

C. We won't always have the devices...this needs to WORK DEPENDABLY when a BB is stolen or lost.

D. When something doesn't work, it's a reasonable thing to want to find out why and not just work around it.

[nb_mitch]

I understand what it is "suppose" to do, but in your case it isn't working. So, if it were me I would rather hit it with a hammer than wonder if some command I sent over the network actually worked. I would think the "kill" would be a last ditch effort for a lost or stolen device.

I totally understand the need to know why it isn't working and possible fixing it. Not sure it would save much time though if you have to verify it actually worked with each device before you throw them in the trash/return them/donate them to charity, etc.

Typing "X" in the password 10 times works too rather than doing an official wipe connected via the USB

[JRV]

Gotcha. Whatever. Yes, we're wiping them manually, of course; currently we have no other choice.

Now, back to the question...anyone have any idea why this just started happening and how I can fix it?

[mahoward]

Messages REFUSED by the wirless network mean that the account is either provisioned incorrectly by the wireless carrier, i.e. for BIS instead of BES, or the account has been deactivated. Check to see that the owner of this devices SIM card is up to date on their bill payment.

[JRV]

Those were some of my first thoughts...but it isn't messages that are being REFUSED, it's only the Kill command. Messages flow before and after the kill command. I can resend service books, I can resend policy, I can even locally wipe & activate the device, all OTA.

Only thing I can't do is kill it.

[adminbes]

Originally Posted by JRV

Those were some of my first thoughts...but it isn't messages that are being REFUSED, it's only the Kill command. Messages flow before and after the kill command. I can resend service books, I can resend policy, I can even locally wipe & activate the device, all OTA.

Only thing I can't do is kill it.

Carrier probably issued a deactivation command - I see the kill command refused when Cingular killed the device before or during the kill command being issued from the BES - We issue this command for the data on the device when the device is lost or stolen - Cingular has to take care of the phone portion of the device - kill command does not disable the phone

[DoomBringer]

Wait, a carrier can block my kill commands? I'd stop service immediately, because this functionality is pretty important to me and security. Frankly, it is none of Cingular's business to prevent me from doing what I want to the things.

[d_fisher]

Originally Posted by DoomBringer

Wait, a carrier can block my kill commands? I'd stop service immediately, because this functionality is pretty important to me and security. Frankly, it is none of Cingular's business to prevent me from doing what I want to the things.

What if your user called Cingular to report the device stolen before they called you? Cingular would disable the device because they were instructed to. This is why I feel it is ultra important to password protect the handheld. If someone loses their BlackBerry and the kill command never gets to the handheld, after 10 attempts the BlackBerry will be wiped.

[JRV]

Totally agree about the password-protection. Kill command or no kill command, that's critical.

I think it's correct that the carrier disabled the device. The company was changing carriers and BBs simultaneously. I learned later that the person handling the changeover did not generally wait for me to kill the BB before making the switch. Hopefully she wiped them before returning them to the old carrier.

Perhaps instead of coming back with "REFUSED" status, it should give the reason: "REFUSED - DEVICE DISABLED BY CARRIER". That way you'd at least know the status of the device...it has data on it but won't be getting any more, and will be wiped after x bad password entries.

Or is a device being disabled by the carrier the ONLY reason a command is ever refused?

[DoomBringer]

Originally Posted by d_fisher

What if your user called Cingular to report the device stolen before they called you? Cingular would disable the device because they were instructed to. This is why I feel it is ultra important to password protect the handheld. If someone loses their BlackBerry and the kill command never gets to the handheld, after 10 attempts the BlackBerry will be wiped.

I agree completely, all handhelds should have a password (of course, one of my users is a total whiner about it). I'm not saying that I can rely on kill instead of passwords, but if its my device, I should be able to do whatever I want.

[CanuckBB]

Originally Posted by nb_mitch

I understand what it is "suppose" to do, but in your case it isn't working. So, if it were me I would rather hit it with a hammer than wonder if some command I sent over the network actually worked. I would think the "kill" would be a last ditch effort for a lost or stolen device.

a 'kill' command would be the FIRST thing I'd do if a user erported a lost/stolen device. My first priority is data security.

[JRV]

Originally Posted by DoomBringer

of course, one of my users is a total whiner about it

Just one?

I have one user that ISN'T a total whiner about it, and that would be me!