Lync 2013 - List CAL Usage

Hi,
This script returns information about client license usage in your organization since the first user connection. Your topology has to include a monitoring server.

#Get Monitoring Instance
$SQLSERVICE=get-csservice | ? {$_.Role -eq "MonitoringDatabase" }
if ($SQLSERVICE -eq $null) { exit }
$SQLINSTANCE = $SQLSERVICE.poolfqdn + "\" + $SQLSERVICE.SqlInstanceName

#Get CALs Usage
$plus=Get-CsClientAccessLicense -MonitoringDatabase $SQLINSTANCE -LicenseName plus -LicenseBasedType Userbased -StartDate 01/01/2012 | ? {$_.IpAddress -match ".+"}
$standard=Get-CsClientAccessLicense -MonitoringDatabase $SQLINSTANCE -LicenseName standard -LicenseBasedType Userbased -StartDate 01/01/2012 | ? {$_.IpAddress -match ".+"}
$enterprise=Get-CsClientAccessLicense -MonitoringDatabase $SQLINSTANCE -LicenseName enterprise -LicenseBasedType Userbased -StartDate 01/01/2012 | ? {$_.IpAddress -match ".+"}

#List Usage
write-host Your organization uses $standard.count Standard Lync CALs"," $enterprise.count Enterprise Lync CALs and $plus.count Plus Lync CALs

Tweeter

DirectAccess 2012 RTM–Epic Fail

Hello,
Today, I installed a DlrectAccess PoC on 2012 RTM. I prepared every thing, NLS, PKI, Firewalling, features, everything! I prepared my installation script and launch it!
First line : Install-RemoteAccess  ….
The term 'Install-RemoteAccess' is not recognized as the name of a cmdlet
Hum weird…. And via GUI?? File C:\Windows\system32\RAMgmtUI.exe cannot be located

Ok.. and now? Do i forget something?

EDIT : YES!!! With the install-windowsFeature, don't forget -includemanagementtools....

Tweeter

Lync 2013, IPv6 and Directaccess

 
Hi everyone,
This is my first post about Lync and my last about Directaccess

With Lync 2013 Preview, ipv6 is fully supported, so directaccess should work with Lync. Let’s check!

Firstly, we need to configure the lync topology. There is only one standard front-end server.
My sip domain is labda.local. Directaccess clients are configured to send every packet to labda.local domain in the IPsec tunnel.


My environment is full ipv6 so I disable IPv4 and enable IPv6 in the topology builder.


I activate the enterprise voice and the conferencing service on this server.

Ok now let’s check that Lync 2013 is working on the client!
Firstly, the dns resolution for the automatic configuration (2abc::11 is the dns server on my nrpt table, it’s the directaccess server):


Great, now let’s connect the lync client.


And a call? (i have only one user ). It’s working.


And a meet now?


So every thing is working is IPV6. Even Location services!


Even location services? Maybe not… Let’s check on the client…


No proposition, what is my ipv6 address?


Mmmm, very weird… Snooper is my friend!! So firstly, turn on tracing on my client


I get a log file on the client, stored in
%userprofile%\AppData\Local\Microsoft\Office\15.0\Lync\Tracing
Let’s analyze the log with snooper, and search the keyword subnet



So the subnet information sent by the client contains the ipv4 address, that’s why i don’t get my location information. So Lis doesn’t work with directaccess ip. I thing that it’s a normal behavior, we cannot predict where my client will be with directaccess. The best location with directaccess is somewhere!

Bye
Tweeter

Windows 8 and DirectAccess 2012

Hi everyone,

As you know, with windows 7 and directaccess, a tool is necessary to determine easily if the directaccess connection is working. The tool enables the end user to disable the directaccess connection if it’s not working. It enables the end user to send information about the connection to the help desk team.



This tool is not necessary with windows 8! This functionality is included by default.

How do we configure it?
On the directaccess server with the command :Set-DAClientExperienceConfiguration

What are the parameters?

Firstly, we need to choose the Gpo where these settings will be stored: –policystore

-Friendlyname : Specifies the name of the DirectAccess deployment to be shown in the client computer user interface.

-CorporateResources : Configures the connectivity tests that DirectAccess client computers use to determine connectivity.

-IPsecTunnelEndpoints : Configures the IPsec tunnel endpoints to use for DirectAccess. Client computers use this information to verify the availability of the DirectAccess servers and present that information to the user.

-PreferLocalNamesAllowed: Controls if users can disconnect DirectAccess.

-SupportEmail: Configures the email address displayed in the user interface for users to send logs and requests for assistance.

Together :


Verify the Gpo


Ok, now let’s check on the client!


The settinga are deployed. Let’s check the behaviour. The connection name is well configured and the user can disconnect the tunnel, so disable the nrpt Table



Right-click, view connection properties


We see the connection status, we can send the logs by email and we can view the logs


The logs have been improved!


The information are sorted. I can see that i can’t ping my second public ip. (I need to write a rule in my edge firewall )

As a conclusion, directaccess rocks!

Tweeter

UAG - Appwrap and Change Header

Hi,

I got a problem on UAG some weeks ago.
An application need to use a referer header in the http requests to deliver contents.

The application was published by UAG, but it was not working.

I captured the traffic between the client and the UAG and between the UAG and the application.
The only difference between both requests was a change in the referer header. UAG behaviour is to rewrite the referer header, replacing the host name by the published ip server.

The microsoft support said me to use AppWrap to rewrite (again) the referer Header.
So, We need to rewrite the ip with the host name.

The appwrap syntax was the following :

And that's all!

Bye
Tweeter

DirectAccess 2012 – Enable NLB

Hey,
So this post will be in English!
In the RAMgmtUI.exe, we enable Load Balancing



And we see a nice message : the length of the prefix used to assign IPv6 addresses to directaccess clients connecting over IP-HTTPS should be 59 bits.


What is our prefix?


The prefix is based on our internal IPV6 prefix : 2abc::/64. I think that the maximum number of Node in a directaccess cluster is 32. Why? 64-59 = 5. 2^5 = 32.
.

For the node 1, the client ipv6 address will be 2abc::FF00::eui-64/64
For the node 2, the client ipv6 address will be 2abc::FF01::eui-64/64

Great. Now, let’s try to activate the NLB! (We need to relaunch the RAMgmtUI.exe so that the wizard takes into account the prefix change).

The wizard is simple. The DIP will become the VIP. We just need to define new DIP for the directaccess server.



Let’s check on the windows 8 client if the directaccess server is still working. The client gets an ipv6 with the iphttpsinterface. And the client resolves an intranet dns record.



Now, we are going to add a new node in powershell. The second node reboots automatically. (but maybe not voluntarily... )


And the GPO? Great the security filtering is automatically updated!


But now, i get nice blue screen on EDGE2


So, i need to format!!!
See you after the formatting

EDIT: I tried again... and got same results whatever if use powershell or GUI... Waiting the final release!! I have to deploy a POC with 2012 RC for a client.(hopfully wihout NLB :) )

Tweeter

Windows Server 2012 - DirectAccess Part 2

Accrochez-vous, il va y avoir de l'IPV6

Aujourd'hui, nous allons rajouter un prefix IPV6 dans notre LAN : 2abc::/64
Pour simplifier, le "dernier octet" sera identique au dernier octet de l'ipv4.
Le dc aura l'ip 2abc::1/64
Edge1 aura l'ip 2abc::11/64 (et non pas 2abc::B/64, je simplifie au maximum ;) )
J'ai également supprimer le record ISATAP.

Regardons les différences que cela entraîne.
Déjà dans l'ip obtenu pour les client directaccess. Celle-ci est basée sur le prefix IPv6 en interne. Il vaut donc mieux éviter d'utiliser l'ipv6 monprefix:1000::/64 dans nos reseaux ipv6 sinon il y aura des petits soucis de routage par défaut ;)

S'il n'y a pas d'ipv6 sur le lan du serveur directaccess, le prefix qu'utilise le serveur directaccess pour les ips des clients est base sur l'ip 6to4.

Bien sur, cette fois-ci les résolutions dns sont en IPV6.

Le dns dans la table NRPT pointe sur l'ipv6 interne du serveur et non plus une ipv6 basée sur le prefix 6to4.

Bien sur les gpo ont été mises a jour pour permettre d'ouvrir des tunnels IPSec sur le prefix 2abc::/48

Et voila, c'est tout pour l'ajout d'IPV6!

Tweeter

Windows Server 2012 - DirectAccess Part 1

Hello,

Je me suis fait une petite maquette directaccess sur server 2012. Le but de cette architecture est d'avoir une ferme DirectAccess de serveur 2012 en NLB.

Cette première partie concerne la mise en place d'un seul serveur DirectAccess. La mise en place de la ferme sera effectuée plus tard.

Voici l'architecture

L'ip du DC est 192.168.11.1
L'ip de la PKI (qui fait egalement office de nls) est 192.168.11.20
Enfin le serveur directaccess a l'ip interne 192.168.11.11. En externe, le serveur a les ip 178.22.145.226 et 178.22.145.227.
Il y a un firewall en bridge devant le serveur directaccess.
Le domaine est labda.local.

Maintenant que l'architecture est présentée commençons l'installation du serveur EDGE1.

Un record isatap a ete crée pointant sur 192.168.11.11, et le record isatap a ete supprime de la liste bloquée.

Au passage, pourquoi isatap est un record dns bloqué par defaut? Car si jamais un poste se nomme isatap, il va s'enregistrer dans le DNS est devenir le routeur Isatap du reseau. Cela peut entrainer des attaques de  Man-In-The-Middle.

Ensuite passons vraiment a l’installation de directaccess. On commence par installer la feature.
L'url pour IPHTTPS est da35094.cloud1.fr
L'url du NLS est nlsda.labda.local

Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress da35094.cloud1.fr -ClientGPOName "labda.local\DirectAccess Clients GPO" -ServerGPOName "labda.local\DirectAccess Servers GPO" -InternalInterface LAN -InternetInterface INTERNET -NLSURL https://nlsda.labda.local –Force –PassThru

Petite remarque, il va trouver le certificat IPHTTPS correspondant tout seul, comme un grand!
Choisissons la CA a utiliser pour les tunnels IPSec. (merci a Benoît SAUTIERE pour cette joli technique ;) )

$CA = (Get-ChildItem Cert:\\LocalMachine\Root | Where {$_.Subject -like "CN=labda*"})
Set-Daserver -IPSecRootCertificate $CA -PassThru

Vérifions que tout est bien installe avec un get-daserver.

OK, tout est la! Tiens TeredoState : Disabled... On y reviendra plus tard!
Verifions aussi le NLS.

Parfait, passons maintenant a la configuration du client et on supprime le filtrage WMI
Choix du groupe :

Add-DAClient –SecurityGroupNameList “labda.local\GG_DA”
Set-DAClient –OnlyRemoteComputers Disabled

Il ne reste plus qu'a tester sur notre windows 8!!
Premièrement verifions la table NRPT. Netsh na sh eff

Maintenant testons d’accéder a un partage réseau.

OK ca marche!

Bon, en theorie, si je ping dc.labda.local, je resous l'ip isatap! Vérifions

C'est quoi cette ip? C'est pas une isatap... Ca finit par l'ipv4 du contrôleur de domaine... Bon ben ca doit être une ip DNS64... Et donc ça veut dire qu'il fait du NAT64...
Vérifions ce qu'il se passe avec un trace réseau. (Wireshark veut pas s'installer sur Server 2012, on va donc utiliser network Monitor)
On voit bien que la requete relayée par le serveur directaccess ne demande qu'un record IPv4.

De plus, on voit egalemement qu'un ping envoyé par un client directaccess (donc en IPv6) , est relaye par le serveur directaccess en IPv4. Nat64 en action!

Ca me pose un leger probleme. Microsoft a toujours dit que Nat64 et DNS64 étaient des processus gourmands... Cela me parait étrange que maintenant le Nat64 soit pas default s'il n'y a pas d'ipv6 sur l'interface interne du serveur....

Mais moi je suis tetu et je veux mes résolutions en ISATAP! Comment faire... tout simplement ne plus utiliser le seveur UAG en tant que DNS dans la table NRPT, donc plus de Nat64 et de DNS64...

Et maintenant, la table NRPT ressemble a ca :

On voit que 192.168.11.1 est devenu fd06:5990:21b1:7777::c0a8:b01 : c'est l'adresse DNS64
Bon, on va pinger dc.labda.local.

Et voila, c'est bien l'ip Isatap!

Autre point interessant. Si je fais un ipconfig /all, je vois que je suis connecte en IPHTTPS. Ce n'est pas normal, cela devrait etre en Teredo, vu que Teredo est préféré (sous UAG/2008) a IPHTTPS

Regardons l’état de l'interface teredo.

Étrange elle est dans sa configuration par défaut. Si on reprend notre get-daserver du début, on remarque que TeredoState : Disabled. Essayons de l'activer.
set-daserver -TeredoState enabled

On update nos GPO, et après : miracle teredo is working.

Par contre directAccess ne marche plus trop, faut que je creuse pourquoi...

EDIT : IP-HTTPS est desormais prefere car server 2012 peut utiliser une null encryption. Ce qui veut dire que le flux n'est cryptee qu'une seule fois (par ipsec). Cela ameliore donc nettement les performances de IPHTTPS. Bon a savoir!

Et voila c'est fini pour aujourd'hui. Prochaine étape, NLB!

Tweeter Suivre @sbe35094