|
|
01-11-2006, 09:51 AM
|
#1
|
Thumbs Must Hurt
Join Date: Apr 2005
Location: Houston, TX USA
Model: 7130e
Carrier: Verizon
Posts: 144
|
Kill command REFUSED??
Please Login to Remove!
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:
Code:
[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.
Last edited by JRV; 01-11-2006 at 09:54 AM..
|
Offline
|
|
01-11-2006, 10:00 AM
|
#2
|
CrackBerry Addict
Join Date: Jul 2005
Location: Bentonville, Arkansas
Model: 8310
Carrier: AT&T
Posts: 678
|
If you have the devices, why not just wipe them manually?
|
Offline
|
|
01-11-2006, 10:05 AM
|
#3
|
Thumbs Must Hurt
Join Date: Apr 2005
Location: Houston, TX USA
Model: 7130e
Carrier: Verizon
Posts: 144
|
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.
|
Offline
|
|
01-11-2006, 10:45 AM
|
#4
|
CrackBerry Addict
Join Date: Jul 2005
Location: Bentonville, Arkansas
Model: 8310
Carrier: AT&T
Posts: 678
|
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
|
Offline
|
|
01-11-2006, 11:01 AM
|
#5
|
Thumbs Must Hurt
Join Date: Apr 2005
Location: Houston, TX USA
Model: 7130e
Carrier: Verizon
Posts: 144
|
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?
|
Offline
|
|
01-13-2006, 10:32 AM
|
#6
|
CrackBerry Addict
Join Date: May 2005
Model: 8900
Carrier: T-Mobile
Posts: 560
|
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.
|
Offline
|
|
01-13-2006, 10:36 AM
|
#7
|
Thumbs Must Hurt
Join Date: Apr 2005
Location: Houston, TX USA
Model: 7130e
Carrier: Verizon
Posts: 144
|
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.
|
Offline
|
|
07-11-2006, 10:42 AM
|
#8
|
New Member
Join Date: Apr 2006
Model: 7290
Posts: 1
|
Quote:
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
|
Offline
|
|
07-11-2006, 12:31 PM
|
#9
|
Talking BlackBerry Encyclopedia
Join Date: Feb 2005
Model: 7280
Carrier: cingular, no wait, AT&T
Posts: 300
|
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.
|
Offline
|
|
07-11-2006, 12:46 PM
|
#10
|
Retired BlackBerryForums.com Moderator
Join Date: Oct 2005
Location: Columbus, OH
Model: 9700
OS: SID 6.7
Carrier: AT&T
Posts: 4,455
|
Quote:
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.
|
Offline
|
|
07-11-2006, 01:09 PM
|
#11
|
Thumbs Must Hurt
Join Date: Apr 2005
Location: Houston, TX USA
Model: 7130e
Carrier: Verizon
Posts: 144
|
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?
|
Offline
|
|
07-11-2006, 01:46 PM
|
#12
|
Talking BlackBerry Encyclopedia
Join Date: Feb 2005
Model: 7280
Carrier: cingular, no wait, AT&T
Posts: 300
|
Quote:
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.
|
Offline
|
|
07-11-2006, 01:57 PM
|
#13
|
BlackBerry Extraordinaire
Join Date: Feb 2006
Location: YYZ
Model: 9900
Carrier: Rogers
Posts: 1,183
|
Quote:
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.
|
Offline
|
|
07-11-2006, 05:33 PM
|
#14
|
Thumbs Must Hurt
Join Date: Apr 2005
Location: Houston, TX USA
Model: 7130e
Carrier: Verizon
Posts: 144
|
Quote:
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!
|
Offline
|
|
|
|