Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Zabbix API with Powershell – Example

par | 19 Déc 2018 | , ,

L’API de Zabbix, basée sur le standard JSON-RPC 2.0 peux bien sur etre intérrogée aussi avec Powershell.

 Ci-dessous un script montrant le principe d’interrogation de l’API, en recuperant certaines infos.

 Vous devez renseigner un compte (<my_zabbix_account>) avec au minimum les droits de lecture sur Zabbix, et le nom ou l’ip du serveur Front Web (<zabbix_frontweb_server>).

 

<pre class="wp-block-syntaxhighlighter-code">### Query Zabbix Through native zabbix json api

    $credential = Get-Credential -Credential "my_zabbix_account"

$baseurl = 'https://<name_or_ip_of_front_server>/zabbix'
$params = @{
    body =  @{
        "jsonrpc"= "2.0"
        "method"= "user.login"
        "params"= @{
            "user"= $credential.UserName
            "password"= $credential.GetNetworkCredential().Password
        }
        "id"= 1
        "auth"= $null
    } | ConvertTo-Json
    uri = "$baseurl/api_jsonrpc.php"
    headers = @{"Content-Type" = "application/json"}
    method = "Post"
}

[System.Net.ServicePointManager]::SecurityProtocol = 'tls12'
[Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

$result = Invoke-WebRequest @params -UseBasicParsing



$params.body = @{
    "jsonrpc"= "2.0"
    "method"= "host.get"
    "params"= @{
        output = "extend"
		selectFunctions = "extend"
		selectLastEvent = "extend"
		selectGroups = "extend"
		selectHosts = "extend"
    }
    auth = ($result.Content | ConvertFrom-Json).result
    id = 2
} | ConvertTo-Json

$result = Invoke-WebRequest @params -UseBasicParsing
$result = $result.Content | ConvertFrom-Json</pre>

 

 

 

Active Directory : Migration SYSVOL de FRS vers DFS-R – Etape Eliminated (Partie 5)

par | 21 Nov 2018 | , , , , ,

Bonjour à tous,

Aujourd’hui nous abordons la partie 5 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à la dernière étape Eliminated.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
  Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
  Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
  Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l’état 3 (Eliminated) n’est pas le plus impactant :
  • En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL (cette copie étant devenue depuis l’étape Redirected celle utilisée par les services AD DS), la version répliquée par le mécanisme FRS est supprimée.
  • En façade, c’est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
Il faut souligner les points suivants :
  • Tout retour arrière est impossible une fois cette etape éffectuée.
  • Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant de supprimer la version répliquée par FRS. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
  • Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC.

En pratique

Etat Redirected

Si l’étape précédente a été correctement réalisée, l’état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Redirected.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l’état Eliminated.

Passage vers l’état Eliminated

Etat global (Domaine AD) : dfsrmig /setglobalstate 3

Le passage vers l’état Eliminated est bien indiqué ainsi que son irréversibilité.
Si malgré un certain délai, les RODCs ne passent pas en état Eliminated, il faudra forcer la suppression des objets FRS correspondant avec la commande dfsrmig /DeleteRoNtfrsMember (à éxécuter seulement une fois depuis le PDC)
 

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n’est dans l’état defini au niveau du domaine Active Directory (Etat Global).

Etat Eliminated atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l’état de migration au niveau du domaine Active Directory à Eliminated. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Le message est explicite, tous les contrôleurs de domaine sont dans l’état Eliminated, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
A partir de ce moment, la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R est officiellement terminée.
 
Bonus :
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l’évènement 8019 dans le journal d’évènements Applications and Servicies logs -> DFS Replication

La console DFS Management pour le groupe de réplication Domain System Volume nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.

 

Exchange 2010 – Erreur de synchronisation des bases après la migration d’un serveur Mailbox virtualisé

par | 12 Nov 2018 |

Contexte

Après la migration d’un serveur Mailbox virtualisé vers un nouvel hoster, la réplication des bases Exchange ne fonctionne plus et le message d’erreur suivant est présent lorsque la commande Test-ReplicationHealth est utilisée :

The log copier was unable to continue processing for database DAG\MBX because an error occured on the target server: Continuous replication – block mode has been terminated. Error : the log file sector size does not match the current volume’s sector size (-546)

Problèmatique

Ce problème est causé par un changement de la taille de secteur physique des disques sur lesquels les bases sont. Le problème intervient lorsque le nouvel hoster est plus récent que l’ancien et qu’il ne possède pas le même firmware pour le stockage. Exchange n’est pas en capacité de supporter automatiquement le changement d’un disque avec des secteurs de 512 bytes vers un disque avec des secteurs de 4096 bytes.

Pour vérifier cela, lancer la commande suivante : fsutil fsinfo ntfsinfo <Disk>

On remarque que le paramètre Bytes Per Physical Sector n’est pas supporté.

Solution

La solution pour reprendre la synchronisation des bases est de désactiver la réplication granulaire dans un premier temps. Pour cela, créer la clé de registre DWORD suivante avec la valeur 1 :

HKLM\Software\Microsoft\ExchangeServer\v14\Replay\Parameters\DisableGranularReplication

Après avoir redémarré le serveur, si on relance la commande fsutil fsinfo ntfsinfo <Disk> le paramètre Bytes Per Physical Sector accepte désormais les secteurs en 4096 bytes.

A la suite de ce changement, la réplication fonctionne de nouveau correctement.

Remarque : Attention, Microsoft ne supporte pas que la méthode de réplication ne soit pas la même sur l’ensemble des noeuds d’un DAG. Il est donc nécessaire de revenir en arrière une fois le changement effectué ou de désactiver la réplication granulaire sur l’ensemble des noeuds.

L’ensemble de ce problème est expliqué plus en détails sur le lien TechNet : https://blogs.technet.microsoft.com/exchange/2013/04/24/exchange-2010-database-availability-groups-and-disk-sector-sizes/

Derniers articles

Catégories

Archives

Auteurs/Autrices