PI Services

Le blog des collaborateurs de PI Services

SharePoint 2007 - Bascule du site d’administration centrale

Dans le cas ou le serveur qui héberge le site d’administration centrale est indisponible (Par défaut il s’agit du 1er serveur frontal de chaque ferme). Il est possible de basculer le site sur un des serveurs frontaux de la ferme MOSS

Pour basculer le site d’administration centrale sur un autre serveur frontal, suivre la procédure suivante :

Ouvrir une session sur le serveur frontal devant devenir le nouvel hôte du site d’administration centrale.

  1. Lancer une invite de commande

 

  1. Se positionner au niveau du dossier  "C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\BIN"

 

  1. Lancer la commande : Psconfig -cmd adminvs -provision -port %numéro_port% –windowsauthprovider OnlyUseNtlm

 

  1. Redémarrer les services IIS ainsi que les services SharePoint

 

  1. Vérifier le fonctionnement du site : http://localhost:<n°port admincentrale>  (exemple :http://frontal2:2009)

SMS/SCCM - Visualiser une infrastructure SMS / SCCM avec l'outil SMSMAP

Descriptif :

SMSMap est une application écrite en VB .Net utilisant les librairies du SDK de SCCM pour générer à travers MS Visio le diagramme de votre infrastructure SCCM.

Très utile lors d’un audit ou lorsque les documentations d’architecture ne sont pas disponibles !

Il permet d’afficher (options paramétrables) :

  • Les sites SCCM par type (primaire/secondaire)
  • Les systèmes de sites présents dans ces sites (SQL, point de gestion, déploiement etc..)
  • Les relations inter-site et hiérarchie.
  • Le nombre de clients par sites

Le seul pré-requis est de posséder MS Visio 2003 ou 2007 sur l’ordinateur où il sera installé.

Le fichier obtenu peut être sauvegardé sous un format pdf, jpeg ou autre.

Un exemple :

Options de paramétrage de l’outil :

smsmap01 

smsmap02

Diagramme obtenu pour un environnement de tests :

smsmap03 

Télécharger l’outil :

Vouc pouvez télécharger cet outil gratuitement à l'adresse suivante :

http://www.tondtware.com/

SCCM - Présentation des nouveautés de ConfigMgr 2007 R3 et ConfigMgr 2011

Je reprends ici des informations glanées sur divers blogs concernant les évolutions futures présentées au TechEd de Berlin (Nov 2009) concernant SCCM 2007 R3 et la nouvelle version (anciennement appelée vNext) SCCM 2011.

SCCM 2007 R3 :

  • Améliorations liées à la gestion de l’énergie : 
       - Application de modèles de gestion d’énergie sur les machines via les collections (à la manière des fenêtres de maintenance) 
       - Reporting de la consommation énergétique en fonction des modèles appliqués 
       - Mesures de « l’activité » de l’utilisateur
  • Améliorations des performances 
       - Découvertes AD plus rapides 
       - Mises à jour des collections plus rapides (détection des nouvelles ressources)
  • OSD : possibilité de créer des images OEM

SCCM 2011 :

  • Le produit sera « User Centric ». Ce qui signifie que les applications se déplacent avec les utilisateurs où qu’ils soient
  • Les packages seront remplacés par des applications
  • Les méthodes de déploiement des applications seront liées à des règles de détection : en fonction de l’endroit où l’utilisateur se trouve, de la machine sur laquelle il se connecte, l’application pourra être installée, virtuelle (streaming) ou en remote desktop.
  • Il sera possible d’assigner une machine "principale" à un utilisateur (à utiliser avec les règles de détection par exemple)
  • Au niveau architecture, il y aura moins de niveaux dans la hiérarchie. Le site central sera remplacé par un Client Administrative Server (CAS) et un seul niveau en dessous
  • Les sites seront ajoutés au fur et à mesure pour des raisons de montée en charge (“scalabilité”) et non plus des raisons de délégation d’administration
  • La réplication SQL remplacera les mécanismes de réplication de fichiers pour les réplications entre sites (à l’exception des binaires)
  • Les DP auront des “senders”(donc contrôlables)
  • Les sites secondaires auront une base de données, un MP et un DP par défaut
  • DCM pourra faire de l’auto correction
  • Le reporting classique de SMS disparait. Il n’y aura plus que SSRS (Reporting Services)
  • La console SCCM ne sera plus à base de MMC classique mais plutôt genre SCOM. Dans la ligne des autres produits System Center
  • ConfigMgr 2011 sera 64 bits 

Quelques liens supplémentaires :

http://thoughtsonopsmgr.blogspot.com/2009/11/tech-ed-berlin-2009-day-3-wednesday.html

http://blogs.technet.com/systemcenter/archive/2009/09/08/announcing-system-center-configuration-manager-2007-r3.aspx

2008R2 - Configurer les stratégies de mots de passe granulaires (« Password Security Objects ») en PowerShell

 

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.

Exemple : gg_Utilisateurs_Ciblés

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

SQL Server 2008 – Réduction de la taille des fichiers Log

Parmi les options de configuration  d’une base de données on trouve le mode de récupération qui peut être Complet (Full), Journalisé en bloc (Bulk-Logged) ou Simple (Simple).

image

Si le mode de récupération d’une base de données est différent du mode Simple, il faut impérativement mettre en place une stratégie de sauvegarde des fichiers journaux de cette base de données sinon les fichiers log n’arrêteront par de croitre et consommer de l’espace disque.

Au cas où vous avez oublié de mettre en place cette stratégie et que votre disque commence à souffrir il faut impérativement réduire la taille des fichiers journaux volumineux, cet article décrit l’ensemble des actions à entreprendre pour réaliser cette action.

Identifier le nom logique d’un fichier Log d’une base de données

Pour identifier le nom logique d’un fichier journal d’une base de données nommée Demo il suffit d’exécuter la requête suivante :

SELECT DB_NAME(database_id) AS [Base de données],name AS [Nom Logique] ,
physical_name AS [Nom Physique]  FROM sys.master_files  
WHERE DB_NAME(database_id) = 'Demo' AND type = 1

Noter le nom qui apparaît au niveau de la colonne Nom Logique

Sauvegarder la base de données et le fichier Log

Avant de procéder à la réduction de la taille du fichier log et afin de sécuriser l’opération il faut procéder à une sauvegarde de la base de données et du fichier journal pour pouvoir la récupérer en cas de problème.

Pour cela il suffit d’exécuter les scripts suivants :

BACKUP DATABASE [Demo]
TO  DISK = N'F:\Backup\Demo.BAK'
WITH NOFORMAT, NOINIT, 
NAME = N'Demo-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

BACKUP LOG [Demo]
TO  DISK = N'F:\Backup\Demo.bak'
WITH NOFORMAT, NOINIT
NAME = N'Demo-Transaction Log  Backup',
SKIP, NOREWIND, NOUNLOADSTATS = 10
GO

Réduire la taille du fichier log de la base de données

On peut réduire la taille du fichier log en exécutant le script SQL Suivant

USE [Demo]
GO
DBCC SHRINKFILE (N'Demo_log' , 0, TRUNCATEONLY)
GO

Ou

En utilisant SQL Server Management Studio et en cliquant avec le bouton droit sur la base de données en question puis  sur Tasks ==> Shrink ==> Files

image

Au niveau de la fenêtre Shrink file – Demo.log :

  1. Vérifier que le type de fichier est bien Log
  2. Cocher la case Reduce unused space
  3. Cliquer sur Ok

  image

Si la taille du fichier Log n’est pas réduite suite à cette opération chose qui peut survenir si la fin du fichier log est considérée par SQL Server comme portion active non réductible, on peut forcer l’opération de réduction en changeant le mode de récupération de la base de données vers le mode simple, exécuter l’opération de troncature une autre fois et ensuite remettre le mode de récupération de la base de données au mode Complet (Full).

Pour changer le mode de récupération de la base vers le mode Simple exécuter le script suivant :

USE [master]
GO
ALTER DATABASE [Demo] SET RECOVERY SIMPLE WITH NO_WAIT
GO

Pour remettre le mode de récupération à Complet exécuter le script suivant :

USE [master]
GO
ALTER DATABASE [Demo] SET RECOVERY FULL WITH NO_WAIT
GO

Au niveau du script de la troncature on peut choisir la taille cible que doit prendre notre fichier log en utilisant la syntaxe suivante :

USE [Demo]
GO
DBCC SHRINKFILE (N'Demo_log' , <Taille Cible en MB>)
GO

SharePoint 2007 – Erreur DCOM à l'installation dans une ferme de serveurs SharePoint

L’erreur DCOM est une erreur qui apparait quasi systématiquement après l’installation et la configuration d’une plateforme MOSS 2007. Cette erreur apparait sur tous les serveurs de la ferme et à des intervalles réguliers.

Cette erreur est due au droit « LOCAL Activation » manquant sur certains objets DCOM pour les utilisateurs SharePoint et principalement les comptes utilisés pour les pools d’application qui font partie du groupe IIS_WPG.

Exemple d’erreur

Type de l'événement : Erreur
Source de l'événement : DCOM
Catégorie de l'événement : Aucun
ID de l'événement : 10021
Date : 22/01/2008
Heure : 11:07:36
Utilisateur : N/A
Ordinateur : « Nom_Serveur »
Description : Le descripteur de sécurité d'exécution et d'activation défini pour l'application serveur COM avec le CLSID {61738644-F196-11D0-9953-00C04FD919C1}  n'est pas valide. Il contient des entrées de contrôle d'accès (ACE) avec des autorisations qui ne sont pas valides. Par conséquent, l'action demandée n'a pas été effectuée. Cette autorisation de sécurité peut être corrigée à l'aide de l'outil d'administration Services de composants.

Pour plus d'informations, consultez le centre Aide et support à l'adresse http://go.microsoft.com/fwlink/events.asp.

Pour remédier à cette erreur procédez comme suit :

Ajoutez l’utilisateur “Service Réseau” (NETWORK Service)  au groupe “Utilisateurs du modèle COM distribué” (Distributed COM Users).

 image

Accordez au groupe IIS_WPG les bons droits sur les composants IIS Admin Service et IIS WAMREG Admin Service

1 - Démarrez la console services de composants en exécutant : C:\Windows\System32\com\comexp.msc

      image

ou

Cliquez sur Démarrer | Outils D’administration | Services de composants

2 - Réinitialisez la configuration de la sécurité des composants IIS Admin Service et IIS WAMREG Admin Service :

Cliquez sur le composant IIS Admin Service avec le bouton droit puis cliquez sur Propriétés.

image

Sélectionnez l’onglet Sécurité et positionnez toutes les autorisations à Par Défaut (Use Default) puis cliquez sur le bouton OK.

image

Important : Réalisez la même opération pour le composant IIS WAMREG Admin Service.

Cliquez sur le composant IIS Admin Service avec le bouton droit puis cliquer sur Propriétés.

image

Sélectionnez l’onglet Sécurité, au niveau de la section Autorisation d’exécution et d’activation ("Launch and Activation Permissions"), côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit").

image

Ajoutez le groupe IIS_WPG et accordez-lui toutes les autorisations.

image

Au niveau de la section Autorisations d’accès ("Access Permissions"), côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit").

image

Ajoutez le groupe IIS_WPG et accordez-lui toutes les autorisations.

image

Vérifier les droits de configuration pour le groupe Utilisateurs.

Au niveau de la section Autorisations de configuration ("Configuration Permissions") côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit"). 

image

Vérifiez que le groupe Utilisateurs dispose des autorisations Lecture ("Read") et Autorisations Spéciales ("Special permissions").

image   

Important : Réalisez la même opération pour le composant IIS WAMREG Admin Service.

A l'issue de cette procédure, l'erreur DCOM ne devrait plus ce produire !

Exchange 2007 – Attribut “Recipient Type Details” après une migration depuis Exchange 2003 vers Exchange 2007

Après une migration de boites aux lettres depuis une organisation Exchange 2003 vers une organisation Exchange 2007, il peut arriver que l’attribut “Recipient Type Details” ne soit pas défini en tant que “User Mailbox

Voici différent cas rencontrés :

Legacy Mailbox

Ceci est typiquement le type de boite aux lettres créé avec les outils Exchange 2003. Ce type de boite aux lettres fonctionne sous Exchange 2007 mais afin d’éviter la perte de certaines fonctionnalités d'Exchange 2007, il est préférable de la convertir.

Pour cela, une simple commande Powershell suffit :

Set-Mailbox –Identity “UserAlias” –ApplyMandatoryProperties

 

Linked Mailbox

Ceci indique que la boite aux lettre disposait d’un compte externe associé (autre que le compte SELF) avant la migration.

Pour résoudre le problème, il faut modifier les attributs de l’utilisateur en question (avec ADSIEdit) et modifier la valeur de l’attribut msExchRecipientTypeDetails de la valeur 2 à la valeur 1.

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

Shared Mailbox

Ceci indique que le compte SELF est configuré en tant que compte externe associé sur la boite aux lettres.

Après la migration de la boite aux lettres, supprimer l’association du compte SELF en tant que compte externe associé. Ceci modifiera l’attribut msExchMasterAccountSid et lui donnera la valeur <Not Set>. Ensuite, lancer la commande Powershell suivante :

Set-Mailbox xxx –Type:Regular

 

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

SCOM - Ressources "services" et "nom réseau" sur un cluster RMS

Un paramètre important lors de l’installation d’un serveur RMS en cluster:

Dans les propriétés des ressources services…

image

Il est indispensable dans l’onglet Dependencies de faire dependre la ressource sur le nom reseau du cluster RMS

image

Puis dans l’onglet General de cocher l’option Use Network Name for computer name

image

Ainsi les agents discuteront bien avec le SPN de la ressource RMS et non celui des nœuds physiques du cluster.

LUA - Optimisation des performances d'un serveur Live Update interne

Rappel sur LUA et PostGreSQL

Dans le cadre d’un projet d’intégration de SEP, j’ai installé un serveur LiveUpdate en interne. LiveUpdate est la technologie utilisée par les produits Symantec pour se mettre à jour par Internet (c'est l'équivalent d'un serveur WSUS chez Microsoft).

Dans la suite de ce billet, Live Update désigne le service de mise à jour et Live Update Administrateur (LUA) désigne le serveur interne de distribution des mises à jour.

Le client Live Update utilise une technologie PULL pour se connecter en HTTP et en FTP. Par défaut le client Live Update est configuré pour pointer vers les serveurs publics de Symantec. Il est possible de modifier ce comportement de manière à ce qu'il se connecte au serveur LUA interne en lieu et place des serveurs publics.

Le serveur LiveUpdate Administrateur utilise le moteur de base de données PostgreSQL . La version de PostgreSQL fournie avec LUA 2.x est la version 8.1(cf. site officiel PostGreSQL).

Remarque : Le support technique de Symantec recommande fortement à ses clients l'application de toutes les mises à jour du serveur LUA de manière à bénéficier de toutes les améliorations disponibles (notamment des améliorations apportées par la version 8.1 de PostGreSQL).

Le moteur PostGreSQL est configurable via le fichier « postgresql.conf » situé a la racine du dossier d’installation de LiveUpdate Administrator.

Tuning des performances PostGreSQL

Voici les principaux paramètres ayant une grande influence sur les performances de la base ainsi que les valeurs recommandées :

1. shared_buffers

Le paramètre shared_buffers détermine la quantité de mémoire utilisée pour la mise en cache des données. Certaines sources recommandent une valeur correspondant à 25% de la mémoire vive du serveur.

Par défaut la valeur du paramètre shared_buffers est de 32Mo avec LUA 2.2. Une valeur de 512 Mo permet d'améliorer les performances. Certains gros clients ont augmenté cette valeur jusqu'à 1024 Mo et on ensuite pû observer de grandes améliorations.

2. temp_buffers

Le paramètre temp_buffers n'est utilisé que pour le maintient des tables temporaires en mémoire.

Comme LUA 2.x ne dépend pas fortement de ces tableaux, certains clients ont réduit cette valeur de 2 Mo dans le cadre de leur mise au point.

3. work_mem

work_mem fixe la quantité maximale de mémoire à utiliser pour l’exécution d’une requête.

Le réglage de work_mem à 256 Mo a conduit à une amélioration des performances pour certains clients.

4. max_fsm_pages

Cette valeur doit être réglée sur le nombre maximum de pages de données (affichage Web) que vous voulez modifier ou supprimer. Une valeur de 20 000 a bien fonctionné pour certains clients.

5. wal_buffers

Une valeur de 256Kb devrait être suffisamment grande. pour une bonne utilisation de LUA.

6. checkpoint_segments

Les valeurs recommandées vont de 16 à 128 en fonction de l’espace disque disponible.

Par défaut, la valeur est de 3. Certains gros clients ont augmenté cette valeur à 30 et vu de grandes améliorations.

7. effective_cache_size

Effective_cache_size définit la taille du cache disque par rapport à la quantité de mémoire RAM disponible pour la mise en cache des données,

Il est recommandé de configurer la valeur effective_cache_size à 50% de la RAM du système (cette préconisation est valide si et seulement si le serveur est dédié au rôle LUA).

Par défaut, LUA 2.2 a effective_cache_size a une valeur de 128Mo. Certains gros clients ont augmenté cette valeur jusqu'à 2048 Mo et vu de grandes améliorations.

Exchange 2010 – Erreur “the execution of scripts is disabled on this system” lors du lancement d’un script powershell

Lors de l’exécution d’un script powershell (.PS1) sur un serveur Exchange 2010, alors que vous possédez des droits Administrateurs, vous rencontrez l’erreur suivante :

image

Par défaut, et pour des raisons évidentes de sécurité, l’exécution de script “Powershell for Exchange” est bridée. Afin de visualiser ce niveau de sécurité, il suffit de lancer la commande “Get-ExecutionPolicy” :

image

afin de se rendre compte que les droits sont positionnés à “Restricted” par défaut.

Les différents droits existants pour l’exécution de script sont les suivants :

  • Unrestricted
  • RemoteSigned
  • AllSigned
  • Restricted
  • Default
  • Bypass
  • Undefined

image

Il est alors possible d’autoriser l’exécution de script à l’aide de la commande “Set-ExecutionPolicy” et d’y ajouter la valeur désirée (nommée précédemment).

image

Mais comme l’indique alors le message lors du passage de la commande, le niveau de sécurité est dans ce cas abaissé. Ce qui peut poser problème. Si on désire autoriser momentanément l’exécution de script sans toucher au niveau de sécurité, il est possible de paramétrer l’environnement d’exécution juste pour ce lancement, avec un VBS par exemple, et qui servira de “lanceur” au script powershell.

1/ Le raccourci de lancement du Powershell for Exchange s’exécute comme suit :

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"

  • Lancement de l’exécutable –Command “appel du script RemoteExchange.ps1 permettant d’alimenter le Powershell avec les commandes pour Exchange 2010”; Connexion au premier serveur Exchange disponible

2/ Il suffit alors de rajouter ce type de commande supplémentaire :

  • Set-ExecutionPolicy -ExecutionPolicy Bypass –Force

Ce qui pourrait donner :

  • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"; Set-ExecutionPolicy -ExecutionPolicy Bypass –Force
    3/ Une fois inclus dans un script VBS, cela peut donner :
  • Return = WshShell.run (“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit –command            ".'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"; Set-ExecutionPolicy -ExecutionPolicy Bypass –Force; MonScript.ps1; exit“)

    Le script “MonScript.ps1” sera alors exécuté avec les bonnes autorisations sans impacter les paramètres de sécurité du serveur de manière définitive.

    N.B.: il est possible de remplacer “-auto” par le nom d’un serveur Exchange spécifique permettant ainsi d’effectuer du “Remote Scripting” sur le serveur désiré.

N'hésitez pas à laisser un commentaire si ce tips vous a été utile ou bien si vous avez des éléments à ajouter !…