Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Gestion de WSUS en Powershell – Partie 4

1- Décliner des KB

Voici comment décliner toutes les KB de sécurité remplacées (Superseded).

# Decline Action
$KBState = $Wsus.GetStatus()
$DeclinedBefore = $KBState.DeclinedUpdateCount
$DeclineSupersed = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $True)}
$DeclineSupersed | ForEach-Object -Process {$_.Decline()}
$DeclinedAfter = $KBState.DeclinedUpdateCount

Write-Host "Before we had $DeclinedBefore KB declined, and now  $DeclinedAfter"

2 – Approuver des KB

 Pour approuver des KB de sécurité non approuvées et non remplacées.

# Approve Action
$AproveKB = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $false) -and ($_.IsApproved -eq $false) -and ($_.State -ne "NotNeeded")}
$MyTarget = $wsus.GetComputerTargetGroups() | Where-Object {$_.Name -eq "TEST-Workstations"}
$AproveKB[0].ApproveForOptionalInstall($MyTarget)

Attention dans l’exemple ci-dessus nous approuvons les KB « nécessaires » pour un groupe appelé « TEST-Workstations », pensez à modifier la variable « $MyTraget » avec le nom de votre ou vos groupes.

Exemple:

# Approve Action
$ApprovedKB = $Wsus.GetUpdates() | Where-Object {($_.UpdateClassificationTitle -eq "Security Updates") -and ($_.IsSuperseded -eq $false) -and ($_.IsApproved -eq $false) -and ($_.State -ne "NotNeeded")}
$MyTarget = $wsus.GetComputerTargetGroups() | Where-Object {$_.Name -eq "Prod_Servers"}
$AproveKB[0].ApproveForOptionalInstall($MyTarget)

 

Office 365 migration tenant-to-tenant – Retour d’expérience 1/3

Contexte

Cet article divisé en trois parties est un retour d’expérience sur une migration Office 365 tenant-to-tenant. La première partie traitera de l’architecture et des pré-requis à la migration. La seconde partie traitera du plan d’action et de la migration. Enfin la troisième partie traitera des problèmes rencontrés lors de celle-ci.

Architecture

L’architecture de cette migration est assez simple. Deux environnements similaires contenant chacun Active Directory, Azure AD Connect, ADFS et O365. Le but de la migration est de migrer l’ensemble des données du tenant A vers le tenant B. Les comptes Active Directory ne sont pas migrés et l’ADFS A sera toujours utilisé par les utilisateurs de l’Active Directory A. La synchronisation vers le tenant utilisera bien évidemment le serveur AD Connect B. Enfin les adresses emails garderont le même nom de domaine de la source vers la destination.

Figure 1 – Schéma source de l’architecture

schemaSource

Figure 2 – Schéma cible de l’architecture

schemaCible

Pré-requis

Le premier pré-requis est d’avoir une relation d’approbation inter-forêt entre les deux forêts AD.

La migration tenant-to-tenant nécessite également un outil tiers afin de migrer l’ensemble du contenu des boites aux lettres (emails, contacts, calendrier…).

Un nombre de licences suffisant dans le tenant B est également indispensable pour accueillir les comptes du tenant A.

Enfin il est important d’avoir un compte administrateur global utilisant le domaine par défaut de microsoft (@domaine.onmicrosoft.com).

 

Voilà qui conclut la première partie de mon retour d’expérience. Stay tuned!

Office 365 migration tenant-to-tenant – Retour d’expérience 2/3

Contexte

Cet article divisé en trois parties est un retour d’expérience sur une migration Office 365 tenant-to-tenant.. Voici la seconde partie qui traitera du plan d’action et de la migration.

Plan d’action

Lors de la migration les noms de domaine des adresses emails étant conservés, une coupure de service est obligatoire. Il est donc primordial de bien préparer la migration et d’effectuer en avance de phase toutes les tâches pouvant être traitées pré-migration.

Le plan d’action sera le suivant :

    1. Avoir un export de l’ensemble des données du tenant A. Pour chaque compte connaître son adresse de messagerie, ses alias, ses droits… Idem pour l’ensemble des objets Exchange (boites partagées, listes de distribution, contacts…)
    2. Créer des utilisateurs cloud uniquement dans le tenant B correspondant aux utilisateurs du tenant A. Exemple : john.doe@domainea.com aura un compte john.doe@domaineb.onmicrosoft.com
    3. Assigner des licences aux utilisateurs dans le tenant B
    4. Créer le reste des objets Exchange (attention certains objets peuvent-être synchronisés avec l’AD et d’autre uniquement dans le cloud) du tenant A dans le tenant B
    5. Commencer les migrations via l’outil de migration. Exemple : l’ensemble des mails plus vieux que les 30 derniers jours
    6. Arrêter la synchronisation de l’ensemble des objets de l’Active Directory A vers le tenant A (supprimer la synchronisation des OU dans Azure AD Connect A). L’ensemble des comptes dans le tenant A sont à présent en Soft-Deleted
    7. Utiliser la commande suivante pour restaurer l’ensemble des comptes en tant que comptes cloud uniquement :
      Get-MsolUser –ReturnDeletedUsers –All | Restore-MsolUser
      
    8. Supprimer l’ensemble des références aux noms de domaine présent sur le tenant A (alias, adresses SIP,…). Tous les objets doivent avoir uniquement des adresses avec l’adresse par défaut de Microsoft
    9. Supprimer les noms de domaine du tenant A
    10. Ajouter les noms de domaine sur le tenant B
    11. Modifier l’UPN des comptes cloud du tenant B pour qu’ils soient égaux aux UPN des comptes de l’Active Directory A.
    12. Créer un nouveau connecteur sur l’AD Connect B pour synchroniser les comptes de l’Active Directory A. Une fois la synchronisation terminée, les comptes cloud du tenant B ont fusionné avec les comptes de l’Active Directory A.
    13. Finaliser la migration via l’outil (attention, les adresses sources et destinations ont changé, il est peut-être nécessaire de les mettre à jour dans l’outil utilisé pour la migration)
    14. Mettre à jour l’ADFS A via les commandes suivantes :
      <pre class="wp-block-syntaxhighlighter-code">Set-MsolDomainFederationSettings –domainname "domainea.com" –ActiveLogOnUri "https://<url ADFS A>/adfs/services/trust/2005/usernamemixed" –issuerUri "http://<domainea.com>/adfs/services/trust/" –logoffuri "https://<url ADFS A>/adfs/ls/" –metadataexchangeuri "https://<url ADFS A>/adfs/services/trust/mex" –PassiveLogOnUri "https://<url ADFS A>/adfs/ls/"
      Update-MsolFederatedDomain –DomainName "domainea.com" –SupportMultipleDomain</pre>
      

 

Migration

La planification

La planification de la migration est importante. En effet lorsque l’on se réfère au plan d’action on remarque que beaucoup d’actions sont à faire pendant l’interruption de service (de l’étape 6 à l’étape 12). Il est donc important de bien planifier la migration sur un weekend et de vérifier qu’aucune autre action est prévue à cette date là (paye, bilan comptable…).

Il est également très important de communiquer avec les utilisateurs tout au long du projet. Expliquer pourquoi une telle migration (intégration de la messagerie dans la messagerie groupe par exemple), bien indiquer les dates de la migration, prévenir de l’interruption de service et informer des éléments qui ne sont pas pris en compte par cette migration (signature…).

Y penser !

Une fois la migration terminée, le support utilisateur peut être amener à avoir une surcharge de travail. Avoir une équipe renforcée lors des premiers jours post-migration aidera grandement à la résolution des problèmes et à la gestion du stress des équipes.

Les actions post-migrations

Une fois la migration terminée, certaines actions sont nécessaires côté utilisateur (création d’un nouveau profil sur Outlook par exemple) mais aussi côté administrateur (donner de nouveaux droits d’administration aux équipes sur le tenant B par exemple).

Mettre en place un fichier de suivi pour les problèmes rencontrés est fortement conseillé. Cela permet de centraliser et donc de faciliter la résolution des problèmes et de ne pas oublier certains points (notamment si c’est un problème mineur).

 

Voilà qui conclut la seconde partie de mon retour d’expérience. Stay tuned!