We lost remarkably few days of productivity to the bad weather at Black Marble. That wasn’t because we were all intrepid, hardy types and all made it into the office. Far from it – some of us live in areas where they don’t grit very often and can’t make it to the main roads.
As you guessed from the title, the reason we came through the bad weather so well was because of our ability to work remotely. I thought I’d write a post about what we do – not because we have any wonderfully clever solution, but because lost time is lost money, and many people discard remote access out of hand.
Keep it simple
I come at this from two sides: Firstly, complex solutions are hard to manage and are more likely to fail. Secondly, users don’t want to have to remember some peculiar incantation to access their stuff just because they are somewhere other than their desk.
I have a simple approach; Anything the users do to access stuff on our company network should be what they do to access it when they aren’t on the company network. If I don’t allow remote access to that system (and I can’t think of any of those off the top of my head) then they should get some kind of access denied message; otherwise, they should be asked to authenticate and carry on.
Pick a protocol. Don’t pick lots.
To be fair, I’m in a strong position with this because of the portfolio of services I run. I don’t profess to be a network security ninja so I have very few rules in our firewall. Only one protocol is allowed in for remote access: https.
How can I do that? Well, SharePoint, Project Server and CRM are all very obviously web-based. Exchange has OWA and Outlook can connect using https as well. Even our remote desktop access is published using https, using Terminal Services Gateway. Since I’m using https outside the LAN, I use it inside as well. Why? Well, why trust my own network any more than the internet, and why make users remember a different URL when outside.
A short list of the stuff we use
ISA Server 2006 sits at the edge of our network. I use it to publish out the various services. It’s very easy to manage and works beautifully. It’s about to be replaced, however, by Forefront Threat Management Gateway (TMG). My own plan is to move towards using DirectAccess and Unified Access Gateway (UAG) in the near future.
Our SharePoint, Project Server and CRM systems all run on IIS. We have a wildcard certificate, which I would recommend to any small organisation wanting to publish web systems securely as they offer a much lower cost approach than getting specific certs for all the different URLs.
Out Visual Studio Team Foundation Server (TFS), in both 2008 and 2010 flavours also works quite happily over https, and can be published out securely.
Terminal Services Gateway allows me to connect to appropriate systems securely using RDP over HTTPS.
What don’t we publish?
Perhaps unsurprisingly, none of our file shares are accessible from the outside world. However, since all our business data is in SharePoint or CRM (including documents), the stuff on the file shares is not needed and is mostly stuff like ISOs of software.
How easy is it?
If you keep things simple, remote access can be delivered securely and easily. ISA Server takes only a short time to install and configure if you stick to a very limited and straightforward ruleset.
I would, however, urge you not to simply rush out and allow access to your systems without thinking: Security is essential and that means putting some thought into what you want to publish outside your corporate LAN and how you manage access and auditing.
The bottom line, though, is the effect that incidents like the recent bad weather can have on the company’s bottom line. Being able to work remotely doesn’t mean that your staff can do so on a whim, but it means that should they need to, they can do all the things they would normally do in the office without penalty. If you haven’t considered remote access solutions yet, perhaps now is the time to do so – before next winter and your workforce is stuck at home…