Spécifier une adresse IP statique depuis Windows RE

Dans cet article, je vous propose premièrement de vous accompagner dans la configuration d’une adresse IP statique sous Windows RE. Deuxièmement, je vous propose une solution pour ceux qui aurait l’erreur  « interface inconnue » avec « netsh » (allez directement ICI).

Lorsque vous démarrez à l’aide de Windows RE (environnement de récupération Windows – http://technet.microsoft.com/fr-fr/library/cc765966(v=ws.10).aspx), vous aurez sans doute besoin d’un accès réseau pour accéder à une de vos images. Ça se complique  généralement lorsque vous n’avez pas de serveur DHCP et qu’il faut définir une adresse IP statique à l’aide de l’outil en ligne de commande « netsh ».

« netsh » est un outil en ligne de commande donc allez dans « Dépannage | Invite de commandes ».

 

 

Vous devrez peut-être spécifié un compte administrateur si votre ancien système n’est pas complètement « crashé ».

 

Une fois dans l’invite de commande, nous allons commencer par identifier le nom de l’interface à l’aide de la commande « netsh interface show interface ». Notez le nom de l’interface voulue. Dans mon cas il s’agit de l’interface nommée « Ethernet ».

 

Si vous n’avez aucune interface, il est fort probable que les pilotes de votre carte réseau ne sont pas chargés ou installés. Si c’est le cas, je vous conseille de passer par l’assistant « Récupération de l’image système » pour installer les pilotes et revenir ensuite à l’invite de commandes.

Remarque : dans mon cas, le fait de sélectionner l’option « Chercher une image système sur le réseau » a suffit à faire apparaitre la carte réseau.

 

Maintenant que vous avez bien votre carte réseau qui apparait à l’aide de « show interface », taper la commande suivante pour définir une adresse IP statique : « netsh interface ipv4 add address [NOM_INTERFACE] [ADRESSE_IP] [MASK] [GW] ».

Exemple : « netsh interface ipv4 add address “Ethernet” 192.168.0.50 255.255.255.0 »

 

Si vous les accumulez, comme moi, alors vous devriez obtenir le message « Interface inconnue ». Pour remédier au problème, tapez la commande « wpeinit » et relancez la commande précédente.

 

L’adresse IP statique est enfin configurée ! On peut valider à l’aide d’un « ipconfig » et d’un « ping » si nécessaire.

Jonction au domaine: Cette demande n’est pas prise en charge

Vous obtenez le message d’erreur « L’erreur suivante s’est produite lors de la tentative de jonction au domaine « XX » : Cette demande n’est pas prise en charge » lors de la tentative d’intégration d’une machine sur un domaine Active Directory.

 

Le problème est lié à la présence de la clé de registre « HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\DSA Database file ». En effet, lors de l’intégration d’une machine à un domaine, le processus vérifie la présence de cette clé pour s’assurer que la machine n’est pas un contrôleur de domaine. Le problème est que la machine a été rétrogradée mais que la clé de registre n’a pas été correctement supprimée.

La consultation du fichier de journalisation « %systemroot%\debug\netsetup.log » permet également de confirmer le problème.

Extrait du fichier netsetup.log : NetpIsTargetImageADC: Determined this is a DC image as RegQueryValueExW loaded Services\NTDS\Parameters\DSA Database file: 0x0

 

Pour information, cette vérification est apparue avec la fonctionnalité AD « jonction au domaine hors connexion » (http://technet.microsoft.com/fr-fr/library/offline-domain-join-djoin-step-by-step(v=ws.10).aspx).

En supprimant la clé, ne problème devrait donc disparaitre.

Source : http://blogs.technet.com/b/askds/archive/2012/02/11/friday-mail-sack-get-off-my-lawn-edition.aspx#dcjoin

DCDIAG: avertissement sur attribut userAccountControl

J’ai eu le problème suivant chez un de mes clients.

Lorsque je validais l’installation d’un contrôleur de domaine à l’aide de DCDIAG, j’obtenais le message d’avertissement :

« L’attribut userAccountControl de [DC] est 0x82020

Paramètre par défaut pour un contrôleur de domaine : 0x82000 »

 

Après quelques recherches, je suis tombé sur l’article de Clint Boessen (http://clintboessen.blogspot.fr/2013/04/warning-attribute-useraccountcontrol-of.html) qui m’a donné l’explication du problème et la solution.

L’objet ordinateur Active Directory de mon contrôleur de domaine a été créé préalablement et manuellement. Du coup la valeur de l’attribut « userAccountControl » n’était pas la bonne.

Pour remédier au problème, il suffit donc de réinitialiser la valeur de l’attribut à « 532480 ».

 

Pour cela, ouvrez la console « Utilisateurs et ordinateurs Active Directory ». Activez les fonctionnalités avancées depuis le menu « Affichage » de la barre d’outils.

 

Accédez aux propriétés de l’objet ordinateur du contrôleur de domaine concerné. Modifier la valeur de l’attribut « userAccountControl » depuis l’onglet « Editeur d’attributs ».

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

Vérifier simplement la version Lync Server appliquée au schéma Active Directory

La méthode pour identifier que votre schéma Active Directory a fait l’objet d’une mise à jour pour le support de Microsoft Lync Server (anciennement connu sous le nom de Office Communications Server ou encore Live Communications Server)  consiste à vérifier la présence de l’objet « ms-RTC-SIP-SchemaVersion »  au sein de la partition de schéma. Ensuite, il faudra récupérer la valeur de l’attribut « rangeUpper » pour identifier le numéro de version.

Pour cela, le plus simple est d’utiliser la commande suivante: dsquery * « cn=ms-RTC-SIP-SchemaVersion,cn=schema,cn=configuration,<DC=VOTRE-DOMAINE-RACINE> -attr rangeUpper« 

 

Une fois la valeur de l’attribut « rangeUpper » récupérée, il suffit de la comparer avec le tableau suivant :

Schema

Version
Live Communications Server 2005 1006
Office Communications Server 2007 R1 1007
Office Communications Server 2007 R2 1008
Lync Server 2010 1100
Lync Server 2013 1150

 

Nous avons également développé le petit script PowerShell ci-dessous permettant de réaliser toutes les opérations de manière automatique.

 

{codecitation style= »brush:PowerShell »}

# table de hachage contenant les versions du schéma Lync Server
$script:SchemaHashLync = @{
1006= »LCS 2005″;
1007= »OCS 2007 R1″;
1008= »OCS 2007 R2″;
1100= »Lync Server 2010″;
1150= »Lync Server 2013″
}

# Connection a la foret
$Forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

Write-Host « Version Lync Server appliquée au schéma AD:  » -NoNewline

# Recupere l’objet « ms-RTC-SIP-SchemaVersion »
try
{
$LyncVersion = « LDAP://CN=ms-RTC-SIP-SchemaVersion, »+$Forest.Schema.GetDirectoryEntry().distinguishedName

# Recupere le numéro de version (attribut ‘rangeUpper’)
if ( $script:SchemaHashLync.ContainsKey($(([ADSI] $LyncVersion).rangeUpper)) )
{
# Affiche le nom de la version associée au numéro de version
Write-Host -ForegroundColor Green -Object $script:SchemaHashLync[$(([ADSI] $LyncVersion).rangeUpper)]
}
else
{
# Traitement spécifique si le numéro de version n’existe pas dans la table de hachage
Write-Host -ForegroundColor Yellow « Inconnue »
}
}
# Passe dans le catch si l’objet n’existe pas
catch
{
Write-Host -ForegroundColor Red « introuvable »
}

{/codecitation}

Vérifier simplement la version Exchange Server appliquée au schéma Active Directory

La méthode pour identifier que votre schéma Active Directory a fait l’objet d’une mise à jour pour le support de Microsoft Exchange Server consiste à vérifier la présence de l’objet « ms-Exch-Schema-Version-Pt »  au sein de la partition de schéma. Ensuite, il faudra récupérer la valeur de l’attribut « rangeUpper » pour identifier le numéro de version.

Pour cela, le plus simple est d’utiliser la commande suivante: dsquery * « cn=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,<DC=VOTRE-DOMAINE-RACINE> -attr rangeUpper« 

 

Une fois la valeur de l’attribut « rangeUpper » récupérée, il suffit de la comparer avec le tableau suivant :

Schema

Version
Exchange Server 2000 4397
Exchange Server 2000 SP3 4406
Exchange Server 2003 6870
Exchange Server 2003 SP3 6936
Exchange Server 2007 10628
Exchange Server 2007 10628
Exchange Server 2007 SP1 11116
Exchange Server 2007 SP2 or Exchange Server 2010 14622
Exchange Server 2010 SP1 14726
Exchange Server 2010 SP2 14732
Exchange Server 2013 15137

 

Nous avons également développé le petit script PowerShell ci-dessous permettant de réaliser toutes les opérations de manière automatique.

 

{codecitation style= »brush:PowerShell »}

# table de hachage contenant les versions du schéma Exchange Server
$script:SchemaHashExchange = @{
4397= »Exchange Server 2000″;
4406= »Exchange Server 2000 SP3″;
6870= »Exchange Server 2003″;
6936= »Exchange Server 2003 SP3″;
10628= »Exchange Server 2007″;
10637= »Exchange Server 2007″;
11116= »Exchange Server 2007 SP1″;
14622= »Exchange Server 2007 SP2 or Exchange Server 2010″;
14726= »Exchange Server 2010 SP1″;
14732= »Exchange Server 2010 SP2″;
15137= »Exchange Server 2013″
}

# Connection a la foret
$Forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

Write-Host « Version Exchange Server appliquée au schéma AD:  » -NoNewline

# Recupere l’objet « ms-Exch-Schema-Version-Pt »
try
{
$ExchangeVersion = « LDAP://CN=ms-Exch-Schema-Version-Pt, »+$Forest.Schema.GetDirectoryEntry().distinguishedName

# Recupere le numéro de version (attribut ‘rangeUpper’)
if ( $script:SchemaHashExchange.ContainsKey($(([ADSI] $ExchangeVersion).rangeUpper)) )
{
# Affiche le nom de la version associée au numéro de version
Write-Host -ForegroundColor Green -Object $script:SchemaHashExchange[$(([ADSI] $ExchangeVersion).rangeUpper)]
}
else
{
# Traitement spécifique si le numéro de version n’existe pas dans la table de hachage
Write-Host -ForegroundColor Yellow « Inconnue »
}
}
# Passe dans le catch si l’objet n’existe pas
catch
{
Write-Host -ForegroundColor Red « introuvable »

}
{/codecitation}

Forcer la suppression d’un contrôleur de domaine

Vous êtes amené à rétrograder un contrôleur de domaine en tant que serveur membre mais, suite à des problèmes de connectivité, vous ne pouvez pas mener à bien cette opération de rétrogradation. Vous aurez le message d’erreur suivant : « Le domaine spécifié n’existe pas ou n’a pas pu être contacté. »

{gallery}54_DCFORCEREMOVAL/01{/gallery}

 

 

 

 

 


Si vous voulez impérativement réaliser la rétrogradation de votre contrôleur de domaine, il faudra lancer DCPROMO avec le commutateur « /forceremoval ». Cela permettra à DCPROMO de s’affranchir de l’étape consistant à faire le ménage des références de ce contrôleur de domaine sur la forêt Active Directory.

ATTENTION !!! en utilisant ce commutateur, il faudra que vous fassiez le ménage vous-même à l’aide d’un « metadata cleanup ». Cette opération est impérative. Nous en parlons plus en détail à la fin de l’article.

 

Depuis « Démarrer | Exécuter », lancez la commande « dcpromo /forceremoval ».

{gallery}54_DCFORCEREMOVAL/02{/gallery}

 

 

 

 

 


Vous aurez un avertissement si votre contrôleur de domaine fait office de serveur DNS ou si l’option « catalogue global » était activée.

{gallery}54_DCFORCEREMOVAL/03{/gallery}

 

 

 

 

 

 

 


L’assistant « Installation des services de domaine Active Directory » démarre. Il débute en vous avertissant des risques et impacts d’une rétrogradation forcée au sein d’une forêt Active Directory.

{gallery}54_DCFORCEREMOVAL/04{/gallery}

 

 

 

 

 

 

 

 


L’assistant détecte ou non que votre contrôleur de domaine fait également office de serveur DNS et qu’il ne sera pas capable de supprimer de potentielles délégations DNS.

{gallery}54_DCFORCEREMOVAL/05{/gallery}

 

 

 

 


 

Comme toute rétrogradation, il faudra spécifier le mot de passe du nouveau compte d’administrateur local.

{gallery}54_DCFORCEREMOVAL/06{/gallery}

 

 

 

 

 

 

 

 


L’assistant terminera par un résumé pour ensuite débuter la rétrogradation forcée. Au redémarrage, le serveur n’est plus contrôleur de domaine.

{gallery}54_DCFORCEREMOVAL/07{/gallery}

 

 

 

 

 

 

 

 


Toutefois et comme nous vous le disions plus haut, il faut impérativement que le nettoyage des métadonnées  (metadata cleanup) de cet ancien contrôleur de domaine soit réalisé sur la forêt Active Directory. Cette opération est habituellement réalisée durant la rétrogradation mais, avec l’option « forceremoval », il faudra la réaliser manuellement. Vous pouvez consulter l’article « Supprimer un contrôleur de domaine corrompu (Active Directory Metadata Cleanup) » pour mener à bien cette opération.

Un autre point d’attention est le placement des maîtres d’opérations. Si l’ancien contrôleur de domaine en hébergeait un ou plusieurs, il faudra en faire la saisie. Pour cela, vous pouvez consulter l’article « Localiser et déplacer les maîtres d’opérations Active Directory ».

Remarque : la commande « netdom query /domain:[MONDOMAIN] fsmo » permet d’avoir la liste des maîtres d’opérations du domaine.