WindowsNetworking.com Monthly Newsletter of March 2010 Sponsored by: Spiceworks
Welcome to the WindowsNetworking.com newsletter by Debra Littlejohn Shinder, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: email@example.com
Branch office networking has always been problematic. You could use expensive dedicated WAN links if you have a lot of money to throw around. If you do not have the sort of budget to be able to do this, you could take advantage of more economical site to site VPN connections. These days, you have a variety of approaches that you can use, but they always seem to have one thing in common - they are trying to connect networks to each other.
All well and good - I mean, isn't that what you want? The resources are contained on networks, so you want to be able to connect networks to one another; that only makes sense. But think about it. Exactly why are you trying to connect these networks to each other? Some reasons include:
There are other reasons that are not mentioned, but is it not true that what you really want to do is connect systems to one another, and not necessarily entire networks? Consider the branch office. Is there a reason that you need to connect the entire branch office network to the main office or any other office? Aren’t you primarily concerned with connecting the clients and servers at the branch office to the main office and perhaps to other regional offices?
I think that is the point. We have been thinking in terms of networks because that is how we have always done it, and there was no better way, especially when it comes to access control and management. But what if there were viable alternatives to connecting networks?
For example, consider the typical small branch office that has fewer than 100 users. Those users need access to resources on the corporate network. Why not use an SSL VPN gateway at the main office to provide users with access to web, client/client and other applications at the main office? There is no need to connect the entire branch office network to the main office; instead you can just make the applications available through an SSL VPN gateway, such as the Microsoft Unified Access Gateway (UAG) 2010.
You can even manage the machines in the branch office network using some workarounds, such as the System Center Configuration Manager IBCM client. However, that does introduce some limitations, since servers on the main office network are not able to initiate connections to the branch office networks. Not that this scenario is frequently required, but when it is required, it is painful not to have this capability.
In addition, what do you do about bandwidth issues? When you connect networks, you can use outrageously expensive "WAN accelerators" to connect the branch office network to the main office network and cache content at the accelerator, thus giving the branch office users a better end user experience than they would have otherwise. The SSL VPN gateway solution would not solve the bandwidth or the IT initiated traffic issues, so it looks like we are back to connecting networks again.
But maybe not. Think about the new Microsoft technology called DirectAccess. Using DirectAccess, all computers acting as DirectAccess clients are always connected to the main office network at all times. The connection is also bidirectional, so IT can initiate connections to any branch office client whenever IT needs to do that. You don’t need to use workarounds like the SCCM IBCM client, and the DirectAccess clients act and behave like any other corpnet client. In addition, the DirectAccess clients are able to connect to other offices over the DirectAccess connection or connect to each other directly if you want to allow that.
What about the bandwidth issue? Since you ae not connecting the branch office network to the main office network, you would not be able to benefit from “WAN accelerators”. However, there is the Microsoft BranchCache feature. BranchCache can work in either Hosted Mode or Distributed Mode. What if all the branch office clients were Windows 7 clients participating in a Distributed Mode BranchCache configuration? When one of the Windows 7 DirectAccess clients accesses content at the main office, that information will be cached at the branch office. When another Windows 7 client asks for the same content, it would be delivered from the cache of the Windows 7 client that already asked for that content, so that no WAN bandwidth is used to access that content at the main office. Or if you want to use Hosted Mode BranchCache, you can make the BranchCache Hosted Mode server a DirectAccess client, too - and then the Windows 7 clients at the branch office will be able to access the cached contents from the Hosted Mode server.
The beauty of this configuration is that you do not have to connect the branch office network to the main office or any other office. The client systems are able to connect to the server systems using point to point connections. This is consistent with the original intent of the Internet, way back when the powers that be thought that 4 billion addresses would be enough. With DirectAccess and IPv6 (including IPv6 transition technologies) we can get back to the original intent of the Internet founders and reestablish those direct connections between systems, using authentication and encryption that’s built right into the protocol, with IPsec.
This is how I see Microsoft clients and servers changing the game for branch office connections. The design will no longer be network centric - instead, it will be system centric, since we are most interested connecting systems, not networks. The entire configuration is secure because of strong identity management, authentication, authorization, and encryption, with IPsec ensuring privacy and integrity and non-repudiation. How far are we from this dream? Not too far at all, I believe. The technologies are already available in Windows Server 2008 R2 and Windows 7. While it might take a few years to get all the client systems upgraded, the potential cost savings are enormous - so much so that I suspect that the cost of upgrading the client and server operating system will be offset relatively quickly by the significant reduction in networking costs.
What do you think? Is this a picture of the real vision of branch office network as it should be, or just a pipe dream that the network device vendors will “beat down” because they need to maintain their market share and jobs? Let me know! Write to me a firstname.lastname@example.org and I will share your opinions with everyone else, and with Microsoft. See you then!
By Debra Littlejohn Shinder, MVP
Quote of the Month - “Supercomputers will achieve one human brain capacity by 2010, and personal computers will do so by about 2020." - Ray Kurzweil
3. WindowsNetworking.com Articles of Interest
Formatting USB Flash Drive Using exFAT
The Extended FAT (exFAT) file system is a new file system supported by Windows Vista, Windows 7 and Windows Server 2008. The exFAT file system is intended mainly for removable flash media such as USB flash drives. Such media typically use either FAT or FAT32 as their file systems, but these file systems have several limitations. For example, FAT32 has a maximum file size of 4 GB, and the Windows format restricts the maximum FAT32 volume size to 32 GB. FAT is even more restrictive on file and volume size. To overcome these limitations, Microsoft created exFAT, which can support files up to 2^64 bytes in size and can handle more than 1000 files in a single directory.
You can use the Format command on Windows Vista and Windows Server 2008 to format removable flash media using exFAT. For example, if K: is a USB flash device plugged into your computer, you can type format k: /fs:exfat to format the device using exFAT.
You can find this administrator tip here.
For more administrator tips, go to WindowsNetworking.com/WindowsTips
You want to give your users access to remote desktops regardless of their locations. You could use a service like GoToMyPC, but that can get expensive, and you don’t have control of the security infrastructure, which is not a good thing. You could publish your Remote Desktop Servers through your firewall, but that would require that you consume an IP address for each Remote Desktop Server, which isn’t something you’re really interested in doing from a management point of view. And then there is the problem with users being located behind firewalls and web proxies that don’t allow outbound TCP port 3389.
What to do? How about deploying a Remote Desktop Services Gateway (RDG)? A RDG server will allow your users to connect to Remote Desktop Services over an SSL connection, which means they never need to worry about being behind a restrictive firewall or web proxy. With Windows Server 2008 R2, you get some cool improvements too:
Sound interesting? You bet! Check out the details of the Remote Desktop Gateway included with Windows Server 2008 R2 here.
I have been hearing more and more about Windows and DirectAccess. It seems really interesting and something I think my boss and users would really like. They are definitely tired of messing around with VPNs and SSL VPN gateways, and while VDI seems interesting, bandwidth and some other issues regarding VDI (like cost) make it seem like less than an ideal solution. But I have got some questions about DirectAccess that maybe you can answer for me:
Thanks! - Ronald H.
Good questions! Here are my answers:
Good luck with your DirectAccess plans and deployment! And watch WindowsNewtorking.com for more articles on DirectAccess and how to make it work on your network.