WindowsNetworking.com Monthly Newsletter of March 2010
Sponsored by: Spiceworks <http://www.spiceworks.com/free-network-monitoring-management-software/?swsrc=windowsnetworking-newsletter-test>
-----------------------------------------
Welcome to the WindowsNetworking.com newsletter by Debra Littlejohn Shinder <http://www.windowsnetworking.com/Deb_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: dshinder@windowsnetworking.com
1. Branch Office Networking in the Future Enabled by Windows Servers and Clients
---------------------------------------------------------
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:
* You want to connect networks so clients have access to network resources at the main office
* You want to connect networks so clients have access to network resources at regional offices that might not be the main office
* You want to connect networks so that IT can manage all the hosts on all the networks
* You want to connect networks to isolate your private networks from other non-private networks and the Internet
* You want to connect networks so that communications are secure from intruders and so you can monitor communications on your networks
* You want to be able to control bandwidth within and between the networks
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 dshinder@windowsnetworking.com and I will share your opinions with everyone else, and with Microsoft. See you then!
By Debra Littlejohn Shinder, MVP
Thanks!
Deb
dshinder@windowsnetworking.com
=======================
Quote of the Month - "Supercomputers will achieve one human brain capacity by 2010, and personal computers will do so by about 2020." - Ray Kurzweil
=======================
2. ISA Server 2006 Migration Guide - Order Today!
---------------------------------------------------------
Dr. Tom Shinder's best selling books on ISA Server 2000 and 2004 were the "ISA
Firewall Bibles" for thousands of ISA Firewall administrators. Dr. Tom and his
illustrious team of ISA Firewall experts now present to you , ISA Server 2006
Migration Guide
<http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/>. This book
leverages the over two years of experience Tom and his team of ISA Firewall
experts have had with ISA 2006, from beta to RTM and all the versions and builds
in between. They've logged literally 1000's of flight hours with ISA 2006 and
they have shared the Good, the Great, the Bad and the Ugly of ISA 2006 with
their no holds barred coverage of Microsoft's state of the art stateful packet
and application layer inspection firewall.
Order your copy of ISA Server 2006 Migration Guide
<http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/>. You'll be
glad you did.
3. WindowsNetworking.com Articles of Interest
---------------------------------------------------------
* Using GUI to script PowerShell with PowerGUI
<http://www.windowsnetworking.com/articles_tutorials/Using-GUI-script-PowerShell-PowerGUI.html>
* Seven Free Network Tools for the Busy Admin
<http://www.windowsnetworking.com/articles_tutorials/Seven-Free-Network-Tools-Busy-Admin.html>
* Windows 7 Compatibility Testing (Part 2)
<http://www.windowsnetworking.com/articles_tutorials/Windows-7-Compatibility-Testing-Part2.html>
* Group Policy Object Backups (Part 1)
<http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Object-Backups-Part1.html>
* Deploying Windows 7 - Part 18: Determining the UUID of a Computer
<http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part18.html>
* Windows 7 Compatibility Testing (Part 1)
<http://www.windowsnetworking.com/articles_tutorials/Windows-7-Compatibility-Testing-Part1.html>
* 10 Core Concepts that Every Windows Network Admin Must Know
<http://www.windowsnetworking.com/articles_tutorials/10-Core-Concepts-Every-Windows-Network-Admin-Must-Know.html>
* DameWare NT Utilities - Voted WindowsNetworking.com Readers' Choice Award Winner - Remote Control
<http://www.windowsnetworking.com/news/WindowsNetworking-Readers-Choice-Award-Remote-Control-DameWare-NT-Utilities-Jan10.html>
4. Administrator KB Tip of the Month
---------------------------------------------------------
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. <http://www.windowsnetworking.com/kbase/WindowsTips/WindowsVista/UserTips/Misc/FormattingUSBFlashDrivesUsingexFAT.html>
For more administrator tips, go to WindowsNetworking.com/WindowsTips
<http://www.windowsnetworking.com/kbase/WindowsTips/>
5. Windows Networking Tip of the Month
---------------------------------------------------------
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:
* Configurable idle and session timeouts
* Background session authentication and authorization
* System and logon messages
* Device redirection enforcement
* Network Access Protection (NAP) remediation
* Pluggable authentication and authorization
Sound interesting? You bet! Check out the details of the Remote Desktop Gateway included with Windows Server 2008 R2 here <http://technet.microsoft.com/en-us/library/dd560672(WS.10).aspx>.
6. WindowsNetworking Links of the Month
---------------------------------------------------------
* Introducing Windows Server 2008 R2 eBook
<http://download.microsoft.com/download/5/C/0/5C0BD0AB-040D-4C56-A60B-661001012DDA/Windows_Server_2008_R2_e-book.pdf>
* Tom Shinder – Man on the Edge
<http://blogs.technet.com/wsnetdoc/archive/2010/03/12/tom-shinder-man-on-the-edge.aspx>
* BranchCache Distributed Cache Mode Step by Step Guide
<http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=89422460-1092-4679-93bc-39e1700d75b4>
* Using Windows Tools to Obtain IPv6 Configuration Information
<http://technet.microsoft.com/en-us/library/bb726952.aspx>
* Remote Access Step-by-Step Guide: Deploying Remote Access with VPN Reconnect
<http://technet.microsoft.com/en-us/library/dd637783(WS.10).aspx>
* Migrating Active Directory Domain Controller from Windows Server 2003 to Windows Server 2008
<http://www.elmajdal.net/Win2k8/Migrating_Active_Directory_Domain_Controller_from_Windows_Server_2003_to_Windows_Server_2008.aspx>
7. Ask Sgt. Deb
---------------------------------------------------------
* QUESTION:
Hi Deb,
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:
* Is there a limit on the number of connections a DirectAccess server can service?
* How much more do I need to pay to get DirectAccess?
* Do I have to migrate my entire network to IPv6?
* Can I use my current TMG firewall for DirectAccess?
Thanks! - Ronald H.
* ANSWER:
Hi Ronald,
Good questions! Here are my answers:
1. No. There is no hard coded limit on the number of connections a DirectAccess server can service. The only limit is going to be based on the hardware and network limits for the server. DirectAccess has high encryption computational costs, so you want to make sure you get the most powerful processors your budget can support.
2. There is no additional cost to get DirectAccess. DirectAccess is part of the Windows 7 Enterprise and Ultimate and Windows Server 2008 R2 operating systems. There are no client licensing fees or client access licenses required. As long as you have the right client and server operating systems, you're in good shape.
3. It depends. DirectAccess can take advantage of ISATAP (Intra-site Automatic Tunnel Addressing Protocol) to tunnel IPv6 communications over your IPv4 network. That requires that you have IPv6 "aware" operating systems, such as Vista and above and Windows Server 2008 and above. If you want to support non-IPv6 aware client and server operating systems (like older versions of Windows, Mac and Linux) then you can bring the Forefront Unified Access Gateway 2010 onto your network. UAG includes IPv6/IPv4 translation features that allow your DirectAccess clients to connect to IPv4 only resources on your network
4. You can use your TMG firewall as a DirectAccess server, or you can put your UAG firewall in front of your DirectAccess server. The functionality you get with TMG and DirectAccess will be the same as you get with the Windows DirectAccess experience. You will not get the additional DirectAccess features provided with UAG, unless you decide to put your UAG DirectAccess server behind the TMG firewall.
Good luck with your DirectAccess plans and deployment! And watch www.windowsnetworking.com for more articles on DirectAccess and how to make it work on your network.
TechGenix Sites
---------------------------------------------------------
MSExchange.org <http://www.msexchange.org/>
WindowSecurity.com <http://www.windowsecurity.com/>
ISAserver.org <http://www.isaserver.org/>
VirtualizationAdmin.com <http://www.virtualizationadmin.com/>
--
Visit the Subscription Management <http://www.techgenix.com/newsletter/>
section to unsubscribe.
WindowsNetworking.com is in no way affiliated with Microsoft Corp.
http://www.techgenix.com/advert/index.htm for sponsorship
information or contact us at advertising@windowsnetworking.com
Copyright c WindowsNetworking.com 2010. All rights reserved.
No comments:
Post a Comment