PI Services

Le blog des collaborateurs de PI Services

Exchange 2013 CU8 – Le service Microsoft Exchange Search Host Controller ne démarre pas

Contexte

Sur un serveur Exchange 2013 (CU8), le service Microsoft Exchange Search Host Controller ne démarre pas et dans le journal d’évènements l’erreur suivante est présente :

Source : Application Error
Evènement : 1000
Nom de l’application défaillante hostcontrollerservice.exe
 

2015-05-13_183652

Solution

Le problème semble provenir d’une corruption des fichiers du dossier <X:>\Program Files\Microsoft\Exchange Server \V15\Bin\Search\Ceres\HostController\Data.

Il existe un script Exchange qui reconstruit ce dossier. Pour ce faire, renommez l’ancien dossier Data en DataOld.

2015-05-13_183745

Puis lancez les commandes suivantes dans une console PowerShell Exchange :

  • cd X:\Program Files\Microsoft\Exchange Server \V15\Bin\Search\Ceres\Installer
  • .\installconfig.ps1 –action –i –dataFolder X:\Program Files\Microsoft\Exchange Server \V15\Bin\Search\Ceres\HostController\Data
    La commande renvoi un Successfully configured Search Foundation for Exchange.

2015-05-13_183755

Le service a normalement démarré automatiquement.

2015-05-13_183828

Exchange 2013 CU6 – Le service Microsoft Exchange Replication ne démarre plus

Contexte

Sur un serveur Exchange 2013 CU6, le service Microsoft Exchange Replication ne démarre pas et dans le journal d’évènements l’erreur suivante est présente :

Source : MSExchangeRepl
Event ID : 4401
Microsoft Exchange Server Locator Service failed to find active server for database <MailboxDatabase GUID>. Error: An Active Manager operation failed. Error: Invalid Active Manager configuration. Error: Active Manager hasn't completed configuration initialization.

De plus la commande Get-MailboxDatabaseCopyStatus renvoie toutes les bases en ServiceDown.

image001

Solution

Ce problème provient d’anciennes entrées corrompues dans le journal d’évènements (dans le crimson channel log plus précisément).

L’installation du CU7 d’Exchange 2013 résout ce problème. Cependant si vous souhaitez résoudre le problème sans passer le CU7, suivez la procédure ci-dessous.

Depuis un invite de commande (en administrateur) lancez la commande suivante :

Wevtutil.exe cl “Microsft-Exchange-MailboxDatabaseFailureItems/Operational”

image003

Le service redémarre automatiquement et les réplications entre les MailboxDatabases reprennent normalement.

image004

Mise à jour d’un service dans SCVMM 2012

 

Nous avons une VM associée à un service. Nous allons ici mettre à jour le service en installant une application virtualisée : SumatraPDF

Notre service nommé Generic Server 2K12 a été installé à partir du service Template ST –Generic Server 2K12.

image

Pour mettre à jour notre service, nous allons dupliquer le service Template ST –Generic Server 2K12, effectuer notre modification sur celui-ci et ensuite l’appliquer à notre service en production.

Aller sur le service Template à éditer

image

Faites un clic droit et cliquer Copy

image

Une copie apparait dans la console.

image

Sur celui-ci à l’aide d’un clic droit allez dans Open Designer

image

La fenêtre d’édition du service Template apparait

Double-cliquer sur votre service Template

image

 

Aller dans la section Application Configuration et cliquez sur Add et sélectionner Virtual application

image

 

Cliquez sur Browse

image

Sélectionner votre Package. Pour l’exemple, nous allons sélectionner notre package correspondant à SumatraPDF.

Cliquez sur OK.

image

 

Donnez un nom à votre application virtuelle et cliquez sur ok.

image

Cliquez maintenant sur Save and Validate.

image

 

Faites maintenant un clic droit sur le service Template dupliqué et cliquer sur Publish.

image

Nous allons maintenant appliquer notre service Template sur le service en production.

Remarque : pour que la modification apportée sur le service soit effective, il faut que la/les VM présente sous le service dispose(nt) de l’agent App-V. (Celui-ci est présent dans la librairie VMM)

Affichez les services et faites un clic droit sur le service à updater et sélectionner Set Template

image

Cliquez sur Browse pour sélectionner le service précédemment configuré.

image

 

Cliquer sur Next

image

Sélectionner Apply updates to existing to virtual machines in-place et cliquer sur Next.

Cocher la case Apply the updates et cliquer sur Next puis sur Finish

image

Le job se lance.

image

Une fois celui-ci finit, rendez vous sur la / les VMs concernés.

SumatraPDF s’est bien installé sur l’ensemble des VMs de notre service.

image

ADFS / Yammer : Renouvellement des certificats

Introduction

Cet article est un retour d'expérience sur un incident rencontré dans le cadre d'une infrastructure ADFS possédant une fédération avec Yammer. Ce dernier s'est produit lors du renouvellement de certains certificats de l'environnement ADFS. L'authentification unique n'était plus fonctionnelle. En effet, une mise à jour doit être réalisée du côté de Yammer lorsque l'un des certificats ADFS est renouvelé. Pour rappel, contrairement à d'autres services qui peuvent être fédérés (comme Office 365), il n'est pas possible de configurer automatiquement le SSO. Cette opération doit être réalisée via une demande au support Office 365.

 

Dans un premier temps, il sera question de faire quelques rappels sur les certificats ADFS puis d'étudier leurs renouvellements. Enfin, nous verrons comment mettre à jour Yammer pour que le l'authentification ne soit pas indisponible lorsque les certificats sont renouvelés. Ce dernier nous permettra de voir comment gérer les certificats avec des services fédérés qui ne peuvent pas récupérer les métadatas automatiquement.

 

Cette manipulation a été réalisée sur une infrastructure sous Windows 2012 R2 (ADFS 3.0).

 

ADFS

Dans une infrastructure ADFS, 3 certificats sont nécessaires au bon fonctionnement de celle-ci :

  • Un certificat public portant le nom DNS du service de fédération. Il s'agit d'un certificat web permettant de sécuriser les communications via SSL.

  • Un certificat auto-généré de type X.509 permettant de signé les tokens d'authentification (Token-Signing). Celui-ci permet de certifier que le token provient bien de la ferme ADFS.

  • Un certificat auto-généré de type X.509 permettant de décrypter des tokens (Token-Decrypting) provenant d'un autre fournisseur de revendications.

Renouvellement du certificat Service-Communications

Le renouvellement pour le certificat public de type Service-Communications se fait manuellement. Lorsque vous posséder votre nouveau certificat, il est nécessaire de l'importer dans le magasin personnel de l'ordinateur des serveurs ADFS (comme lors de la configuration d'ADFS) et des serveurs Web Application Proxy (si vous en posséder) .

 

Sur les serveurs ADFS, lorsque le certificat est importé, il faut ajouté les permissions de lecture sur la clé privée. Pour réaliser cette opération, il faut effectuer un clic droit sur le certificat (lorsque l'on se trouve dans le magasin personnel de l'ordinateur) puis choisir “All Tasks” puis “Manage Private Keys”.

 

03

 

Dans l'onglet sécurité, il suffit d'ajouter les comptes “NT Service\ADFSSRV” et “NT Service\DRS” (pour la fonctionnalité Workplace Join) puis d'attribuer le droit “Read”. Attention, cette opération est à réaliser sur l'ensemble des serveurs de la ferme ADFS.

 

02

 

Les commande Powershell ci-dessous nous permettent ensuite de mettre à jour la configuration des serveurs ADFS.

 

Sur les serveurs ADFS :

 

On récupère, le certificat en utilisant la commande suivante :

 

Cette dernière permet d'interroger le magasin personnel de l'ordinateur (pensez à remplacer NOM_DNS_FERME_ADFS par le nom de votre ferme de serveurs ADFS). Il est nécessaire de récupérer la valeur de l'attribut thumbprint (Pour rappel, ce champ est unique pour chaque certificat).

 

Ensuite, on modifie la configuration du service ADFS pour utiliser notre nouveau certificat en spécifiant la valeur de l'attribut thumbprint.

 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Sur chacun des serveurs ADFS d'une ferme, il faut exécuter la commande ci-dessous pour mettre en place le bindings HTTPS avec le nouveau certificat :

 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Enfin, il est nécessaire de redémarrer le service ADFS sur chacun des serveurs de la ferme.

 

On peut ensuite vérifier les valeurs grâce aux commandes suivantes :

 
 

La seconde cmdlet doit être exécuté sur chacun des serveurs de la ferme ADFS pour effectuer une vérification complète.

 

Les serveurs Web Applications Proxy se mettent à jour via les commandes suivantes :

 
 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Tout d'abord on change le certificat. Dans un second temps, on redémarre le service ADFS pour que le changement de configuration soit pris en compte. Ces deux commandes sont à exécuter sur chacun des serveurs Web Applications Proxy que vous possédez.

 

Renouvellement des certificats Token-Signing et Token-Decrypting

Au sujet, des autres certificats, il existe deux possibilités :

  • Renouvellement manuel

  • Renouvellement automatique

Le renouvellement automatique est la configuration par défaut d'ADFS. 20 jours avant l'expiration d'un certificat, ADFS en génère un nouveau. Celui-ci possède le statut de certificat secondaire. Au bout de 5 jours (soit 15 jours avant l'expiration du certificat), il est promu comme certificat primaire.

 

Les paramètres d'auto renouvèlement se consultent/configurent via Powershell. Pour cela, il faut utiliser la commande “Get-ADFSProperties”. C'est l'attribut AutoCertificateRollover qui permet de déterminer si l'auto renouvèlement des certificats de type Token-Signing et Token-Decrypting est activé.

 

Voici les paramètres ADFS qui peuvent être modifiés par la commande Set-ADFSProperties et qui concernent le mécanisme évoqué précédemment :

  • CertificateDuration : Durée de validité d'un certificat auto généré (par défaut : 365 jours)

  • CertificateGenerationThreshold : Nombre de jours avant la génération d'un nouveau certificat Token Signing or Token Decrypting (par défaut 20).

  • CertficatePromotionThreshold : Nombre de jours avant la promotion du nouveau certificat (passage du status Secondary au status Primary, valeur par défaut : 5 jours).

  • CertificateRolloverInterval : Interval de temps (en minutes) entre chaque vérification de la validité d'un certificat (par défaut 720 minutes).

  • CertificateCriticalThreshold : Nombre de jours avant qu'un certificat expire et qu'un renouvèlement critique ne soit déclenché (ce paramètre intervient lors d'un problème avec le système d'auto renouvellement).

Point d'attention :

Lors du renouvèlement d'un certificat, les métadatas changent. Aussi, si l'un des relying party trust n'est pas capable de récupérer par lui même les métadatas alors l'authentification ne sera plus fonctionnelle.

 

Yammer

La configuration de l'authentification unique via Yammer se fait manuellement. Il est nécessaire d'ouvrir un ticket auprès du support. Celle-ci ne nécessite pas d'envoyer les certificats mais simplement les métadatas. Néanmoins lorsque les certificats ADFS se renouvèlent, il est nécessaire de les transmettre au support Yammer via une demande de service sur le portail d'administration Office 365. Pour se faire, il suffit de créer une archive contenant les nouveaux certificats et de les joindre…

 

Cependant, il peut arriver que le délais soit trop court pour que le ticket soit traité à temps par le support si l'on se trouve presque à la fin de la période de 5 jours après le renouvellement des certificats (voir paragraphe précédent) ou pire, si le nouveau certificat a déjà été défini comme certificat primaire. Ce dernier cas aura pour effet de couper totalement l'authentification unique auprès de Yammer et ainsi causé une coupure de service pour les utilisateurs. En effet, Yammer n'est pas capable de récupérer les nouvelles métadatas contenant les nouvelles informations des certificats.

 

Dans ce cas, on obtient l'erreur ci-dessous lorsque l'on essaie de s'authentifier :

 

01

 

De plus dans l'observateur d'évènements, on remarque des events avec l'id 364 avec pour message :

Lorsque ce problème est rencontré, il faut transmettre le nouveau certificat au support Office 365, ce qui peut peut demander un temps de traitement long. Cependant, si l'ancien certificat est encore valide (c'est à dire qu'il est passé en statut secondaire), il existe une méthode pour rétablir le service temporairement pendant la durée de validité dudit certificat. Pour ce faire, il faut repasser le certificat en statut primaire. Cette opération peut être réalisée via la console graphique.

 

Dans la console ADFS Management, il faut se rendre dans la section “Service” puis “Certificate” puis effectuer un clic droit sur le certificat concerné et choisir l'option “Set as Primary”. Celle-ci peut être grisée. Cela survient lorsque le renouvellement automatique est activé. Il faut donc le désactiver temporairement via la commande suivante :

 

Lorsque le certificat sera de nouveau en statut primaire, le service sera rétabli. Attention, n'oubliez pas de changer le certificat primaire lorsque le support Office 365 vous aura informé de la prise en compte du nouveau certificat.

WINRM : Error 2147749890

Aujourd’hui mon blog va porter sur l’erreur WINRM : 2147749890                    que l’on peut retrouver sur tout les serveurs de :                                                                                                                                 - Windows 2003 SP2 à Windows 2012 R2. Même en regardant dans l’observateur d’évènement ID 4 qui correspond à une solution TechNet qui n’est pas adapter à la situation.

PERIMETRE: Dans le cadre de l’organisation des reboots de serveurs chez un de nos client, j’ai mis en place une vérification Post-démarrage de ces serveurs.

Voici la commande du script powershell qui permet de vérifier si le service MSDTC commun à tout les serveurs de Windows 2003 SP2 à Windows 2012 R2.

MON SCRIPT DE BASE:

######SERVEURS A REDEMARRER################

$Computerdestination = "SRV02"

###SERVICES A ARRETER, REDEMARRER ou VERIFER##

$Servicesname = "MSDTC"

######LOG CREER POUR LA VERIFICATION DES SERVICES SUR CHAQUES SERVEURS + GESTION ERREUR ###

$StatusSvcRebootSRV = $NULL                                                                                $StatusSvcRebootSRV =

try {

Invoke-Command -ScriptBlock {param($ServicesName) Get-Service $ServicesName -ErrorAction stop | select PScomputerName,Status,Name   } -ArgumentList $ServicesName -ComputerName $Computerdestination 

}catch{

"error : " + $error[0]

}       

#GESTION ERREUR DES SERVICES

$ExitCodeService =

try {

if ($($StatusSvcRebootSRV.Status.value) -eq "Running") {

"success : $Computerdestination or $Servicesname"    

} else {

"error : " + $error[0]

}

}catch{

"Error : Syntaxe command ExitCodeService "

}   

$ExitCodeService

RESULTAT: malgré winrm activer et enable-psremoting + port 5985 ok

clip_image001[11]

-SessionOption (New-PSSessionOption -NoMachineProfile) qui a permis de résoudre le problème

 

MON SCRIPT CORRIGE BASE:

######SERVEURS A REDEMARRER################

$Computerdestination = "SRV02"

###SERVICES A ARRETER, REDEMARRER ou VERIFER##

$Servicesname = "MSDTC"

######LOG CREER POUR LA VERIFICATION DES SERVICES SUR CHAQUES SERVEURS + GESTION ERREUR ###

$StatusSvcRebootSRV = $null

$StatusSvcRebootSRV =

try {

Invoke-Command -ScriptBlock {param($ServicesName) Get-Service $ServicesName -ErrorAction stop | select PScomputerName,Status,Name   } -ArgumentList $ServicesName -ComputerName $Computerdestination -SessionOption (New-PSSessionOption -NoMachineProfile)

}catch{

"error : " + $error[0]

}       

#GESTION ERREUR DES SERVICES

$ExitCodeService =

try {

if ($($StatusSvcRebootSRV.Status.value) -eq "Running") {

"success : $Computerdestination or $Servicesname"

                                    } else {

"error : " + $error[0]

                                    }

}catch{

"Error : Syntaxe command ExitCodeService "

}   

$ExitCodeService