It’s only been a year since Windows Server 2012 was released, but we already have a new version of the operating system incoming in the form of Windows Server 2012 R2.
While R2 releases usually don’t change things dramatically, there’s still some new features and general polish to make it worthwhile. If you’ve got a few hundred hours to spare I can recommend streaming through both Build and TechEd sessions over on Channel9 to learn more 🙂
As per the usual marketing speak there’s no end to what the new release can do to empower businesses and enabling visions, etc.
That’s all nice and dandy, but how about seeing if there’s something we can use?
Clearly there’s no need for me to cover everything, but I thought I’d look into the Workplace Join feature today as that must be said to be a feature intended for the mobile crowd. It currently supports iOS in addition to Windows 8.1. Windows 7 has been confirmed as a candidate for support after RTM. Android has an unknown status.
I spun up a couple of servers and configured them according to this guide:
Workplace Join – Setting up the lab environment:
If you’ve ever played around with setting up multiple web sites on your servers using SSL for enabling HTTPS there’s probably a thing that’s been annoying you once or twice – the fact that you can only use one SSL certificate per IP address. (I am assuming IIS is your web server of choice for the sake of this discussion.)
You can easily have http://www.contoso.com, http://mail.contoso.com, etc. all tied to the same IP, but once you want to have https://www.contoso.com and https://mail.contoso.com things change.
Now of course if you happen to have an ISP which will happily supply you with IP addresses this isn’t a problem (at least in the short term); I have TMG servers with 20 external IPs for this very purpose. But IPv4 addresses are getting harder to come by, and if you try to sign up for 100 public IPs from your DSL-connection at home your ISP will most likely just laugh at you and say “no go”.
But why does it work for HTTP and not HTTPS? Well, the thing is that the host name is included in the HTTP header, and as such the client’s intended host name can be parsed by the web server. With HTTPS an SSL handshake is performed before exchanging headers, and the web server thus cannot base itself on the header information.
Server Name Indication (SNI) is an attempted solution to fix this issue. The domain name is extended to be part of the SSL handshake process, and then you can do for HTTPS what you can do for HTTP.