Archives de la catégorie ‘Microsoft Azure’

 

Malgré l’ajout des ~2300 nouvelles Cmd-lets PowerShell sur Windows Server 2012 R2 et 2016, le meilleur outil de gestion du Networking & Firewalling Windows reste (pour moi :D) le super Command-Line Tool Netsh.exe (Windows Network Shell).

En effet, Windows PowerShell fonctionne aujourd’hui qu’avec un sous-ensemble de fonctionnalités de management Windows Server, n’incluant pas la possibilité de configurer et gérer le Pare-feu Windows et ses fonctions avancées.

J’ai donc décidé de vous regrouper dans le présent post les « Top 10″ des Commandes Netsh que vous devez connaître pour créer, configurer et gérer vos Pare-feu Windows (Client & Server).

Les commandes détaillées ci-dessous peuvent aussi vous être utile lors de la configuration du Firewall Windows IaaS (E.g : VM Azure ou AWS)

 

1.Afficher /Lister une règle spécifique ou toutes les règles du Pare-feu Windows
  • Afficher toutes les règles : netsh advfirewall firewall show rule name=all
  • Afficher une règle spécifique (« SQL » dans l’exemple suivant) : netsh advfirewall firewall show rule name=SQL


2.Activer /Désactiver un ou plusieurs profils du Pare-feu Windows
  • Activer tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state on
  • Désactiver tous les profils du Pare-feu Windows : Netsh advfirewall set allprofiles state off
  • Activer le profil « Public » du Pare-feu Windows : Netsh advfirewall set publicprofile state on
  • Désactiver le profil « Privé » du Pare-feu Windows : Netsh advfirewall set privateprofile state off
  • Activer le profil « Domaine » du Pare-feu Windows : Netsh advfirewall set domainprofile state on

3.Réinitialiser les stratégies (par défaut) du Pare-feu Windows
  • netsh advfirewall reset

4.Afficher et Configurer les fichiers Logs du Pare-feu Windows

Notez que le chemin par défaut des fichiers « Logs » liés au Pare-feu Windows est le suivant : C:\Windows\system32\LogFiles\Firewall\pfirewall.log

Vous pouvez visualiser ce chemin par défaut (pour tous les profils du Pare-feu) en exécutant la commande suivante :

  • netsh advfirewall show allprofiles logging

Nous allons définir dans l’exemple suivant le chemin « D:\WSFirewall\Logs\pfirewall.log », pour tous les profils du Pare-feu Windows (Domaine – Privé – Public)

  • netsh advfirewall set allprofiles logging filename « D:\WSFirewall\Logs\pfirewall.log« 

Note : après configuration d’un nouvel emplacement du fichier log pfirewall.log, l’ancien fichier log placé dans le chemin par défaut est automatiquement déplacé et renommé en .old


5.Autoriser ou Refuser le « Ping »
  • Autoriser le « Ping »: netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=allow protocol=icmpv4
  • Refuser le « Ping » : netsh advfirewall firewall add rule name= »All ICMP V4″ dir=in action=block protocol=icmpv4

6.Ajouter (Autoriser) ou Supprimer un Port spécifique
  • Ajouter une nouvelle règle autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall add rule name= »Autoriser_Port_SQL Server » dir=in action=allow protocol=TCP localport=1433
  • Supprimer la règle précédente autorisant le port 1433 (port par défaut utilisé par SQL Server) : netsh advfirewall firewall delete rule name= »Autoriser_Port_SQL Server » protocol=tcp localport=1433

7.Autoriser un Programme
  • Dans l’exemple suivant, le Programme « IPScan » placé dans C:\Program Files\IPScan\IPScan.exe » sera autorisé : netsh advfirewall firewall add rule name= »Autoriser_IPScan » dir=in action=allow program= »%ProgramFiles%\IPScan\IPScan.exe »

8.Activer la gestion à distance
  • netsh advfirewall firewall set rule group= »Gestion à distance de Windows » new enable=yes


9. Activer /autoriser Les Connexions Bureau à distance
  • netsh advfirewall firewall set rule group= »Bureau à distance » new enable=Yes


10.Exporter ou importer la configuration & paramètres du Pare-feu Windows
  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

  • Pour exporter toute la configuration du Pare-feu Windows vers D:\WSFirewall : netsh advfirewall export « D:\WSFirewall\WFconfiguration.wfw »

Je vous laisse Run > Netsh Advfirewall /? et découvrir le reste des commandes.

Enfin, toujours gardez à l’esprit que le CLI Netsh.exe fait parti des outils en ligne de commande Windows les plus puissants (et compliqué aussi). Toujours PoC(er), Tester et Valider l’opération sur un LaB /Environnement d’Intégration /PréProd …Etc avant toute application sur les serveurs de Production.

A bientôt

Publicités
 
Introduction 

Un réseau virtuel Azure (Azure Virtual Network) est la représentation de votre réseau local d’entreprise dans le Cloud. En effet, quand vous décidez de déployer des ressources dans le Cloud et choisissez Microsoft comme fournisseur de Cloud public, eh bien votre « Réseau dans le Cloud » est le Azure Virtual Network (appelé aussi VNET : cf documentations Microsoft)

Vous pouvez configurer votre ou vos VNETs Azure de la même manière que pour votre ou vos réseaux locaux « On-Premise » : définir le plan d’adressage IP, les sous-réseaux (Subnets), le(s) serveur(s) DNS, les stratégies de sécurité, le routage …Etc

Vous pouvez également subdiviser votre VNET Azure en sous-réseaux pour isoler les différents trafics réseaux (e.g : environnements DMZ /INT /PREPROD /PROD) , ces sous-réseaux peuvent aussi représenter des « Branch Office » ou simplement des Sites de Backup /PRA pour votre S.I, un VNET Azure devient alors une extension de vos réseaux locaux internes « On-Prem » dans le Cloud.

La création d’un VNET Azure peut se faire via :

Le nouveau portail Azure : portal.azure.com

Windows PowerShell : utilisation du module PS Azure

Azure CLI 2.0 : via l’utilisation de la commande az network vnet

Nous allons découvrir à travers cet article la troisième méthode qu’est l’utilisation de l’interface Azure CLI 2.0

Now let’s create & manage our Azure Virtual Network via Azure CLI 2.0__O

 

Comment ça marche ?
  • Ouvrez une Session Windows sur la machine d’administration sur laquelle Azure CLI 2.0 a été installé
  • Lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez az pour vérifier la disponibilité de l’interface Azure CLI 2.0
  • Après avoir saisi et exécuté la commande az, le Menu suivant vous est retourné :

  • La commande qui nous intéresse est Network. En effet, l’interface az dans le contexte Network vnet permet de créer et gérer les réseaux virtuels Azure.
  • Pour afficher toutes les commandes & sous-commandes liés à la création et gestion des VNETs, saisissez la commande suivante : az network vnet -h 

  • Pour afficher /lister les VNETs existants, saisissez az network vnet list –output table
    • Note : le paramètre –output table est utilisé pour une meilleure lisibilité du résultat retourné (résultat affiché sous forme de tableau)

  • Pour créer une nouveau VNET nommé « hk-vnet01 » dans le groupe de ressource « hk-ResourceGroup » et l’héberger au niveau de la région Azure « Europe de l’Ouest« , la commande suivante est utilisée : az network vnet create -n « hk-vnet01 » -g « hk-ResourceGroup » -l WestEurope

  • Pour créer une nouveau VNET nommé « hk-vnet02 » dans le groupe de ressource « hk-ResourceGroup » et l’héberger au niveau de la région Azure « Europe de l’Ouest » en spécifiant l’espace d’adressage 10.10.0.0/16 et en créant un premier sous-réseau dont l’ID est 10.10.1.0/24, la commande suivante est utilisée : az network vnet create -g hk-ResourceGroup -n hk-vnet02 -l WestEurope –address-prefix 10.10.0.0/16 –subnet-name HK-SUB-PROD –subnet-prefix 10.10.1.0/24

  • Pour afficher des informations détaillées sur un VNET spécifique (hk-vnet01 dans l’exemple suivant), la commande suivante est utilisée : az network vnet show -n « hk-vnet01 » -g « hk-ResourceGroup »

  • Pour supprimer un VNET spécifique (hk-vnet02 dans l’exemple suivant), la commande suivante est utilisée : az network vnet delete -n hk-vnet02 -g hk-ResourceGroup

  • Enfin, pour mettre à jour (modifier) un VNET spécifique, la commande suivante est utilisée : az network vnet update suivie du nom du groupe de ressource hébergeant le VNET (paramètre -g) et le nom du VNET à modifier /updater (paramètre -n). Les paramètres –address-prefixes et –add sont à utiliser pour mettre à jour la configuration de votre VNET. Si toutefois vous voulez afficher l’aide en ligne pour la commande az network vnet update, exécutez la commande suivante : az network vnet update -h

 

 

Lors de la phase « étude » d’un projet de migration de Datacenter vers Microsoft Azure, vous devez d’abord étudier, de manière approfondi les Workloads devant ET pouvant être migrées vers de la VM Azure.

Un client m’a récemment fait part du besoin suivant : je souhaiterais déployer une infra WDS (2012 R2 ou 2016) sur Azure (services WDS hébergé sur de la VM Azure).

Cette demande ne peut malheureusement être étudiée ni réalisée car :

WDS (Windows Deployment Services) est un rôle Windows non supporté sur une VM Azure

Vous aurez compris, il est primordial d’étudier et prendre connaissance de la liste complète des rôles, fonctionnalités et logiciels NON SUPPORTES sur une VM Azure avant de se précipiter et commencer à préparer et créer des environnements cibles unitelement … (perte de $$ et du time :)).

Nous allons découvrir à travers cet article les rôles Windows et composants serveurs que vous pouvez migrer « from OnPrem » ou directement déployer dans un environnement Azure VM (en mode IaaS  : Infrastructure-as-aService)

 

Rôles et Fonctionnalités Windows supportés sur une VM Azure

Les rôles suivants sont supportés sur une VM Azure exécutant Windows Server 2008 R2 ou ultérieur :

  • Active Directory Certificate Services (AD CS) : certains Best Practices doivent être respectés pour déployer correctement une nouvelle PKI AD CS ou étendre votre PKI existante vers le Cloud Azure.
  • Active Directory Domain Services (AD DS)
  • Active Directory Federation Services (AD FS)
  • Active Directory Lightweight Directory Services (AD LDS)
  • Application Server
  • DNS Server
  • Failover Clustering *
  • Services de fichiers
  • Services de Stratégie et d’Accès Réseau
  • Services d’impression et de Numérisation de document
  • Services Bureau à distance (RDS : Remote Desktop Services **
  • Web Server (IIS)
  • Windows Server Update Service (WSUS)

 

*  : L’utilisation d’un Cluster à Basculement Windows Server sur une VM Azure présente certains prérequis :

Le Cluster à Basculement doit être exécuté sur les OS Windows Server suivants : Windows Server 2008 R2, 2012 ou 2012 R2

Pour les Cluster Windows Server 2008 R2 et 2012, le Hotfix 2854082 doit être installé sur tous les nœuds du Cluster

Le Cluster doit être accessible par une adresse IP unique

Le Cluster doit utiliser le Stockage Azure

** : si vous disposez déjà des CALs RDS Par-Utilisateur (avec un programme /contrat active SA « Software Assurance »), celles-ci peuvent être installées et utilisées sur un Windows Server « 2008 R2 ou ultérieur » qui tourne sous forme de VM Azure.

Notez donc que les rôles suivants ne sont pas supportés (au moment de la rédaction du présent article) sur une VM Azure exécutant Windows Server 2008 R2 ou ultérieur :

  • DHCP Server
  • Hyper-V
  • Active Directory Rights Management Services (AD RMS)
  • Windows Deployment Services (WDS)

 

En ce qui concerne les fonctionnalités Windows, celles listées ci-dessous ne sont pas supportées au moment de la rédaction de cet article:

  • BitLocker (Chiffrement de disque OS non supporté, mais BitLocker peut être activé et utilisé sur des vDisks de données)
  • iSNS (Internet Storage Name Service)
  • Multipath I/O
  • Equilibrage de la charge réseau (Network Load Balancing)
  • Protocole PNRP (Peer Name Resolution Protocol)
  • Service Routage et accès distant (RRAS : Routing and Remote Access service)
  • DirectAccess
  • Services SNMP
  • Gestionnaire de stockage pour réseau SAN
  • WINS (Windows Internet Name Service)
  • Service de Réseau Local sans fil

 

Note importante : Si vous devez migrer des composants et/ou services d’infrastructure encore hébergés sur des VMs Windows Server 2003, je vous recommande la consultation de cet article pour prendre connaissances de certaines « Useful informations » concernant l’exécution de Windows Server 2003 sur une VM Azure

 

Logiciels & Composants Serveur supportés sur une VM Azure

Les logiciels et composants serveurs suivants peuvent être déployés et exécutés sur une VM Azure :

  • Microsoft BizTalk Server 2013 ou ultérieur (Notez que certaines fonctionnalités BizTalk 2013 ne sont pas supportées en mode VM Azure)
  • Microsoft Dynamics AX 2012 R3 ou ultérieur
  • Microsoft Dynamics CRM 2013 ou ultérieur (Nécessite de l’Azure Premium Storage)
  • Microsoft Dynamics GP 2013 ou ultérieur
  • Microsoft Dynamics NAV 2013
  • Exchange Server 2013 ou ultérieur
  • Forefront Identity Manager 2010 R2 SP1 ou ultérieur
  • Microsoft HPC Pack 2012 ou ultérieur
  • Project Server 2013 ou ultérieur
  • SharePoint Server 2010 ou ultérieur
  • SQL Server 2008 ou ultérieur (version 64-bit uniquement)
  • System Center 2012 Service Pack 1 (SP1) ou ultérieur
  • Team Foundation Server 2012 ou ultérieur

 

En outre, deux autres points « importants » sont à retenir :

L’Upgrade d’OS (Guest OS) d’une VM Azure n’est pas supporté : Si vous souhaitez migrer vos Workloads vers des VMs Azure et migrer (upgrader) ensuite le Guest OS exécuté au niveau celles-ci, sachez que cette option n’est pas supportée. Pensez donc à migrer vos Guest OS (OnPrem) avant toute migration vers Azure.

Seuls les logiciels « Serveur » respectant la politique de Support Microsoft peuvent être hébergés et exécutés sur une VM Azure. Je vous invite à consulter cette page avant toute migration ou déploiement de logiciel serveur sur une VM Azure;

 

Lien utile ! 

Je vous recommande de consulter régulièrement cette page avant tout projet de migration vers des VMs Azure ou déploiement de nouveaux services ou composants en mode IaaS. Si de nouveaux rôles, fonctionnalités ou encore composants /logiciels serveurs sont pris en charge sur une VM Azure, cet article est automatiquement updaté par l’équipe Azure Corp.

Vous aurez compris, cette page est à garder dans son Folder « Web Favoris ».

HK.

Note : si vous n’avez pas encore connecté votre interface Azure CLI 2.0 à votre abonnement Azure, suivez les instructions détaillées dans cet article.

Introduction

Toutes les ressources créés /provisionnées dans Microsoft Azure ont besoin d’être associées à des « Groupes de Ressources ». il s’agit ici d’une fonctionnalité de base du modèle ARM (Azure Resource Management).

Utiliser un groupe de ressource Azure vous permettra de grouper toutes vos ressources Cloud (VM, vNIC, stockage, IP Public..etc) dans une sorte de « Conteneur » et de les gérer de manière centraliser.

La création d’un groupe de ressource Azure peut se faire via :

Le nouveau portail Azure : portal.azure.com

Windows PowerShell : utilisation du module PS Azure

Azure CLI 2.0 : via l’utilisation de la commande az group

Nous allons découvrir à travers cet article la troisième méthode qu’est l’utilisation de l’interface Azure CLI 2.0

Now let’s create & manage our Azure Resource Group via Azure CLI 2.0__O

Comment ça marche ?
  • Ouvrez une Session Windows sur la machine d’administration sur laquelle Azure CLI 2.0 a été installé
  • Lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez az pour vérifier la disponibilité de l’interface Azure CLI 2.0
  • Après avoir saisi et exécuté la commande az, le Menu suivant vous est retourné :

  • La commande qui nous intéresse est Group. En effet, l’interface az dans le contexte group permet de créer et gérer les groupes de ressources Azure.
  • Pour afficher /lister les groupes de ressources existants, saisissez az group list

  • Pour créer un nouveau groupe de ressource, la commande az group create est utilisée. Dans l’exemple suivant, un groupe de ressource nommé « G2R_HK » sera créé. Le paramètre -l (comme location) permet de spécifier la région Azure dans laquelle le groupe de ressource sera placé /hébergé.

  • Le champ « ProvisioningState » vous indique le résultat de l’opération > Succeeded dans notre cas (groupe de ressource créé avec succès).
  • Si vous vous connectez sur le nouveau portail Azure (> portal.azure.com), vous pouvez constater l’existence du groupe G2R_HK créé précédemment

  • Nous allons maintenant afficher des informations sur notre groupe de ressource G2R_HK. La commande az group show G2R_HK est utilisée :

Notez que vous pouvez ajouter des « Tags » à vos groupes de ressources, cela devient vite pratique si vous devez créer plusieurs groupes de ressources pour des entités ou départements spécifiques > e.g : un groupe de ressource pour le département RH, un second groupe de ressource pour le département Compta …

  • Pour ce faire, le paramètre -Tags est utilisé. Dans l’exemple suivant, nous allons créer un nouveau groupe de ressource appelé G2R_RH et nous allons le « TagGer » > Depart-RH, la commande suivante est utilisée :
  • az group create -l WestEurope -n G2R_RH –tag « Depart-RH »

  • Vous pouvez mettre à jour un groupe de ressource existant pour ajouter des Tags si cela n’a pas été fait lors de la création. la commande update et le paramètre –set sont utilisés. Dans l’exemple suivant, les Tags « Depart-IT » « Env=PROD » seront ajoutés au groupe de ressource existant G2R_HK, la commande suivante est donc utilisée : az group update -n G2R_HK –set tags.Depart=IT tags.Env=PROD

  • Enfin, pour supprimer un groupe de ressource Azure, la commande az group dans le contexte « delete » est utilisée. Dans l’exemple suivant, le groupe de ressource G2R_RH sera supprimé : az group delete -n G2R_RH
  • Vous devez confirmer l’opération de suppression en saisissant y comme yes

Azure CLI Tip : pour une meilleure lisibilité du résultat retourné par une commande Az CLI, je vous recommande l’utilisation du paramètre –output suivi de table pour formater les informations retournées au format « Tableau », dans l’exemple suivant nous listons les groupes de ressources disponibles en spécifiant un format de sortie > « Tableau » :

az group list –output table

 

What Next ?

Maintenant que vous avez créé votre (ou vos) groupe(s) de ressource(s), découvrez comment créer votre premier réseau virtuel Azure (VNET Azure) en suivant le HowTo #N°3 Créer et gérer les réseaux virtuels Azure (VNET : Virtual Network)

 

 

 

 

 

 

 

 

===================================================================

Cet article un extrait de l’unique eBook (guide pas à pas en Français :)) sur Azure CLI 2.0. Il sera bientôt disponible sur BecomeITExpert.com  :), so stay in touch les copains.

HK.

Si vous souhaitez démarrer avec Microsoft Azure, commencez par comprendre tous les composants et services disponibles sur celui-ci.

Je vous propose de consulter la version cliquable d’Azure Periodic Table, disponible à cet URL.

Il s’agit d’une « Big Picture » cliquable qui vous détaille chaque service disponible sur Azure.

C’est un bon point de départ si vous souhaitez vous former sur MS Azure.

 

MS a annoncé au « Ignite 2016″  la disponibilité générale de l’IPv6 pour les Machines Virtuelles (VMs) Azure.

La plupart des Régions Azure (voir liste ci-après) peuvent désormais héberger des VMs « Dual-Stack » : IPv4 + IPv6

Brazil South

Canada Central

Canada East

Central India

Central US

East Asia

East US

East US 2

Japan East

Japan West

North Europe

North Central US

South India

South Central US

Southeast Asia

UK North

UK South 2

West Central US

West Europe

West India

West US

West US 2

 

Notez qu’au moment de la rédaction de cet article, les Régions suivantes ne peuvent faire du hosting de VMs Dual-Stack (IPv4 + IPv6) :

Australia East, Australia Southeast

UK West, UK South

Germany Central, Germany Northeast

USGov Central, USGov East

China North, China East