PI Services

Vérification de l’application d’une GPO (Heure de la dernière application de la stratégie de groupe)

Il est possible de vérifier la dernière fois que les stratégies de groupe ont été appliquées avec la commande Gpresult

Pour cela, il suffit de lancer une fenêtre de commande cmd, exécuter ensuite la commande GPresult :

Le résultat de la commande est composé de deux parties :

· Paramètre de l'ordinateur : liste les GPO appliquées au compte ordinateur.

· Paramètre Utilisateur : liste les GPO appliquées au compte utilisateur.

L’utilisation de cette commande nous permet de valider la liste des GPO’s liées aux compte ordinateur et utilisateur et nous permet aussi de valider l’heure de la dernière application de celles-ci.

Pour cela, il suffit de vérifier la ligne «Heure de la dernière application de la stratégie de groupe » :

· Capture écran Paramètre ordinateur :

· Capture écran paramètre utilisateur :

A bientôt

Khalil Bezneiguia

Pour vérifier la santé de l’Active Directory on utilise habituellement un outil

en ligne de commande tel que  REPADMIN.

Microsoft met à disposition un outil graphique, Active Directory Replication Status Tool.

Cet outil s’installe sur plusieurs version d’OS Windows (prérequis .Net Framework 4.0).

Après installation de l’outil, lancez la console.

Cliquez sur Refresh Replication Status

Ce type de résultat est retourné:

Dans ce cas il n’y a pas d’erreur.

En fonction des erreurs liées au “Tombstone LifeTime”, les informations prendront une couleur diffèrente.

Pour rappel le “Tombstone LifeTime” est de 180 jours depuis Windows 2003 SP1.

On peut modifier les colonnes à afficher par un clique droit dans l’une des colonnes :

Le rapport peut être exporté:

N’hésitez pas à installer cet outil que vous pourrez télécharger depuis ce lien:

http://www.microsoft.com/en-us/download/details.aspx?id=30005.

La commande “Switchover server” permet de basculer les banques actives

vers un serveur de destination.

Ayant rencontré à de maintes reprises des soucis lors de l���utilisation de cet utilitaire

j’ai préféré utiliser un script.

*********************************************************

######## Move database
######## Ce script permet le déplacement des banques actives d'un serveur "A" vers un serveur "B"
######## Ecrit par Pascal FEDAN
######## Le 05 Novembre 2012
######## Version 1.0
######## Modifié le
######## Version

######## Déclaration des serveurs source et cible

$sourceserver = "serveur2"
$targetserver = "serveur1"

####### Fonction d'envoi d'un message

function sendmail {
         send-mailmessage -from "adm_mail@pub.ad" -to "Franck.Test@pub.ad" -subject "MoveDatabase" -body " Merci de consulter le fichier." -Attachment "C:\Temp\databasecopystatus.txt" -priority High -dno onSuccess, onFailure -smtpServer 10.10.10.10
                  }
####### Statut des bases avant la bascule

get-Date >> c:\Temp\databasecopystatus.txt
Write-output "########## Databasecopystatus avant le déplacement " >> c:\Temp\databasecopystatus.txt
Write-output " " >> c:\Temp\databasecopystatus.txt

get-mailboxdatabasecopystatus -Server $sourceserver >> c:\Temp\databasecopystatus.txt

Write-output " " >> c:\Temp\databasecopystatus.txt

get-mailboxdatabasecopystatus -Server $targetserver >> c:\Temp\databasecopystatus.txt

######### recherche des banques "montées" sur le serveur source

$MountedDB=get-mailboxdatabasecopystatus -Server $sourceserver | where { ($_.Status -eq "Mounted")}

########  si aucune banque "montée", sortie du script

if (!$MountedDB) { Write-Host "PAS DE BANQUE ACTIVE SUR $sourceserver"
                   Write-output " " >> c:\Temp\databasecopystatus.txt
                   Write-output "########## PAS DE BANQUE ACTIVE SUR $sourceserver " >> c:\Temp\databasecopystatus.txt
                   Write-output " " >> c:\Temp\databasecopystatus.txt
                   sendmail
                   exit
                  }
                           
######### bascule des banques

else {
      Foreach ($DB in $MountedDB)
         { Move-ActiveMailboxDatabase -Identity $DB.DatabaseName -ActivateOnServer $targetserver -MountDialOverride:None -confirm:$false >> c:\Temp\databasecopystatus.txt}
      }
     
Start-Sleep -s 30

######### statut des banques après la bascule

Write-output " " >> c:\Temp\databasecopystatus.txt
Write-output "########## Databasecopystatus après le déplacement" >> c:\Temp\databasecopystatus.txt
Write-output " " >> c:\Temp\databasecopystatus.txt

get-mailboxdatabasecopystatus -Server $sourceserver >> c:\Temp\databasecopystatus.txt

Write-output " " >> c:\Temp\databasecopystatus.txt

get-mailboxdatabasecopystatus -Server $targetserver >> c:\Temp\databasecopystatus.txt

######## Appel de la fonction sendmail

sendmail

***********************

Ce script recherche les banques actives et les bascule sur le serveur de destination

mentionné dans la déclaration des variables.

Bien sûr, testez avant de l’utiliser en production.

Le script suivant:

- envoi un mail a un responder (ping@oleane.net)

- attends et récupère la réponse du responder dans Outlook

- retourne un état en cas d’echec

- retourne un état et le message en cas de succes, et supprime le message.

Prerequis: client outlook installé avec le composant “Visual Basic for application” et présence de l’assembly .net Microsoft.Office.Interop.Outlook (cette assembly est présente dans le dossier C:\Windows\assembly).

Dans le menu Outil/Macro/Sécurité , cochez l’option ci-dessous

Paramètre de script a modifier:

$smtpServer: le nom du serveur smtp

$From: l’emeteur du mail

$ReplyTo: l’adresse de réponse

$Dest: le destinataire du mail

$Subject: le sujet du mail

$Body: le corp du mail

$SecondToWait: le temps d’attente de la réponse du responder

[System.Reflection.Assembly]::Load("Microsoft.Office.Interop.Outlook, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")

    [string]$smtpServer=”mon_serveur_smtp@home.fr”

    [string]$From="test@home.fr"

    [string]$ReplyTo="test@home.fr"

    [string]$Dest="ping@oleane.net"

    [string]$Subject="Test envoi mail"

    [string]$Body="Test envoi mail"

    [string]$SecondToWait =90

 

function sendMail

{

     Write-Host "Sending Email"

     #Creating a Mail object

     $msg = new-object Net.Mail.MailMessage

     #Creating SMTP server object

     $smtp = new-object Net.Mail.SmtpClient($smtpServer)

     #Email structure

     $msg.From = "$From"

     $msg.ReplyTo = "$ReplyTo"

     $msg.To.Add("$Dest")

     $msg.subject = "$Subject"

     $msg.body = "$Body"

     #Sending email

     $smtp.Send($msg)

}

Function Get-MessageInBox

{

Add-type -assembly "Microsoft.Office.Interop.Outlook" | out-null

$olFolders = "Microsoft.Office.Interop.Outlook.olDefaultFolders" -as [type]

$outlook = new-object -comobject outlook.application

$namespace = $outlook.GetNameSpace("MAPI")

write-host "waiting for the response from Oleane..."

$namespace.SendAndReceive($false)

sleep -Seconds $SecondToWait

$folder = $namespace.getDefaultFolder($olFolders::olFolderInBox)

$folder.items |

Select-Object -Property * -Last 1 | where-object {$_.subject -eq "[echo] Votre message a $Dest"}

}

 

Function Delete-mail

{

Add-type -assembly "Microsoft.Office.Interop.Outlook" | out-null

$olFolders = "Microsoft.Office.Interop.Outlook.olDefaultFolders" -as [type]

$outlook = new-object -comobject outlook.application

$namespace = $outlook.GetNameSpace("MAPI")

$folder = $namespace.getDefaultFolder($olFolders::olFolderInBox)

$folder.items | Select-Object -Property * -Last 1 | where-object {$_.subject -eq "[echo] Votre message a $Dest"} | tee-object -Variable MessageToDelete

$folder.Items.Remove(1)

}

#Calling function sendmail

sendMail

#Retrieve message to oleane in inbox

Get-MessageInBox | Tee-Object -Variable Message | out-null

if ($Message -eq $null)

{

write-host -ForegroundColor Darkred "---PAS ENCORE DE REPONSE DE $Dest---"

}

else

{

write-host -ForegroundColor Darkgreen "---REPONSE OK DE $Dest---"

Write-Host -ForegroundColor Darkgreen "----MESSAGE----:"

Write-Host "SUJET:" $Message.Subject

Write-Host "ENVOYE LE:" $Message.SentOn

Write-Host "RECU LE:" $Message.ReceivedTime

Write-Host "CORP DU MESSAGE:" $Message.Body

Clear-Variable -Name Message

Write-Host -ForegroundColor Yellow "SUPPRESSION DU MESSAGE..."

Delete-mail | Out-Null

}

A la sortie d’Exchange 2010 convertir par exemple une “linked mailbox” vers une

“user mailbox” impliquez la suppression de la boite puis de réaliser une reconnexion.

Le SP2 offre la possibilité par “powershell” de modifier le type de boite.

Voici une boite liée:

On constate visuellement ainsi qu’en utilisant le “powershell” que c’est une “linkedmailbox”.

On exécute la commande pour réaliser la conversion (set-user):

On remarque visuellement ainsi qu’en utilisant le  “powershell” que le boite est maintenant de type “usermailbox”.

Et voilà.

Microsoft stipule que les permissions Send As, Full Access, partages,etc sont perdues.

Pour ma part je ne l’ai pas constaté.

L’ouverture de cette boite n’est pas toujours instantanée (réplication des informations).

Référence : http://technet.microsoft.com/en-us/library/bb201694.aspx

Symptôme

Lors d’un déploiement d’Exchange Server 2010 SP2 avec RU4v2 (rollup stocké dans le sous-dossier Updates des sources Exchange), j’ai rencontré l’erreur suivante durant l’installation du rôle Hub :

Service “MSExchange Transport” failed to reach status “Running” on this server.

Voici le détail de l’erreur dans le journal Application :

Cette erreur à l’installation peut être considéré comme un “classique” d’Exchange 2010 lorsqu’une mauvaise configuration IPv6 est positionnée sur le serveur (cf. ce billet réalisé peu après la sortie d’Exchange 2010 : http://blog.piservices.fr/post/Exchange2010-Erreur-lors-de-linstallation-du-role-de-transport-Hub.aspx).

Néanmoins dans ce cas précis l’erreur n’était pas liée à la configuration IPv6 (interface réseau et clé de registre DisableComponents correctement configurés).

Après investigation l’erreur d’installation s’accompagnait de plusieurs évènements autour du service AD Topology dont le suivant :

Event ID: 2080
Source: MSExchange ADAccess
Task Category: Topology
Level: Information
Error:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=2386). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
dc01.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc02.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc03.domain.lan CDG 1 7 7 1 0 0 1 7 1
Out-of-site:
dc05.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc06.domain.lan CDG 1 7 7 1 0 0 1 7 1

Explication

Après investigation il s’avère que le problème d’installation est dû à un droit manquant sur la stratégie de groupe Default Domain Controllers Policy  pour le groupe Exchange Servers.

Pour rappel le groupe Exchange Servers est créé lors de la phase de préparation de l’annuaire Active Directory pour Exchange 2010 (ou Exchange 2007) et plus exactement via la commande setup.com /PrepareAD.

Lors de la phase de préparation des domaines via la commande setup.com /PrepareDomain la GPO Default Domain Controllers Policy de chaque domaine est modifiée de manière à donner le droit Manage auditing et security log au groupe Exchange Servers.

Dans le cas rencontré ici ce droit était manquant (d’où la présence d’un zéro dans la colonne SACL right lors de la détection des contrôleurs de domaine par le service de détection de la topologie Active Directory).

Résolution

Pour résoudre le problème rencontré la stratégie de groupe GPO Default Domain Controllers Policy est éditée via la console Group Policy Management Editor. Le droit manquant est situé dans l’emplacement suivant :

Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / user Rights Assignments

Il faut modifier le paramètre Manage auditing and security log et y ajouter le groupe nommé “Domaine racine \ Exchange Servers”.

Une fois la modification de stratégie de groupe prise en compte (comptez quelques minutes), l’instalation du rôle Hub Transport peut être relancée et cette fois-ci se déroule sans encombres.

Pour aller plus loin, vous pouvez consulter les articles suivants :

http://blogs.technet.com/b/richardroddy/archive/2010/06/16/msexchange-adaccess-dsaccess-errors-and-the-manage-auditing-and-security-right.aspx

http://jasonshave.blogspot.fr/2010/04/dscenosuitablecdc-error-with-exchange.html

http://blog.mattsampson.net/index.php/exchange-hogging-dc-s-and?blog=1

Introduction

Dans le cadre d’un POC (proof of concept) ou bien tout simplement dans le cadre d’un rapprochement entre deux sociétés (fusion / acquisition), il peut être nécessaire de déployer Lync Server 2010 dans une forêt distante.

S’il s’agit d’un POC, l’intérêt de monter une forêt dédiée à Lync 2010 est généralement de ne pas impacter l’environnement de production (Lync nécessitant une extension du schéma Active Directory) et donc de permettre un retrait / une désinstallation facile de Lync dans l’hypothèse où le produit ne serait pas retenu à l’issue de la phase de test.

S’il s’agit d’une fusion entre deux sociétés ou tout simplement d’une société disposant de plusieurs forêts (reliées entre elles par le biais de relations d’approbation) on déploie généralement Lync dans une seule forêt (la forêt “principale” ou bien la forêt de ressources le cas échéant) pour éviter de multiplier les serveurs.

Quel que soit le cas de figure, à un moment donné l’administrateur se retrouve contraint de donner un accès à des serveurs Lync dans une forêt B sur ses utilisateurs de la forêt A.

Ce billet a pour but de lister l’ensemble des contraintes et actions à prendre en compte dans un tel scénario.

Points à prendre en compte

Les points à prendre en considération (par rapport à un déploiement de Lync en environnement mono-forêt et mono-domaine) sont les suivants :

• Une relation d’approbation (de type inter forêt) doit exister entre les deux forêts
• Les comptes utilisateurs de la forêt A doivent être provisionnés dans la forêt B par le biais d’un outil tél qu’ADMT (si la population est réduite) ou bien via un outil de synchronisation de compte tel que FIM (si l’environnement est de plus grande taille)
• L’outil de provisionnement des comptes doit migrer l'attribut SID du compte source dans l’attribut SIDHistory des comptes cible. Il est conseillé de désactiver les comptes présents dans la forêt cible pour des raisons de sécurité (de la même manière que pour une boîte aux lettres Exchange 2010 de type “linked”)
• Un script doit ensuite être développé pour copier le SID source dans l’attribut msRTCSIP-OriginatorSid du compte utilisateur
• Les certificats utilisés sur les serveurs frontaux et Edge Lync 2010 devront être émis par une infrastructure PKI reconnue comme de confiance par les clients des deux forêts

L’intégration du composant Lync au Webmail Exchange 2010 est possible quelle que soit la forêt dans laquelle est déployée Exchange. Si la messagerie Exchange 2010 est déployée dans une forêt distincte de celle de Lync alors les adresses SIP devront être ajoutées manuellement (ou pas script) sur les boîtes aux lettres.

N.B. : Le déploiement de Lync 2010 dans une forêt distante n’a pas d’impact particulier sur le déploiement des services de Mobilité Lync 2010.

Dans ce blog, nous allons voir comment préparer un VHD étapes par étapes en appliquant notre image de référence Windows 8 pour un serveur sous Hyper-v.

Il est intéressant de connaitre les cmdlets sous Powershell étant donné que l’utilisation de Diskpart est maintenant dépréciée.

Notre serveur Hyper-v ne détient actuellement aucune machine.

Nous définissons dans une variable le nom qu’aura notre VM dans Hyper-v

$NameVm="Demo"

Nous définissons dans une variable l’emplacement et le nom qu’aura notre VHD créé

$PathVM="C:\VHD\$NameVM.vhdx"

Nous créons maintenant notre VHD à l’aide de la cmdlet " new-vm " qui créera directement la VM dans Hyper-v .

new-vm -Name $NameVm -MemoryStartupBytes 1024MB -NewVHDPath $PathVM -NewVHDSizeBytes 10000MB

Le résultat :

Il est maintenant nécessaire que nous montions notre VHD pour le préparer (partionnement, boot,..)

Mount-VHD $PathVM

En utilisant maintenant la cmdlet "Get-disk" nous pouvons vérifier que notre VHD à correctement été monté.

Notre VHD n’ayant pas encore été partitionné, il apparait sous le style de partition raw. Nous allons maintenant récupérer le numéro de partition de ce VHD grâce au « Friendly Name » et au « Partition Style »

$numero=(get-disk | Where-Object {$_.friendlyname -match "virtual" -and $_.partitionstyle -match "raw"}).number

Il faut maintenant initialisé le VHD afin de pouvoir formater celui-ci et y stocker des données.

Initialize-Disk $numero -PartitionStyle mbr

get-disk $numero

Le disque a bien été initialisé.

Nous allons maintenant partitionner ce VHD en NTFS

$Label="Demo"

New-Partition $numero -UseMaximumSize -AssignDriveLetter | Format-Volume -NewFileSystemLabel $label -FileSystem NTFS –asjob

Nous ne connaissons pas la lettre de volume qui lui a été alloué. Pour cela, on peut consulter tous les volumes à l’aide de la cmdlet :

Get-volume

Nous allons maintenant récupérer notre volume par l’identifiant de notre label précédemment définit.

$vol=(Get-Volume | Where-Object {$_.filesystemlabel -match $label}).driveletter

$vol1=$vol+":"

Et maintenant nous appliquons notre master de référence sous l’extension WIM avec DISM.

dism /apply-image /imagefile:C:\Users\administrateur\Desktop\Master_8.wim /index:1 /applydir:$vol1

On définit maintenant la partition comme étant active pour que celle-ci puisse booter depuis un OS.

Set-Partition -DriveLetter $vol -IsActive $true

Et maintenant nous allons configurer notre magasin BCD en lui ajoutant l’entrée de notre nouveau disque VHD.

$vol2=$vol1+"\Windows"

bcdboot $vol2 /s $vol1

Nous pouvons maintenant démonter notre VHD puis démarrer notre VM.

Dismount-VHD $PathVM

Start-VM $NameVm

Maintenant si nous revenons sur la console Hyper-v, nous pouvons constater que notre VM a bien démarrer et que notre master de référence Works !!

Il suffit maintenant d’imaginer un déploiement de master de référence à plus grande échelle pour une phase de recette par exemple.

Pour cela, il suffit d’effectuer une boucle dans un script avec toute les cmdlets et cela se déploiera au sein de Hyper-v de façon automatisé.

L’administration, l’exploitation ou l’exécution de toutes les tâches relatives à SharePoint peuvent être réalisées à partir de différents outils selon la version de SharePoint déployée sur la plateforme :

- La console d’administration centrale

- L’outil stsadm.exe

- L’outil SharePoint 2010 Management Shell (disponible depuis la version SharePoint 2010)

Plateformes MOSS 2007

1. Console d’administration centrale

Cette console est simple puisque elle offre l’aspect visuel des actions.

L’accès à la console d’administration centrale se fait à partir du chemin suivant :

All Programs-> Microsoft Office Server -> SharePoint 3.0 Central Administration

Néanmoins plusieurs actions sont indisponibles à partir de cette console. C’est pour cette raison que Microsoft a mis à disposition l’outil de ligne de commande: stsadm.exe

2. Stsadm.exe

Cet outil est disponible en suivant le chemin suivant : C:\Programs files\Common Files\Microsoft shared\web server extension\12\BIN

L’exécution de cette commande se fait à partir d’une fenêtre cmd ou powershell.exe en se plaçant dans le répertoire C:\Programs files\Common Files\Microsoft shared\web server extension\12\BIN.

Il existe 182 commandes possibles avec l’outil stsadm.exe

Les tâches réalisées à partir de stsadm doivent être exécutées avec le compte administrateur local du serveur, autrement, le résultat d’exécution retourne une erreur « Accès refusé ».

L’avantage de cet outil réside dans le fait de pouvoir programmer l’exécution des actions en utilisant les tâches planifiées du serveur.

Par exemple la planification d’une sauvegarde :

- Réalisation des scripts contenant la commande stsadm –o backup

Il est possible utiliser l’outil de scripting Powershell.exe. Dans ce script, le chemin vers la commande stsadm.exe doit être renseigné.

- Création d’une tâche planifiée qui permet de lancer le script crée.

Important: cocher la case « Run with highest privileges ».

Cet outil de ligne de commande reste tout de même limité par rapport à l’outil SharePoint 2010 Management Shell disponible depuis la version SharePoint 2010.

Plateforme SharePoint 2010

1. Console d’administration Centrale

Cette console est accessible à partir de : Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Central Administration

La console d’administration de SharePoint 2010 est plus ergonomique que la console d’administration de MOSS 2007.

Cette dernière offre plus d’actions à réaliser en mode graphique.

Mais reste néanmoins moins riche que l’outil de ligne de commande SharePoint 2010 Management Shell.

2. Stsadm.exe : l’utilisation de cet outil reste possible mais est déconseillée.

Cet outil est accessible à partir de C:\Program Files\Common Files\Microsoft shared\web server extensions\14\BIN

Cet outil doit être exécuté à partir d’un serveur SharePoint

3. SharePoint 2010 Management Shell

Cet outil se trouve dans : Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell.

Cette console est une console personnalisée dédiée à SharePoint et différente de la console Windows PowerShell par défaut qui au moment de son exécution charge le script Sharepoint.ps1 permettant d’utiliser la console PowerShell avec les cmdlets propres à SharePoint

Il existe plus de 600 Cmdlets propre à SharePoint.

Remarque: Windows PowerShell 2.0 est requis.

4. Powershell.exe

Il est possible d’utiliser l’outil Powershell.exe pour exécuter les cmdlets SharePoint, pour cela il faut obligatoirement :

Ajouter le composant « Microsoft.SharePoint.PowerShell » en procédant comme suit :

Add-PSSnapin Microsoft.SharePoint.PowerShell

Il est bien evidement possible de planifier l’exécution des cmdlets powershell par tâche planifiée

Remarque : Que ce soit l’utilisation de la console SharePoint 2010 Management Shell ou la console PowerShell, il faut respecter la configuration minimale requise pour exécuter les cmdlets SharePoint :

- Etre membre du rôle SharePoint_Shell_Access ou du groupe local WSS_Admin_WPG

Sinon utiliser la cmdlets suivante « Add-SPShellAdmin » qui permet :

- d’ajouter l’utilisateur au groupe WSS_Admin_WPG dans tous les serveurs web frontaux

-D’ajouter l’utilisateur au rôle SharePoint_Shell_Access. Dans le cas où les bases de données ne possedent pas ce rôle , ce dernier est crée automatquement à l’aide cette commande.

Après exécution de la cmdlets Add-SPShellAdmin, il est possible d’exécuter les cmdlets SharePoint.

L’utilisateur exécutant la cmdlet Add-SPShellAdmin doit posséder les autorisations suivantes :

o Accès au rôle de serveur Securityadmin sur l’instance SQL et rôle db_owner dans une base de données.

o Autorisation administrative sur l’ordinateur local.

Il faut exécuter la cmdlet Add-SPShellAdmin pour toutes les bases de données auxquelles vous voulez accorder l’accès. Si aucune base de données n’est spécifiée, la base de données de configuration de la batterie de serveurs est utilisée. Si vous spécifiez une base de données, la base de données de contenu de la batterie sera incluse en plus de la base de données de configuration de la batterie que vous spécifiez.

Une plateforme SharePoint utilise l’Active Directory de l’entreprise pour l’authentification des utilisateurs. Lorsqu’on se retrouve dans le cas d’une migration d’un domaine AD à un autre, nous somme dans l’obligation de réaliser une migration des comptes utilisateurs afin que chaque utilisateur puisse s’authentifier et conserver ses droits et ses autorisations sur la plateforme SharePoint.

Cette étape de migration doit obligatoirement suivre la migration des comptes utilisateurs au niveau de l’AD.

Commande de migration :

Stsadm –o migrateuser –oldlogin –newlogin -ignoresidhistory

• oldogin represente le nouveau login de l’utilisateur : anciendomaine\user
• newlogin represente l’ancien login utilisateur : nouveaudomaine\user
• Le paramétre ignorersidhistory lorsque ce dernier n’est pas renseigné ou porte la valeur « False », les métadonnées d’historique SID du nouvel utilisateur sont vérifiées pour savoir si elles correspondent au nom de l’ancien utilisateur. Si le paramètre ignoresidhistory est renseigné, la vérification des métadonnées n’est pas effectuée.

Pour rappel :

SIDHistory signifie " historique des identifiants de sécurités ".Cette fonction permet de conserver temporairement le SID (Security IDentifier) de l’ancien domaine. La conservation de cet identifiant permet de préserver l’accès des utilisateurs à leurs ressources habituelles malgré l’utilisation d’un nouveau compte utilisateur dans un nouveau domaine de sécurité. Ceci permet donc de pourvoir migrer les différentes ressources du domaine A vers le domaine B par étape sans avoir un impact sur l���utilisateur.

Il peut arriver aussi que des autorisations soient attribuées aux groupes Active Directory sur la plateforme SharePoint, Afin que les utilisateurs appartenant à ces groupes puissent conserver leurs autorisations hérités des groupes parents. Ces groupes doivent aussi être migrés dans SharePoint.

Comme pour le cas de la migration des utilisateurs cette dernière doit suivre la migration des groupes dans l’AD.

Il faut aussi que cette migration soit effectuée après la migration des utilisateurs dans l’AD.

Commande de migration :

Stsadm –o migrategroup –oldlogin –newlogin

Cette commande de migration est disponible depuis les cumulatives updates Aout 2009.