Configurer une application ou un script en tant que service Windows

Dans cet article, nous allons voir comment créer un service Windows afin de lancer une application ou même un script PowerShell en tant que service. Après quelques recherches, je suis tombé sur une KB Microsoft très intéressante sur le sujet dont voici le lien : http://support.microsoft.com/kb/137890/fr. Cet article s’appuie en grande partie dessus.

Premièrement, nous allons récupérer l’exécutable « srvany.exe » disponible depuis le « Windows Server 2003 Ressource Kit Tools » (http://www.microsoft.com/en-us/download/details.aspx?id=17657). Il permet de lancer n’importe quel programme en tant que service. Le problème est qu’il est déprécié à partir de Windows Server 2008 mais il n’y a pas vraiment de remplaçant et il fonctionne bien sous Windows Server 2008 ou Windows Server 2008 R2.

Notez également que vous n’êtes obligé d’installer le Ressource Kit dans son intégralité. Vous pouvez récupérer l’exécutable en décompressant le fichier d’installation à l’aide de 7-Zip. Dans le cadre de notre article, je l’ai toutefois installé et son chemin d’accès par défaut est « C:\Program Files (x86)\Windows Resource Kits\Tools\srvany.exe ».

Maintenant, nous allons créer notre service à l’aide de l’outil « sc ». Ouvrez une invite de commandes et lancez la commande suivante « sc create MonService binPath= « C:\Program Files (x86)\Windows Resource Kits\Tools\srvany.exe »  DisplayName= « Mon service personalisé » »

 

Le service est désormais créé mais il faut préciser l’application à exécuter en tant que service. Pour cela, il faut passer par l’éditeur de registre. Vous allez donc lancer « regedit » depuis « Démarrer | Exécuter » et vous rendre vers le chemin suivant : « HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MonService ».

{gallery}70_TIPS_APPSERVICE/02{/gallery}

 

 

 

 

 

 

Vous allez créer une nouvelle clé que vous appellerez « Parameters » à l’aide d’un clic droit sur la clé « MonService » (correspondant au nom du service donné avec l’outil « sc »).

{gallery}70_TIPS_APPSERVICE/03{/gallery}

 

 

 

 

 

Au sein de cette clé, ajoutez une valeur chaîne (REG_SZ) nommée « Application » avec, comme donnée, le chemin de votre application (dans notre exemple nous avons pris Notepad).

{gallery}70_TIPS_APPSERVICE/04{/gallery}

 

 

 

 

 

 

 

Il vous suffit enfin de lancez votre service personnalisé et de faire les modifications nécessaires depuis la console « Services » en lançant la commande « services.msc » depuis « Démarrer | Exécuter ».

{gallery}70_TIPS_APPSERVICE/05{/gallery}

 

 

 

 


 

Maintenant, allons un poil plus loin et essayons de lancer un script PowerShell en tant que service. En guise d’exemple, j’ai créé le script basique suivant :

{codecitation style= »brush: powershell »}

$date = get-date

« $($date): script is starting » > C:\temp\output.txt


while ( !$stop )

{

$date = get-date

« $($date): script is running » >> C:\temp\output.txt

sleep 10

}

{/codecitation}

 

Il suffit de modifier la donnée de valeur chaîne « Application » depuis la base de registre avec la ligne suivante : « C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -executionPolicy unrestricted -file C:\temp\ScriptPosh.ps1 ».

En clair, nous précisons le chemin de l’application « powershell.exe » et nous rajoutons les paramètres :

  • « -file » pour spécifier le chemin de notre script fraichement créé.
  • « -executionPolicy » pour éviter que la stratégie d’exécution PowerShell soit trop contraignante.

 

Lors du démarrage du service, vous devriez voir le fichier « output.txt » s’alimenter au fur et à mesure.

 

 

How to Find Active Directory Schema Update History by Using PowerShell

Vérifier rapidement l’état d’une relation d’approbation Active Directory

J’ai déjà mis à disposition un article pour vérifier, via un script, l’état de vos réplications Active Directory. Ce script est disponible ICI. Vous pouvez également consulter notre article sur le sujet « Audit Active Directory : Part 2 – les relations d’approbation ». Avec ce script, vous pouvez récupérer toutes les informations sur vos relations d’approbation et d’obtenir une synthèse au format CSV.

Toutefois, si vous voulez rapidement vérifier l’état d’un lien d’approbation entre deux domaines/forêts Active Directory, vous pouvez utiliser une simple requête WMI en PowerShell ou en VBS. Pour cela, nous allons utiliser le fournisseur WMI « TrustMon » (http://msdn.microsoft.com/en-us/library/windows/desktop/aa393921(v=vs.85).aspx), introduit avec Windows Server 2003 et plus particulièrement la classe « Microsoft_DomainTrustStatus » qui va permettre donc de recueillir des informations sur les relations d’approbation.

La requête WMI doit être exécutée idéalement sur le maître d’opération « Emulateur PDC ». Il va donc falloir l’identifier préalablement. Pour cela, exécuter la commande suivante « NETDOM query /domain:domaine.local fsmo ».

 

Une fois le maître d’opération « Emulateur PDC » identifié, vous pouvez exécuter la commande PowerShell suivante :

{codecitation style= »brush: powershell »}

Get-WMIObject –Namespace root\MicrosoftActiveDirectory –Class Microsoft_DomainTrustStatus `
–ComputerName emulateurPDC.domaine.local | ft TrustedDCName,TrustedDomain,TrustIsOk,TrustStatusString

{/codecitation}

 

 

La propriété « TrustIsOk » permet de valider l’état de la relation d’approbation et la propriété « TrustStatusString » va permettre d’avoir plus de détail sur une erreur éventuelle.

 

Si vous ne pouvez pas exécuter du PowerShell (ce qui serait quand même assez étonnant), vous pouvez utiliser le code ci-dessous au sein d’un fichier script VBS. Le script a été  généré à l’aide de l’outil Microsoft WMICodeCreator (http://www.microsoft.com/en-us/download/details.aspx?id=8572).

{codecitation style= »brush: vbs »}

strComputer = « emulateurPDC.mondomaine.local »

Set objWMIService = GetObject(« winmgmts:\\ » & strComputer & « \root\MicrosoftActiveDirectory »)

Set colItems = objWMIService.ExecQuery( _

« SELECT * FROM Microsoft_DomainTrustStatus »,,48)

For Each objItem in colItems

Wscript.Echo « ———————————–« 

Wscript.Echo « Microsoft_DomainTrustStatus instance »

Wscript.Echo « ———————————–« 

Wscript.Echo « TrustedDCName:  » & objItem.TrustedDCName

Wscript.Echo « TrustedDomain:  » & objItem.TrustedDomain

Wscript.Echo « TrustIsOk:  » & objItem.TrustIsOk

Wscript.Echo « TrustStatusString:  » & objItem.TrustStatusString

Next

{/codecitation}

Remarque : pensez à changer la variable strComputer en spécifiant votre contrôleur de domaine « Emulateur PDC ».

How to Find Active Directory Schema Update History by Using PowerShell

Migrer un serveur DHCP Windows Server 2003 vers Windows Server 2008

Sommaire

 

 

Introduction

Dans cet article nous allons voir comment migrer votre base de données DHCP d’un serveur Windows Server 2003 vers un serveur Windows Server 2008. L’article concerne également les versions R2 de 2003 et 2008.

La migration présentée dans cet article s’appuie exclusivement sur l’outil en ligne de commande NETSH. Il existe également l’outil « Server Migration Tools » pour mener à bien cette opération de migration cependant la procédure est plus longue à mettre en œuvre pour un résultat équivalent (pour plus d’information voir l’article Technet « Guide de migration du serveur DHCP »).

Il est évident qu’avant de pouvoir importer la base DHCP de votre serveur Windows 2003 sur votre serveur Windows Server 2008, vous devez installer le rôle « Serveur DHCP » sur votre machine de destination Windows Server 2008.

Ouvrez la console « Gestionnaire de serveur », faites un clic droit sur le nœud « Rôles » et sélectionnez « Ajouter des rôles ».

{gallery}68_DHCPMIG_0308/01{/gallery}

 

 

 

 

 

 


Choisissez le rôle « Serveur DHCP » et cliquez sur le bouton « Suivant ».

{gallery}68_DHCPMIG_0308/02{/gallery}

 

 

 

 

 

 


Définissez les connexions réseau sur lesquelles votre serveur traitera les demandes des clients DHCP.

{gallery}68_DHCPMIG_0308/03{/gallery}

 

 

 

 

 

 


Précisez le suffixe de votre domaine DNS ainsi que vos serveurs DNS et vos serveurs WINS si nécessaire.

{gallery}68_DHCPMIG_0308/04{/gallery}

 

 

 


 

 


A l’étape suivante, ne spécifiez aucune étendue DHCP sachant que nous allons importer celles de votre serveur Windows Server 2003.

{gallery}68_DHCPMIG_0308/05{/gallery}

 

 

 

 

 

 


Si vous le désirez, vous pouvez également configurer le mode DHCPv6.

{gallery}68_DHCPMIG_0308/06{/gallery}

 

 

 

 

 

 


Lancez l’installation en cliquant sur le bouton « Installer ».

{gallery}68_DHCPMIG_0308/07{/gallery}

 

 

 

 

 


 

 

 

Exportation de la base de données DHCP depuis le serveur Windows Server 2003

Pour les besoins de l’article, nous avons créé un serveur DHCP sur un serveur Windows Server 2003 avec une étendue, une exclusion, des options… dont vous voyez le détail ci-dessous.

{gallery}68_DHCPMIG_0308/08{/gallery}

 

 

 

 

 

 


L’exportation de la base de données DHCP est d’une simplicité enfantine. Il vous suffit d’ouvrir un invite de commandes et d’entrer la commande « netsh dhcp server export c:\temp\DHCP-Export.txt 192.168.0.0 ».

Bien entendu, il faudra remplacer l’étendue « 192.168.0.0 » par celles de votre serveur DHCP ( à la suite les unes des autres si vous en avez plusieurs).

{gallery}68_DHCPMIG_0308/09{/gallery}

 

 

 

 


ATTENTION !!! Si vous utilisez le paramètre « All » à la place de la liste des étendues, cela peut générer l’erreur « Erreur lors de l’importation de la classe ‘Classe de routage et d’accès distant par défaut’ ».

{gallery}68_DHCPMIG_0308/10{/gallery}

 

 

 

 

 


 

Importation de la base de données DHCP sur le serveur Windows Server 2008

L’importation de la base de données DHCP est aussi simple que l’exportation réalisée préalablement.

Récupérez la base de données DHCP exportée sur votre serveur Windows Server 2008 et lancez la commande « netsh dhcp server import c:\temp\DHCP-Export.txt all ».

{gallery}68_DHCPMIG_0308/11{/gallery}

 

 

 

 

 

Une fois l’importation réalisée, ouvrez la console « DHCP » depuis « Démarrer » | « Outils d’administration » et vérifiez que l’ensemble des informations a été correctement importé.

{gallery}68_DHCPMIG_0308/12{/gallery}

 

 

 

 

 

 

 

 

 

Opérations post-migration

La dernière étape de la migration de notre serveur DHCP consiste à désactiver la ou les étendues sur le serveur Windows Server 2003 à l’aide d’un clic droit sur chaque étendue et en sélectionnant l’option « Désactiver ».

{gallery}68_DHCPMIG_0308/13{/gallery}

 

 

 

 

 


 

Autorisez ensuite le serveur DHCP sur le Windows Server 2008 en réalisant un clic droit sur le nœud racine du serveur et en sélectionnant l’option « Autoriser » (dans un environnement Active Directory, vous devrez être administrateurs de l’entreprise).

{gallery}68_DHCPMIG_0308/14{/gallery}

 

 

 

 

 

 

Vous pouvez valider la migration en faisant des tests de renouvellement de baux DHCP sur vos postes clients à l’aide de la commande « ipconfig /renew ». N’oubliez pas également de supprimer les étendues inactives sur votre serveur source.

 

 

 

How to Find Active Directory Schema Update History by Using PowerShell

Bien choisir son nom de domaine Active Directory

Sommaire

 

 

Introduction

Faisons un rapide parallèle : un couple de jeunes mariés attend un bébé. Ils réfléchissent longuement au prénom qu’ils vont lui donner. Ils savent que cette décision suivra leur enfant durant toute sa vie et qu’il pourra difficilement en changer.

Pour Active Directory, nous sommes un peu dans le même cas. Le nom que vous allez donner à votre domaine va le suivre toute son existence. De plus, il va être également très difficile voire impossible de le changer après coup. Enfin, il faudra s’assurer que le nom de domaine choisi ne représentera pas le moindre problème technique ou organisationnel.

Cet article va donc vous aider à faire le bon choix. Il fait écho à un article de Microsoft sur le sujet que je vous engage à consulter l’article Active Directory Domain Naming Considerations (http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-domain-naming-considerations.aspx).

 


Les critères techniques

L’ouverture des réseaux vers l’extérieur, la fédération de services ou la construction d’un Cloud hybride nécessitent plus que jamais que votre nom de domaine Active Directory soit localisable et compatible avec ce nouvel écosystème.

La première chose à respecter est d’utiliser un TLD existant. TLD pour « Top Level Domain » est un terme désignant les noms de domaines de premier niveau comme par exemple « .fr » ou « .com » (vous trouverez la liste complète depuis http://data.iana.org/TLD/tlds-alpha-by-domain.txt). En clair, il faudra éviter les « .local » ou « .lan ».

Idéalement, vous devriez vous appuyer sur votre nom de domaine Internet existant. A l’heure d’aujourd’hui, la plupart des entreprises ont à leur disposition un nom de domaine, ne serait-ce que pour leur site Internet. Il vous suffira de créer un sous-domaine rattaché à ce domaine existant. Par exemple, votre nom de domaine Internet est « macompagnie.fr ». Votre nom de domaine Active Directory pourra être « intra.macompagnie.fr » ou « ad.macompagnie.fr ». Et si vous ne disposez pas d’un nom de domaine sur Internet, il sera temps donc temps d’en prendre un!

Concernant les restrictions de caractères, c’est assez simple. Vous ne pouvez utiliser que des caractères alphabétiques (A-Z), caractères numériques (0-9) ou le signe moins (-). Pour plus de détails sur les conventions de noms Active Directory vous pouvez consulter ce lien http://support.microsoft.com/kb/909264.

 

 

Les critères humains et organisationnels

Ce point est secondaire mais le plus visible pour l’ensemble des utilisateurs. Du coup, il va falloir choisir un nom de domaine adapté à la structure et surtout qui sera viable dans le temps. Evitez une dénomination trop générique ou trop technique. J’ai cité « intra » un peu plus haut à titre d’exemple mais éviter ce genre de nom. Cela rentre dans le cadre du générique ou de l’ordinaire. Essayez de trouver un acronyme accrocheur en rapport avec l’activité de l’entreprise. Vous pourriez également faire participer les utilisateurs au choix du nom!

N’oubliez pas également qu’une entreprise peut changer de nom, être rachetée, fusionnée … et sans doute plus facilement que votre annuaire.

 

 

Changer le nom de votre domaine Active Directory

Il est possible de modifier le nom de votre domaine Active Directory mais les conditions sont restreintes. Microsoft fourni l’outil « rendom » pour réaliser l’opération. La procédure est disponible en anglais depuis le lien http://technet.microsoft.com/fr-fr/library/cc794869(v=ws.10).aspx.

En terme de contraintes au niveau des produits Microsoft, seul Exchange 2003 SP1 est supporté (les versions ultérieures ou antérieures ne le sont donc pas) et aucune version de SCCM (pas de support officiel). Il faudra également que vous disposiez à minima d’un niveau fonctionnel Active Directory supérieur ou égal à Windows Server 2003.

Pour les applications tierces, il faudra gérer au cas par cas. Plus l’adhérence de l’application à l’annuaire est forte, plus le risque sera grand.

En clair, c’est une opération plus ou moins réalisable en fonction de votre environnement mais à éviter autant que possible.

 

 

How to Find Active Directory Schema Update History by Using PowerShell

Auditer votre annuaire: les premières briques

Bonjour à tous,

J’ai le plaisir de vous annoncer deux premiers articles sur l’audit des composants Active Directory assortis de scripts pour vous faciliter la vie.

Articles:

 

Scripts (disponibles depuis MS Technet):

 

N’hésitez pas à voter sur le site de MS pour mes scripts en leur mettant quelques étoiles 🙂

Merci !