Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Démarrer une instance MSSQL 2017 sous linux sur un conteneur Docker installé sous Windows

par | 1 Fév 2018 |

1. Objectif

L’objectif de ce blog est de démontrer comment lancer une instance MSSQL Server 2017 sous linux sur un conteneur Docker installé sous windows.

2. Installation de Docker

Télécharger la version de docker pour votre système d’exploitation depuis ce lien [https://docs.docker.com/install/#supported-platforms] . J’utilise la version de docker pour un windows 10 comme indiqué ci-dessous:

Avant d’installer Docker sous windows, assurez vous que hyper-v est installé. Docker utilisera hyper V pour monter une VM linux automatiquement pour faire tourner l’image contenant MSSQL server 2017 dans une conteneur Linux sous Windows.

Une fois l’installation terminée , lancer Docker depuis le bureau et l’icon ci-dessous apparaitra: 

Faire un clique droit puis « switch to linux containers » car l’image que nous allons faire tourner est une image linux:

On constatera que Docker a créé automatiquement une VM sous hyper-v, qui se nomme MobyLinux:

3. Téléchargement d’une image

Il existe une multitude d’image sur le portail https://hub.docker.com/ . Nous allons prendre l’image microsoft/mssql-server-linux [https://hub.docker.com/r/microsoft/mssql-server-linux/]

Pour télécharger l’image depuis powershell , tapper la commande suivante:

docker pull microsoft/mssql-server-linux

Pour afficher une image, tapper la commande suivante: 

docker image ls

On voit bien notre image microsoft/mssql-server-linux est présente dans la repository.

4. Démarrage de l’instance MSSQL Server 2017

Pour démarrer une instance MSSQL Server 2017 depuis l’image, tapper la commande suivante:

docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=yourStrong(!)Password' -p 1433:1433 -d microsoft/mssql-server-linux:2017-latest

Changer le mot de passe SA_PASSWORD et le port d’écoute au besoin. Une fois la commande passée, vérifier que l’image s’est bien créé et est démarrée avec la commande suivante:

docker ps

On voit bien que notre image a bien été créée et l’état est bien « up ».

5. Tests

 

Lancer SQL Server Management Studio, puis entrer les informations suivants:

On arrive bien a se connecter à l’instance sql :

Tapper la commande suivante pour vérifier les informations du serveur sql:

select @@version

>Microsoft SQL Server 2017 (RTM-CU3-GDR) (KB4052987) - 14.0.3015.40 (X64)   Dec 22 2017 16:13:22   Copyright (C) 2017 Microsoft Corporation  Developer Edition (64-bit) on Linux (Ubuntu 16.04.3 LTS)

Nous voyons bien qu’en étant sur localhost (windows), nous avons réussi à lancer une instance MSSQL Server 2017 installée sur un serveur Linux dans un conteneur Docker.

Stratégies de groupe : Analyse du fichier gpsvc.log (Partie 2/3)

par | 30 Jan 2018 | , ,

Bonjour,

Après un premier article sur l’activation de ce fichier, voici un second sur l’analyse de celui-ci.

Vous pouvez le trouver dans le dossier C:\Windows\debug\usermode\gpsvc.log

Threads

Sur les machines avec des architectures multi-coeurs, il peut y avoir plusieurs threads qui s’exécutent au même moment (un thread pour les paramètres utilisateurs et un thread pour les paramètres machine.). Il peut être utile de savoir les différencier dans le fichier de log.

Pour se faire, il suffit d’analyser les valeurs rapportées pour GPSVC :

GPSVC(78d.666) 12:41:45:477 Caller requesting for user notification/lock is from session 0

On remarque que celles-ci sont composées de deux parties :

  • 78d : Correspond au PID (Process ID) (en héxadécimal)
  • 666 : Correspond au TID (Thread ID)

Début du traitement des stratégies

Le traitement des stratégies débute toujours avec les paramètres machine.

Il peut être repéré par l’enregistrement suivant :

GPSVC(2dc.18c) 11:40:08:707 bMachine = 1
GPSVC(2dc.18c) 11:40:08:707 Setting GPsession state = 1

Connectivité réseau

Immédiatement après le début du traitement des stratégies machines, une vérification de la connectivité réseau est faite :

GPSVC(2dc.18c) 11:40:08:707 bMachine = 1
GPSVC(2dc.18c) 11:40:08:707 Setting GPsession state = 1
GPSVC(2dc.520) 11:40:08:707 Waiting for connectivity before applying policies

Souvent, le client Stratégies de groupe démarre avant que la connectivité réseau soit effective, ce qui génère le message suivant :

GPSVC(2dc.18c) 11:40:08:806 There is no connectivity. Waiting for connectivity again …

Mais quelques secondes plus tard, la connectivité est établie :

GPSVC(2dc.18c) 11:42:09:106 There is connectivity
GPSVC(2dc.18c) 11:42:09:106 Wait For Connectivity : Succeded

GPSVC(2dc.18c) 11:42:09:106 We have network connectivity… proceeding to apply policy.

En cas de non connectivité (30 secondes de timeout par défaut), on trouvera toujours l’erreur suivante :

GPSVC(2dc.520) 11:45:10:033 Application complete with bConnectivityFailure = 1.

Note : Cela peut être une erreur de connectivité mais pas uniquement réseau, cela peut concerner du LDAP par exemple

Estimation de la bande passante

Avant de traiter les stratégies de groupe, une estimation de la bande passante est faite.

Celle-ci est calculée en se connectant d’abord à un contrôleur de domaine afin d’obtenir une liste de ceux-ci, puis en évaluant la vitesse de la connexion entre le poste et un contrôleur de domaine. Le calcul de la bande passante est effectuée par le NLA (Network Location Awarnesss).

Le début de l’estimation se présente comme ceci :

GPSVC(2cc.c28) 15:56:04:821 GetDomainControllerConnectionInfo: Enabling bandwidth estimate.
GPSVC(2cc.c28) 15:56:05:134 Started bandwidth estimation successfully

La fin de l’estimation se présente comme ceci :

GPSVC(2cc.c28) 15:56:05:510 IsSlowLink: Bandwidth Threshold (WINLOGON) = 500.
GPSVC(2cc.c28) 15:56:05:510 IsSlowLink: Bandwidth Threshold (SYSTEM) = 500.
GPSVC(2cc.c28) 15:56:05:510 IsSlowLink: WWAN Policy (SYSTEM) = 0.
GPSVC(2cc.c28) 15:56:05:510 IsSlowLink: Current Bandwidth >= Bandwidth Threshold.
 
On remarque que le seuil est de 500 kbps par défaut.

Ordre de traitement des stratégies

Les stratégies vont être traitées de manière hiérarchique dans l’ordre suivant :
1) Ordinateur Local
2) Sites AD
3) Domaines AD
4) OU Parentes
5) OU Enfants
 
Avec toutefois quelques exceptions :
  • Le lien d’un GPO peut être appliqué (enforced) ou/et désactivé
  • Une stratégie peut avoir des paramètres ordinateurs/utilisateurs désactivés
  • Le blocage de l’héritage au niveau de l’OU est activé
  • Le mode bouclage est activé
 
La règle à retenir est la suivante : C’est le dernier paramètre lu qui gagne
 
Exemple : Vous avez deux GPOs qui définissent une page de démarrage pour Internet Explorer.
Une est à la racine du domaine, l’autre dans une OU enfant.
Dans le fichier de log, le paramètre de la GPO étant à la racine du domaine sera traité en premier et le paramètre de la GPO étant dans une OU enfant sera traité en deuxième.
Le dernier paramètre lu étant celui qui est appliqué, ce sera donc le paramètre de la GPO étant située dans l’OU enfant qui sera appliqué.
 
Voici comment cela se présente dans le fichier de log :

Lecture des stratégies :

GPSVC(2dc.22b0) 17:16:01:922 SearchDSObject: Searching <OU=OU_Enfant,OU=OU_Parent,DC=contoso,DC=local>
GPSVC(2dc.22b0) 17:16:01:922 SearchDSObject: Found GPO(s): <[LDAP://cn={D110C8FA-777B-4F95-BB65-A333A8B0091D},cn=policies,cn=system,DC=contoso,DC=local;0]…>
GPSVC(2dc.22b0) 17:16:01:922 ProcessGPO: ==============================
 
Il existe trois valeurs numériques à la fin de la requête LDAP pour chaque lien :
  • 0 : Paramètre par défaut
  • 1 : Le lien est désactivé
  • 2 : Le lien est appliqué (enforced)
 Une fois que toutes les GPO sont lues, celles-ci sont traitées.

Traitement des stratégies :

GPSVC(2dc.22b0) 17:16:02:109 ProcessGPO: Searching <cn={EC37F666-21C0-459E-88DF-3AD63AE600A1},cn=policies,cn=system,DC=contoso,DC=local>
GPSVC(2dc.22b0) 17:16:02:109 ProcessGPO: User has access to this GPO.
GPSVC(2dc.22b0) 17:16:02:109 FilterCheck: Found WMI Filter id of: <[contoso.local;{118D5E2E-9A8A-41C8-AB0C-D87AAE094BF1};0]>
GPSVC(2dc.22b0) 17:16:02:171 ProcessGPO: GPO passes the filter check.
GPSVC(2dc.22b0) 17:16:02:171 ProcessGPO: Found functionality version of: 2
GPSVC(2dc.22b0) 17:16:02:171 ProcessGPO: Found file system path of: <\\contoso.local\sysvol\gds.local\Policies\{EC37F666-21C0-459E-88DF-3AD63AE600A1}>
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: Found common name of: <{EC37F666-21C0-459E-88DF-3AD63AE600A1}>
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: Found display name of: <CONTOSO-COMPUTER_WSUS>
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: Found user version of: GPC is 1, GPT is 1
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: Found flags of: 1
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: No client-side extensions for this object.
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: GPO CONTOSO-COMPUTER_WSUS is disabled. It will be skipped.
 
Plusieurs remarques peuvent être faites :
  • La présence d’un filtre WMI est détecté en 1er et s’il est présent, il est évalué.
  • Le GUID de la GPO renvoie à son chemin physique dans le dossier SYSVOL.
  • La présence de paramètres CSE est évaluée
  • L’état de la GPO (désactivée ou non) est évaluée afin de décider de son traitement
  • La présence de paramètres CSE est évaluée
Une fois ces GPO traitées, une passe particulière est réalisée pour les paramètres CSE (Client Side Extentions).
Ce sera l’objet de notre prochain billet.
 

Azure AD Connect – Relancer les synchronisations après la suppression d’un domaine Active Directory enfant

par | 12 Jan 2018 |

Contexte

La synchronisation entre l’Active Directory et Office 365 est un sujet extrêmement sensible dans un environnement de production. Une mauvaise configuration peut entrainer la suppression de nombreux objets dans le cloud (comptes, groupes…).

Le domaine enfant de mon domaine Active Directory a été décoché dans la configuration de mon connecteur dans la console Synchronization Service Manager.

2018-01-10_1613512

Figure 1 – Propriétés du connecteur

Lorsque l’on coche à nouveau le domaine enfant et que l’on relance une synchronisation, le domaine enfant n’est pas resynchronisé.

Solution

Lors de la suppression du domaine enfant, les étapes de synchronisation associées sont supprimées.

On remarque en allant dans Configure Run Profiles… sur le connecteur qu’il n’y a qu’une seule étape qui correspond au domaine parent.

2018-01-12_1111362

Figure 2 – Profil du connecteur pour le Full Import avec une seule étape (domaine parent)

Il est donc nécessaire de recréer les étapes pour le domaine enfant. Pour cela il est recommandé de lancer l’outil de configuration d’Azure AD Connect.

Une fois l’outil de configuration terminée, les étapes pour le domaine enfant sont de nouveaux en place.

2018-01-12_1142582

Figure 3 – Profil du connecteur pour le Full Import avec deux étapes (domaine parent et domaine enfant)

Il est ensuite nécessaire de relancer dans l’ordre :

  • Full Import – Connecteur Active Directory
  • Full Synchronisation – Connecteur Active Directory
  • Export – Connecteur Active Directory
  • Delta Import – Connecteur Office 365 (domaine.onmicrosoft.com)
  • Delta Synchronisation – Connecteur Office 365 (domaine.onmicrosoft.com)
  • Export – Connecteur Office 365 (domaine.onmicrosoft.com)

Derniers articles

Catégories

Archives

Auteurs/Autrices