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.
Problématique rencontrée :
Lorsque l’on veut ajouter un pilote supplémentaire x86 de type NT/2K/XP à une imprimante sous 2008R2, un message vous avertit que « Windows ne trouve pas de pilotes pour l’imprimante dans le répertoire sélectionné pour l’architecture demandé ».
Les pilotes x64 existent déjà dans Windows, mais celui-ci refuse d’y ajouter les homologues x32.
Le problème est dû au nommage des imprimantes qui peut être différent dans server 2008R2 par rapport au package de pilotes d’origine sur 2K/XP.
Ce problème toucherait les imprimantes dont les pilotes ne sont plus mis à jour pour les OS postérieurs à XP ou Vista, par les constructeurs.
Solution testée : Une HP LaserJet 1320 est nommées HP LaserJet 1320 series sur NT/2K/XP alors que Server 2008 R2 reconnait les pilotes si le mot « series » disparait.
Pour que le pilote x86 d’une HP Laserjet 2200 series PCL 5e soit accepté sur Serveur 2008 R2 il faut que celui-ci désignent une HP Laserjet 2200 series PCL 5 simplement.
Pour cela il faut récupérer les pilotes authentiques NT/2K/XP x86, dé zipper, modifier le fichier .inf en renommant l’ancienne appellation de l’imprimante par celle attendu par Windows.
Après un petit message d’avertissement le pilote est installé, ce qu’on peut vérifier dans le gestionnaire d’impression.
Cette astuce permet d’utiliser le pilote d’origine si de plus récent de type PCL 6 ou HP Universelle existe et ne donne pas satisfaction.
Symptôme
Suite à la publication de l’interface Communicator Web Access à travers un équipement de type “reverse proxy” (ISA/TMG ou IAG/UAG), l’erreur suivante se produit de manière aléatoire (environ 1 fois sur 3) :
Voici l’intitulé exact de l’erreur :
Cannot sign in because your computer clock is not set correctly or your account is invalid.(Error code: 0-1-492)
Explication
Cette erreur est un “classique” sur CWA. Elle se produit souvent lorsque l’URL utilisé pour accéder au service Web ne correspond pas au certificat positionné dans IIS ou bien encore aux URL d’accès publiées durant la configuration OCS (étape 4 de l’assistant d’installation du rôle CWA).
Cette erreur peut également se produire lorsque les SPN du compte ordinateur sont mal configurés et ne contiennent pas le SPN correspondant à l’URL publiée. Pour cela le SPN manquant peut être rajouté en suivant la procédure suivante :
Dans ce cas précis, la bonne URL est utilisée lors de l’accès et les SPN du serveur hébergeant CWA sont correctement configuré ! De plus l’erreur ne se produit pas systématiquement mais de manière aléatoire, et ce, uniquement à travers un équipement de type “reverse proxy” (comprendre l’accès à CWA depuis le LAN fonctionne systématiquement et sans aucune erreur) !
Résolution
Après quelques recherches sur le Web, je suis tombé sur le billet suivant qui propose d’activer l’authentification de type Anonyme sur l’une des pages du site CWA (page AuthMainCommandHandler.ashx).
http://www.tincupsandstring.com/2009/03/31/cwa-error-code-0-1-492/
Dans notre cas, cette manipulation a totalement corrigé le problème rencontré avec les publications de CWA à travers Unified Access Gateway (UAG) et Intelligent Application Gateway (IAG).
Remarque : A priori ce problème peut également être rencontré lors de la mise en place d’un load balancing matériel (HLB) sur le site CWA (cf. Blog Technet de Stefan Plizga).
Depuis sa sortie en 2009, de nombreuses mises à jour sont régulièrement publiées pour OCS 2007 R2.
L’application de l’ensemble de ces patchs peut sembler complexe à première vue. En effet Microsoft ne développe pas de correctifs “globaux” contrairement à Exchange ou TMG mais plutôt des correctifs ciblés sur chaque composant d’OCS :
- Application Host
- Application Sharing Server
- Administration Tools
- Audio/Video Confering
- Core Components
- Communicator Web Access
- Conferencing Attendant
- Conferencing Announcement Service
- Monitoring Server
- Mediation Sever
- Outside Voice Control
- Response Group Service
- Standard / Enterprise edition Server
- Standard / Enterprise edition Back-End
- Unified Communications Managed API 2.0 Core Redist 64-bit
- Web Conferencing Server
- Web Components Server
En fonction des rôles installés sur chaque serveur OCS certains packages accepteront de s’installer et d’autres non !
Afin de simplifier l’application de l’ensemble des mises à jour sur un serveur OCS 2007 R2, Microsoft met à disposition deux outils très pratiques :
L’outil détecte les rôles installé sur le serveur local, télécharge les mises à jour associées et enfin les installe toute !
Pour mettre à jour entièrement un serveur OCS 2007 R2 nouvellement installé, les deux fichiers suivants doivent être téléchargés :
- ServerUpdateInstaller.exe
- OCS2009-DBUpgrade.msi
Voici la fenêtre affichée par l’outil de déploiement des mises à jour sur un serveur Front-End OCS 2007 R2. Il suffit de cliquer sur le bouton Install Updates pour déclencher l’installation de l’ensemble des mises à jour.
Après une quinzaine de minutes (temps d’installation de l’ensemble des mises à jour), l’outil propose de redémarrer le serveur.
Suite au redémarrage du serveur il est probable que le service principal d’OCS (service Front-End) ne démarre pas.
En effet certaines mises à jour nécessitent une mise à jour de la base de données RTC associée à OCS 2007 R2.
Pour cela le fichier MSI précédemment téléchargé doit être exécuté avec le paramètre POOLNAME=<FQDN de votre pool de serveurs Front-End>.
A l’issue de ces manipulations, le serveur OCS 2007 R2 est 100% à jour.
Symptôme
Lors de l’ajout d’un serveur OCS 2007 R2 au sein d’un pool de serveur front-end, l’erreur suivante peut se produire :
[0xC3EC78D8] Failed to read the Office Communications Server version information. This can happen if the computer clock is not set to correct date and time
De plus l’erreur suivante peut également apparaître dans le journal d’évènements Applications (y compris si vous utilisez des sources auxquelles est associée une licence valide) :
The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.
Explication
Contrairement aux intitulés qui sont parfois trompeurs, ces erreurs ne sont pas dues à un problème de synchronisation d’horloge ni de” version” mais tout simplement à une mise à jour de Windows (bulletin de sécurité MS09-056).
Résolution
Pour résoudre ce problème et pouvoir ajouter avec succès le serveur au sein du pool OCS existant, deux alternatives sont possibles :
L’outil OCSASNFix est disponible à l’adresse suivante :
http://support.microsoft.com/kb/974571/en-us
Symptôme
Suite au déploiement d’une architecture OCS 2007 R2 composée de plusieurs serveurs (typiquement un serveur front-end déployé dans le réseau local associé à un serveur Edge situé en DMZ), les erreurs suivantes peuvent se produire si l’un des serveurs ou les deux exécutent Windows Server 2008 R2 :
Voici le détail de chacune des deux erreurs :
Log Name: Office Communications Server Source: OCS Protocol Stack Date: 23/12/2010 00:53:43 Event ID: 14428 Task Category: (1001) Level: Error Keywords: Classic User: N/A Computer: <FQDN du serveur OCS source> Description: TLS outgoing connection failures. Over the past 15 minutes Office Communications Server has experienced TLS outgoing connection failures 122 time(s). The error code of the last failure is 0x80004005 (Unspecified error) while trying to connect to the host “<FQDN du serveur OCS de destination>”. |
Log Name: Office Communications Server Source: OCS Protocol Stack Date: 23/12/2010 00:46:08 Event ID: 14502 Task Category: (1001) Level: Error Keywords: Classic User: N/A Computer: <FQDN du serveur OCS source> Description: A significant number of connection failures have occurred with remote server <FQDN du serveur OCS de destination>”. IP <Adresse IP du serveur OCS de destination>”. There have been 60 failures in the last 7 minutes. There have been a total of 60 failures. The specific failure types and their counts are identified below.
Instance count - Failure Type 60 80004005 |
Explication
Ces erreurs sont dues à un problème “connus” avec OCS 2007 R2 et Windows Server 2008 R2 autour de la fonction InitializeSecurityContext de la couche TLS.
Ces erreurs empêchent toute communication TLS entre les serveurs et entraînent donc des disfonctionnement au sein d’OCS (le protocole SIPs étant utilisé par défaut).
Résolution
Pour résoudre ces problèmes, il faut installer un correctif sur l’ensemble des serveurs OCS 2007 R2. Ce correctif est disponible sur demande à l’adresse suivante :
Suite à l’installation, les serveurs doivent être redémarrés.
La fonctionnalité de Call Park permet a un utilisateur de mettre un appel en attente et de le récupérer sur un autre téléphone assigné lors de la mise en attente de l’appel.
Configuration du Call Park
La configuration du Call Park peut être réalisé via la console Lync ou en PowerShell pour Lync:
Via la console Lync
Dans la console navigué dans la partie “Voice Feature” puis Call Park:
Les paramètres sont peux nombreux:
- Nom du Call Park
- Plage de numéro (déterminera le nombre de place disponible pour les appels en attente/Transfère)
- Le server hébergeant les Call Park
Via le PowerShell pour Lync
La commande New-CscallParkOrbit Permet d’ajouter un call park au serveur:
Une fois le Call Park mis en place il faut activer l’utilisation du call park a la politique d’utilisation de la voix
Test de la configuration
Pour tester la configuration de notre Call Park, un appel est emis a destination d’un utilisateurs Lync:
Une fois la communication établis, l’option Parking Lot est disponible et peut être sélectionnée:
Une fois l’option validée, l’appel est mis en attente sur l’un des numéro de la plage définie. Dans cet exemple l’appel pourra être repris en composant le 207 a partir de n’importe quel poste:
Enfin du coté de l’utilisateur mis en attente, la fenêtre de communication est modifier pour faire apparaitre le fait qu’il est actuellement en communication avec le Call Park. Tant que l’utilisateur est dans le call Park, la musique d’attente est émise.
Conclusion
La configuration du Call Park est assez rapide et permet une gestion des appels simple et au travers du client Lync.
La nouvelle version d’office Communication Serveur 2007R2 nommé Lync Server 2010 est actuellement RTM et devrait être disponible début décembre sur le portail Technet.
Cette version apporte sont lots de nouveautés et un nouveau client de communication. Ce client subit une politique configurée par l’administrateur, par défaut une politique est appliquer a tous les client, elle permet notamment aux utilisateurs de positionner une photo .Cette politique est nommée Global dans LCP (Lync Control Panel). Voici donc a quoi peut ressemblé le client une fois la photo mise en place:
Avec la centralisation de la politique de gestion des client, il est assez simple de pouvoir interdire aux utilisateurs ou à certains de positionner une photo dans leur client Lync.
Pour cela une peu de Powershell pour Lync:
Tout d’abord nous récupérons les différents paramètres de la politique Global avec la commande:
Get-CsClientPolicy –identity Global
Une fois la politique affichée nous récupérons le paramètre aàmodifier:
DisplayPhoto
Ce paramètre peut prendre 3 valeurs différentes:
- AllPhotos
- NoPhoto
- PhotosFromADOnly
Ici je souhaite que mes utilisateurs ne puisse pas afficher les photos de leurs contacts dans le client Lync. Je positionne donc le paramètre NoPhoto. Pour cela la commande PowerShell Lync suivant est utilisé:
Set-CsClientPolicy Global –DisplayPhoto NoPhoto
Suite a cette modification de la politique Global s’appliquant a tous mes utilisateurs, une déconnexion (sign-Out) puis reconnexion (sign-in) me permet de vérifier que la politique c’est appliquée à mes utilisateurs:
D’autre part la politique ne permettant plus a mes utilisateurs à partir des option du client d’afficher les photos, le menu du client est lui aussi modifié pour ne pas lui permettre de forcer cet affichage:
Enfin une fois la configuration Global reconfigurer avec la commande
Set-CsClientPolicy Global –DisplayPhoto Allphéeos
L’ensemble des paramètres sont de nouveau disponible et l’utilisateur peut modifier son affichage si il le souhaite:
Cette configuration permet aux utilisateurs qui changerait de version de ne pas avoir une modification d’affichage trop importante entre OCSR1/R2 et Lync Server 2010.
Lors de l’organisation de conférence, les premiers échanges consiste à indiquer à tous les participants les règles de la conférence. En fonction des conditions d’écoute de chacun l’information peut ne pas parvenir aux participants et aucune acceptation de ces règles n’est demandée explicitement.
Dans Lync Serveur, il est possible d’ajouter un disclaimer qui s’affichera pour tous les utilisateurs qui souhaite intégrer la conférence.
Par défaut le disclaimer est vide et donc aucune page ne s’affiche pour rejoindre une conférence:
Get-CsconferenceDisclaimer
Afin de pouvoir afficher un message avant la conférence il est nécessaire de saisir les paramètres de CsConfernecingDisclaimer:
Set-CsConferencingDisclaimer Global –Header “Disclaimer de PI Services” –body “Votre message de disclaimer”
Une fois le header et le Body valider, les paramètres sont modifiés sur le disclaimer Global.
Get-CsconferenceDisclaimer
Une fois le paramètre positionné, nous allons créer une conférence, pour cela seul le client lync est nécessaire (Live Meeting n’est pas un pré-requis)
Lancer l’option Dial-in Conferencing settings pour récupérer votre adresse d’organisation de conférence:
Une fois authentifié vous accéder à vos informations d’organisation de conférence via Lync Server 2010:
Il ne vous reste qu’a communiquer votre adresse de conférence (par defaut elle commence par https://meet.mondomaine.fr/).
Votre interlocuteur sera invité a rejoindre la conférence par différent moyen:
Enfin le disclaimer apparait et nécessite la validation pour poursuivre l’accès à la conférence:
Les utilisateurs de LWA (Lync Web Application) sont aussi sujet à ce disclaimer qu’ils soient Invité ou membre de la société.
Bonne conférence avec Lync Server 2010!