PI Services

Ce billet a pour objectif de référencer les versions des différentes extensions de schéma disponibles pour Active Directory, Exchange et LCS/OCS.

Remarque : Les versions intermédiaires (Beta, RC, CTP...) des produits utilisent des numéros de versions spécifiques qui ne sont pas indiqué dans ce billet (seules les versions finales ou RTM sont prises en compte).

Extensions de schéma Active Directory

Le tableau ci-dessous liste les différentes versions de schéma existantes pour l'annuaire Active Directory.

Extensions de schéma Exchange

Le tableau ci-dessous liste les différentes versions de schéma existantes pour la plateforme de messagerie Exchange.

Extensions de schéma LCS/OCS

Le tableau ci-dessous liste les différentes versions de schéma existantes pour le logiciel de collaboration Office Communication Server (OCS).

Comment vérifier manuellement une version de schéma ?

Pour vérifier manuellement la version du schéma Active Directory, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut objectVersion sur le conteneur "CN=Schema,CN=Configuration,DC=domaine,DC=local"
• Exécuter la commande suivante :

dsquery.exe * "CN=Schema,CN=Configuration,DC=domaine,DC=local" -scope base -attr objectversion

Pour vérifier manuellement la version du schéma Exchange, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut rangeUpper sur l'attribut ms-Exch-Schema-Version-Pt
• Exécuter la commande suivante :

dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=domaine, dc=local -scope base –attr rangeUpper

Pour vérifier manuellement la version du schéma OCS, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut rangeUpper sur l'attribut ms-RTC-SIP-SchemaVersion
• Exécuter la commande suivante :

dsquery.exe * CN=ms-RTC-SIP-SchemaVersion,CN=Schema,CN=Configuration, DC=domaine,DC=com -scope base -attr rangeupper

Beaucoup de programmes TCP/IP comme Ping et FTP utilisent la fonction WinSock INET_ADDR() :

unsigned long inet_addr( __in const char *cp );

pour convertir les adresses IPv4 du format chaine de caractère avec séparateur ”.” dans un format IN_ADDR qui n’est qu’une structure.

typedef struct in_addr { union { struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b; struct { u_short s_w1,s_w2; } S_un_w; u_long S_addr; } S_un; } IN_ADDR, *PIN_ADDR, FAR *LPIN_ADDR;

Toute adresse IPv4 sera formatée dans cette structure sous le format d’un entier long non signé (u_long).

La fonction INET_ADDR accepte les chaines de caractères au format suivant :

• a.b.c.d
• a.b.c
• a.b
• a

Les différentes parties qui définissent l’adresse IP dans son format caractère avec séparateur “.” peuvent avoir des valeurs décimales , octales ou hexadécimales.

Ainsi pinger l’adresse 172.19.0.40 revient à pinger  l’adresse 0254.023.0.050 en octal et l’adresse 0xAC.0x13.0.0x28 en hexadécimal.

172.19.0.40

0254.023.0.050

0xAC.0x13.0.0x28

Lors du traitement de la chaine de caractère en entrée, la fonction INET_ADDR traitera les nombre selon les règles suivantes :

• Tout nombre commençant par  0x ou 0X sera traité comme un chiffre hexadécimal
• Tout nombre commençant par 0 sera traité comme étant un nombre octal
• Les autres cas seront traité comme des nombres décimaux.

Ainsi il faut faire attention à ne pas utiliser un Zéro à gauche au niveau d’une partie de l’adresse IP si vous voulez la pinger car la partie qui commence par zéro sera traité comme étant un nombre octal et le Ping sera dirigé vers une autre adresse qui ne correspond pas à celle que vous avez tapé.

Annoncé lors du Microsoft Management Summit 2010 (19/23 Avril), Data Protection Manager 2010 est désormais disponible dans sa version RTM.

Pour le téléchargement, suivez le lien.

Pour un peu plus de détails sur les possibilités de l’outil, voici un “petit” compte rendu de la présentation qui a été faite de DPM 2010 au MMS 2010.

Bref résumé des fonctionnalités clefs implémentées :

• Gestion centralisée des politiques de sécurités pour les ordinateurs portables itinérants, qu’ils soient connectés sur le réseau de l’entreprise ou bien à distance.
• Une protection renforcée au niveau de la virtualisation, incluant des scénarios de Live Migration avec Hyper-V R2, ainsi que la possibilité de récupérer de façon granulaire des fichiers à partir de sauvegardes basées sur l’hôte.
• Des protections et capacités de restauration accrues pour des serveurs applicatifs Microsoft tel que SQL Server, Exchange ou Sharepoint.
• Une gestion native de la réplication Site-à-Site vers un autre serveur DPM ou vers un fournisseur de service externe.
• Une amélioration de l’évolutivité significative afin de déployer DPM 2010 sur de grands environnements.

Lorsqu’un serveur Windows 2008 ou 2008 R2 est membre d’un domaine, il arrive parfois que l’on ai besoin d’ouvrir une session avec un compte local.

Dans ce cas, il est nécessaire de spécifier le nom du serveur devant le login :

<SERVEUR>\<login>

Voici une astuce permettant d’éviter la saisie du nom du serveur : utiliser le point à la place :

.\<login>

De cette manière, Windows va considérer qu’il s’agit d’une ouverture de session locale. Le nom du serveur sera même affiché (pratique lorsque l’on connait que l’IP du serveur !)

Voilà, j’espère que cette astuce vous sera utile.

Problématique rencontrée

Lorsqu'une nouvelle imprimante est ajoutée sur un serveur d'impression Windows Server 2008 R2, le pilote injecté par l'assistant d'installation est celui correspondant au système d'exploitation (pilote pour architecture x64).

Les postes de travail 2000/XP/Vista et Seven étant généralement déployés en 32 bits (architecture x86), il faut impérativement rajouter le pilote x86 dans les propriétés de l'imprimante partagée.

Lorsque l'on réalise cette opération un fichier système nommé ntprint.inf est requis. Par défaut le media d'installation Windows est demandé (répertoire D:\i386).

Les images ISO de Windows 2000, Windows XP et Windows Server 2003 32 bits contiennent effectivement un fichier ntprint.inf sous le répertoire i386. Or lorsque l'on sélectionne ce fichier, l'assistant ne le prend pas en compte et réaffiche indéfiniment la fenêtre permettant de sélectionner l'emplacement du fichier.

Explication

Le fichier ntprint.inf contenu dans les sources de Windows 2000/XP/2003 n'est pas celui attendu par l'assistant d'ajout de pilote.

Ce dernier s'attend à recevoir un fichier ntprint.inf plus récent (Windows Vista 32 bits ou supérieur) situé dans le répertoire C:\Windows\winsxs.

Solution

La solution consiste à utiliser le fichier ntprint.inf situé dans C:\Windows\winsxs de l'une des versions suivantes de Windows :

• Windows Vista 32 bits
• Windows Seven 32 bits
• Windows 2008 32 bits

Le nom précis du répertoire est le suivant :

C:\Windows\winsxs\x86_ntprint.inf_<id>_<version>.<id>_none_<id>

Remarque : <id> et <version> correspondent à des ID et à la version du système (par exemple 6.0.6002 pour Windows Server 2008 SP2) - cela signifie que le nom du répertoire varie d'une version de Windows à l'autre et également en fonction du service pack

Voici le nom exact du répertoire pour Windows 7 32 bits :

• x86_ntprint.inf_31bf3856ad364e35_6.1.7600.16385_none_3ad6f3251c0676a9

Pour Windows Server 2008 SP2 32 bits le nom exact est :

• x86_ntprint.inf_31bf3856ad364e35_6.0.6002.18005_none_3cec160db7d4ac84

Exemple pas-à-pas avec une imprimante Laser Dell 5200

Voici un exemple pas-à-pas pour ajouter une imprimante partagée sous Windows Server 2008 R2 avec les pilotes x64 et x86.

Dans un premier temps il est conseillé d'installer le rôle Print and Document Services avec le sous-composant Print Server (cf. captures d'écran ci-dessous).

Une fois l'installation du rôle effectuée, lancez la console MMC Print Management. Dans l'arborescence de la console, développez Print Servers / <Nom du serveur>, puis faites un clic droit sur Printers et lancez l'assistant Add Printers...

Dans la page Printer Installation, choisissez Add a TCP/IP or Web Services Printer by IP address or hostname, puis cliquez sur le bouton Next.

Dans la page Printer Address, sélectionnez TCP/IP Device dans la liste déroulante, entrez l'adresse IP de l'imprimante, puis cliquez sur le bouton Next.

Si le pilote n'est pas déjà installé sur le serveur, sélectionnez Install a new driver puis cliquez sur Next.

Si le pilote de votre imprimante n'est pas présent dans la liste prédéfinie de Windows Server 2008 R2, cliquez sur le bouton Have Disk... pour insérer le pilote (le pilote demandé ici est celui correspondant au système serveur à savoir le pilote x64).

Une fois le fichier INI chargé, sélectionnez le pilote correspondant à votre périphérique d'impression (dans cet exemple il s'agit d'une imprimante Dell M5200N).

Dans la page Printer Name and Sharing Settings, entrez le nom de l'imprimante, le nom du partage de fichiers et l'emplacement (dans cet exemple le nom du partage est "Imprimante Technique" et l'emplacement est PIS/FRANCE/NOISY/OPEN-SPACE-TECHNIQUE).

Patientez durant l'installation du pilote d'impression...

Une fois le pilote installé, afficher les propriétés de l'imprimante dans la console MMC Print Management, allez dans l'onglet Sharing, puis cliquez sur le bouton Additionnal Drivers...

Remarque : Vous pouvez également côcher la case List in directory pour créer l'objet imprimante correspondant dans l'annuaire Active Directory (par défaut l'objet imprimante sera créé à l'intérieur du compte ordinateur correspondant au serveur d'impression).

Côchez la case x86, puis cliquez sur le bouton OK.

Une fenêtre doit alors s'ouvrir et demander le pilote d'impression x86 (à télécharger sur le site du constructeur).

Une fois le pilote x86 correctement installé, une nouvelle fenêtre demande un fichier nommé ntprint.inf présent dans le répertoire i386.

Spécifiez ici l'emplacement du fichier ntprint.inf (emplacement situé dans le répertoire C:\ Windows \ winsxs \ x86_ntprint.inf_<id>_<version>_none_<id> d'une machine Vista / Seven / 2008 en version 32 bits).

Après quelques secondes le pilote est correctement installé !

Commande sconfig et activation de Windows

Les versions Core de Windows Server 2008 R2 intègrent un nouvel utilitaire nommé sconfig. Cet utilitaire permet de simplifier les tâches de configuration usuelles (installation des mises à jour Windows Update, intégration dans un domaine, activation du bureau à distance, réglage de la date et de l’heure…) via un système de menus textuels.

Malheureusement sconfig n’intègre pas d’option pour activer le système d’exploitation. Pour cela il faut toujours utiliser le script slmgr.vbs présent dans “C:\Windows\System32”.

Procédure d’activation

Voici la procédure à suivre pour effectuer l’activation avec slmgr.vbs :

Dans un premier temps il est possible d’afficher l’état d’activation du serveur en saisissant les commandes suivantes :

• cd c:\Windows\System32
• slmgr.vbs –xpr

Dans notre exemple le système n’est pas activé car une date de fin est annoncée pour la période de grâce.

Pour insérer la clé de produit dans le système il faut ensuite saisir la commande suivante :

• slmgr.vbs –ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

Une fenêtre Windows Script Host doit apparaître suite à l’injection de la clé de produit. Pour débuter l’activation à travers Internet, la commande suivante doit être saisie :

• slmgr.vbs /ato

Si l’activation est réussie, le message suivant doit apparaître au bout de quelques secondes : “Product activated successfully”.

Suite à l’activation du serveur, la commande slmgr.vbs –xpr doit renvoyer le message suivant “The machine is permanently activated”.

Positionnement d’un serveur de proxy

Si l’accès au Web est conditionné par le passage à travers un serveur de proxy, celui-ci doit être renseigné au préalable avec la commande suivante :

• netsh winhttp set proxy <proxy-FQDN>:<proxy-port>

Dans le cas contraire une erreur de type “slui.exe 0x2a 0x80072EE2” ou “error: 0x80072EE2” se produit lors de la tentative d'activation.

Parmi les nouveautés de Windows Server 2008 R2 et au niveau du composant Active Directory on trouve les comptes de services gérés (Managed Service Accounts).

Plusieurs applications SQL Server et IIS reposent sur des services qui doivent parfois être démarrés avec des comptes de domaines pour des besoins spécifiques. L’administration de ces comptes, de leurs mots de passe ainsi que des SPN peut s’avérer complexe et peut affecter la disponibilité de l’application.

L’utilisation des comptes de services gérés réduit la charge administrative quant à la gestion des mots de passe et des SPN (nom principal de service) tout en assurant la disponibilité de ces applications et réduisant les risques lié à la modification des mots de passe.

Pré-requis

Pour pouvoir utiliser les comptes de services gérés :

- Les ordinateurs hébergeant les applications à configurer doivent être équipés de Windows Server 2008 R2 ou Windows 7,

- Les domaines dont le niveau fonctionnel est Windows Server 2008 R2 supportent nativement la gestion automatique des mots de passe et des SPN,  

- Si le domaine n’est pas au niveau fonctionnel Windows Server 2008 R2 mais que le schéma Active Directory a été mis à jour au niveau Windows Server 2008 R2 les comptes de services gérés peuvent être utilisés, la gestion automatique des mots de passes de ces comptes sera possible mais pas la gestion automatique des SPN

- Pour utiliser les comptes de services gérés dans des domaines Windows Server 2008, Windows Server 2003 ou des domaines mixtes il faut tout d’abord procéder aux actions suivantes :

           1- Exécuter adprep /forestprep au niveau de la forêt AD

           2- Exécuter adprep /domainprep dans chaque domaine où on souhaite utiliser le comptes de services gérés

           3- Avoir un contrôleur de domaine Windows Server 2008 R2 ou Windows Server 2008 avec Active Directory Management Gateway Service ou Windows Server 2003 avec Active Directory Gateway Service, Active Directory Management Gateway Service permet l’utilisation des commandes PowerShell nécessaires à la gestion des comptes de services gérés

- Pour utiliser les commandes PowerShell nécessaires à l’administration des comptes de services gérés au niveau des ordinateurs clients sur lesquels les applications doivent être configurées on doit avoir installé le Framework .NETainsi que le module Active Directory pour Windows PowerShell

Installation des pré-requis sur Windows Server 2008 R2

1. Démarrer la console Server Manager

1. Sélectionner Features puis cliquer sur Add Features   

1. Sélectionner  .NET Framework 3.5.1 Features

1. Sélectionner  Active Directory module for Windows PowerShell sous Remote Server Administration Tools |  Role Administraion Tools | AD DS and AD LDS Tools

1. Cliquer sur Next

1. Cliquer sur Install

1. Redémarrer le serveur si nécessaire

Installation des pré-requis sur Windows 7

1. Télécharger Remote Server Administration Tools for WIndows 7
2. Installer la mise à jour
3. Ajouter les fonctionnalités .NET Framework 3.5.1 et le module Active Directory module for Windows PowerShell
4. Redémarrer l’ordinateur

Création et configuration d’un compte de service géré

• Ouvrir une invite PowerShell  Active Directory

• Créer le compte de services en exécutant la commande suivante :

New-AdServiceAccount <Nom Du Compte>  -AccountPassword (ConvertTo-SecureString –AsPlainText “<mot de passe>” –Force) –Enabled $true –Path “CN=Managed Service Accounts,DC=<Domain Name>,DC=COM”

• Associer le compte de service à l’ordinateur client en exécutant la commande suivante :

Add-ADComputerServiceAccount –Identity <Nom Ordinateur> –ServiceAccount <Nom du compte>

• Installer le compte de service sur l’ordinateur client (cette commande soit être exécutée sur le poste qui utilisera le compte de service géré)

Install-ADServiceAccount –Identity <Nom du compte>

• Vérifier que le compte de service à été bien affecté au compte de la machine au niveau Active Directory en explorant les propriétés de l’objet ordinateur en question avec ADSI Edit et en cherchant l’attribut msDS-HostServiceAccount   

Utilisation du compte de service

Nous allons maintenant utiliser un compte de service géré pour démarrer le services SQL Server Reporting Services au niveau d’un serveur Windows Server 2008 R2.

• Double cliquer sur le service SQL Server Reporting Services au niveau de la console Services 

• Au niveau de l’onglet Log On cocher This account et cliquer sur Browse afin de localiser le compte de service, ou taper le nom du compte au format <Nom du Domaine>\<Nom du compte>$ , laisser le mot de passe vide et cliquer sur Apply puis sur Ok     

Attention : si vous tapez le nom du compte à la main il faut ajouter un $ à la fin. 

  
• Démarrer ou redémarrer le service

• Vérifier que le service a bien démarré malgré la fait que le mot de passe n’a pas été saisi !

Pour plus de détails, vous pouvez consulter les articles suivants :

• Service Accounts Step-by-Step Guide
• Managed Service Accounts

AD 2008 permet la mise en œuvre de « Password Settings Objects », ce qui évite la création d’un nouveau domaine lorsque l’on souhaite mettre en œuvre une politique de mots de passe différente pour certains utilisateurs. Avec Windows 2008 la création de ces PSO s’effectuait via ADSIedit ou Ldifde.

On connait moins les commandes PowerShell qui viennent avec 2008R2 et qui encadrent l’administration de ces objets.

A titre d’exemple, on peut imaginer la procédure suivante :

1) Un groupe global est créé. Les utilisateurs concernés par le futur PSO devront en être membres.

2) Un PSO est créé avec le jeu de paramètres destiné aux utilisateurs ciblés

Exemple :

New-ADFineGrainedPasswordPolicy -Name "PSO-Utilisateurs_Ciblés " -Precedence 500 -ComplexityEnabled $false -Description "Strategie pour tous les utilisateurs ciblés" -DisplayName "PSO pour les utilisateurs ciblés" -LockoutDuration "-1" -LockoutObservationWindow "0:30" -LockoutThreshold 30 -MaxPasswordAge "60.00:00:00" -MinPasswordAge "1.00:00:00" -MinPasswordLength 7 _PasswordHistoryCount 3 -ReversibleEncryptionEnabled $false

3) Le PSO est assigné au groupe global.

Exemple :

Add-ADFineGrainedPasswordPolicySubject PSO-Utilisateurs_Ciblés -Subjects ' gg_Utilisateurs_Ciblés '

Pour plus d’informations sur la gestion des mots de passe ( Stratégie du domaine et PSO ) :

http://technet.microsoft.com/en-us/library/dd378968(WS.10).aspx

Pour plus d’information sur les valeurs à paramétrer avec la commande de création de PSO :

http://technet.microsoft.com/en-us/library/ee617238.aspx

Suppression d’une sauvegarde de type « Non Système » (Bare Metal Recovery).

Lancez une console PowerShell et affichez la liste des sauvegardes disponibles

Recherchez la sauvegarde à supprimer (creation time)

Copiez le Shadow Copy ID, puis lancez Diskshadow

Pour supprimez, tapez Delete shadows ID et collez l’ID.

Dans le cadre d’une migration depuis un “ancien” serveur SQL 2005 vers un nouveau serveur sous SQL 2008 SP1, j’ai été amené à déplacer les bases de données associées à un pool OCS 2007 R2.

Ce billet décrit la procédure à suivre pour réaliser cette opération.

La première étape consiste à arrêter tous les services OCS sur le ou les serveurs frontaux composant le pool.

Ensuite, il faut se connecter au serveur SQL et mettre hors ligne l’intégralité des bases de données liées à OCS 2007 R2.

N.B. : Il est également possible d’utiliser la fonction “Detach…”, voire d’effectuer une sauvegarde des bases.

Les fichiers de bases de données (MDF) ainsi que les journaux de transaction (LDF) doivent être copiés sur le serveur SQL de destination dans les répertoires appropriés.

Il est ensuite possible de rattacher les bases de données OCS sur le serveur SQL de destination à l’aide de la console SQL Server Management Studio. Pour cela il faut se connecter à l’instance adaptée, faire un clic droit sur “Databases” puis sélectionner “Attach…”.

Dans la fenêtre permettant de rattacher une base SQL, il faut cliquer sur “Add”, puis sélectionner le fichier MDF nouvellement copié.

Attention : Il est possible que le fichier LDF ne soit pas localisé automatiquement (notamment si l’emplacement de stockage a changé par rapport au serveur SQL d’origine). Dans ce cas un message “Not Found” s’affiche en face du fichier LDF et le chemin doit être corrigé manuellement.

Cette opération doit être répétée pour chacune des bases de données OCS 2007 R2.

Le script suivant doit ensuite être exécuté dans la console SQL Server Management Studio afin de repositionner les autorisations nécessaires sur les groupes d’administration OCS (<domain> doit être remplacé par le nom NetBIOS de votre domaine Active Directory) :

CREATE LOGIN [<domain>\RTCArchivingUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCComponentUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCHSUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCUniversalReadOnlyAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCUniversalServerAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCUniversalUserAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;

EXEC sp_dboption 'rtc', 'db chaining', TRUE EXEC sp_dboption 'rtcdyn', 'db chaining', TRUE

Une fois le script exécuté, vous pourrez vérifier la présence des groupes OCS dans la section Security / Logins de la console SQL.

Enfin, la dernière étape consiste à exécuter la commande suivante sur le serveur OCS (le but de cette commande est de reconfigurer le pool OCS pour pointer vers le nouveau serveur SQL) :

lcscmd /forest /action:updatepoolbackend /poolname:mypool /poolbe:mysqlserver\rtc

Remarque : “mypool” doit être remplacé par le nom NetBIOS du pool et mysqlserver\rtc représente la nouvelle instance SQL Server (si vous utilisez l’instance par défaut alors il suffit de préciser le nom du serveur).

A l’issue de cette étape vous pouvez valider la bonne modification du pool en affichant la valeur de l’attribut msRTCSIP-BackEndServer à l’aide d’ADSIEdit.

Une fois ce point validé, la migration est terminée et les services OCS peuvent être redémarrés !