Sep 042015

AMQP 1.0 is “broker model independent” meaning there are no protocol requirements related to the internals of the broker. It complies with the International Standard ISO/IEC 19464. It is the only standard version of AMQP. As of last month, QPid Proton, SwftMQ, RabbitMQ, ActiveMQ, and MQLite are all supporting this relatively new standard.

Microsoft is currently working to retire their .NET-centric proprietary protocol, SBMP, over the next few months/ This will leave only the AMQP protocol when working with Azure Service Bus. The AMQP protocol backs the .NET SDK, which still has support for WCF with NetMessagingBinding. Developers may also choose to use AMQPNet Lite, which is an open source library for .NET and UWP (store apps). It is a lighter library exposing more of the primitives of AMQP. Another alternative is SBLite, which is a wrapper around AMQPNet Lite to abstract the low level details of AMQP.

Download Qpid Proton 0.10

Download AMQPNet Lite

Download SBLite


Sep 152014

I had a great time at Jax Code Impact over the weekend. Many thanks to Bayer and Brandy for putting together a free, enjoyable, and educational Saturday conference. As a first year conference, it was impressive to see more than 300 people registered for six tracks of Microsoft-focused presentations. Kevin Wolf was a big hit with his quadcopters, 3-D printer, and oculus rift. I personally enjoyed two separate talks on Redis by Henry Lee and Steve Danielson.

I talked about the Windows Azure Service Bus offerings, and hit on topics such as Relays, Queues, Topics, WCF bindings, Pub/Sub, AMQP, and of course some Cloud Design Patterns. 

Here are the slides and code demos from my talk:

Code Impact Service Bus Presentation – Slides

Code Impact Service Bus Presentation – Demo Code

Feb 062014

If you’ve been operating an application as an Azure Cloud Service for a year or two, then you are probably due to renew or upgrade your SSL certificate. People move on, and contractor rates go up. You may not be the person that installed the original SSL cert or may not have documentation on how to install a new cert. The process is simple and takes only an hour once you’ve acquired your new certificate.

  1. Downloaded the new certificate from your certificate provider
    Each provider is different in how they will deliver the certificates. GoDaddy will have you select your server type (e.g. IIS6, IIS7, Tomcat, Apache) before downloading the certificate. When you requested the certificate from your provider, you had to use one of these servers to generate the CSR (certificate signing request). You will be receiving a CRT (web server certificate) from your provider. It’s important to choose the right server type so the CRT can be imported. If you’re deploying to Azure, then you’ll probably choose IIS7 like I did. Download the cert files (or zip file) and save it somewhere safe from prying eyes.

    NOTE: You will likely also receive some intermediate certificates. These have much longer lifespans than a 1-2 year SSL certificate. You’ll follow your provider’s instructions to install these later, if necessary.

  2. Complete the certificate request on IIS
    If you received intermediate certificates from your provider, now is the time to do so. This will ensure that you have a full certification path. Follow your provider’s instructions for this. These intermediate certificates have lifespans of up to 10-20 years, so if the thumbprint is the same no action will be necessary. You can check this by double-clicking the certificate and checking the thumbprint on the details tab. Compare that value to what was previously uploaded to Azure under Cloud Services – <Your Cloud Service> – Certificates tab. Any previously uploaded intermediate certificates will appear here as well as your existing SSL certificate.

    In IIS7 on your server, VM, developer workstation, click on Server Certificates. In the Actions pane on the right, click Complete Certificate Request. Browse to find the name of the CRT file you downloaded in the previous step. Type a friendly name like “*” and click OK. If the import is successful, you’ll see your certificate appear in the list on the Server Certificates screen in IIS.

  3. Export the certificate as a PFX file
    Open MMC and add the snap-in to work with the Local Machine certificate stores appearing as Certificates (Local Computer). Find your certificate in the Personal \ Certificates store and look for the friendly name you entered in the previous step. Right-click on the certificate, choose All Tasks and then Export to open the Certificate Export Wizard. Follow the wizard, choosing Yes, export the private key and Include all certificates in the certification path if possible options. Type a good password and choose a file path to export the PFX file. For future-you’s sake, name the file with a .pfx extension. When the wizard completes, your PFX file will be ready for use.

    Before you leave the certificate manager (MMC), double-click the certificate to open it and copy the thumbprint from the Details tab. You’ll need the thumbprint in later steps.

  4. Upload the PFX and intermediate certificates to Azure
    Now that you have both certificates, navigate to the uploaded to the Azure Management Portal, and click on Cloud Services. Find the desired cloud service in the list, and click on it to select it. Click on the Certificates tab, and then click the Upload button in the bottom menu. Browse to find your PFX file, and type the password. Click the OK button.
  5. Change the service configuration to use the new thumbprint
    Open your application’s solution, and open the ServiceConfiguration.Cloud.cscfg file in the Azure hosting project. Find the existing SSL certificate under <Certificates>. Paste in your new thumbprint, making to sure it’s all uppercase with no spaces. If your thumbprintAlgorithm has changed, change that value in the config file as well.
  6. Deploy your app to Staging
    Now that your certificate is on Azure and your application has been updated, it’s time to deploy to staging, Once your deployed is complete and your staging environment status returns to “Running”, try out the Staging environment using the HTTPS version of the Site URL seen in the Azure Management Portal. Using Chrome, find the certificate information by clicking on the lock symbol in the address bar and then click the Connection tab and then Certificate Information.
    It’s expected that it is complaining at this point because we aren’t using the intended domain name, staging uses <random> Check that the end date, thumbprint, name, and other properties are what you expect to see.
  7. Swap VIPs
    Once you’re satisfied that the Staging environment is a good build and that the certificate is correctly assigned, swap the staging and production environments. When completed (< 30 seconds), check out your application using the HTTPS endpoint and domain name. You should see the lock in the address bar, and make sure to check the properties (e.g. expiration date) again.

That’s it. Party on!