Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Hyper-V : Créer un disque de différenciation (Partie 2)

par | 1 Août 2019 | ,

Après avoir définit les paramètres de la VM dans le précédent article nous allons maintenant déployer l’OS de notre VM de référence.

1. Déploiement de l’OS.

1- Connectez vous à la VM et démarrez-la.

2- Sélectionnez la langue d’installation du système d’exploitation (s’il vous plait Anglais cela évitera les problèmes plus tard) puis le fuseau horaire et la langue du clavier (cette fois-ci vous pouvez mettre Français) et enfin faites « Next »

3- Cliquez sur « Install Now »

4- Sélectionnez la version de l’OS à installer (Core ou Graphique) et la version de licence correspondante (Standard ou Datacenter) et faites « Next »

5- Cochez « I accept the license term agreement” et faites « Next »

6- Sélectionnez « Custom: Install Windows only (advanced) »

7- Sélectionnez le disque et faites « Next »

8- Attendez la fin de l’installation

9- Entrez un mot de passe Admin local

Une fois l’installation terminé, identifiez vous sur la machine (je ne mets pas à jour l’OS car au moment où je rédige ces lignes Windows Server 2019 viens juste de sortir), nous allons donc directement passer au Sysprep.

2. Sysprep

Pour réaliser un sysprep de la machine, allez dans « C:\Windows\System32\Sysprep » et exécuter « Sysprep.exe ».

Lorsque la fenêtre apparait cochez la case « Generalize » et sélectionnez « Shutdown » et faites « OK »

Attendez l’extinction de la VM puis dans « Hyper-V Manager » supprimez la, cette action vous évitera de rallumer la VM par inadvertance (ce qui poserait problème pour toutes les machines configurées à l’aide du disque de référence).

Maintenant que le disque de référence a été créé nous allons pouvoir créer les nouveaux disques et VMs, nous verrons cela dans la partie 3.

Netdom Trust et les OS Français

par | 11 Juil 2019 | , , , , ,

Un environnement homogène avec des OS installé en Anglais, c’est la vision de notre éditeur préféré (je parle bien sur de Microsoft).

Dans la pratique on a pas toujours l’opportunité d’avoir tous les OS dans la même version et pire encore dans la même langue d’installation.

 

Quel impact ?

Même si pour certain, installer un OS en Français est plus « Confortable / facile d’administration », en terme de « recherche / résolution » d’incident on est quand même nettement moins bien aidé (entre les messages d’erreur qui ne veulent rien dire ou les commandes qui diffèrent, avoir un langage différent de l’anglais peut vous faire perdre quelques heures).

 

Des Exemples :

Prenons un exemple simple l’activation ou la désactivation du « SID Filtering » dans un « Trust » entre deux domaines.

OS Anglais :

Si les OS des serveurs contrôleur de domaine sont en Anglais les commandes sont simples :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:No  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l’autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

 

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Yes

 Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l’autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

 

OS Français :

Lorsque les OS sont en Français il y a une petite subtilité :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Non  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l’autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

 

 

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Oui

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l’autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

 

Vous l’avez ?

Et oui la commande est quasi identique puisqu’elle est en Anglais, mais les arguments eux sont en Français et le pire dans tout ça c’est que si vous passez la commande en Anglais avec les arguments en Anglais, l’OS vous dira que la commande s’est terminée avec succès même si ce n’est pas le cas; mais dans la pratique cette dernière aura échouée.

 

Alors de grâce ayez le réflex lors d’une installation serveur de sélectionner un Iso en Anglais et de l’installer en Anglais (rassurez vous pour le clavier et le fuseau horaire le Français est autorisé ^^ ).

Azure DNS : Du mieux dans les zones privées !

par | 2 Juil 2019 |

Bref rappel : Azure DNS est un service PaaS qui propose d’héberger vos zones DNS sans que vous n’ayez besoin de vous préoccuper de la gestion de l’infrastructure sous-jacente.

De plus, comme tout service « cloud », il est possible de gérer ces zones et leurs entrées à l’aide d’une API REST, ce qui apporte une flexibilité certaine face au fonctionnement encore un peu archaïque du service Windows DNS dont la gestion passe nécessairement par la MMC DNS ou par Powershell, voire par l’utilisation de dnscmd.exe pour ceux d’entre vous qui lisent cet article en 1992.

Microsoft a introduit il y a quelques mois un type de zone « Private » à ce service, permettant ainsi d’héberger des zones qui ne seraient pas résolvables depuis l’extérieur de votre environnement ; mais ce mode souffrait de lacunes sérieuses, qui le rendaient inexploitable dans un contexte réel :

  • Il n’était disponible qu’en Powershell
  • Seules les requêtes provenant d’un unique VNet avaient le droit de créer des entrées dans une zone donnée
  • Seuls 10 VNet avaient le droit de lire les entrées d’une zone donnée
  • Ces VNet devaient être déclarés manuellement
  • Ces VNet ne devaient contenir aucune ressource au moment de leur déclaration (!!)
  • Les enregistrements étaient invisibles via powershell ou l’API REST, mais étaient bel et bien resolvables
  • … etc.

Une mise à jour majeure est apparue la semaine dernière, et elle corrige la majorité de ces défauts :

  • On peut désormais créer les zones privées directement dans le portail Azure
  • On peut lier jusqu’à 1000 VNet à une zone privée, même si ces VNet contiennent déjà des ressources ; et les notions de VNet « enregistreur » ou « requêteur » disparaissent
  • On peut désormais accéder aux enregistrements via l’API ou Powershell

Bref, on peut maintenant raisonnablement utiliser ce service dans un environnement réel… mais attention tout de même, il est toujours en Public Preview et susceptible d’évoluer n’importe quand !

Notez également que la résolution dans une zone Private DNS ne fonctionne par défaut que si votre VNet est configuré pour utiliser la résolution DNS native d’Azure.

Si vous utilisez une résolution « Custom » (un contrôleur de domaine déployé dans votre tenant par exemple), il faudra créer un conditional forwarder pour votre zone Private DNS, pointant vers l’IP d’Azure DNS (unique pour tous les tenant et toutes les régions) : 168.63.129.16

Enfin, comme la résolution dans une zone Private DNS n’est possible que depuis un VNet, il faudra également prévoir un forwarder différent sur les serveurs DNS de votre Lan si vous souhaitez pouvoir résoudre depuis cet emplacement !

L’occasion idéale pour mettre en place une partition DNS à réplication limitée…

Derniers articles

Catégories

Archives

Auteurs/Autrices