Tuesday, January 19, 2010
Microsoft DirectAccess - No ugly truth here
I just finished reading the following Infoworld article on Microsoft DirectAccess by Keith Schultz titled "Microsoft DirectAccess: The ugly truth. I think Keith is trying to get a response out of folks when there really isn't any ugly truth to reveal. I question some of Keith's claims in the article regarding some of the dependencies that he outlines and claims are ugly. Specifically, the deployment requirements for DirectAccess that are outlined are textbook Microsoft and (as is expected from the vendor) they include everything, likely far more than most customers would deploy for a working solution.
A more practical view is to realize that DirectAccess is specifically designed around a Windows Server 2008 and Windows 7 better together story. So, obviously, those two products need to be in use or planned to be deployed. Given the very fast adoption that Windows 7 is enjoying and the fact that Windows Server 2008 R2 is a solid deployment choice for an OS it is natural to start leveraging some of the better together options available. If you don't plan on using Windows 7 or Server 2008 R2 then guess what, don't deploy DirectAccess. I don't think that is an ugly truth it is just logic.
DirectAccess does not require that you replace any infrastructure but instead allows a company to simply upgrade a domain controller to Server 2008 SP1 or R2. Given the refresh cycle it is reasonable to assume that most IT shops will be adding Server 2008 SP1 or R2 into their environment very soon if they have not already. In addition, you will need to deploy (yes a new server or virtual machine) a DirectAccess server or Forefront Unified Access Gateway 2010 server. If you deploy the Forefront UAG 2010 solution you do not require a separate NAT64(NAT-PT is dead BTW) device (UAG provides this function) and UAG can be the DirectAccess solution as well.
I would also argue there are many AD configurations deployed today that are starting to use machine certificates for wireless 802.1x requirements and domain signed certificates for SharePoint and therefore a reasonable amount of customers have started deploying or are looking to deploy certificate services. DirectAccess can piggyback on the CA infrastructure in place or being planned. (As a side note, if you are deploying a CA on Windows Server 2008 R2 - remember to launch IE with "Run as administrator" when you are trying to see the newly copied certificate templates options you have added to the CA server.)
If you end up deploying DirectAccess with Forefront UAG 2010 the issue of having services internally not running IPv6 natively is a mute since it has the NAT64 option. Additionally, there is no requirement to run IPv6 or any transition services at all on the DirectAccess server if desired as it has the option to simply do DA over IP-HTTPS. You will notice in the TechNet article that it outlines transition services "available" for use in DA - not a requirement. Granted, I think running Teredo or 6to4 would be a good deployment option but it is NOT a requirement. Also, regardless of what any of the Microsoft documentation says, do not deploy DA with ISATAP, you will have nothing but headaches and no management or troubleshooting tools to determine why things are not working. You've been warned - no ISATAP!
One of the additional items listed is Network Access Protection (NAP). NAP is far from a requirement to deploy DA. All that Microsoft did was insure that DA conformed to previously designed deployment specification for NAP. That way shops that already have NAP deployed in their environment can continue to leverage and use it for health checks against machines regardless of how they are gaining entry to the network (wired, wireless, DA, ipsec vpn, ssl vpn, pptp.) So, if you are not running NAP and don't plan to then there is nothing to worry about. If you are running NAP already just know you can do integration with DA to leverage your existing investment in NAP.
So, more than likely the purchase of Forefront UAG 2010 with some small upgrades in a typical environment would allow for a successful DirectAccess deployment assuming you have decided that Windows Server 2008 R2 and Windows 7 are where you are going. I don't see a lot of ugly in any of that. The nice thing about choosing Forefront UAG 2010 is that it a high available solution option and builds the group policy configurations for you for DA, a pretty nice plus if you ask me.
- Ed
A more practical view is to realize that DirectAccess is specifically designed around a Windows Server 2008 and Windows 7 better together story. So, obviously, those two products need to be in use or planned to be deployed. Given the very fast adoption that Windows 7 is enjoying and the fact that Windows Server 2008 R2 is a solid deployment choice for an OS it is natural to start leveraging some of the better together options available. If you don't plan on using Windows 7 or Server 2008 R2 then guess what, don't deploy DirectAccess. I don't think that is an ugly truth it is just logic.
DirectAccess does not require that you replace any infrastructure but instead allows a company to simply upgrade a domain controller to Server 2008 SP1 or R2. Given the refresh cycle it is reasonable to assume that most IT shops will be adding Server 2008 SP1 or R2 into their environment very soon if they have not already. In addition, you will need to deploy (yes a new server or virtual machine) a DirectAccess server or Forefront Unified Access Gateway 2010 server. If you deploy the Forefront UAG 2010 solution you do not require a separate NAT64(NAT-PT is dead BTW) device (UAG provides this function) and UAG can be the DirectAccess solution as well.
I would also argue there are many AD configurations deployed today that are starting to use machine certificates for wireless 802.1x requirements and domain signed certificates for SharePoint and therefore a reasonable amount of customers have started deploying or are looking to deploy certificate services. DirectAccess can piggyback on the CA infrastructure in place or being planned. (As a side note, if you are deploying a CA on Windows Server 2008 R2 - remember to launch IE with "Run as administrator" when you are trying to see the newly copied certificate templates options you have added to the CA server.)
If you end up deploying DirectAccess with Forefront UAG 2010 the issue of having services internally not running IPv6 natively is a mute since it has the NAT64 option. Additionally, there is no requirement to run IPv6 or any transition services at all on the DirectAccess server if desired as it has the option to simply do DA over IP-HTTPS. You will notice in the TechNet article that it outlines transition services "available" for use in DA - not a requirement. Granted, I think running Teredo or 6to4 would be a good deployment option but it is NOT a requirement. Also, regardless of what any of the Microsoft documentation says, do not deploy DA with ISATAP, you will have nothing but headaches and no management or troubleshooting tools to determine why things are not working. You've been warned - no ISATAP!
One of the additional items listed is Network Access Protection (NAP). NAP is far from a requirement to deploy DA. All that Microsoft did was insure that DA conformed to previously designed deployment specification for NAP. That way shops that already have NAP deployed in their environment can continue to leverage and use it for health checks against machines regardless of how they are gaining entry to the network (wired, wireless, DA, ipsec vpn, ssl vpn, pptp.) So, if you are not running NAP and don't plan to then there is nothing to worry about. If you are running NAP already just know you can do integration with DA to leverage your existing investment in NAP.
So, more than likely the purchase of Forefront UAG 2010 with some small upgrades in a typical environment would allow for a successful DirectAccess deployment assuming you have decided that Windows Server 2008 R2 and Windows 7 are where you are going. I don't see a lot of ugly in any of that. The nice thing about choosing Forefront UAG 2010 is that it a high available solution option and builds the group policy configurations for you for DA, a pretty nice plus if you ask me.
- Ed
Labels: Microsoft DirectAccess, Microsoft Forefront UAG
Monday, November 23, 2009
Follow up items to NAC / 802.1x post
I realized I left out some important clarifications on my post about NAC and 802.x, so here they are in no particular order. I've includes some other random thoughts too, just to keep life interesting.
1. I did not do a Cisco NAC Appliance + 802.1x (Cisco NAC Framework) deployment configuration - which would likely address some of the items in the fourth point. I would still argue that for trusted hosts that are able to run virtual machines you can still have issues with the overall security deployment and you need that HR/Security policy and procedures.
2. I did not address VMware's View (VDI) or ACE platforms or Microsoft's Remote Desktop or Citrix's XenApp or XenDesktop since they are all inherently remote access methods. I have not had a chance to look into View's authentication method supports but I imagine for the thin client machines simple MAC based security would suffice along with ACL's if a large thin client deployment is done.
For ACE I would recommend building out the internal network with 802.1x with a default guestnet configuration and let machines boot and get Internet access and then launch the ACE desktop to connect via VPN, just like if they are out on the public Internet. I would use this same method for people running View on a desktop or laptop since they have an underlying OS. With both of these solutions I see limited value in attempting to do single sign on or an 802.1x supplicant in the native OS. Basically you are building a public access network where View is the only service available or in the case of ACE where they have to VPN back for resources just like if they were on the public Internet.
3. I did not address the function of most of the agents used in NAC solutions and what benefit you might get from them. For instance, Cisco's Trust Agent (CTA) can allow the end host to pass posture information to Cisco ACS and can work with Cisco Security Agent (CSA) to build a more comprehensive solution. Basically, CTA was the first NAC client agent (2004?) and allows for end hosts to work with with a AAA server to do both authentication but also posture validation.
CSA is different, it works independently on the end host and watches the behavior of the native OS and basically denies any activity that looks outside the normal behavior of that machine. It doesn't care what an application or service is trying to do, if it isn't something that has been previously defined as ok it blocks it. It can run as a centrally managed or standalone configuration. So, if you glue the two together you can get health posture/remediation + validation of machine and end user + very secure end host with reduced exploitable footprint.
4. Some IT professionals argue it is easier and cheaper to run a VMware View setup (or a Pano Logic configuration) and just blow away potential desktops that don't meet company standards or appear to have issues (security or otherwise). They argue it is cheaper and more cost effective to simply deploy a new desktop than to determine what is wrong. They often also say you do not need to incur the cost of deploying either NAC or 802.1x solutions since everything is resident back on a VMware ESX host. I think the cost argument for not wasting time trying to determine what has gone wrong on a desktop OS makes sense. I would still argue that you want some sort of endpoint security to keep foreign systems from accessing your View configuration or ESX host. Also, you will still need to audit your systems for security issues and while patching the OS might have gotten easier and even automated the exposure from guest hosts isn't any different.
5. I think it is sort of obvious right now but I didn't mention it specifically, there is no unified framework or management method for deploying this as a solution right now. What does this mean for IT Professionals who are running and maintaining this? It is possible to break NAC or 802.1x by doing a simple upgrade of your AAA service or radius solution if there is a bug. It is possible to lock everyone out of the network by mis-applying the wrong policy configuration (always have a backup reserved port with no 802.1x or NAC authentication on it!) and you have to manage this on all the network devices connected to your network.
6. To the best of my knowledge there is no way to automate deployment of new switches on the network and have them self provision with 802.1x. You can avoid trusting a new switch connection by using Cisco TrustSec but I have not seen a lot of activity in that area myself.
7. I think there might be something to the argument that deploying an all wireless (no public access switchports) might be more secure in some cases. You can't address the DOS problems with wireless spectrum so that is a negative but it is only a single unified solution for wireless. Everything else is back in the datacenter on a trusted well known port.
8. I think there is also something to be said for shops that deploy everything in a data center and require everyone to VPN in to access content. Then they simply build out public access networks at their office locations and don't worry about port security. As bandwidth has gotten cheaper and cheaper this solution seems viable. With Cisco's AnyConnect client being able to auto reconnect it makes this a more tolerable solution to end users since they don't have to reconnect via VPN if they disconnect by losing network connectivity.
9. I believe Microsoft's DirectAccess solution is a great way to extend a corporate network with trusted client machines and still get the same sort of policy management. The solution allows IT professionals to run basic 802.1x. For machines that don't run a supplicant it still provide them basic corporate services in a dynamic VPN configuration no different then if they were on the public Internet by having them fall back to guestnet access. In addition, they can run the Microsoft's NAP solution with DirectAccess and have all the posture and remediation work happen regardless of location. The best part is that 802.1x can be run and maintained by the network team and NAP by the server team and neither solution gets in the way of the other for the most part.
Ok, that is it for now, I am sure I'll think of something else and I know I've forgotten a point or two so I will post again when they resurface in my head.
- Ed
1. I did not do a Cisco NAC Appliance + 802.1x (Cisco NAC Framework) deployment configuration - which would likely address some of the items in the fourth point. I would still argue that for trusted hosts that are able to run virtual machines you can still have issues with the overall security deployment and you need that HR/Security policy and procedures.
2. I did not address VMware's View (VDI) or ACE platforms or Microsoft's Remote Desktop or Citrix's XenApp or XenDesktop since they are all inherently remote access methods. I have not had a chance to look into View's authentication method supports but I imagine for the thin client machines simple MAC based security would suffice along with ACL's if a large thin client deployment is done.
For ACE I would recommend building out the internal network with 802.1x with a default guestnet configuration and let machines boot and get Internet access and then launch the ACE desktop to connect via VPN, just like if they are out on the public Internet. I would use this same method for people running View on a desktop or laptop since they have an underlying OS. With both of these solutions I see limited value in attempting to do single sign on or an 802.1x supplicant in the native OS. Basically you are building a public access network where View is the only service available or in the case of ACE where they have to VPN back for resources just like if they were on the public Internet.
3. I did not address the function of most of the agents used in NAC solutions and what benefit you might get from them. For instance, Cisco's Trust Agent (CTA) can allow the end host to pass posture information to Cisco ACS and can work with Cisco Security Agent (CSA) to build a more comprehensive solution. Basically, CTA was the first NAC client agent (2004?) and allows for end hosts to work with with a AAA server to do both authentication but also posture validation.
CSA is different, it works independently on the end host and watches the behavior of the native OS and basically denies any activity that looks outside the normal behavior of that machine. It doesn't care what an application or service is trying to do, if it isn't something that has been previously defined as ok it blocks it. It can run as a centrally managed or standalone configuration. So, if you glue the two together you can get health posture/remediation + validation of machine and end user + very secure end host with reduced exploitable footprint.
4. Some IT professionals argue it is easier and cheaper to run a VMware View setup (or a Pano Logic configuration) and just blow away potential desktops that don't meet company standards or appear to have issues (security or otherwise). They argue it is cheaper and more cost effective to simply deploy a new desktop than to determine what is wrong. They often also say you do not need to incur the cost of deploying either NAC or 802.1x solutions since everything is resident back on a VMware ESX host. I think the cost argument for not wasting time trying to determine what has gone wrong on a desktop OS makes sense. I would still argue that you want some sort of endpoint security to keep foreign systems from accessing your View configuration or ESX host. Also, you will still need to audit your systems for security issues and while patching the OS might have gotten easier and even automated the exposure from guest hosts isn't any different.
5. I think it is sort of obvious right now but I didn't mention it specifically, there is no unified framework or management method for deploying this as a solution right now. What does this mean for IT Professionals who are running and maintaining this? It is possible to break NAC or 802.1x by doing a simple upgrade of your AAA service or radius solution if there is a bug. It is possible to lock everyone out of the network by mis-applying the wrong policy configuration (always have a backup reserved port with no 802.1x or NAC authentication on it!) and you have to manage this on all the network devices connected to your network.
6. To the best of my knowledge there is no way to automate deployment of new switches on the network and have them self provision with 802.1x. You can avoid trusting a new switch connection by using Cisco TrustSec but I have not seen a lot of activity in that area myself.
7. I think there might be something to the argument that deploying an all wireless (no public access switchports) might be more secure in some cases. You can't address the DOS problems with wireless spectrum so that is a negative but it is only a single unified solution for wireless. Everything else is back in the datacenter on a trusted well known port.
8. I think there is also something to be said for shops that deploy everything in a data center and require everyone to VPN in to access content. Then they simply build out public access networks at their office locations and don't worry about port security. As bandwidth has gotten cheaper and cheaper this solution seems viable. With Cisco's AnyConnect client being able to auto reconnect it makes this a more tolerable solution to end users since they don't have to reconnect via VPN if they disconnect by losing network connectivity.
9. I believe Microsoft's DirectAccess solution is a great way to extend a corporate network with trusted client machines and still get the same sort of policy management. The solution allows IT professionals to run basic 802.1x. For machines that don't run a supplicant it still provide them basic corporate services in a dynamic VPN configuration no different then if they were on the public Internet by having them fall back to guestnet access. In addition, they can run the Microsoft's NAP solution with DirectAccess and have all the posture and remediation work happen regardless of location. The best part is that 802.1x can be run and maintained by the network team and NAP by the server team and neither solution gets in the way of the other for the most part.
Ok, that is it for now, I am sure I'll think of something else and I know I've forgotten a point or two so I will post again when they resurface in my head.
- Ed
Labels: 802.1x, Cisco NAC, Microsoft DirectAccess, VMware ACE, VMware View
Wednesday, July 15, 2009
DirectAccess and Forefront UAG plus IPv6
For those who are watching the happenings in Microsoft's DirectAccess solution the most interesting news as of late is from the Forefront Unified Access Gateway product group. They announced at the end of last month the availability of a UAG DirectAccess solution.
I participated in one of the Microsoft MVP LiveMeeting session on it and I think the most compelling part of using UAG for DirectAccess is the easy of provisioning the solution. They have a nice wizard driven deployment set up which I think will make getting DirectAccess up and going much easier. The nice part is that they handle setting up the NAT-PT (NAT64) and other transition tunneling needed to get the solution up and working.
I downloaded the beta and will be trying it out next week at our office. We just finished rolling out native IPv6, IPv6 routing and even got IPv6 working over Cisco DMVPN. We have Windows Server 2008, Windows 7, Ubuntu 8.10 and 9.04 all working on IPv6 and we even have our Cisco Communication Manager and IP handsets working on IPv6 now.
With the addition of the UAG DirectAccess we will have a complete solution that also integrates Microsoft OCS and MOC with our Cisco Unified Communications infrastructure. Pretty cool stuff.
- Ed
I participated in one of the Microsoft MVP LiveMeeting session on it and I think the most compelling part of using UAG for DirectAccess is the easy of provisioning the solution. They have a nice wizard driven deployment set up which I think will make getting DirectAccess up and going much easier. The nice part is that they handle setting up the NAT-PT (NAT64) and other transition tunneling needed to get the solution up and working.
I downloaded the beta and will be trying it out next week at our office. We just finished rolling out native IPv6, IPv6 routing and even got IPv6 working over Cisco DMVPN. We have Windows Server 2008, Windows 7, Ubuntu 8.10 and 9.04 all working on IPv6 and we even have our Cisco Communication Manager and IP handsets working on IPv6 now.
With the addition of the UAG DirectAccess we will have a complete solution that also integrates Microsoft OCS and MOC with our Cisco Unified Communications infrastructure. Pretty cool stuff.
- Ed
Labels: IPv6, Microsoft DirectAccess, Microsoft Windows 7
Wednesday, May 20, 2009
New Microsoft DirectAccess content
Joe Davies has a new Cable Guy article up about DirectAccess that folks should read. In addition, there is a new Step by Step Guide for a DirectAccess lab (which looks a lot like Joe wrote it - but I haven't confirmed that yet)
I've been slow getting my DirectAccess deployment going at work, seems other items keep getting in the way but I hope to get more done this week and have something to share with everyone.
- Ed
I've been slow getting my DirectAccess deployment going at work, seems other items keep getting in the way but I hope to get more done this week and have something to share with everyone.
- Ed
Labels: Microsoft DirectAccess
Friday, May 15, 2009
Microsoft DirectAccess - some brief thoughts
I think out of anything coming out of the Microsoft Server 2008 R2 and Windows 7 releases the feature I am most excited about is DirectAccess (anyone remember DirectConnect?) Microsoft has some excellent content starting to build up at http://www.microsoft.com/directaccess which gives an overview of how DirectAccess works and how it can be utilized so I won't repeat that here.
I have had the chance due to both my Microsoft MVP status and Springboard STEP status to have access to some deployment guides that are not generally available. After reviewing these and after playing with gear I have some opinions on what Microsoft should be recommending to IT Pros to do as initial trials of DirectAccess.
In a nutshell, I believe that people should set up an initial native IPv6 deployment with a tunnel broker (use Hurricane Electric) and get native IPv6 addresses working in their environment. In addition, I would minimize the deployment model to utilize proxy services or a NAT-PT device for resources on the network that are available via DA. This model comes pretty close to many VPN deployments today but does not have the pain involved with doing a functional overlay technology like ISATAP.
So, what do I mean by proxy services in this case? Well, for those deploying DA, I would set up a new Server 2008 R2 machine to front end file servers that are still running Server 2003 or older by utilizing SharePoint, that same server or an additional one could potentially do Exchange OWA or front end services depending on what Exchange environment you are on. I would utilizes a NAT-PT for specific line of business applications but I would narrow the selected application list initially to reduce troubleshooting on the NAT-PT device. There are options for NAT-PT devices, Cisco can do it in software on their routers and there is the Forefront UAG from Microsoft.
Most importantly, I would set expectations that there are a lot of moving parts with DirectAccess to get a deployment done correctly. You need to have PKI with a public CRL, IPv6, Windows Server 2008 R2 and Windows 7 just as minimum requirements, that doesn't say anything about the networking technologies you have to learn.
DirectAccess has the potential to bring about some of the most exciting changes in how people will work in the future on Windows but it will take a lot of planning and testing to get it all right.
I'll post more thought shortly.
- Ed
I have had the chance due to both my Microsoft MVP status and Springboard STEP status to have access to some deployment guides that are not generally available. After reviewing these and after playing with gear I have some opinions on what Microsoft should be recommending to IT Pros to do as initial trials of DirectAccess.
In a nutshell, I believe that people should set up an initial native IPv6 deployment with a tunnel broker (use Hurricane Electric) and get native IPv6 addresses working in their environment. In addition, I would minimize the deployment model to utilize proxy services or a NAT-PT device for resources on the network that are available via DA. This model comes pretty close to many VPN deployments today but does not have the pain involved with doing a functional overlay technology like ISATAP.
So, what do I mean by proxy services in this case? Well, for those deploying DA, I would set up a new Server 2008 R2 machine to front end file servers that are still running Server 2003 or older by utilizing SharePoint, that same server or an additional one could potentially do Exchange OWA or front end services depending on what Exchange environment you are on. I would utilizes a NAT-PT for specific line of business applications but I would narrow the selected application list initially to reduce troubleshooting on the NAT-PT device. There are options for NAT-PT devices, Cisco can do it in software on their routers and there is the Forefront UAG from Microsoft.
Most importantly, I would set expectations that there are a lot of moving parts with DirectAccess to get a deployment done correctly. You need to have PKI with a public CRL, IPv6, Windows Server 2008 R2 and Windows 7 just as minimum requirements, that doesn't say anything about the networking technologies you have to learn.
DirectAccess has the potential to bring about some of the most exciting changes in how people will work in the future on Windows but it will take a lot of planning and testing to get it all right.
I'll post more thought shortly.
- Ed
Labels: IPv6, Microsoft DirectAccess, NAT-PT
Thursday, March 05, 2009
Microsoft 2009 MVP Summit - thoughts
I wasn't sure if I was going to attend the Microsoft MVP Summit this year. After the MVP program decided to remove the Windows Server - Networking category I didn't think I had much reason to attend and honestly was expecting to not be renewed because of the category going away.
I am now very happy I changed my mind and I attended. It seems that my new category of Enterprise Security felt that it was important to add networking sessions back to the mix.
A ton of folks from the MS Networking Team showed up! From Sandeep Singhal, Sean Siler, Dave Thaler, Ravi Rao, Tyler Barton, Devrim Asli Iyigun, Mahesh Prakriya, to Joseph Davies - thanks to you all for taking the time and effort to listen to my feedback and opinion about networking and what Microsoft is doing right and wrong.
So, without violating my NDA what was I most excited about from the event? Honestly, it is things that were already on my radar (NDA or not) - specifically Direct Access, Branch Cache and IPv6. I think any Enterprise that is running AD and has a large mobile workforce will adopt Direct Access just to make remote support of that mobile workforce easier, there is literally nothing the end user has to do at all (well, you have to turn the computer on and have some sort of Internet connection) to make it work and the initial scaling numbers I have heard put it on par with a typical traditional VPN deployment. Just as many Enterprises have adopted rpc over http/s for Outlook to Exchange the next natural step is to adopt a paradigm that allows ALL corporate applications the same flexibility and access that Outlook and Exchange currently have today - that solution is Direct Access.
Microsoft is pushing more advanced services into both Windows Server 2008R2 and Windows 7 - Branch Cache is one of these services and one that makes a lot of sense for folks to use (big and small IT shops will win with this one - and it is free to turn it on - how cool is that). It does not replace WAN accelerations devices (though with the changes in Windows Vista / Windows 7 / Server 2008 networking you could argue you might not need the acceleration part) but specifically targets the caching of file content. Given the cost point and relative easy of deployment I think it will have a good adoption rate.
Finally, IPv6 - there are several solutions in both Windows 7 and Windows Server 2008R2 that just won't work without IPv6. There is no getting around it and you need to start learning it - period. In Windows 7 there is HomeGroup and for Windows Server 2008R2 if you want Direct Access you will need to get up to speed on IPv6. There are more subtle IPv6 items but those two alone should make folks stand up and notice.
- Ed
I am now very happy I changed my mind and I attended. It seems that my new category of Enterprise Security felt that it was important to add networking sessions back to the mix.
A ton of folks from the MS Networking Team showed up! From Sandeep Singhal, Sean Siler, Dave Thaler, Ravi Rao, Tyler Barton, Devrim Asli Iyigun, Mahesh Prakriya, to Joseph Davies - thanks to you all for taking the time and effort to listen to my feedback and opinion about networking and what Microsoft is doing right and wrong.
So, without violating my NDA what was I most excited about from the event? Honestly, it is things that were already on my radar (NDA or not) - specifically Direct Access, Branch Cache and IPv6. I think any Enterprise that is running AD and has a large mobile workforce will adopt Direct Access just to make remote support of that mobile workforce easier, there is literally nothing the end user has to do at all (well, you have to turn the computer on and have some sort of Internet connection) to make it work and the initial scaling numbers I have heard put it on par with a typical traditional VPN deployment. Just as many Enterprises have adopted rpc over http/s for Outlook to Exchange the next natural step is to adopt a paradigm that allows ALL corporate applications the same flexibility and access that Outlook and Exchange currently have today - that solution is Direct Access.
Microsoft is pushing more advanced services into both Windows Server 2008R2 and Windows 7 - Branch Cache is one of these services and one that makes a lot of sense for folks to use (big and small IT shops will win with this one - and it is free to turn it on - how cool is that). It does not replace WAN accelerations devices (though with the changes in Windows Vista / Windows 7 / Server 2008 networking you could argue you might not need the acceleration part) but specifically targets the caching of file content. Given the cost point and relative easy of deployment I think it will have a good adoption rate.
Finally, IPv6 - there are several solutions in both Windows 7 and Windows Server 2008R2 that just won't work without IPv6. There is no getting around it and you need to start learning it - period. In Windows 7 there is HomeGroup and for Windows Server 2008R2 if you want Direct Access you will need to get up to speed on IPv6. There are more subtle IPv6 items but those two alone should make folks stand up and notice.
- Ed
Labels: Branch Cache, Direct Access, IPv6, Microsoft DirectAccess, Microsoft MVP, Microsoft Windows 7
Unless otherwise expressly stated, all original material of whatever nature created by Ed Horley and included in this weblog and any related pages, including the weblog's archives, is licensed under a Creative Commons License.
