SBS is going! A sign of the future?

27 08 2012

The recent news that Microsoft are discontinuing their all-in-one Small Business Server (SBS) offering sent a shockwave through the entire IT community. In a blog post on the SBS product group’s blog at the start of July, the news was made very clear: the end of an era is upon us. However, it is not just small businesses or those who specialise in working with them who should listen up and take note. This development is one of many which will define lasting change in the way we do computing, in this decade and beyond.

For those who are not in the Microsoft or the SMB market, SBS rapidly became a valuable product for companies with 75 users or fewer when it was introduced to the market. The platform was an instant winner because it combined a good number of products from the Windows Server portfolio into a single server which was very easy to manage. For the first time, small businesses were able to compete in the global marketplace alongside their enterprise rivals — realising the benefits of identical technologies, but without breaking the bank. Many companies sought a collaboration server like Exchange to manage all their communication better than they could achieve with conventional email systems. This was undoubtedly one of the most popular products to be bunded with SBS, and one which enabled many to thrive and flourish.

I owe a lot to SBS — in fact, without it, I would not be writing this article. Regular contributors at Experts Exchange may be aware that I began learning about networks and servers when I built my first server at the age of 11 to run the family computers. That server was running SBS 2003. Back then, my knowledge of networking was non-existent, but over time and with the supportive guidance from my peers at Experts Exchange, I was able to learn. I work now with a few organisations from 5 users up to several thousand, managing their infrastructure and developing solutions to help them integrate technology into their business model to position themselves and grow. For one such company, having an office staff and a snazzy computer system is unheard of in its industry, yet I have watched them develop from a small setup with a single laptop and a home office to a very successful company in their own right — and they give credit to their SBS server for helping make that happen.

So what’s the alternative?

Well, it’s not all bad news, and no, that’s not because I’m advocating we make what we already have the de facto standard for the next umpteen years and stop innovating. The replacement product comes from the Windows Server 2012 range, which has been massively revamped and simplified. It’s called Windows Server Essentials. This supports a maximum of 25 users on a single physical server and provides many of the services expected of a local server. Unfortunately, there’s a drawback. No Exchange Server. Companies are encouraged to push email hosting away from the local premises to Office 365 in Microsoft’s public cloud. The Essentials server provides integration with the Office 365 cloud to manage and control the service. It does still provide support for an on-premises Exchange Server and there is the option to use Windows Server 2012 Standard, which now allows a physical host and 2 virtual servers under a single license. However, the licensing for that must be acquired separately. Quite understandably, this strategic change in the rules of engagement has caused much controversy.

I understand and fully appreciate the intention of cloud-based computing – moving the infrastructure away from individual companies to service providers and large datacentres, increasing reliability and managing cost for the end-user. The model makes sense on the surface and has been enjoyed by many for years – consider Hotmail, one of the first cloud-based email services, joined rapidly by Yahoo! and Gmail in the late 20th and early 21st centuries. The technology is not new. Indeed, Google, Microsoft, Apple et al. have been successfully pushing it for years. What is new and scary is the paradigm shift which is trying to immerse the business sector kicking and screaming into the cloud before the technology is proven. There are many issues blocking adoption of the cloud: compliance, conflicting privacy laws between countries (where the service provider is in one and the user in another) and the lack of affordable, high-speed Internet connections in all corners of the globe. For these reasons, I am not convinced that cloud is the way forward for business (and apparently, neither is Steve Wozniak). I want to know exactly where my data is and have complete control over who is permitted to access it. I cannot afford to entrust such data to another individual. If everything is in my hands, it’s my fault and my fault alone if something goes wrong. On the contrary, in the cloud, it’s impossible to know exactly what is happening to your data, nor is there any guarantee today’s data will still be there tomorrow.

There is always difficulty effecting change in just about any situation, but this becomes very prominent when the impact is global. At first, I was saddened by the loss of SBS, but at least I know there are valid options for the future. I am concerned over the direction of the IT industry and the forced shift of companies to the cloud. It is a very big worry, and many IT professionals feel their entire livelihoods have been torn from beneath their feet. However, we cannot stand still. As Paul Cunningham of says in his news article on this story, This is IT. Things change. You either change with them, or you die too. We do, however, need to be very careful how we play the hand we have been dealt, and moving leaps and bounds into the cloud is not a card I am about to play any time soon.


iPhone 4S, Exchange ActiveSync and internal wifi

30 04 2012

It has been known for a while that iPhones and other iDevices do not play well with Exchange ActiveSync when roaming between a public network (such as 3G) and a private internal network to which the Exchange Server is connected. In particular, push email often does not work, which seems to be a bug in the iOS software. It’s a known issue, according to Apple. However, it caught me out recently, because the problem seemed to go away for a long time with the release of the iPhone 4.

At work, we have a set-up which is quite common for organisations of our size. We have two distinct networks: the internal network, which is reserved only for trusted devices owned and managed by us (the PCs, laptops, printers, switching gear, servers and now, thin clients). With 1000s of devices on this network, it is VLANed quite heavily to increase manageability, although I will admit this project was something I only completed fairly recently. Before last year, it was a single broadcast domain… but that is another story.

However, we also have a guest network. The guest network is isolated into its own VLAN, and is for wired clients which cannot authenticate as domain members (via 802.1x authentication) or for wireless clients connecting via a “Guest” SSID issued by our wireless controller. The guest network is still restricted to internal use – users authenticate to our RADIUS servers from their phones or laptops. Provided they provide valid credentials, they are provided with restricted access to the Internet.

All of the networks are linked together by our Forefront TMG deployment. This is driven by our inbound ISP connection and exposes several interfaces to the network – the internal network has two, teamed interfaces (for redundancy and throughput for data from cache) and the guest network has a further interface. The TMG deployment is the gateway for the guest network, and the internal network has a default route for unresolved traffic crossing the VLANs.

When the Forefront TMG was provisioned last year, I initially configured the guest network both for internet access, but also with an internal set of “relay” rules, if you like, for access to certain resources on the internal network – OWA, RD Web Access, our management system, internal websites and, crucially, DNS lookups via our internal name servers. In effect, guest traffic was not NATed onto its own public IP. When it matched a firewall rule for one of our internal services, it was simply routed into the internal network. This made the deployment much simpler, and meant the internal IP addresses returned by internal DNS nameservers would still work for guest clients. Upshot: I don’t need more nameservers!

At the time, this did not pose a problem, even with the iPhone and iPad devices used by our staff. These phones could have been on 3G and wifi simultaneously, and we never had an issue with the mismatched IP addresses on the two networks stopping ActiveSync working.

That is, however, until someone upgraded to the iPhone 4S.

As noted in the blog post linked above:

“push” may stop working if your company’s Exchange ActiveSync server has a different IP address for intranet and Internet clients. Make sure the DNS for your network returns a single, externally-routable address to the Exchange ActiveSync server for both intranet and Internet clients

The problem experienced with this one iPhone 4S user went beyond push email. The user’s phone worked perfectly when away from the network. However, the moment it roaming onto our wifi, it seemed to have an adverse effect on the Exchange account configuration. Almost immediately, the phone would report a password error on a manual email check. The Exchange account would then refuse to work at all – on any network – until the user deleted the device from the Exchange Control Panel (ECP), switched back to 3G and re-created his connection.

I was not convinced the issue was with Exchange – all manner of other devices, even the iPhone 4, were still working. Nothing tested incorrectly. The problem was not a user issue, as I had him configure a test user account for a few days. Same problem.

Eventually, after a lot of painstaking troubleshooting (and waiting for feedback), it started to become very clear the issue was present only on the iPhone 4S and only in certain circumstances. However, it was much more serious than before – when the issue occurred, it did not just stop the iPhone from working until it roamed off-site again. It essentially wrote the email capability on the device off.

The resolution was a simple one, and one I should probably have implemented in the first place. The Forefront TMG deployment was re-configured. No routing was permitted between the internal network and the guest network. Instead, I added a network rule for guest network traffic to be NATed to its own public IP. I built a new cluster of standalone DNS servers, which serve two purposes – recursive lookups from the internal network (they are, effectively, caching servers) and hosting of the public DNS zones which return public IP addresses for all our network services.

When the guest network was given access to these nameservers, the iPhone 4S problem immediately went away. As detailed by Apple, it seems their devices are once again having issues with multiple IP addresses being issued by DNS for the same service. I thought this inconvenience had been resolved, but it would appear this design strategy will be going back into my network design methodology in the future. In any event, it did allow me to streamline and simplify our guest network configuration, which is always a good thing!

Watch out for Apple devices and the problem with issuing different internal and external IPs if they are used on your internal wifi. Either make the public IP routable internally and use that for internal access, or – a very common solution – don’t use them on wifi at all.