Archives mensuelles : juin 2013

How much bandwidth your users consume with DirectAccess?

This question always come during presale or at the beginning of the design phase of the DirectAccess project. My answer is always the same. Technically it’s difficult to estimate bandwidth used by users. Some reasons are purely technical (how many companies exactly know network traffic for his applications?). With Windows 8 and Null encapsulation for IPHTTPS, we can now estimate that DirectAccess users will generate the same amount of traffic compared to a traditional VPN/SSL VPN.

But there is another reason. Users become addict to DirectAccess and consume more resources. We need to prove that. With Windows Server 2012, we have many new capabilities in reporting. I started with the Get-RemoteAccessConnectionStatistics command and generate a script that calculate incoming and outgoing bandwidth consumed for each users as illustrated bellow :

RESULTAT

The URADAUserStatistics.PS1 script is available at this location. The script will generate statistics for all users during the period provided in input.This first version was tested in the following scenarios :

  • Windows Server 2012 single server deployments
  • Windows Server 2012 NLB deployments

Note that this version of the script is not yet compatible with Multisite deployments.

 

It’s now much more easier to estimate how much bandwidth my DirectAccess users consumes. This point must be considered seriously in a DirectAccess project.

BenoîtS – Simple and Secure by design but Business compliant

URA DirectAccess activation failure in NLB

A MVP colleague of mine challenged me a few days ago about an URA DirectAccess activation process failure in NLB. I already wrote a blog post on that scenario. I tried to reproduce his bug on my platform and succeeded. I was surprised. Why the wizard is asking me for IPv6 addresses? It’s not a HLB deployment.

URANLB1

 

After providing required information, activation started but ended with the following error. What parameter is incorrect. After some research, I found it’s the “Set-RemoteAccessLoadBalancer” Powershell command that fail.

URANLB3

I retrieved the original command generated by the URA Wizard and discovered that the command include IPv6 related parameters. After removing them and run the “Set-RemoteAccessLoadBalancer” Powershell command as illustrated bellow. It works.

URANLB4

That’s why I choose to configure DirectAccess in Powershell.

 

BenoîtS – Simple and Secure by Design but Business compliant.

Framework Dot Net 3.5 sur Windows Server 2012

Juste un billet rapide sur une erreur rencontrée lors de l’installation de SQL Server 2012 sur un serveur Windows Server 2012. Lors de l’installation de SQL Server, l’installation des outils d’administration a échouée à cause de la fonctionnalité NetFX3 (FrameWork Dot.Net 3.5)

NETFX3_SQLBUG

 

La fonctionnalité n’est pas installée, pas de problème il suffit de l’installer. Manque de bol, il semblerait bien que la fonctionnalité ne soit pas présente dans une installation standard de Windows Server 2012.

ADDFEATUREGUINETFX30

 

Passons sous la moquette avec un peu de Powershell à la recherche du Framework Dot.Net perdu.

SOUSLAMOQUETTE 

Le résultat est sans appel. Le Framework Dot.Net est effectivement pas présent dans une installation de Windows Server 2012. Conclusion, DISM.EXE va donc s’imposer. On va utiliser DISM.EXE sur notre installation pour ajouter la feature manquante et sous ses sous-composants à partir du média d’installation.

DISM

Dès lors, la fonctionnalité devient disponible, il est possible de relancer l’installation de la feature. Après vérification, elle est bien disponible pour installation et même installée.

NETFRAMEWORKFEATUREINSTALLED

 

Ne reste plus qu’à relancer l’installation des mes outils d’administration de SQL Server et miracle, cela fonctionne enfin.

SQLSUCCESS

Comme quoi, tout n’est pas nécessairement inclus. C’est aussi le cas de Powershell V2.

 

BenoîtS – Simple and Secure by Design but Business compliant.

DirectAccess Challenge series : Total isolation

A customer of mine had an interesting challenge with SDI (Server and Domain Isolation) and DirectAccess (off course).

His network is composed of multiple branch office sites connected to a headquarter site with a MPLS Network. To avoid IPSEC on LAN, Isolation mechanism only rely on IP routing at MPLS level. Branch sites can communicate with Headquarter site but cannot communicate each other. His wish was to reproduce this isolation with DirectAccess. A challenge for me.

The challenge

My initial proposal was based on a previous DirecyAccess challenge blog post. With this design, my customer immediately understand that he will have to deal with IPSEC on LAN. Firewall management can become painful, especially if each server have a specific set of protocols to secure (Do you really know your applications and  associated network traffic that pass on your LAN? For this reason, my customer refuse my initial design. From his point of view, illustration below represent his vision.

WISH

Each secure zone represent a branch site and only DirectAccess clients computers (and users) linked to a specific branch site should be allowed to access to it. Now let respond to this challenge with an additional condition : Do not have to handle IPSEC on LAN.

My response

If each Secure zone represent a complete environment (including authentication and authorization services provided by domain controllers located on each Branch site) why not put a DirectAccess entry-point in each Branch site as illustrated bellow :

MYPROPOSAL

Each Secure zone will have a dedicated URA Server configured for DirectAccess. Each Secure zone will have it’s own dedicated set of client-side GPO and server-side GPO. A DirectAccess client can only be associated to a single DirectAccess Infrastructure. In my design I consider that each DirectAccess infrastructure will be deployed behind a NAT device. This NAT Device will be responsible to translate external IPHTTPS port to default IPHTTPS internal port. Even a TMG box can do that.

As you already understood, DirectAccess clients will only be able to use IPHTTPS protocol. Teredo will not be available as URA Server are located behind a NAT device. With URA included in all editions of Windows Server 2012, it’s much more easier to deploy DirectAccess on a server with other roles. You no longer need a dedicated server. High availability only rely on IPHTTPS, witch is easier to put in high availability (F5 Big-IP, Citrix, NetScaler or other).

Simple and Secure by Design but Business compliant