I had a recent requirement from one of our clients that took a little bit of tinkering to figure out… we will call our client Contoso LLC. and our project that we host for them we will call the “Cool Widget Project.”

We built a really neat widget of an application for Contoso to use and we are hosting it under a sub-domain of a domain we control. We needed to keep hosting it under this domain. However, our client, Contoso, wanted to hand out a link for their users to the new widget we built using an existing sub-domain from a domain they control. This was of course under their main domain, constosollc.com, and they already had existing users that came to the old version of the widget (built by another vendor) at widget.contosollc.com.

Our company was hosting the new widget app at widgetapp.appworks.net.

To further complicate things… our company appreciates security, likes fast DNS updates, and the app really benefits from using a CDN… so we are using Cloudflare to manage DNS for the appworks.net domain. Better yet, we also like the cloud, and this new widgetapp is actually an Azure Web App.

So there’s the situation…

We essentially need this to happen:

User visits widget.contosollc.com --> widgetapp.appworks.net.

Oh but this is Azure… so actually widgetapp.appworks.net is already a CNAME record and it actually points to widgetapp.azurewebsites.net. So it is this:

User visits widget.contosollc.com --> widgetapp.appworks.net --> widgetapp.azurewebsites.net.

To elaborate the above just a little bit more:

widget.contosollc.com (DNS from random provider) --> widgetapp.appworks.net (Cloudflare DNS, CNAME) --> widgetapp.azurewebsites.net (the DNS name provided by Azure for the application)

Simple right? Just get our client to create a CNAME record that points to widgetapp.appworks.net and move on with life… wrong…

I work with a lot of IIS servers. Keeping track of what sites are present on which servers can sometimes be a daunting task. Heretofore I have been dealing with the rather obnoxious and time consuming process of checking sites and bindings by looking at each one in the IIS console. The other day I thought to myself, surely there must be a more effecient way to do this from the CLI via PowerShell… There is… I quickly found the following code on Stack Overflow after a Google search: (more…)

I think I have put together a pretty good solution for load balancing websites across multiple instances of IIS 8.5. I am sure my ideas aren’t novel but I am documenting them here for future reference. This isn’t meant to be a full walkthrough but rather it is me keeping notes for personal use and may be a useful springboard for admins with similar needs.

A Quick Introduction to DFSR
DFSR (Distributed File System Replication) is a Role/Feature built into Windows Server – it can be used to keep folders in-sync across multiple servers. Caveats such as replication latency mean that it might not be ideal for all use cases. DFSR is based more or less on the same technology that replicates active directory information between domain controllers. DFSR does “block level replication” which means changes made to files on one end don’t require the entire file to be re-replicated but rather just the changes. This is extremely useful if you are dealing with large “non-static” files. DFSR, I think, was introduce circa Server 2003 so it has been around for quite a while, it just wasn’t something that had really been on my radar until very recently.

In a post Heartbleed world, implementation of SSL is being scrutinized like never before (at least in my short years of experience in information security). Even though Microsoft/IIS implementations were hardly, if at all, affected by Heartbleed, they do often suffer from other common SSL vulnerabilities. This is particularly true of Microsoft Server 2003 R2 / IIS 6.5 and older setups.

Back in the olden days (you know, like 5 – 10 years ago…) before massive Chinese super-computers, NSA spying programs, and 30-core processors, a 48-Bit SSL cipher may have been considered sufficient as the length of time it would take to brute-force decrypt collected data was significant on the hardware of the day. No so much anymore.

Fast forward to today, many environments still have aging servers sitting around from a bygone era whose weak implementation of SSL pose a security risk. It is time to turn off archaic SSL ciphers on these old boxes and strengthen your connection security.

So… before you read any further, you need to check a few things to find out if this article is relevant to you.

First, do you host any websites in IIS that use SSL? (i.e. do they have “HTTPS” preceding the URL?) (more…)