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.

Les cumulatives updates sont les mises à jour dédiées à SharePoint qui sont publiées tous les 2 mois. Ces packages peuvent corriger des bugs apparus sur le produit SharePoint, comme ça peut être une évolution du produit, par exemple certaines commandes propres à SharePoint sont disponibles à la suite d’une publication d’un cumulative Updates.

Les cumulatives peuvent contenir des corrections mineures, elles peuvent aussi contenir des changements importants et dans ce cas on parle de Service Pack

Pour une bonne administration de SharePoint, il faut se tenir informé et consulter ces mises à jour tous les 2 mois sur le site officiel de Microsoft, bien prendre du recul par rapport aux mises à jour surtout lorsqu’elles sont importantes et surtout toujours les tester sur des plateformes de test avant de les déployer en production. Il faut valider leur interaction avec la plateforme déjà mise en place et personnalisée.

Format des packages Cumulatives Updates SharePoint

MOSS 2007 :

• CU pour WSS + CU pour MOSS 2007

SharePoint 2010 :

• CU SharePoint Foundation 2010
• CU pour SharePoint Foundation 2010 + SharePoint Server 2010
• CU pour SharePoint Foundation 2010 + SharePoint Server 2010 + Project Server 2010

Mode d’installation des packages de mises à jour :

1. MOSS 2007 :

• Plateforme à serveur autonome (unique) : installation et configuration du package CU pour WSS ensuite installation et configuration du package CU pour sharePoint.

· Plateforme multiserveurs :

• Les CUs pour WSS doivent être installés sur le serveur d’application qui héberge la console d’administration centrale en premier , il faut ensuite lancer le wizard de configuration, cette étape doit être mise en pause le temps de déployer les CUs pour WSS sur les serveurs frontaux, une fois ces CUs installés et configurés sur les serveurs frontaux, l’etape de configuration des CUs sur le serveur d’application peut être finalisée.
• Les CUs pour sharePoint doivent être installées à l’identique des CUs pour WSS expliqué ci-dessus.

2. SharePoint 2010

· Plateforme à serveur autonome (unique) :

Important : En raison du changement du mode de packaging, il n’est plus nécessaire d’installer les CU de SharePoint Foundation puis les CU de SharePoint Server.

• De ce fait et selon le package de CU choisi suivant le type de produit SharePoint déployé sur la plateforme SharePoint, il faut lancer l’installation ensuite la configuration du CU sur cette dernière.

· Plateforme multiserveur :

Comme expliqué ci-dessus, suivant le produit SharePoint déployé sur la plateforme, il faut installer les CUs correspondants dans l’ordre suivant :

• Installation des CU sur le serveur d’application qui héberge la console d’administration centrale en premier,
• Installation des CU sur le(s) serveur(s) d’application
• Vérifier que les mises à jours ce sont correctement installées
• Arrêter le load balancing entre les serveurs frontaux
• Installer les CUs sur les serveurs frontaux un par un
• Vérifier que les mises à jour ce sont correctement installées
• Lancer le wizard de configuration sur le serveur d’application qui héberge la console d’administration centrale
• Lancer le wizard de configuration sur le reste des serveurs d’application
• Lancer le wizard de configuration sur les serveurs frontaux un par un

Une fois les CUs installées et configurées, il faut vérifier que la version de SharePoint correspond à celle attendue et publiée par Microsoft.

Microsoft ayant pris la décision de ne pas assurer la compatibilité de la console “lourde” SCOM 2012 avec Windows XP, il n’est plus possible de l’installer sur des ordinateurs exécutant encore ce système.

Toutefois, il peut toujours s’avérer nécessaire d’accéder à une console SCOM 2012 depuis un de ces ordinateurs et pour ce faire, la console Web semble être une solution parfaitement adaptée.

Malheureusement, une nouvelle mauvaise surprise vous attend : après avoir installé l’extension Silverlight SilvelightClientConfiguration.exe (proposée automatiquement à la première connexion) et tenté d’ouvrir une session, le message d’erreur suivant vous accueille et la console ne se charge pas :

The procedure entry point LocaleNameToLCID could not be located in the dynamic link library Kernel32.dll.

Cette erreur se produit car l’API LocaleNameToLCID n’est présente dans Kernel32.dll qu’à partir de Windows Vista (cf. http://msdn.microsoft.com/en-us/library/windows/desktop/dd318711%28v=vs.85%29.aspx ). Décidemment, cette console refuse de s’ouvrir sous Windows XP…

A l’aide de l’outil Procmon, on constate que SilverlightClientConfiguration.exe doit normalement créer des entrées dans la base de registre, correspondant à des certificats propres à SCOM 2012 et SCOM 2012 UR1 respectivement.

Il est donc possible de contourner le problème en important directement ces entrées dans la base de registre via le fichier OM2012WebConsoleFix.reg (disponible ici : http://blogs.technet.com/b/mihai/archive/2012/05/08/making-the-om-2012-web-console-accessible-from-a-windows-xp-client.aspx ), sans passer par SilverlightClientConfiguration.exe.

Il est cependant vraisemblable que les futures mises à jour de la console Web induiront des certificats différents.
Afin de pouvoir les retrouver (sur un client Vista ou supérieur) pour les exporter et les réimporter sur vos clients Windows XP, il est intéressant de noter que la clé de registre utilisée est HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Silverlight pour les Windows 64bits et HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Silverlight pour le Windows 32bits ainsi que HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\TrustedPublisher\Certificates\19F8F76F4655074509769C20349FFAECCECD217D dans tous les cas.

Une fois cette modification apportée au registre, la console Web SCOM 2012 est accessible sans avoir besoin d’installer SilverlightClientConfiguration.exe ni nécessiter de redémarrage.

Suite au déploiement manuel de l’agent SCOM sur des contrôleurs de domaine Active Directory d’un domaine distant, les alertes de type “script based test failed to complete” suivantes peuvent apparaitre :

AD Lost And Found Object Count : The script 'AD Lost And Found Object Count' failed to create object 'McActiveDir.ActiveDirectory'. This is an unexpected error.
The error returned was 'ActiveX component can't create object' (0x1AD)

AD Replication Monitoring : encountered a runtime error.
Failed to create the 'McActiveDir.ActiveDirectory' object.
The error returned was 'ActiveX component can't create object' (0x1AD)

Cette erreur se produit car il manque un composant de supervision spécifique aux Contrôleurs de Domaine, nommé AD Helper Object. Ce dernier s’installe automatiquement et de façon transparente lors du déploiement de l’agent via une installation « push », mais pas lors d’une installation manuelle (cas d’un serveur situé derrière un firewall par exemple).

Il est donc nécessaire d’installer ce composant à la main également, à l’aide du package oomads.msi disponible sur le média d’installation de SCOM dans le dossier HELPEROBJECTS :

Copier le package oomads.msi correspondant à l’infrastructure matérielle du contrôleur de domaine (I386 pour les Windows 32 bits ou AMD64 pour les Windows 64bits) sur le contrôleur de domaine qui remonte l’erreur, puis l’y installer.
L’installation ne requiert aucune intervention et affiche l’écran suivant une fois terminée :

L’alerte devrait alors cesser de remonter, sans nécessiter de redémarrage.

Comme l’a déjà détaillé Christophe Jourdan dans ce billet, il est nécessaire de créer et d’attribuer un certificat à chaque serveur situé dans un domaine non approuvé ou dans un workgroup/DMZ et que l’on souhaite monitorer à l’aide de SCOM .

Cependant, cette tâche peut s’avérer fastidieuse et répétitive si elle concerne un nombre important de serveurs… Il est possible de contourner le problème en faisant appel à des serveurs Gateway, mais cette solution n’est pertinente que si les serveurs à monitorer se trouvent majoritairement dans le même domaine distant.

Dans le cas où il s’agit de serveurs répartis dans de nombreux domaines différents, ou principalement situés en Workgroup ou en DMZ, cette solution du serveur Gateway ne présente pas d’avantage particulier puisqu’il faudra toujours générer un certificat par serveur à monitorer.

Heureusement, l’équipe de développement de SCOM a mis à disposition deux outils bien utiles pour automatiser en grande partie ce procédé : CertGenWizard et CertInstaller, réunis dans le package certgenbinaries.

CertGenWizard permet de requêter votre Autorité de Certification (CA) pour demander en une seule fois la création des certificats pour la liste de serveurs que vous lui indiquerez, puis les télécharge et les enregistre dans le dossier de votre choix. Il récupère également le certificat d’autorité racine (Root CA).

CertInstaller permet quant à lui d’automatiser l’installation des certificats machine et root CA dans le magasin de certificats du serveur à monitorer, ainsi que de les inscrire dans la configuration SCOM à l’aide de MOMCertImport automatiquement.

Aperçu de leur utilisation :

Pré-requis:

-.NET Framework 3.0

-Une autorité de certification (Win2K3/Win2K8 Enterprise/Stand-alone CA)

-S’il s’agit d’une CA Entreprise, un template OpsMgr doit être créé (cf. http://blogs.technet.com/b/ptsblog/archive/2011/12/28/monitoring-machines-using-certificates-with-system-center-operations-manager-2007-r2-part-1.aspx )

- createReqFile.bat doit rester dans le même dossier que CertGenWizard.exe

-Copier le MOMCertImport.exe correspondant à votre version de SCOM (2007/R2/2012) ainsi qu’aux serveurs visés (32 ou 64bit) depuis votre media d’installation de SCOM (dossier SUPPORTTOOLS) dans le même dossier que CertInstaller.exe.

-Attention, CertInstaller ne fonctionne pas sous Windows XP et ne pourra donc pas être utilisé si les machines que vous souhaitez superviser utilisent encore ce système !

Génération des certificats:

1. Télécharger l’archive zip de l’outil et la décompresser.

2. Lancer CertGenWizard.exe et cliquer sur Next.

3. Indiquer si l’Autorité de Certification est présente sur le serveur qui exécute l’outil (Search this computer) ou si elle se trouve sur un autre serveur (Search the network). Dans ce second cas, indiquer son nom et son domaine dans les champs CA name et CA host name.
Cliquer sur Next.

4. Indiquer la liste des serveurs à superviser hors-domaine (un seul par ligne) dans la liste Computers ainsi que le dossier où stocker les certificats dans Certificate Destination Folder.
Cliquer sur Create.

5. Après quelques secondes, l’outil confirme la création des demandes de certificat auprès de l’Autorité de Certification et demande de les y approuver :

6. Ouvrir la console « Autorité de Certification », dossier « Pending Requests ». Sélectionner les demandes de certificat en attente et faire Clic-droit > Issue :

7. Revenir à l’outil CertGenWizard et cliquer sur Retrieve. Les certificats sont copiés dans le dossier préalablement indiqué. Une fenêtre de résumé s’affiche, indiquant les certificats générés et copiés. Cocher Open folder to view certificates puis cliquer sur Close.

8. LE dossier contenant les certificats pour chacun des serveurs à monitorer s’ouvre. Il contient également le certificat racine Root Certificate, qui servira aussi sur chacun des serveurs à monitorer.

Import des certificats sur les serveurs cible:

Réaliser cette étape à la main (import du certificat racine et du certificat machine puis exécution de MOMCertImport) peut s’avérer tout aussi fastidieux que de créer les certificats à la main.

L’outil CertInstaller, fourni dans le package, permet heureusement de simplifier également ce processus.

Attention : l’agent SCOM doit être installé avant de réaliser cette opération !

1. Sur chaque serveur à monitorer, copier dans le même dossier le certificat machine généré à l’étape précédente correspondant ainsi que le certificat racine RootCertificate. Copier également l’outil CertInstaller.exe présent dans le package et l’exécutable MOMCertImport disponible sur le media d’installation de SCOM correspondant à la plateforme à monitorer (x86 ou x64).

2. Sur le serveur à monitorer, lancer CertInstaller. Sélectionner le certificat machine dans le champ Machine Certificate et le certificat racine dans le champ Root CA Certificate. Cliquer sur Install.

Voilà, c’est terminé. Vous pouvez vérifier que les certificats sont bien importés en ouvrant le magasin de certificat du serveur à monitorer.

S’il n’y a pas d’autre problème, le serveur doit remonter dans SCOM au bout de quelques minutes.

Nous allons voir comment effectuer une recherche sur un objet utilisateur dans Active Directory à l’aide du SamAccountName. Et ainsi avoir accès aux propriétés du compte.

Tout d’abord on initialise une variable contenant la connexion à un contrôleur de domaine avec les éléments d’identification.

$dc= New-Object system.directoryservices.directoryEntry('LDAP://192.168.1.1','login','mdp')

Ensuite on initialise notre variable de recherche.

$Search_DC=New-Object system.directoryservices.directorysearcher($dc)

Nous allons maintenant rechercher l’utilisateur ayant pour SamAccountName “alphonse.dupuit”

$Search_DC.filter="(&(objectClass=user)(samaccountname=alphonse.dupuit))"

On affiche le résultat.

$search.findone()

On peut maintenant afficher et donc récupérer les différentes propriétés de l’objet utilisateur.

($search.findone()).properties

Nous pouvons également accéder a ces informations en utilisant d’autres méthodes :ajout de module tel que Active-Directory, Quest, etc..

Exemple avec les cmdlets Quest

Ajout des cmdlets Quest au shell :

Add-PSSnapin Quest.ActiveRoles.ADManagement

initialisation de variables pour identification

$U="login"
$PU="mdp"
$D=convertto-securestring -string $pu -AsPlainText –force (mot de passe crypté)

Connexion au contrôleur de domaine

Connect-QADService 192.168.1.1 –ConnectionAccount $U -ConnectionPassword $D

Recherche de l’utilisateur cedrick.vaccard

Get-qaduser cedrick.vaccard

On peut désormais accéder et récupérer les propriétés de l’utilisateur

Get-qaduser cedrick.vaccard |fl

Introduction

Si l’on pouvait autrefois dire qu’il n’était pas possible de cloner un contrôleur de domaine a moins de vouloir voir son infrastructure Active Directory comprise, on ne peut plus dire la même la chose aujourd’hui.

En effet, avec la génération 2012 de Windows Server apporte le support des contrôleurs de domaine virtualisé (on parlera alors de vDC). Ce support donc comprend la tolérance aux snapshots ainsi qu’au clone de contrôleur de domaine.

Dans ce billet, nous attarderons donc sur la procédure à suivre pour cloner un contrôleur de domaine.

Fonctionnement

Il faut tout d’abord savoir que cette opération nécessite un niveau de forêt en Windows Server 2012 ainsi qu’une préparation au préalable.

Lors de cette préparation, un fichier de configuration au format XML, sera généré dans C:\Windows\NTDS.

Au redémarrage du contrôleur de domaine va donc lire le contenu du fichier de configuration et s’adaptera pour s’ajouter en tant que contrôleur de domaine supplémentaire.

Dans les informations de configuration, il est possible de changer le nom de la machine, de modifier sa configuration IP ou encore de spécifier un site Active Directory.

En cas d’incohérence, le contrôleur de domaine démarrera en mode de restauration.

Enfin, il faut savoir que le clone de contrôleur virtuel ne supporte pas tous les services et fonctionnalité pouvant être ajouté à Windows Server (par exemple la fonctionnalité SNMP). Si des applications non supportées sont présentes, la génération du fichier de configuration ne sera pas permise à moins qu’une exclusion définie.

Mise en place

Le clonage d’un contrôleur doit être effectué dans l’ordre suivant :

Ajout des permissions Active Directory

Ajouter le contrôleur de domaine qui servira de base pour le clonage dans le groupe « Cloneable Domain Controllers »

Contrôle de conformité

Puis, sur ce contrôleur de domaine, réalisez la commande Get-ADDCCloningExcludeApplicationList pour obtenir la liste des services et application non supportée par le clonage.

Les résultats affichés doivent être désinstallé ou placé dans un fichier d’exception pouvant être généré automatiquement grave à l’argument –GenerateXML de la commande précédente.

Le fichier d’exclusion sera alors généré dans le répertoire NTDS.

Génération du fichier de configuration

Puis générez le fichier de configuration de clonage à l’aide de la commande New-ADDCCloningConfigFile.

Il est possible de définir de nouveaux paramètres grâce à l’argument –Static et des configurations configurations éditables :

· Pour un nouveau nom de machine, employez l’argument –CloneComputerName

· Pour une nouvelle configuration IP, employez les arguments –Ipv4Address, -IPv4DNSResolver, -IPv4DefaultGateway.

· Pour que le nouveau contrôleur de domaine intègre un autre site Active Directory, utilisez l’argument –Site.

Clonage de la machine virtuelle

Pour finir l’opération, clonez votre machine virtuelle par l’intermédiaire de vos outils de gestion d’hyperviseurs, déplacez là si nécessaire et enfin allumez là. Votre contrôleur de domaine adaptera alors sa configuration pour ne pas causer de conflit dans votre forêt Active Directory.

Fonctionnement

Les contrôles d’accès dynamiques sont une nouveauté introduite avec Windows Server 2012 qui se base sur les concepts de classifications et d’accès centralisé.

Les classifications sont, rappelons-le, des attributs permettant de catégoriser un objet, elles sont aujourd’hui couramment utilisées dans les systèmes de messagerie.

Les accès centralisés sont tout simplement le fait que les stratégies et règles d’accès sont stockées sur les contrôleurs de domaine Active Directory.

Prérequis

La mise en place d’une infrastructure repose sur l’emploi de revendication par le biais de Kerberos. Cette technologie n’est cependant prise en charge uniquement sur les systèmes d’exploitation Windows 8 (pour les clients) et Windows Server 2012 (pour les serveurs).

Il sera donc nécessaire d’utiliser des contrôleurs de domaine Active Directory dont le niveau fonctionnel de forêt est supérieur ou égal à « Windows Server 2012 ».

De plus, les serveurs de fichiers nécessitent le service de rôle FSRM.

Mise en place

Pour cela nous allons donc devoir définir des propriétés de ressources et d’utilisateurs, qui serviront de correspondance à une règle.

Par la suite nous pourrons agréger nos règles dans une stratégie.

Stratégie qui sera publiée sur les serveurs de fichiers, puis appliquées sur les ressources.

Les utilisateurs qui respecteront les propriétés définis auront donc accès aux ressources en fonction des permissions établies dans les règles.

Dans le billet suivant, nous mettrons en place pas à pas un système d’autorisation n’autorisant uniquement les utilisateurs à accéder aux fichiers qui sont dans le même département et la même compagnie que celle définie dans la classification.

Configuration des utilisateurs

Attribution des propriétés d’organisation

Par exemple, l’utilisateur User1, ayant les champs Department et Company respectivement définis sur « Administration » et « PIServices », ne pourra accéder qu’aux ressources ayant les même valeurs.

Définition des types de revendication.

Afin que l’utilisateur puisse communiquer ses propriétés Department et Company, ce dernier doit étendre son ticket Kerberos avant les revendications correspondantes.

Pour cela, ajoutez les types de claims correspondant dans la section Active Directory > Dynamic Access Control > Claim Types.

Dans le cas présent, il s’ajout d’une revendication « company » et d’une seconde « department ».

Configuration des ressources

Définition des propriétés de ressource

A présent, créez des propriétés de ressources depuis la section Active Directory > Dynamic Access Control >Ressource Property.

Microsoft met à disposition un certain nombre de propriétés de ressources, libre à vous de les personnaliser ou d’en créer de nouvelles.

Dans le cadre de notre exemple, nous allons activer et personnaliser les propriétés de ressources « Company » et « Department ».

La personnalisation consiste à ajouter, éditer ou supprimer des valeurs suggérées, qui seront proposée lors de la classification de la ressource.

Configuration de l’accès

Définition des Règles d’accès centralisées

Une fois que les propriétés de ressources sont éditées, il suffit de les ajouter dans une règle d’accès centralisée.

Cette dernière pourra donc être créée depuis la section Active Directory > Dynamic Access Control > Central Access Rules.

Nous allons donc créer une règle s’appliquant aux ressources (donc fichiers) dont la classification « Company » correspondra à « PIServices ».

Pour cela, éditez les ressources cibles pour y intégrer la condition Ressource.Company Equals « PIServices » depuis l’assitant.

Enfin, dans les permissions, intégrez le groupe d’utilisateurs qui doit avoir le droit d’accès à la ressources et spécifiez les contraintes de revendications.

Dans notre cas, il faut que l’utilisateur soit dans la même compagnie et le même département que le fichier.

Définition des Stratégies d’accès centralisées

Enfin, agrégez les règles dans une nouvelle stratégie depuis la section Active Directory > Dynamic Access Control > Central Access Policies.

Publication des Stratégies d’accès centralisées

Pour que les serveurs de fichiers chargent les stratégies d’accès, créez une nouvelle GPO, qui injectera les stratégies définies aux serveurs correspondant au périmètre de votre GPO.

Activation du support des revendications auprès des systèmes du domaine

Pour que les systèmes de votre parc étendent le ticket Kerberos, activez l’option « KDC support for claims, compound authentication and Kerberos armoring » sur l’ensemble de votre domaine Active Directory.

Application de la classification sur la ressource

Enfin, testons nos configurations.

En effectuant un clic droit « propriétés », nous appliquerons des valeurs aux classifications disponibles.

Puis depuis les paramètres de sécurité avancée, il sera nécessaire de définir la stratégie précédemment créée.

Note : si vos stratégies ne sont pas disponibles effectuez la commande PowerShell suivante sur le serveur de fichier : Update-FsrmClassificationPropertyDefinition.

Les évolutions

Il est aujourd’hui possible d’utiliser le (Microsoft File Server Resource Manager) FSRM pour classifier automatiquement les dossiers et documents et réduire drastiquement le temps d’administration lié à l’application des permissions.

Déjà présente depuis 2008R2 la corbeille AD permet de récupérer des objets accidentellement effacés.

Avec Windows Server 2012, l’utilisation de la corbeille se simplifie avec une interface graphique.

Prérequis à l’activation

Pour activer la corbeille avec GUI, il faut avoir une forêt avec un niveau fonctionnel 2008R2 ou supérieur. Vous pouvez vérifier le niveau fonctionnel de la forêt avec la commande PowerShell suivante :

Get-ADForest | Select forestmode

Activation de la corbeille

Attention, l’activation de la corbeille sur 2008R2 ne permet pas le retour au niveau fonctionnel 2008.

La corbeille AD étant par défaut désactivée il faut l’activer à l’aide de la commande suivante :

Utilisation de la corbeille

La corbeille est activée, il est maintenant possible de tester son fonctionnement avec l’interface GUI :

Supprimez un objet de l’AD

Puis lancez l’Administrative Center et sélectionnez le container “Deleted Objects”

Il suffit de sélectionner l’objet à restaurer puis cliquez sur “Restore” (“Restore To” permet de choisir l’OU dans laquelle l’objet sera restauré)

L’objet est maintenant de nouveau disponible dans l’AD.

Pour aller plus loin dans l’utilisation de la corbeille AD et utiliser des fonctions tel que la restauration de tous les objets en fonction de la date et de l’heure de la suppression, je vous conseille les liens suivants :

- http://blogs.technet.com/b/askds/archive/2009/08/27/the-ad-recycle-bin-understanding-implementing-best-practices-and-troubleshooting.aspx

- http://technet.microsoft.com/en-us/library/dd379481(v=ws.10).aspx

Introduction

Avec l’arrivée des nouvelles technologies et des nouveaux produits, les entreprise sont amenées à mettre à niveau leurs architectures et faire évoluer leur parc applicatifs selon leurs besoin.

L’un des points cruciaux aussi qui pousse les entreprises à faire évoluer leurs plateforme est lié principalement à la supportabilité des produits eux même par l’éditeur.

SQL Server et comme tout autre produit dispose d’un cycle de vie de support qui varie d’une version et d’une édition à une autre, dans ce post j’ai essayé de regrouper le cycle de vie des dernières version de SQL Server de telle sorte qu’on puisse avoir trouver l’information rapidement.

Sachant que SQL Server 6.0, 6.5 et 7.0 ne sont plus supportés par l’éditeur voici la liste des dates clés pour les autres versions du produit :

1. SQL Server 2000 : Le 9 Avril 2013 fin du support étendu
2. SQL Server 2005 : Le 12 Avril 2016 fin du support étendu
3. SQL Server 2008 : Le 9 Juillet 2019 fin du support étendu
4. SQL Server 2008 R2 : Le 9 Juillet 2019 fin du support étendu
5. SQL Server 2012 : Le 12 Juillet 2022 fin du support étendu

Et pour plus d’information voici le détail du cycle de vie de support de chaque version(Source: Microsoft Product Lifecycle Serach) :  

SQL Server 2012

SQL Server 2008 R2

SQL Server 2008

SQL Server 2005

SQL Server 2000