Cisco has a beta version of the IPSec VPN Client out, version 5.0.7 BETA (vpnclient-winx64-msi-5.0.07.0240-k9-BETA.exe) available for download. It appears they got the message about the need for a 64-bit version of the IPSec client for Windows 7! It is available for download on CCO but requires a valid CCO login and current contract to get the code.
This is great news for Microsoft customers that have Cisco ASA's, PIX's or VPN 3000 concentrators deployed and their IT team is migrating their client OS's to Windows 7. Many OEM's are shipping the default OS as Windows 7 64-bit to take advantage of the all the RAM systems can support today.
Cisco is still pushing their AnyConnect client + ASA platform to compete with Microsoft's DirectAccess solution on Forefront UAG. Cisco is positioning the AnyConnect client as an always ready vpn client that auto-reconnects and is seamless in that process. I don't know if I am buying that position given the flexibility of what DirectAccess can do and how you can manage the policies with GPO's in AD in the Microsoft solution. Plus the fact that once DirectAccess is deployed there is no VPN "client" per-say, it is more of a policy function which is a very unique position in terms of product positioning.
At least if you have a Cisco IPSec solution deployed today you can now leverage it with Windows 7 without requiring any third party software to get around the problem of being on a 64-bit OS.
- Ed
Howfunky...a place with useless technical content!
Showing posts with label Microsoft Forefront UAG. Show all posts
Showing posts with label Microsoft Forefront UAG. Show all posts
Friday, March 19, 2010
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
Subscribe to:
Posts (Atom)