Invitation aux Journées Portes Ouvertes de Microsoft Maroc



One step for man


One giant leap for mankind


The msExchInternalTLSCert attribute


Have you ever wondered where Exchange looks to find the certificate for inbound and outbound TLS for the SMTP service?

Well, it's actually documented in detail here and here. If you read the TechNet articles you can come to the conclusion that Enable-ExchangeCertificate for the SMTP service will stamp the msExchServerInternalTLSCert attribute on the transport server object in AD with the certificate thumbprint you specify in the command.

But what happens if you run Enable-ExchangeCertificate and choose to not overwrite the certificate for SMTP.

If you check the certificate list now, you'll notice two certificates, both are valid, and apparently both are assigned to SMTP. So which one will Exchange use for X-AnonymousTLS, because I didn't overwrite the current certificate.

Luckily we know from the TechNet articles that Exchange queries AD to match the thumbprint in the msExchInternalTLSCert attribute during the certificate selection process for X-AnonymousTLS. So, how can I quickly check which one of the certificates is actually being used?

 Import-Module activedirectory  $transportServers = Get-TransportServer|select -ExpandProperty Name  $forest = [System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain().Forest.ToString();  $searchbase = "CN=Configuration,DC="+($forest).replace('.',',DC=')  $results = @()    foreach($transportServer in $transportServers)  {       $CertThumbPrint = Get-ADObject -Filter "ObjectClass -eq 'msExchExchangeServer' -and name -eq '$transportServer'" -properties * -SearchBase $searchbase -server $forest|%{[Security.Cryptography.X509Certificates.X509Certificate2]$_.msExchServerInternalTLSCert}|select -expandproperty thumbprint    $obj = New-Object PSObject -Property @{"TransportServer"=$transportServer;"SMTPCertificate"=$CertThumbPrint}    $results+=$obj  }  $results|select TransportServer,SMTPCertificate

Michael Hall
Service Engineer
Office 365


Why the correct load balancing persistence is so important in Exchange Server 2010?


I'm sure this has been covered by many other sources on the internet, but I thought I'd put down my thoughts on the matter as many people still don't understand why the correct load balancing configuration is important.

I've been involved in a number of Exchange Server 2010 deployments during my last couple of months and most of the deployments were upgrades on hosted platforms from Exchange Server 2007 to Exchange Server 2010.

What I noticed in these Exchange Server 2007 deployments were that load on Client Access Servers (CAS) were somewhat skew. And this makes sense, because the load balancing was configured for Source IP persistence.

What does this mean in a hosting environment?

Well, firstly all clients are connecting to the messaging platform over the Internet behind a NATed IP.

You could potentially have a tenant with a 1000 users behind a single IP. The hosting environment won't have any visibility to the internal IP's and thus only see the source IP being the external interface on the tenants firewall. If source IP persistence is configured on the load balancer it will basically send all traffic for that source IP to one CAS server (give or take a few connections).

Something like this:

This concept is also the same for corporate enterprises running their own on-premise Exchange Server 2010 solution. The reason I'm saying it effects corporate deployments as well is that most mobile phones connect to the internet via NATed IP's behind the carrier firewall. So mobile phone ActiveSync connections from a specific carrier will be sent to one CAS box.

So how do we fix this? Configure the correct persistence.

First we check that the load balancer is on the Exchange qualification program for load balancers. The main reason for this is that we'll know if it was tested and reviewed by Microsoft and the partner for the type of load balancing we want to do. It's also a very good resource to find deployment guides on the specific load balancer.

When I deployed the Exchange Server 2010 solution we incorporated cookie based persistence on the load balancers for the customer. We did not configure SSL Offloading. To keep things simple we configured an SSL Bridge whereby the load balancer will decrypt the packets, read the cookies then re-encrypt the packets before sending it to the CAS boxes.

Implementing cookie based persistence can be tricky. but it can also be very easy, it really depends on the person responsible for the load balancer, which usually falls into the networking or security team. Personally, I put in a lot of effort to understand how the specific vendors' load balancer works. I find that this makes discussions with the network engineer easier. If the engineer understands the concepts on the Exchange side and the impact then it makes life very easy to implement the correct solution.

What protocols require persistence?

I've detailed the recommendations on the specific services below that will help you determine the correct persistence method for optimal load balancing.

  • Exchange Address Book service within the Intranet

    • This service provides directory access for clients. Not using affinity results in a significantly higher level of communication between the client and the Client Access servers.
    • Recommended persistence type: Source IP.

  • Outlook MAPI connections within the Intranet

    • Outlook clients on the Intranet assume that all RPC connections are made to the same server. Outlook uses multiple sessions per user and assumes that all sessions connect to the same server.
    • Recommended persistence type: Source IP.

  • Outlook Web App and Exchange Control Panel

    • These services must have affinity to the same Client Access server.
    • Recommended persistence type for Outlook Web App: OutlookSession cookie.
    • Recommended persistence type for Exchange Control Panel: msExchEcpCanary cookie.

  • Exchange Web Services (Load balancer generated cookie or SSL Session ID)

    • Microsoft does not support the use of Exchange Web Services without affinity.
    • Recommended persistence type: Load balancer generated cookie or SSL Session ID.

  • Outlook Anywhere – (RPC over HTTPs)

    • Recommended persistence type: User-agentcookie or OutlookSession (Outlook 2010 only) cookie.

  • Exchange ActiveSync – (HTTPs)

    • Recommended persistence type: Authorization header cookie

  • Offline Address Book – HTTPs (Transactional connection)

    • Recommended persistence type: SSL Session ID or Source IP

  • Autodiscover service – HTTPs ((Transactional connection)

    • No affinity is required for Autodiscover.

Hopefully, this helps some administrators/implementer's understand the concept better. As I mentioned earlier, I personally do a lot of research during my planning and deployment phases to help ease configuration on firewalls, load balancers and such.

Some references that you will find very valuable:

Until next time…..happy load balancing :-)

Michael


Windows 8, Hyper-V, Vyatta Lab and Wireless adapter saga


I had some time recently to fine tune my lab environment on my laptop and thought I would share my experiences.

Microsoft was kind enough to provide me with a drive upgrade a couple of months back – a 250 GB Solid State Drive – Thank you Microsoft!!

I also took the liberty of purchasing an additional 128 GB Solid State to act as my OS drive.

So my setup is as follows:

  • Lenovo W510 with 16GB RAM
  • OS Drive: 128GB SSD
  • Data Drive: 250GB SSD

I didn't want to utilize my precious SSD space for ISO images so I still have my 1TB SATA external HDD that contain my bulky ISO's that I use during my deployments.

My goal in my lab was very simple –

  • Create a site resilient Exchange Server 2010 solution with a hardware load balancer.
  • Configure a Hybrid deployment to Office 365.
  • Use as little storage as possible.

First order of business was creating the virtual switches.

At this stage I didn't want to create a situation where my VM's might affect a customer production network where I might be working – and yes this has happened to me once before…many many moons ago…I won't go into detail but I started providing DHCP IP's to machines…hehehe, sounds funny now!

Anyway, the vSwitch configuration on Hyper-v is configured as follow:

External vSwitches:

  • LAN pNic – vSwitch-LAN-Access
  • WLAN pNic – vSwitch-WLAN-Access
  • Planned Subnet: 192.168.41.0/24

Internal vSwitch:

  • Internal only – vSwitch-Internal-Access
  • Planned Subnets:
    • 192.168.42.0/24
    • 192.168.43.0/24

As seen above I planned on having two subnets internally within the Hyper-v environment and then my external home subnet for Internet access. I'll then configure routing (I'll cover this later) between these subnets to allow internet access and RDP from my home network.

Next step was to create my template VM.

  1. Deploy a VM called Template.
  2. Configure this VM with my base prerequisites – RDP, Hotfixes, whatever I wanted in the base.
  3. Sysprep this VM – OOBE with Generalize check box and Shutdown option.

This VM's vhd will be used as the parent disk for all my other VM's in the lab environment by using the Differencing disk feature.

Start deploying my VM's as follow:

Save the following as PowerShell script and run in PowerShell window (Run as Administrator and change paths where required) :

 Import-module Hyper-v  $LABVMs =@('DC01';'DC02';'EX01';'EX02';'EX03';'ADFS';'SQL';'LYNC')      Foreach ($LABVM in $LABVMs)      {      New-VHD -ParentPath "C:\LAB\TEMPLATE\Template.vhd" -Differencing -Path "D:\LAB\$LABVM\$LABVM.vhd"    New-VM -VHDPath "D:\LAB\$LABVM\$LABVM.vhd" -VMName $LABVM -MemoryStartupBytes 1024MB -SwitchName vSwitch-Internal-Access   Start-VM -Name $LABVM      }

While the above executes go and download Vyatta Virtual Router here: https://www.vyatta.com/download/trial_software/VyattaCore

The reason I'm using Vyatta is that it has a very small footprint – less than 800mb. 

Vyatta will act as my router between the subnets so it will require three interfaces:

  1. vNIC1 – Associated to vSwitch-LAN-Access
  2. vNIC2 – Associated to vSwitch-Internal-Access
  3. vNIC3 – Associated to vSwitch-Internal-Access

IMPORTANT: There are currently some issues with Windows 8 Hyper-v and Wireless LAN adapters – specifically routing via Wireless LAN adapters. If you assign the Vyatta interface to your Wireless LAN adapter the routing will NOT work. On top of that if you use the Wireless adapter and assign a static route on your Windows 8 machine to other subnets you will encounter an OS crash – I've replicated this behaviour a couple of times. Use the physical LAN adapter or you'll be troubleshooting for hours. I've communicated this to the Hyper-v dev team as well – I'll update this blog if I get a fix for this issue.

So to continue….

Create the Vyatta VM with the ISO downloaded and login with vyatta/vyatta.

My config is very simple no weird NATs or anything like that – just plain routing. I assign IP's to my interfaces created.

#configure

#set interfaces ethernet eth0 address 192.168.41.254/24
#set interfaces ethernet eth2 address 192.168.42.254/24
#set interfaces ethernet eth3 address 192.168.43.254/24

#set system gateway-address 192.168.41.1

#set service ssh port 22

#save

#commit

As this is lab environment I didn't bother with any other config as I didn't require it.

Config looks like this:

interfaces {

     ethernet eth0 {

         address 192.168.41.254/24

         duplex auto

         hw-id 00:15:5d:29:04:3f

         smp_affinity auto

         speed auto

     }

     ethernet eth1 {

         address 192.168.42.254/24

         duplex auto

         hw-id 00:15:5d:29:04:3e

         smp_affinity auto

         speed auto

     }

     ethernet eth2 {

         address 192.168.43.254/24

         duplex auto

         hw-id 00:15:5d:29:04:40

         smp_affinity auto

         speed auto

     }

     loopback lo {

     }

 }

 service {

     ssh {

         port 22

     }

 }

Next step was to add some static routes on my home router:

  • Added a route to 192.168.42.0/24 using gateway IP 192.168.41.254
  • Added a route to 192.168.43.0/24 using gateway IP 192.168.41.254

Next was configuring all my VM's with static IP's and using gateway IP of 192.168.42.254 or 192.168.43.254 depending on which subnet I want the VM in.

Test network – life is good:

 

And then you can create and configure your ADDS, Exchange Server 2010, SQL, Lync etc. as per usual. If you configure DHCP on your internal subnets it won't breach the physical network, but you still have access to those VM's via RDP from you physical network at home.

I can get about 12 VM's running on my Laptop with this parent/child configuration on the VHD's while the SSD drives are still idling along nicely and the laptop is still as responsive as always. My bottleneck at this stage is RAM. 

Hope this helps anyone. I read alot of people struggling with Vyatta, but it's really that simple.

Until next time…..

Michael


15 Minutes pour comprendre le cloud computing


enfin l'informatique en nuage… en français dans le texte

Voici une vidéo très intéressante (17 minutes), permettant de comprendre ce qu'est le cloud computing.

Get Microsoft Silverlight

Visionner cette vidéo au format WMV

DCSIMG

Il est notamment intéressant de comprendre l'origine du Cloud Computing : les grands acteurs, comme Amazon, ont cherché à rentabiliser les datacenters bien souvent sous-utilisés… d'où l'idée de proposer ces machines sous-forme de service…

Cette vidéo explique également,les différents types de service :

  • Infastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a Service (SaaS)

et les responsabilités qui en découlent, ainsi que des scénarios d'utiisation, et la proposition de Microsoft pour ses clients : laisser le choix pour s'adapter aux spécificités de chaque entreprise.

Je vous recommande également la lecture de l'article de Stanislas Quastana : Cloud et Sécurité : Mythes et Réalités qui reprend une bonne introduction au cloud computing.

Pour ceux qui souhaitent avoir une idée de ce qu'est Windows Azure, une vidéo est disponible ici


Bien comprendre le stockage partagé dans un cluster de serveurs Hyper-V


Pour permettre les migrations à chaud de machines virtuelles, le cluster de serveurs s'appuie sur un stockage spécifique : le Clustered Shared Volume (CSV)

Je vous propose une vidéo qui permet de bien comprendre comment utiliser ce type de stockage et d'en découvrir les avantages, dans un contexte de haute disponibilité. Ce webcast va donc présenter :

  • un rappel sur le clustering traditionnel (Failover clustering)
  • les changements du modèle dit "Share nothing" utilisé dans les clusters
  • les fonctionnalités intéressantes des Clustered Shared Volumes (CSV), notamment la tolérance aux pannes de réseau

Dans un deuxième temps, on passe à des cas pratiques :

  • les exigences en matière d'infrastructure réseau (pour un stockage iSCSI), et disques
  • les recommandations pour déployer plusieurs machines virtuelles sur un (ou plusieurs) CSV(s), en fonction des contraintes (IO, principalement)
  • et divers recommandations / considérations concernant :
  • les performances,
  • les backups/restauration,
  • les déploiements multi-sites.

La vidéo (un peu longue : 45 minutes) est disponible ici : https://www.microsoft.com/events/podcasts/default.aspx?pageId=x6330&source=Microsoft-Podcasts&WT.rss_ev=a

A vos serveurs et stockages !


Comment mettre en place un cluster de Serveurs Hyper-V et permettre les Live Migration


Depuis l'arrivée de Windows Server 2008 R2, il est possible de créer des clusters de serveurs Hyper-V. Les machines virtuelles qui sont sur ce type de cluster vont pouvoir être déplacées, d'un nœud à l'autre, sans interruption

Dans cette vidéo, on apprend comment mettre en place le cluster de serveurs Hyper-V. Cela commence par :

  • la configuration du stockage (en utilisant un stockage iSCSI)
  • la configuration du réseau : physique (les cartes des machines physiques) et et virtuel (configuration des switchs virtuels dans Hyper-V)
  • Ajout des fonctions de clustering (et d'administration du cluster)

puis on réalise la création du cluster en lui-même.

Une fois le cluster configuré, on découvre comment ajouter des machines virtuelles (existantes) à ce cluster et comment on peut migrer (Live Migration) une machine virtuelle d'un nœud à l'autre.

L'ensemble de la vidéo est disponible ici : https://www.microsoft.com/events/podcasts/default.aspx?pageId=x6923&source=Microsoft-Podcasts&WT.rss_ev=a

A vos serveurs ! bon tests !