I’ve been working from home a bit more lately, and with that, I’ve been fine-tuning how I work. For instance, I’ve been using the “Use all my monitors” setting in order to stretch my remote desktop session across two screens. In Windows 8 this is a big improvement, as your monitors can be different resolutions and it supports that just as if you were at your desk.
Following my last post on Lync, Strings and Cans I need to report further detail on my test findings, wherein I identified that some Lync Online traffic would route peer-to-peer. This was an exciting finding for us, and remains so, although we’ve also uncovered some initially-unexpected nuances. To this end, my first post describes a model for understanding Lync traffic and details the default experience. In this post, I’ll talk about how in some cases, a two-person session will switch from peer-to-peer routing to a conference mediated by the Lync Online Edge servers. In these cases, Lync traffic routes in the same way as a multiple-participant conference, even though there are only two users involved. Put another way, in these cases all traffic will route via Office 365’s Lync Online Edge servers, even if all the internal ports are open for peer-to-peer communications.
NAT Traversal and Candidate Testing
To understand what’s going on, you first need to understand what to look for. Part of the reason for the delay producing this second post is that I’ve been trying to explain this by picking apart network monitor data. At first these captures were nothing more than an attempt to validate assumed behaviour, but it’s quite a bit more complicated than I expected. Thankfully, there are some excellent resources that describe precisely what I’ve seen with greater precision and detail than I could hope to reverse engineer. Having spun my wheels for a bit, I would recommend some healthy RTFM – getting to grips with Lync topology and possibly even consulting protocol documents, if you’ll spend any amount of time trying to decipher Lync network traffic. I cite some of these resources at the bottom of this post, but for the immediate considerations I’m focusing on some key descriptions from Bernd Ott’s How Communicator Uses SDP and ICE To Establish a Media Channel article.
Like a lot of people in the Microsoft partner community, I’ve been catching up with Lync this year and digging in to the finer details with a few of my colleagues. One thing we wanted to understand better was the routing between two users over a LAN, a private WAN, or some other connection where all the necessary network ports would be open. Would these clients communicate peer-to-peer? If so, does it always behave the same way, how is it accomplished and what might go wrong?
First, consider an organisation with offices across multiple floors or buildings. Lync may be a very effective means of connecting these employees despite their relatively close proximity. If this traffic can route locally it can be a big plus – especially if there’s lots of media traffic. Second, consider an organisation with multiple branches. They invested in private WAN links to connect these branches and don’t necessarily want to route Lync traffic over their internet connections if they can avoid it. For some organisations these will be non-issues, since Lync traffic is optimised for the WAN, but for other organisations this may be important – particularly if they’re in a part of the world where internet connections are slow or expensive (or both). So we went about testing this with the Lync 2010 client and Office 365 users (the behaviour is the same with Microsoft Online IDs or federated users).
A while back, I posted an article on building a SharePoint development environment in Hyper-V, which included a part on automating deployment of the host machine. Although we’ve now moved to VMware Workstation, we still use this approach for automating deployment of our standard Windows 7 builds, and this commentary is generally relevant to any Windows Deployment Services (WDS) deployment.
When I learned WDS and the Windows Automated Installation Kit (which were both quite new in Windows Server 2008 R2 at the time), I contented myself with getting ~90% of the way to a fully-automated build, as the additional effort to get from 90 to 100% (mostly re: drivers) wouldn’t have paid enough immediate dividends and we needed to start capitalising on some of the other wins of our new environment. As is often the case, we never got back to that remaining 10%, but it’s become more of an issue in recent months, as we’ve added a few Dell Latitude E6410 and Lenovo W520 laptops – both of which had network drivers that the Windows 7/Windows Server 2008 R2 boot images didn’t recognise. Unfortunately the TechNet guidance on adding drivers to boot images is unclear (to me anyway), so I’m contributing this quick post to attempt to clarify the problem that we had and the simple step-by-step solution.
In the last couple of weeks I’ve received notification of two important updates regarding Amazon Web Services. I thought I’d share them here, as they are both relevant to use of SharePoint 2010 on EC2 and I’ve seen no mention of them elsewhere. If you’re interested in this broader topic, I’ve covered it in detail here:
- SharePoint 2010 Infrastructure for Amazon EC2 Part I: Storage and Provisioning
- SharePoint 2010 Infrastructure for Amazon EC2 Part II: Cloning and Networking
- SharePoint 2010 Infrastructure for Amazon EC2 Part III: Administration, Delegation and Licensing
- SharePoint 2010 Infrastructure for Amazon EC2 Part IV: Cost Analysis
My commentary here assumes some familiarity with these earlier posts. This is new functionality that enables new design options. These options should make SharePoint 2010 on EC2 more appealing for a few specific uses.
In the first part of this series on SharePoint 2010 infrastructure considerations for Amazon EC2, I introduced the AWS platform and took a closer look at storage, snapshots and provisioning. In the second post I moved on to networking and cloning. In this third post I will discuss administration, delegation and licensing.
In my previous post I introduced some of the peculiarities of designing SharePoint 2010 environments for Amazon’s EC2, specifically focused on the AWS platform, storage, snapshots and provisioning. In this post I continue this exploration, moving on to cloning and networking considerations.
A couple of weeks ago I posted information about a Fix For Bit Rate Throttling W3WP Crashes in SharePoint 2010. A few hours ago, Jack Freelander from IIS.NET announced that IIS Media Services 4.0 has been released, including this fix. This is just a quick post to update that the fix has passed Beta, in case anyone was waiting on the final release before diving in.
I still have yet to find the time to test this myself, but I’d be very keen to hear about your experiences – good or bad. Failing that, I hope to get back to this in the next couple of weeks.
Over the Summer, we dove deep in to SharePoint 2010 for WCM when we re-launched our corporate website. As I mentioned the other day, I spent a decent amount of time looking at caching and some of the new supporting technologies, like Bit Rate Throttling, an IIS.NET extension to IIS 7.x – part of the IIS Media Services 3.0. package that also includes Smooth Streaming. Bit Rate Throttling is like when you watch a YouTube clip and it only buffers a short time in advance of what you’re watching, also known as Progressive Download. In Microsoft’s words, Bit Rate Throttling is…
“…an IIS 7.0 extension that meters the download speeds of media file types and data between a server and a client computer. The encoded bit rates of media file types such as Windows Media Video (WMV), MPEG-4 (MP4), and Adobe Flash Video, are automatically detected, and the rate at which those files are delivered to the client over HTTP are controlled according to the Bit Rate Throttling configuration.”
It basically saves you bandwidth by only transferring what you’ve watched plus a small, configurable buffer. Think about each user that starts watching a ten minute video but only watches one minute. In that time, they may have downloaded five minutes of content – quadrupling the bandwidth consumption unnecessarily. Bit Rate Throttling shares some user experience characteristics with Streaming Media, but it works on a normal web server over HTTP. It’s really quite a simple tool and I won’t devote space here to explaining it when the IIS.NET site already has some great content, including a brief introductory video. Definitely check it out.
So why am I writing about it?
Cloning isolated VMs vs. scripted installation
One of the challenges we’ve always faced with SharePoint development has been the tension between cloning actually identical environments versus automating the deployment across distinct environments (or worse, repeating the installation manually). In the first case we save time by eliminating reconfiguration and this ensures a consistent experience for each user. This is particularly beneficial for software development. These benefits can also be obtained by scripting installation/configuration/deployment but there’s a considerable overhead associated with developing and testing those scripts. As SharePoint 2010 is still quite new and we’ve been working on projects for some time now, we didn’t have the luxury of waiting for those refinements and we needed to take advantage of these efficiencies as we had done with SharePoint 2007 projects.