So you’re an international guest in Germany for a week or a month and you want to use your smart phone, but you don’t want to pay for the usually insane international data roaming charges on your regular mobile plan? If you have a SIM unlocked phone, I’ve got a 10 Euro solution for the week for you – the mobile Internet plan actually only runs E4.95/week, so you’re even getting some extra voice/text for that – and a German phone number.


1) Ensure that the phone is actually SIM unlocked. If you don’t know whether your phone is SIM locked, it likely is. Unlocking procedures vary, sometimes you can’t unlock, at all. I’m on T-Mobile USA and they are very good about it. For T-Mobile USA, the process description is here. You can dial the 1-800 number through Skype (or Communicator for the Microsoft folks) for free. If you’re on T-Mobile, they’ll send you an unlock code by email within 24h.

2) Find a Vodafone store. Here’s a list of all stores in Berlin, for instance. Click the first letter of the city you're in in this list to find a store.

3) Get yourself a Vodafone CallYa SIM card. The SIM card will cost 10E, if they’re asking what plan you need, you likely want CallYa 5/15. Here’s the tricky bit: For the registration procedure you’ll need ID (passport) and they’ll ask for a German mailing address. I’m not going suggest anything here, but in case you’re convinced that you don’t have a German mailing address for this week, you might want to think for a moment whether that’s really true.

4) Put the SIM card in your phone. You will need to enter the PIN that comes with the card. There’s a scratch-off field in the leaflet that holds the card; the four-digit number is what you need. If the phone is SIM locked, you will also need the SIM unlock code right then.

5) Unless the folks in the shop help you out right there, call 22044 from your phone “Tarifmanager”. You’ll (hopefully) be asked whether you want German or English menus on the first call (I was). You need to navigate to Options (Press 2), Data (3), then you can select the “CallYa MobileInternet Flat for a Week” (2). Once you select this, you’ll be asked to confirm the selection (1). At this point you’ve got a data subscription for a week. 200MB limit after which they’ll throttle down to GPRS speed. Congratulations.

6) Configure your phone for data. The Access Point Name is “”, the Proxy Server is, port 80 (required). For Windows Mobile, you need to create a new connection in your connection settings, set it up as GPRS connection, and configure the access point. Once the connection is created, you can configure the Proxy Server. Here’s a walkthrough; even though it’s in German you should be able to follow that if you know your way around Windows Mobile a bit.

7) Done.


Updated this post and made it non-TechEd specific. Click here for the new location of this post.


In my PDC talk I’m showing a few little samples that are not in the SDK for the CTP release.  I’ve bundled them up and they’re attached to this post.

The solution contains three samples:

  1. SBMT is the ‘Service Bus Management Tool’, a small command line utility to create/view/delete ConnectionPoints and MessageBuffers using the new management model for Service Bus. I’ll explain the options of the tool below and will drill into the inner workings of the tool and the ideas behind the new management interface in the next post of this series.
  2. EchoService/EchoClient are versions of the meanwhile probably familiar ‘Echo’ sample for Service Bus that illustrates the new load balancing capability with session affinity.
  3. DurableMessageBufferSample is a variation of the SDK sample for the new durable message buffer that sends a sequence of 200 messages and fetches them back.

The SBMT project/tool is the probably most interesting one, because we’re looking to change the way how connection points are managed on Service Bus and that requires a tiny bit of tooling.

In the current version of Service Bus, creating a listener is an implicit operation. The service (listener) picks a name (or address) in the namespace, binds that name to an endpoint, and opens the ServiceHost holding the endpoint. That’s extremely convenient, but what we’ve found is that this kind of implicit management makes it hard for us to create consistent behavior for eventing (NetEventRelayBinding) and for one of our most-requested ‘missing’ features, which is load balancing and/or failover. For eventing, the majority of customers that we’ve heard feedback from is expecting the the fabric will absorb sent events with no error message even if no event subscribers are present. For the new load balancing capability we’d like to appropriately return an error message in the case that no listener is connected, but differentiate that from the case where the connection point isn’t known, at all.

The implicit model causes no connection point to exist when there are no listeners, so we can’t solve either of these puzzles without making a change. The good thing is that we’ve got a model that works quite well and we’re building on that: Our message buffers already need to be created using an explicit AtomPub operation on the namespace, so what we’re doing is to make connection points explicit by requiring that you create them beforehand just as you create message buffers. We believe that’s the right model long-term, especially also because the <MessageBuffer/> and <ConnectionPoint/> descriptions are going to have more siblings over time and we’d like to have a consistent model. If you take a deeper look at the slides for the PDC talk, you can already infer a few of the siblings.

In the talk I also give a few reasons for why we’re splitting off the management and runtime namespaces as we’re doing this. It turns out that our longer term plans for how to enable rich monitoring and control for connection points and message buffers and other messaging artifacts on Service Bus will require quite a bit space in terms of protocol surface and that’s difficult to create in a single namespace. If I have a connection point at sb://, any right-side extensions of that URI belong to the listener. If we were  now looking to give you a protocol surface to enumerate the current sessions that are active and suspend/terminate the individually or summarily, for instance, it’s difficult to get that slotted into the same place without resorting to stunts like special escape characters in URIs. Instead, we’d like to provide a straightforward mechanism where you can get at the session connection with

If that begs the question how those two addresses are related – I explain it in the talk. The resource has a projection into the runtime namespace. Resources are organized by their type (there will be other taxonomy pivots in the future) and you can project them into the runtime address space as you see it fit.

The SBMT tool allows interacting with the management namespace to create connection points and message buffers. The call structure is:

sbmt.exe –n <namespace> –a <account-name>–s <account-secret> <type> <command> <resource-name> <uri> [<args> ..]</

  • -n <namespace>  - the Service Bus namespace created via
  • -a <account-name>– the service account name that’s set up in Access Control (defaults to ‘owner’)
  • -s <account-secret>– the service account key set up in Access Control (the key you find on the portal)
  • <type>– ‘cp’ for connection points, ‘mb’ for message buffers
  • <command>– ‘create’, ‘get’, or ‘delete’ (see below)
  • <resource-name>– a unique, friendly name for the resource (eg. ‘crm-leads’)
  • <uri>– the URI projection into the runtime namespace (e.g. ‘sb://<NAMESPACE>’)
  • <args>– further arguments (see below)


  1. Create a connection point. ‘cp create’ requires a trailing argument after the URI that indicates the number of concurrent listeners (max. 20):
    sbmt.exe –n clemens –a owner –s […] cp create crm-leads sb://  10
  2. Delete a connection point:
    sbmt.exe –n clemens –a owner –s […] cp delete crm-leads
  3. Show a connection point:
    sbmt.exe –n clemens –a owner –s […] cp get crm-leads
  4. Enumerate all connection points:
    sbmt.exe –n clemens –a owner –s […] cp get
  5. Create a message buffer:
    sbmt.exe –n clemens –a owner –s […] mb create jobs  10
  6. Delete a message buffer:
    sbmt.exe –n clemens –a owner –s […] mb delete jobs
  7. Show a message buffer:
    sbmt.exe –n clemens –a owner –s […] mb get jobs
  8. Enumerate all message buffers:
    sbmt.exe –n clemens –a owner –s […] mb get

The Echo sample requires that you create a connection point in your namespace like this:

  • sbmt.exe –n –a owner –s […] cp create cp1 sb://<namespace>  10

The Message Buffer sample requires this setup, whereby the friendly name is asked for by the sample itself (‘mb1’, so you can choose that freely)

  • sbmt.exe –n –a owner –s […] mb create mb1 https://<namespace> 

The good news here is that you do this exactly once for your namespace. There is no renewal. A connection point that’s created sticks around like an object in the file system.

In the next post I’ll drill into what happens at the protocol level.

Since this is a CTP, we’re keenly interested in your feedback on all the things we’re doing here – making connection points explicit, splitting the namespace, what’s the tooling experience you’d like. This tool here is obviously just something I wrote to get going on demos; you can probably see that having a  durable namespace is begging for tooling and it’s one of the reasons we do it. (24.65 KB)