Azure : Désactiver AD Connect Sync

Dans mon laboratoire Azure, j’avais configuré AD Connect afin de synchroniser mes utilisateurs entre Windows Active directory et Azure Active directory.

J’ai éventuellement supprimé mon contrôleur de domaine sans avoir préalablement désactivé la synchronisation. Par conséquent, j'ai commencé à recevoir des notifications comme quoi la synchronisation ne fonctionnait plus.

Comment désactiver la synchronisation si je n’ai plus accès à l’outil AD Connect ?

Tout d’abord, vous devez télécharger et installer Azure Active Directory Module for Windows PowerShell. 

Ensuite, vous devez vous connecter à Azure

$msolcred = get-credential

connect-msolservice -credential $msolcred

Note: Vous devez utiliser un compte cloud (exemple: admin@mtessier.onmicrosoft.com). Vous ne pouvez pas utiliser un compte LiveID ou un compte qui provient de Windows Active Directory.

Ensuite, désactiver la synchronisation:

Set-MsolDirSyncEnabled –EnableDirSync $false

Vous pouvez vérifier le statut de la synchronisation

(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

Le processus peut prendre jusqu'à 72 heures tout dépendant du nombre d'objets.

Azure : Directory has one or more subscription to Microsoft Online Services

Si vous êtes nouveau avec la plateforme Azure, il se peut que vous soyez un peu confus avec le composant Azure Active Directory. Tout simplement parce que Azure Active Directory est lié à votre compte et un abonnement est lié à Azure Active Directory. La confusion vient du fait que vous pouvez lié un abonnement avec Azure Active Directory qui n'est pas lié avec votre compte.  Confus ?

Moi aussi et c’est pour cette raison que j’ai décidé d’utiliser un seul compte et un seul Azure Active Directory pour gérer tous mes abonnements. Pour ce faire, j’ai créé un nouveau Azure Active Directory que j’ai nommé mtessier.

Ensuite, j’ai associé tous mes abonnements avec mon nouveau directory. Tout est parfait.

Mais, lorsque j’ai voulu supprimer mon vieux directory nommé « Default Directory », le message d’erreur suivant s’affichait :

Directory has one or more subscription to Microsoft Online Services

Effectivement, j’ai effectué des tests dans le passé avec Office 365, mais je ne l’utilise plus et impossible de supprimer l’API.

Pour me débarrasser de mon Default Directory, j’ai décidé d’en faire un directory orphelin. Pour ce faire, j’ai créé un utilisateur local deleteme avec le rôle Global Admin.

Lors de la création de l’utilisateur, un mot de passe temporaire est assigné. Je me suis connecté sur le portail avec l’utilisateur deleteme et son mot de passe temporaire. Azure m’a demandé de changer le mot de passe, ce que j’ai fait.

Ensuite, j'ai installé Azure AD PowerShell sur ma machine.

Manage Azure AD using Windows PowerShell

Ensuite, j'ai utilisé le compte deleteme pour me connecter à Azure Active Directory en utilisant les commandes suivant:

$msolcred = get-credential

connect-msolservice -credential $msolcred

Ensuite, j'ai vérifié tous les utilisateurs présents dans mon répertoire:

Get-MsolUser | ft UserPrincipalName

Je m'assure d'avoir seulement deux utilisateurs: le mien et deleteme. 

Ensuite, il suffit de supprimer mon utilisateur en utilisant la commande suivante:

Remove-MsolUser -UserPrincipalName username

C'est fait! le répertoire Azure Active Directory n'est plus associer à mon compte et sera automatiquement supprimé par Microsoft dans 90 jours.

Azure : Tests de performance des disques (2ème Partie)

Il existe plusieurs utilitaires pour simuler une charge de travail sur les disques durs d'un serveur. Les plus connus sont Crystal Mark, IOmeter, SQLIO et mon préféré Diskspd. 

Je ne veux pas écrire un article afin d'expliquer comment utiliser l'outil puisqu'il en existe suffisamment sur le web. Je recommande Getting Started with Diskspd et Using Microsoft DiskSpd to Test Your Storage Subsystem.

Avant de commencer mon test, je veux expliquer mon but. En fait, j'ai deux objectifs. Le premier est de savoir si je peux obtenir 20 000 IOPS comme promis. Cependant, le nombre d'IOPs est non pertinent lorsqu'il n'est pas associé à un délai de latence. C'est pour cette raison que mon deuxième objectif est de savoir combien d'IOPs je peux obtenir avec un délai de latence très faible dans un contexte SQL.

Commençons les tests. Voici la commande que j'ai utilisée:

diskspd.exe -b64K -d60 -o32 -t8 -h -r -L -w0 -c20g E:\Temp\iotest.dat > C:\diskspd\iotest.txt

-b64K: Grosseur des blocs. J'ai formaté mon disque avec des blocs de 64K. SQL lit les données en bloc de 64k. Donc, je vais faire mon test avec des blocs de 64K :)

-d60: Durée du test, 60 secondes est suffisant.

-o32: Queue Lenght. SQL performe plusieurs petites opérations rapidement. Un Queue Lenght entre 8 et 32 est ce qui se rapproche le plus de SQL.

-t8: Nombre de thread. Je commence toujours avec un thread par coeur.

-h: Désactive la cache logicielle et matérielle en écriture

-r: Random. Oui pour le disque de données et tempdb. Non pour le disque de log.

-w0: Read/Write. 0% write, 100% read dans ce cas-ci. Ensuite je vais faire un test 25% write, 75% read. C'est selon vos besoins.

-c20g: Grosseur du fichier pour effectuer le test. 20GB est normalement suffisant. 

Résultat de mon premier test:

Wow, je suis très loin des 20 000 IOPs ! En plus, le délai de latence en moyenne de 62ms ! 

Perfmon me donne exactement le même résultat en terme de latence:

Je dois avouer que ma combinaison de 8 threads qui lit des blocs de 64K avec une queue lenght de 32 est une charge importante. En revanche, j'effectue seulement un test de lecture!

J'ai fait plusieurs tests avec différente combinaison. J'aurais aimé faire un beau tableau avec des barres et des couleurs, mais pour aujourd’hui ce sera seulement une image de ma feuille Excel :)

La première chose dont je constate est que les performances sont bien meilleures avec les blocs de 8K. Ce qui est bien normal.

Ensuite, les résultats sont très similaires entre les tests de lecture et d'écriture. C'est surprenant.

Ensuite, on remarque que le système atteint un maximum de 4082 IOPs lorsqu'il lit ou écrit des blocs de 64K. J'en retiens que si vous formatez vos disques avec des blocs de 64K, vous allez obtenir environ 25% des IOPs versus 8K. 

Le nombre de thread affecte beaucoup le délai de latence. La question est de savoir combien de thread SQL accèdent les disques simultanément. 

Le délai de latence n'est pas exceptionnel lorsque SQL lit ou écrit des blocs de 64K. Évidemment, plus la charge est élevée, plus le délai de latence augmente.

Conclusion:

• Oui, je suis capable d'atteindre plus de 20 000 IOPs !

• Selon mes tests, j'obtiens 5000 IOPs avec 8 millisecondes de délais si mon serveur SQL exécute un seul thread. Ensuite, les performances se dégradent.

Okay, c'est bien amusant tout cela, mais qu’est-ce qu’on en fait avec Dynamics AX ?

Azure : Performance des disques (1ère Partie)

Initialement, je voulais écrire un article sur la performance des disques durs pour un serveur SQL dans un environnement Dynamics AX. Afin de faire mes tests, j'ai créé une machine virtuelle dans le nuage Azure. C'est à ce moment que je me suis dit qu'il serait intéressant de documenter les étapes de la création de la machine et de la configuration des disques. Donc, voici la première partie d'une série d'articles sur la performance des disques durs.

La plateforme cloud de Microsoft évolue à une vitesse phénoménale. En avril 2015, Microsoft a lancé le Stokage Premium dans plusieurs centres de données Azure. La différence entre le Standard et Premium est bien expliquée dans ce billet: Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads

Note: Lors de la création de cette machine, je n'ai pas respecté toutes les meilleures pratiques en matière de configuration des disques pour un serveur SQL. J'ai dû configurer un disque virtuel pour les données, un disque virtuel pour tempdb et un autre pour les logs. Read Only Host Caching doit être activé seulement pour les disques avec les bases de données et tempdb, mais pas pour les disques qui contiennent les logs. Plus d'information ici: Azure Premium Storage provides highest performance for SQL Server in Azure VM

Tout d’abord, j’ai créé un compte de stockage du type premium:

Ensuite, j’ai créé une machine virtuelle. J’ai sélectionné le dimensionnement de ma machine en portant une attention particulière aux limitations de la machine en matière de performance de disque.

J'ai sélectionné mon compte de stockage de type Premium:

La création de la machine prend quelques minutes et ensuite ma machine devient disponible:

Ensuite, j’ai attaché 4 disques de données d’une grosseur de 1023 GB chacun avec Read-Only Host Caching activé.

Avec Premium, la grosseur du disque a un impact majeur sur la performance, comme indiqué dans l'article suivant: Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads

Ensuite, je me suis connecté à ma machine virtuelle et j’ai ouvert File and Storage Services. Je peux y voir mes 4 disques sous la section disque:

Afin d’obtenir le maximum d'IOPs, je vais créer un storage pool en utilisant PowerShell:

New-StoragePool –FriendlyName StoragePool1 –StorageSubsystemFriendlyName "Storage Spaces*" –PhysicalDisks (Get-PhysicalDisk –CanPool $True)

Sous la section Storage pool, je peux y voir mon Storage Pool avec mes 4 disques. Toutefois, je n'ai toujours pas de disque virtuel:

Je crée un disque virtuel en utilisant une commande PowerShell 

• Le paramètre NumberOfColums doit être égal au nombre de disques.
• Le paramètre Interleave doit être configuré à 256 KB.

Ces recommandations proviennent du document Performance Guidance for SQL Server in Microsoft Azure Virtual Machines.

$disks = Get-StoragePool –FriendlyName StoragePool1 -IsPrimordial $false | Get-PhysicalDisk

New-VirtualDisk -StoragePoolFriendlyName StoragePool1 –FriendlyName VirtualDisk1 -ResiliencySettingName Simple –NumberOfColumns $disks.Count –UseMaximumSize –Interleave 256KB

Je peux voir que mon disque virtuel a été créé:

Finalement, j'ai créé un volume formaté avec une allocation de 64k par cluster

Get-VirtualDisk –FriendlyName VirtualDisk1 | Get-Disk | Initialize-Disk –Passthru | New-Partition –AssignDriveLetter –UseMaximumSize | Format-Volume –AllocationUnitSize 64KB

Je peux vérifier que mon disque a été formaté avec des blocs de 64KB:

wmic volume GET Caption, Blocksize

Ainsi, j'ai maintenant un volume de 4 GB qui contient 4 disques. Chaque disque donne 5000 IOPs, donc j'ai techniquement 20 000 IOPs pour l'ensemble de mon volume !

Ai-je vraiment 20 000 IOPs ? Qu'est-ce qui en est de la latence ? Allons tester !

Azure : Active Directory Sync Services

Aujourd’hui, je voulais faire une petite démonstration de comment synchroniser les comptes utilisateurs entre Windows Active Directory et Azure Active Directory.

Azure Active Directory est une façon facile de gérer l’accès aux applications situé dans le Cloud, mais malheureusement l’utilisateur doit gérer deux comptes: un compte local et un compte dans le Cloud (*.onmicrosoft.com).  L’outil Microsoft Azure Active Directory Sync Services vous permet de synchroniser les comptes et les mots de passe de vos utilisateurs situés dans votre Active Directory local avec Azure Active Directory.

Afin d'effectuer cette démonstration, j’ai utilisé un serveur Windows 2012 R2 avec Active Directory installé, l’outil Microsoft Azure Active Directory Sync Services et Azure Active Directory Basic dont je gère via mon compte Azure. 

Pour commencer, il faut créer un compte service dans Azure Active Directory.

Ouvrez la console de gestion Azure : https://manage.windowsazure.com/.

Ensuite, cliquer sur Active Directory située dans le menu de gauche et cliquer sur votre annuaire. Sous l'onglet Directory Integration, sélectionner Activated et sauvegarder votre modification

Ensuite, cliquer sur Users --> Add User et créer un nouvel utilisateur.

L'utilisateur doit avoir le rôle Global Administrator.

À la fin de la création, vous allez obtenir un mot de passe temporaire. Déconnecter votre session Azure et rouvrez une session en utilisant le nouveau compte. Un changement de mot de passe vous sera demandé.

Ensuite,  télécharger Microsoft Azure Active Directory Sync Services : http://www.microsoft.com/en-us/download/details.aspx?id=44225

Installer le service sur un contrôleur de domaine et lancer Directory Sync Tool

Taper le nom d’utilisateur et le mot de passe de votre compte de synchronisation et cliquer sur Next

Taper les informations afin de vous connecter à la forêt et cliquer sur Add Forest.

Dans cet exemple, nous allons garder les options par défaut.

L'option Password write-back permet aux utilisateur de modifier leur password dans le cloud et celui-ci est synchronisé avec Windows Active Directory. Cette option nécessite Active Directory Premium. J'ai ajouté un lien à la toute fin afin d'avoir plus d'information.

Patienter le temps de la configuration.

Cliquer sur Finish afin d'initialiser la synchronisation.

Vous pouvez maintenant y trouver vos utilisateurs Windows Active Directory dans Azure Active Directory.

Plus d'information sur Password write back

http://msdn.microsoft.com/en-us/library/azure/dn688249.aspx#BKMK_1

Azure AD Premium VS Azure AD Basic

http://msdn.microsoft.com/en-us/library/azure/dn532272.aspx