"SERVICE BLOCKED" (RED X) via DESKTOP (BES) SERVICE BOOK
I've searched herein and googled for same and can't search out a definitive answer.
On a new 8330, from Bell Mobility, I cannot send any email messages via the DESKTOP (BES) SERVICE BOOK.
Sent Using: Desktop (Secure)
Folder: Sent Items
Message Status: Service Blocked.
and the RED "X" on the message listing screen.
The Curve, 8330, is new on May 27th, and was an upgrade from a 7250. All was good -- including by BES EXPRESS use -- until for 7 days until this Tuesday morning, June 3rd. Then everything works EXCEPT BES ACCESS.
Not so coincidentally, Bell's billing computers ran overnight Monday into Tuesday.
I had been operating under a pay-as-you-play 1X data plan and all was good. I took the new $30.00 unlimited data plan on the 27th. Review of the freshly minted bill shows that my new 8830 BES-traffic was still going down the pay-as-play 1X plan path, not the $30 plan path.
Calls into BELL on Tuesday morning and they say, "the $30 plan is BIS only, not BES compatible." This despite my asking and making them note the file so before agreeing to the $30 plan.
They agree to hump me over to a BES compatible data plan. BUT I STILL CANNOT GET BES EMAILS WORKING. I have wiped the 8330 and re-activated numerously. I have even wiped, re-registered the BES EXPRESS with a new Key/cal pair.
Same RED X.
BELL *ASSURES* ME THEY'VE PROVISIONED CORRECTLY.
Other info: When the 8330 is USB tethered to the BES EXPRESS, everything works; therefore, the BES/EXCHANGE relationship is ok. The BES can active the 8330 if tethered, but not over-the-air -- just times out. Untethered, the BES cannot PIN the 8330. Messages through the BIS service books works perfectly. (And, yes, I have tried BES with and without BIS service books co-installed.)
What do I need to do to fix this, if it is an issue in my administrative/technical domain?
What log file or thing do I have to give to BELL to demonstrate that it's their provisioning, if it is in BELL's administrative/technical domain.
I think something is "stuck" between what a first-level tech can see and the Bell-Blackberry.net SRP interface.
But how do I expose this, because -- after ten calls over three days -- Bell tech's have noted the file and dismissed the problem.
Sounds like you're stuck between the proverbial rock and hard place on this one.
I can almost guarantee that you have the wrong data plan provisioned on the line.
I would say to keep calling the carrier until you get someone who knows what they're doing. Proving a carrier wrong is nearly impossible. You're better off trying to find that one rep in the bunch that has a clue and can fix the issue for you.
Maybe ask them to completely remove all of the data plans completely. Then call back and have someone else add it back.
They've essentially said BES -- EXPRESS -- is "unsupported" and go away.
There has to be some logging somewhere that can show where in the path it's getting turned back.
The provisioning of the device is done on the RIM infrastructure, they may have an automated system that sends reprovisioning requests to the infrastructure from their billing platform but this is totally up to the network.
It may be that the data plan is right or wrong but it's the status of the PIN on the infrastructure that matters, unless you can get them to change this for you properly there is nothing you can do for the handset.
RIM manufactures the BB's, the data side is up to the carrier. This is a carrier provisioning issue. It either has not data services or it only has BIS.
A BB will always work with a BES when it's connected via USB, data service or not. Wireless data transmission is not required when using USB.
Bell needs to correct your data plan. You should try to get transferred to RIM. They will prove beyond a doubt that it's the carrier. I PM'ed you earlier about this, I can save you the trouble of getting transferred to RIM. It's up to you.
Either way, the carrier needs to fix this, not RIM.
I've been pondering for hours on how to word my response and everything I came up with sounded way too abrasive. ;-)
Thank you, everyone.
Being in the I.T. business, an admin buddy had some spare CALs on his BES. He set me up for a over-the-air activation to his BES. I wiped my 8330 --again-- and aimed it his way. We all know the result, right.
This too failed. Just timed out like when pointed at mine. Also, his BES showed the activation status as "Never connected." This was, to me, absolute proof positive of a provisioning shortfall.
Back on the line with Bell Mobility.
Nice level-1 tech guy, regrettably informs me there's a supervisors note on the file: NO FURTHER ASSISTANCE TO BE PROVIDED.
I offer the new evidence. L1 just doesn't get the meaning of it, but does relay it to the supervisor. After a few minutes comes back on the line w/the supervisor. Verdict: Please stop calling us. *I'm* wasting *their* time.
I called RIM, not Bell, support and bought a paid incident support ticket.
About 3 minutes for credit card in take processing. About 3 minutes to give them my problem description to the in take agent. About 2 min in queue waiting for a RIM Engineer. About 3 min to re-cap my problem with the RIM Engineer. About 30 seconds for him to query the network and see ... drum roll ... that IT'S A CARRIER PROVISIONING ERROR!
RIM Engineer raises a conference call with BELL MOBILITY DATA SUPPORT, which curiously is the SAME number and access that I've been using. No RM-BELL red BAT phone.
RIM Engineer identifies himself to the Bell tech rep and says he has a subscriber with a BES provisioning difficulty. (which was exactly what I said in my first and every subsequent callin).
I voice out the my account details and magic passwords. And without the RIM engineer saying anything more, the L1 Bell tech, looks at the account and in like 15 seconds says, "yep, provisioned as "ConsumerPro" only and for BES you need "ConsumerPro" AND "Enterprise" provisioning.
This from a very polite and fast Bell level-1 only tech, but otherwise after 4 days and nine previous callins lasting hours and going backwards!
She puts us on hold to call her help desk for the re-provisioning and, while we're waiting, my RED Xs just start disappearing.
Success, at last!
I asked the Bell tech, why it was sooo easy and quick for her and mission impossible for the others. This is the point where she actually read the file notes and said, "oh, my." And, of course, politically, she can't safely answer that question.
She, Bell, drops off the line. I'm doing the wrap-up with the RIM Engineer and he, RIM, waived the paid support incident fee because --after all-- it was a carrier-provisioning error and not a customer error.
So, in less then 20 minutes with RIM involved, I was up and running. Without them, it had been a work week of outage and hours and hours of in queue time, and a dozen device wipes and -- yes -- out of desperation, I even built a fresh BES EXPRESS instance in a VMWARE instance. After all this, I was and would still be down and -- more importantly -- officially unsupported by my carrier.
Falsehoods (aka: crap) I was told.
Not only are the foregoing falsehoods in and of themselves, but each one statement invalidates (or is incongruent with) the others... e.g. Yes, if I had a T1, then a NOT-A-BELL-CAL with a TOO-NEW-8330 on TRIAL-WARE would otherwise be just fine.
Mother of ... who trains these people???
I've been in this business 20 years and this isn't the first loop and won't be the last. It's just this one was sooo utterly simple and straight-forward and about as horrid an experience as could be, compounded by outright supervisor-approved abandonment. And I pay money for this.
Thanks again everyone who posted help!!!
Thanks for indulging my rant.
Hope the points/keywords will help someone else in the future get through this maze quicker.
useful tool: javaloader.exe. It definitively wipes a device, including blowing away policy file lock downs. (Be warned -- it hard-wipes EVERYTHING. No recovery path if you didn't mean it.)
I wasn't insinuating that this needed to be resolved by RIM. RIM will never change the provisioning of any Blackberry directly. However whenever a carrier anywhere in the world needs to change which service the Blackberry needs to be used on the provisioning change command is executed on the RIM Infrastructure (or the RIM relay as it used to be known). The error this OP is getting "service blocked" is generated by the RIM Infrastructure, This is why when the OP contacted RIM they were able to see the provisioning of the device because they have access to their own infrastructure (you noticing a theme here yet)
It works when connected directly through the bes or desktop manager because the bes uses least cost routing and cuts out the network. it's not bell systems that were blocking the traffic it was RIM systems. Bell do need to change it but it doesn't always mean that it's a tarriff problem or data plan problem. Sounds like in this case they simply changed the provisioning like I said they would need to further up the thread.
I have pre-provisioned and re-provisioned thousands of Blackberrys as part of my Job for Vodafone I have direct access to the provisioning systems at RIM. And I have quite an in-depth understand of how this process works. You might want to make sure your own statement is accurate before shooting.someone.down
Wirelessly posted (Breaking Ball)
Grabbing my bag of popcorn. ;-)
And as for BELL, it was their technicians/support staff that ended up blocking this user's access to BES. they changed the option to "ConsumerPRO" instead of Enterprise and Consumer/Prosumer services. Yes, it is RIMs systems that they are modifying, but it is the carrier that is in control of setting up enterprise, not RIM's support staff, hence Bell being completely responsible.
Also, it isn't a least cost routing. It is a "still handled by desktop" flag that is often referred to as serial bypass when the BES forwards messages internally to a cradled device on port 4101.
Sorry if most post offended you. When I read your post it seemed that you were putting the issue on RIM. While the back end of provisioning maybe RIM, it is the carrier that decides what services to give the device. It's just like you said:
It was interesting to hear from the carrier side about Provisioning. Also, when most of us hear talk about provisioning we mean the data services enabled/disabled by the carrier, and not the billing side of things.
I do not know how every aspect of provisioning works, I had access to a view only system and I had to contact the carrier for any changes. I have dealt with Service Blocked often enough to know that it's carrier data plan issue.
It really sucks that 8f27e956 had to endure so much crap for a 2 minute fix. I can't believe that a carrier would deny a customer support because they are too dumb to see the real issue.
It's strange to me because in my experience with RIM the Canadian and European carriers have the fewest calls to RIM for device support. I once had to call Verizon because a BB could not send a PIN message. The rep was very confused about what a PIN message is and then told me it wasn't supported. WTF???? I said they did so she transferred me to their billing department. After I explained it's not a billing issue I got transferred back their data support and the rep I got fixed it in 30 seconds.
Sometimes it just depends on who you get. Some people know what they are doing and some just don't and don't care. It's terrible.
Sorry, kind of rambled on there. Anyways, again, didn't mean to rain on your parade. I just want to help people resolve their issues ASAP and provide as much correct info as possible. I even offered to get a friend to check his PIN on RIM's end to prove that it is carrier issue so he wouldn't have to pay for a RIM call or fight to get transferred.
But it worked out in the end for him.
Expanding beyond the narrow "provisioning" term, maybe to help illustrate the who and the whom.
The BES, in my case, is talking to srp.ca.blackberry.net, which is rim, not carrier, infrastructure. It was this infrastructure that was NOT seeing any traffic from my carrier.
In the ISO standard seven-layer Open Systems Interconnect (OSI) reference model, OSI Model: Definition and additional resources from ZDNet, the carrier and the device's chipset performs layers 1 through 3, RIM infrastructure performs layers 3 and 4, and the end points (BES and the DEVICE applets) perform layers 6 and 7.
I once had (but cannot re-find to include here) a link that showed this as well as positioning GSM and CDMA in the model.
Thanks for clarifying, I can understand how my post may have seemed I was RIM bashing,
The reason I was highlighting the issue of RIM Provisioning systems is because some networks have weird and wonderful different ways of matching up customers data provisioning at network level with the provisioning systems at RIM.
Some treat them as two seperate actions so they add or change the data service/APN they then go off and check the provisioning is as it should be. Problem being this is manual and is open to human error.
Some have a system which connects to RIM provisioning and does the change automatically, I can only imagine they develop this process in house. The problem is, if the provisioning request doesn't go through properly or errors then the monkey in support at the network will see that the data is provisioned fine but has no idea that the PIN has got the wrong service code attached to it on the RIM Infrastructure.
In that situation you need to make sure you speak to someone with a bit of experience and has access to the provisioning system. I was trying to highlight the issue of changing the provisioning on the RIM system as a way of getting straight to the solution without the adding/removing, hard resets, wiping, activating that support will make you go through before fobbing you off.
incidently Vodafone don't have any automatic link, devices are supplied as BIS or BES or Dual provisioned units, they then change them as and when which is done primarily by theirBlackberry support people who have access to the provisioning system and are usually well versed on how to use it.
Another interesting point is that from what I have seen it really doesn't matter which data service you're paying for. the APN is just an APN that allows the data through to the correct gateway (blackberry.net). There is no way of the carriers equipment of knowing which service the traffic belongs to ( I can only assume this is due to encryption) if the data service was capable of allowing certain types of traffic depending on what they are paying for then there would be no point in provisioning at NOC level. The option of changing the service a Blackberry can use is only there because the networks don't have a way of doing it at carrier level. (please note this is from what I have seen in the UK, don't know if the guys in canada have a different set up)
This is why I pay peanuts for a BIS APN and use both BIS and BES without any problems. (Actually I don't pay anything but you get the idea)
Anyway sorry if I got a bit animated, But it just winds me up when people assume that RIM just make handsets and the networks do everything else. Most of the time the carriers just provide a means of connecting to the Blackberry system,
PS - I also offered my services to check the PIN as I also have a read only account that seems to be able to view most PINS
Communication (or traffic) from one layer to its next adjacent (vertical) layer is called a "protocol." e.g. link-layer to network-layer. Communication (or traffic) by one layer on one stack to its corresponding layer on another (device) stack (horizontal) is called an "interface." e.g. device to tower air interface (CDMA).
A word-picture gets complicated and is beyond my authoring skills. And, as I mentioned, I cannot re-locate the carrier-blackberry protocol-interface model graphic that positions all this in one graphic (albeit a busy graphic).
|All times are GMT -5. The time now is 02:01 PM.|
Powered by vBulletin® Version 3.6.12
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.