BlackBerry Forums Support Community

BlackBerry Forums Support Community (http://www.blackberryforums.com/)
-   BES Admin Corner (http://www.blackberryforums.com/bes-admin-corner/)
-   -   "SERVICE BLOCKED" (RED X) via DESKTOP (BES) SERVICE BOOK (http://www.blackberryforums.com/bes-admin-corner/133601-service-blocked-red-x-via-desktop-bes-service-book.html)

8f27e956 06-05-2008 04:17 PM

"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.

Clue, right.

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.

Thanks,

penguin3107 06-05-2008 04:24 PM

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.

8f27e956 06-05-2008 04:35 PM

Quote:

Originally Posted by penguin3107 (Post 957858)
I would say to keep calling the carrier until you get someone who knows what they're doing.

Problem is that they've "noted" the my file, which signals the next rep to catch the call to just flush "this guy."

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.

Stern 06-06-2008 09:45 AM

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.

gibson_hg 06-06-2008 03:03 PM

Quote:

The provisioning of the device is done on the RIM infrastructure
Most.incorrect.statement.ever

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.

penguin3107 06-06-2008 03:05 PM

Quote:

Originally Posted by gibson_hg (Post 959249)
Most.incorrect.statement.ever

Glad you said it, gibson.
I've been pondering for hours on how to word my response and everything I came up with sounded way too abrasive. ;-)

8f27e956 06-07-2008 01:32 PM

Thank you, everyone.

UPDATE.

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.

<deep breaths>

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.

<ka-boom>

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.

Anyway.

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.

Anyway.

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.
  • Because when you enterprise activate (in this case via USB), under options > security > firewall, the firewall is ENABLED (with the red dot meaning user can't override). Though enabled, the sub-settings are un-filtered. So your enabled but blocking nothing. BELL insisted this is the cause of BES not working -- the BB own firewall. (FALSE)
  • The 8330 is too new a device and not compatible with BES. (FALSE)
  • BES EXPRESS is beta software and unsupported. (FALSE)
  • BES EXPRESS is trial-ware (FALSE) and not a real BES (does RIM know this); and this trial status is why it had been working for so long and then just suddenly stopped working -- it expired. (FALSE)
  • The RED X is *ALWAYS* (Bell's emphasis) a user-created issue. (certainly FALSE as ASSERTED)
  • My BES is broadband (5MB/1MB) connected to the internet and BES only works with T1 or faster connectivity. (FALSE)
  • If we, Bell, can BB-PIN the device, you're provisioned correctly. (FALSE)
  • If BIS email is working, you're provisioned for BES (FALSE).
  • Must have a BELL <purchased> CALs to work with BELL 8330. (FALSE)

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.

/S

8f27e956 06-07-2008 01:35 PM

Hope the points/keywords will help someone else in the future get through this maze quicker.
  • Call RIM sooner, not later. RIM will right a carrier error at no charge.
  • Say/Cite "ConsumerPro" vs. "Enterprise," not "BIS" and "BES."
  • Never, ever say, "EXPRESS" and BES together (i.e. "BES EXPRESS"); and,
  • if you're lucky enough to know someone else with a spare CAL, do the test (temporary) activation to their independent-of-your admin/technical domain sooner, not later -- as this test is DEFINITIVE!

/S

8f27e956 06-07-2008 01:46 PM

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.)

Code:

D:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\bin>
javaloader -u resettofactory

  RIM Wireless Handheld Java Loader
  Copyright 2001-2007 Research In Motion Limited
  Connected
  Disconnected


D:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\bin>

Get a buddy to send you the .EXE; otherwise available for free from RIM site and the developer downloads section. Free but large.

/S

8f27e956 06-07-2008 01:51 PM

Quote:

Originally Posted by Stern (Post 958757)
The provisioning of the device is done on the RIM infrastructure...

Per my saga post, RIM can certainly "see" the provisioning status (and in this case error), but RIM engineer had to call the very same 1-877-DATA123 Bell Mobility number that I, as the customer, call in order to effect the provisioning correction.

/S

Stern 06-07-2008 02:24 PM

Quote:

Originally Posted by gibson_hg (Post 959249)
Most.incorrect.statement.ever

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.

Do you actually understand what provisioning actually means when referring the Blackberry services? The billing provisioning is all down to the network so they control the Blackberry APN and how this translates to charges on your bill. But this isn't the root cause of the problem and isn't what I'm talking about. The actual technology that controls whether BIS or BES traffic is allowed on a BIS device via the RIM Infrastructure is all down to RIM systems. Each and every PIN has services assigned to it. It's up to carriers to make sure the device is provisioned correctly on the RIM infrastructure

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

penguin3107 06-07-2008 04:51 PM

Wirelessly posted (Breaking Ball)

Grabbing my bag of popcorn. ;-)

Keyscan 06-10-2008 01:36 AM

Quote:

Originally Posted by Stern (Post 960146)
Do you actually understand what provisioning actually means when referring the Blackberry services? The billing provisioning is all down to the network so they control the Blackberry APN and how this translates to charges on your bill. But this isn't the root cause of the problem and isn't what I'm talking about. The actual technology that controls whether BIS or BES traffic is allowed on a BIS device via the RIM Infrastructure is all down to RIM systems. Each and every PIN has services assigned to it. It's up to carriers to make sure the device is provisioned correctly on the RIM infrastructure

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

I believe gibson used to do server support at RIM as per his previous posts. I understand where you are coming from, but for the people who have had access to RIM's provisioning, I am not sure where you are going with this post. He was correct in his assertion.

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.

Stern 06-10-2008 03:32 AM

Quote:

Originally Posted by Keyscan (Post 963628)
I am not sure where you are going with this post. He was correct in his assertion.

Seriously? You have just agreed with me that the provisioning system is a RIM system, Infact most of your post is exactly what I said in different words so how is gibson correct in his assertion that my post is the "Most.incorrect.statement.ever"

Quote:

Originally Posted by Keyscan
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.

If you read my post this is exactly what I was getting at,

Quote:

Originally Posted by ME!
It's up to carriers to make sure the device is provisioned correctly on the RIM infrastructure

it's Bell's problem to sort out, always has been and always will be.

Quote:

Originally Posted by Keyscan
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.

How is this not a form of least cost routing?

gibson_hg 06-10-2008 08:52 AM

@Stern

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:

Quote:

it's Bell's problem to sort out, always has been and always will be
That's what I, and everyone else here, was getting at. I think that we all took it that you may have been putting this on RIM. That's why I said that your statement was incorrect as it is not an issue for RIM to correct.

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.

8f27e956 06-10-2008 09:13 AM

Quote:

Originally Posted by gibson_hg (Post 964014)
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.

(y) :smile:

8f27e956 06-10-2008 09:44 AM

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.

/S

Stern 06-10-2008 10:14 AM

Gibson

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

Stern 06-10-2008 10:19 AM

Quote:

Originally Posted by 8f27e956 (Post 964126)
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.

/S

Thanks for the link I didn't realise it was standardised to that level. One thing I will say though is the RIM infrastructure has it's own layers much like the components on the bes. If the provisioning component blocks the traffic from the handset then the BES won't see any traffic at all from the SRP server as it sits after the provisioning system in the chain and as a result the traffic doesn't get passed to the big dispatcher in the sky

8f27e956 06-10-2008 10:37 AM

Quote:

Originally Posted by Stern (Post 964209)
... the RIM infrastructure has it's own layers much like the components on the bes.

Yes.

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).

/S


All times are GMT -5. The time now is 03:21 AM.

Powered by vBulletin® Version 3.6.12
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.