Contexte

Suite à un reboot, l’exécution d’un data collector set créé depuis Perfmon est interrompue.

La console PerfMon permet uniquement de planifier le lancement d’un DCS en fonction de dates spécifiques et non en fonction d’un évènement :

Ce post explique comment automatiquement lancer un Data Collector Set à chaque démarrage du serveur.

Résolution

Depuis le Task Scheduler naviguer vers “Library -> Microsoft -> Windows –> PLA” :

Sélectionner le DCS souhaité puis ajouter un trigger du type “At system startup” :

Contexte

Sur une même machine Windows, il est impossible de réaliser plus de 3 sysprep, au bout de la 4eme tentative, l’utilitaire sysprep affiche l’erreur suivante :

Microsoft recommande d’utiliser une image d’un système “sysprepé” afin de contourner cette limite.

Cette limite a été mise en place afin que sysprep ne soit pas utilisé pour réinitialiser la période de grâce de 30 jours que Microsoft fourni pour activer la licence.

Résolution

Pour sysprep une même machine plus de trois fois, les étapes suivantes doivent être réalisées :

1. Depuis l’éditeur de registre,

Depuis la l’entrée “HKEY_LOCAL_MACHINE\System\Setup\Status\SysprepStatus”, modifier la valeur de la clé “CleanupState” à 2 et la valeur de la clé “GeneralizationState” à 7 :

Depuis la l’entrée “HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform”, modifier la valeur de la clé “SkipRearm” à 1 :

2. Depuis un command prompt lancé en tant qu’administrateur,

Exécuter les commandes suivantes :

msdtc -uninstall
msdtc -install

3. Depuis le répertoire “C:\Windows\System32\Sysprep” supprimer le dossier “Panther” :

Contexte

Il arrive souvent qu’un compte utilisateur soit utilisé pour l’exécution d’un job SQL, il s’agit d’une mauvaise pratique car le compte utilisateur peut être amené à changer de mot de passe ce qui provoqueras une erreur d’exécution des jobs en question.

Ce post explique comment détecter puis modifier les comptes utilisés.

Analyse

Le script suivant permet de détecter les jobs exécuté via un compte user (DOMAIN\USER-%) tout en ne remontant pas les jobs lancés par un compte de service (DOMAIN\SERVICE-%).

Les variables “DOMAIN\USER-%” et “DOMAIN\SERVICE-%” sont à modifier en fonction de la nomenclature utilisée pour nommer les comptes. Le “%” correspond à toute chaîne de zéro caractères ou plus Ce caractère générique peut être utilisé comme préfixe ou comme suffixe.

select s.name,l.name
from  msdb..sysjobs s
  left join master.sys.syslogins l on s.owner_sid = l.sid
where l.name like 'DOMAIN\USER-%' and  l.name not like 'DOMAIN\SERVICE-%'

Résolution

Il faut ensuite récupérer le SID du compte utilisateur à changer depuis l’active directory, ainsi que le SID du compte à utiliser, par exemple, SA.

Pour récupérer le SID d’un utilisateur SQL, executer la commande suivante “select sid,name,denylogin from MASTER..syslogins where name='SQLUser'”

Le script suivant permet de modifier l’owner des jobs d’une instance SQL depuis le SID “0x02” vers le SID “0x01” :

UPDATE msdb..sysjobs
SET owner_sid = CONVERT(varbinary(max), '0x01', 1)
where owner_sid = CONVERT(varbinary(max), '0x02', 1)

Exécuter Excel sur un poste Distant.

Quel est l'interêt ?

En dehors du fait qu'installer Excel sur un serveur n'est pas forcément une bonne pratique, dans mon cas cela me permet d'automatiser à 100% mes scripts Powershell, ces derniers fournissent des rapports détaillés à mes interlocuteurs, sans que je n'ai besoin de faire quelques modifications que ce soit (contrairement à un CSV).
Ainsi les scripts tournent de nuit et permettent à chacun de trouver son rapport le matin en arrivant, et ce même pendant mes vacances.

Comment ça marche

Pour exécuter Excel sur un poste distant via Powershell il faudra cumuler 2 paramètres.

1. Activer CredSSP pour la délégation des identifiants.
2. Autoriser le compte d'exécution à se servir de l'application Excel à Distance.

Voyons comment réaliser cela.

1- Activer CredSSP

J'ai déjà traité le sujet ICI.

2- Gestion Excel Distant

Attention la modification que nous allons réaliser n'est pas sans conséquence, comme nous pourrons le voir après, l'application Excel devient vraiment limitée pour tout autre utilisateur que celui qui sera déclaré.

Pour pouvoir autoriser le compte d'exécution à se servir de l'application Excel à distance, nous aurons besoin de la MMC.

Sur la machine qui traitera le fichier Excel :

• Ouvrir la MMC > Ajouter ou supprimer des composants logiciels enfichables > Services de composants.

• Développer Services de composants > Ordinateurs > Poste de travail > Configuration DCOM

• Sur "Microsoft Excel Application" faites clic droit "propriétés", dans la fenêtre sélectionnez l'onglet "Identité"

• Cochez la case "Cet utilisateur" puis faites "parcourir", sélectionnez "Tout l'annuaire" et enfin recherchez le compte d'exécution du script.

• Entrez le mot de passe de votre compte d'exécution et faites "Appliquer".

Maintenant que le paramètre est fixé seul le compte définit est "autorisé" à se servir de l'application Microsoft Excel, l'expérience pour tout autre utilisateur est vraiment dégradé (pas d'impression, de sauvegarde, message d'erreur...); par conséquent si vous souhaitez pouvoir continuer à utiliser Excel, je vous invite à repasser sur "L'utilisateur exécutant" et n'activer la fonction que lors de l'exécution du script (pour ma part je ne l'active sur mon poste que la nuit).

Exemple de message d'erreur.

Annexe

En annexe un petit article sur la gestion d'Excel en Powershell :

https://blog.piservices.fr/post/2013/03/27/Powershell-Creation-de28099objets-personnalises