PI Services

Le blog des collaborateurs de PI Services

SQL Server – Envoyer par email le résultat d’une requête

Introduction

L’une des requêtes qui peut être demandé à un adminsitrateur SQL est l’execution régulière d’une requête et le transmission de son résultat par email.

Prérequis

Afin de répondre à ce type de demande, les outils suivants seront utiles :

  • La procédure “sp_send_dbmail”,
  • L’agent SQL Server,
  • La configuration d’un profile Database Mail.

Réalisation

Le script suivant permet d’envoyer par mail le résultat de la procédure stockée “usp_StoredProcedure” :

image

Depuis la base MSDB, executer la procedure “sp_send_dbmail” (ligne 1), cette procédure prends les paramètres suivants :

@profile_name : profile mail configuré sur SQL Server sous le dossier “Management”

@recipients : adresse mail du destinataire

@subject : sujet qui figureras dans le mail envoyé

@query : requête à executer

@query_result_width : largeur en nombre de caractère du fichier qui seras envoyé en pièce jointe, par défaut la valeur est de 256 caractères, ce paramètre est important si l’on souhaite réaliser par la suite un import vers excel

@attach_query_result_as_file : utiliser la valeur “1” afin de fournir le resultat de cette requête dans un fichier en pièce jointe

@query_attachment_filename : nom du fichier en pièce jointe

@query_result_separator : caractère de séparation qui seras utilisé

L’article suivant explique plus en détails les paramètres qu’il est possible d’utiliser : https://msdn.microsoft.com/fr-fr/library/ms190307.aspx

Identifier le certificat correspondant à l’attribut AD UserCertificate ou cACertificate

Dans le cadre de la gestion des certificats dans Active Directory, il arrive que l’on retrouve des valeurs de ce type pour les attributs UserCertificate ou CaCertificate:

 image

Ce type de champ est difficilement lisible et cela peut donc complexifier la tâche lorsque l’on veut supprimer un certificat déployé en doublon, ou tout simplement un certificat avec des informations erronées.

Pour rapidement différencier les certificats il suffit de suivre les étapes suivantes:

Copier le contenu Hexadécimal dans un fichier texte :

image

image

image

Exécuter la commande suivante :

Certutil –decodehex C:\Temp\HexValue.txt C:\Temp\OutputCert.cer

image

Le résultat de la commande est un fichier .cer que l’on peut ouvrir et qui contiendra les attributs du certificat de manière lisible, ces opérations doivent être répétées sur les différentes entrées pour chaque certificat à identifier.

image

image

Poste de Travail : Fixer le Navigateur par Défaut

Voici comment fixer le navigateur par défaut de vos utilisateurs.

Via PowerShell:

Exécutez les commandes suivantes à l'ouverture de session utilisateur sous forme de script powershell en fonction de votre choix.

Pour Internet Explorer:

Set-Location HKCU:\
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice' -name ProgId IE.FTP
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice' -name ProgId IE.HTTP
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice' -name ProgId IE.HTTPS

 

Pour Mozilla Firefox:

Set-Location HKCU:\
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice' -name ProgId FirefoxURL
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice' -name ProgId FirefoxURL
    Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice' -name ProgId FirefoxURL

Vous pouvez aussi le faire par GPO dans "Configuration Utilisateur > Paramètres Windows > Registre"

Activer le démarrage automatique AppLocker sur Windows Server 2016

AppLocker est une fonctionnalité permettant de spécifier les utilisateurs ou groupes de votre organisation pouvant exécuter des applications particulières en fonction de l’identité unique des fichiers. Si vous utilisez AppLocker, vous pouvez créer des règles pour autoriser ou refuser l’exécution d’applications.

AppLocker peut, par exemple, être utilisé dans le cadre d’un déploiement d’une infrastructure PKI d’entreprise à deux niveaux afin de sécuriser l’autorité de certification racine.

Cependant, sur la version Windows Server 2016 et  il n’est actuellement pas possible de programmer le démarrage automatique du service AppIDSvc via l’interface graphique, ni même par GPO comme indiqué par Microsoft.

L’erreur suivante apparait quand on essaye d’appliquer le paramètre “Démarrage automatique” :

image

Afin que le service AppIDSvc se lance de manière automatique à chaque démarrage il faut modifier la clé de registre suivante:

Valeur: Start=2

Clé: HKLM\SYSTEM\CurrentControlSet\Services\AppIDSvc

image

Une fois la clé modifiée, redémarrez le service.

Le service est maintenant en démarrage automatique:

image

Migrer SharePoint 2010 vers SharePoint 2013

Il existe un type de migration possible connu sous le nom de « database-attach upgrade ». L'upgrade de SPS 2010 à 2013 n'étant pas supporté, il faut nécessairement créer une batterie de serveur SharePoint 2013. Nous supposons que la ferme SPS, du type 3 tiers est déjà créée.

La migration se déroule en trois grandes étapes :

  • La préparation
  • La mise à niveau des bases de données
  • La mise à niveau des sites

Préparation

La première étape consiste à identifier les éléments que vous allez migrer. Par la même occasion, collectez l'ensemble des éléments relatifs à votre infrastructure SharePoint 2010 (configuration des webapp, Mappages des accès de substitution, Fournisseurs et modes d’authentification utilisés, Modèles de quota, Chemins d’accès gérés.... Nombres de sites, de BDD de contenu, d'utilisateurs...).

Il est recommandé de rechercher et réparer les erreurs de cohérence de données de données. Un lien technet explique comment nettoyer l’environnement SP 2010 avant une migration :

https://technet.microsoft.com/en-us/library/ff382641(v=office.15)

Une fois la configuration initiale terminée, créez les applications web pour chaque application web que vous aviez sur votre SPS 2010 sur la nouvelle plateforme SPS 2013.

La mise à niveau des bases de données

  1. Passez en lecture seule les bases de données de SPS 2010 puis sauvegardez là. Pour le faire, dans « Options» de la base de données, sélectionnez « True » pour l’option « Database Read-Only ».

  1. Restaurez les bases de données sur la nouvelle instance SQL de la ferme SPS 2013.
  2. Quand une base de données est copiée, tous les anciens comptes de sécurité associés à la base de données sont conservés. Il faudra donc supprimer ces anciens comptes. Lors de son association avec SharePoint, les droits nécessaires lui seront automatiquement ajoutés (en l’occurrence les comptes Pool et Farm).

Mise à jour des bases de données

Avant d’associer les bases de données à leur WebApp respectives, il est nécessaire de s’assurer qu’elles ne présentent pas d’erreurs. Pour cela :

Test-SPContentDatabase -name "test1" -webapplication http://sitename -ServerInstance "SQL2"

Il se peut alors que les erreurs suivantes apparaissent :

  1. Missing Feature
  2. Missing Web Part
  3. Missing Setup File
  4. Missing Assembly

Ignorer l’erreur de configuration d’authentification suivante "Configuration: The [WebApp] web application is configured with claims authentication mode however […]."

Association des bases de données

Une fois les bases de données disponibles dans la nouvelle batterie, vous pouvez les lier et les mettre à niveau. Bien que cette opération mette à niveau les données, elle ne met pas à niveau l’interface utilisateur des sites contenus dans les bases de données. Mettez à niveau les bases de données à l’aide de la cmdlet Mount-SPContentDatabase.

Mount-SPContentDatabase "MyDatabase" -DatabaseServer "MyServer" -WebApplication http://sitename

Passage en authentification « claims »

Sous SharePoint 2013, l’authentification basique (NTLM) est « dégradée » et il convient d’utiliser l’authentification « claims ». Pour cela :

Convert-SPWebApplication -Identity "https://<webappurl>" -To Claims -RetainPermissions [-Force]

Notez que cela active les modes d’authentifications « Anonymous » et « Forms » dans IIS. De base, seules les authentifications Windows et ASP.NET sont activées.

Version des bases de données

Il est également recommandé de changer le mode de compatibilité des bases de données « Content ». Effectuez cette opération depuis Management Studio: Clic droit sur la base de données « Content » > Properties > Options

MISE À NIVEAU DES SITES

Une fois les bases de données mises à niveau, les administrateurs de collections de sites peuvent mettre à niveau leurs sites. Les étapes suivantes sont effectuées à partir de la page Paramètres du site de la collection de sites.

EXÉCUTION DES VÉRIFICATIONS D’INTÉGRITÉ DE COLLECTION DE SITES

Avant de mettre à niveau, les administrateurs de collections de sites peuvent utiliser l’outil de vérification d’intégrité pour identifier et traiter les problèmes éventuels qui surviennent dans leurs collections de sites. Les vérifications d’intégrité sont également exécutées automatiquement avant la mise à niveau.

MISE À NIVEAU D’UNE COLLECTION DE SITES

Après avoir vérifié que le site est prêt, les administrateurs de collections de sites peuvent mettre à niveau leur collection de sites vers la nouvelle interface utilisateur.

La migration est terminée.

 

 

Chargement du Module PowerShell SCCM 2012 R2

Vous avez installé les outils admins sur un serveur mais vous ne trouvez pas le module Configuration Manager PowerShell.

Il y a une petite subtilité, celui ci est présent mais dans les binaires de l’application:

le fichier à importer se trouver dans le répertoire c:\program files (x86)\Microsoft Configuration Manager\AdminConsole\bin et se nomme ConfigurationManger.psd1

 

Avant import

image

 

Après import

image

Identification du noeud SQL actif en PS

Vous êtes dans un contexte de database mirroré, et vous avez besoin de connaitre l’actuel serveur principal.

 

Voici une fonction qui va vous permettre de l’identifier.

 

Function Test-SQLConn ($Server)
{
    $connectionString = "Data Source=$Server;Integrated Security=true;Initial Catalog=master;Connect Timeout=2;"
    $sqlConn = new-object ("Data.SqlClient.SqlConnection") $connectionString
    trap
    {
    Write-host "Closed";
    continue
    }
    $sqlConn.Open()
    if ($sqlConn.State -eq 'Open')
    {
        $sqlConn.Close();
        "Opened successfully."
    }
}

 

image

SCOM 2012 - Des bugs dans le MP DHCP 2012

Malgré des mises à jour relativement suivies, le Management Pack DHCP conserve des erreurs y compris dans sa version la plus récente à ce jour (6.0.7301.0).

Deux problèmes en particulier me semblent particulièrement récurrents :

- Une alerte “Power Shell Script failed to run” caracterisée par sa description : “System.Management.Automation.RuntimeException: Method invocation failed because [System.String[]] doesn't contain a method named 'Item'.
At line:65 char:20
+ $OS = $CurrVer.Item <<<< (0) + "." + $CurrVer.Item(1) »

- Une absence de retour en Healthy du moniteur DHCP IPv4 Runtime Active Directory Availability Monitor.

Attardons nous donc sur ces deux problèmes.

Dans le premier cas, le message d’erreur nous indique qu’il s’agit de l’échec de l’exécution de la découverte Microsoft.Windows.DHCPServer.2012.R2.ClusterServer.Discovery. Cette dernière permet, comme son nom l’indique, de découvrir les clusters DHCP 2012 R2 et elle utilise pour ce faire le script powershell DiscoverDHCPClusterServer2012R2.

Cette découverte est ciblée sur la classe Virtual Server, c’est-à-dire tous les clusters Windows (et pas uniquement ceux sous Windows 2012), mais le script de découverte vérifie bien la version de Windows dont il s’agit en début d’exécution à l’aide du code suivant :

$CurrOS = Get-WmiObject -Namespace "root\cimv2" -Query "select Version from Win32_OperatingSystem"
$OSVer = $CurrOS.Version
$CurrVer = $OSVer.Split(".")
$OS = $CurrVer.Item(0) + "." + $CurrVer.Item(1)
if ($OS -ne $TargetOSVersion)
{
Write-Host "$SCRIPT_NAME - No Target Operating System"
$discoveryData
exit
}
else
{ exécution de la découverte }

On retrouve dans ce bloc de code la commande indiquée dans la description de l’erreur, $OS = $CurrVer.Item(0) + "." + $CurrVer.Item(1) .

La raison de cette erreur est assez simple : Powershell v2 ne supporte pas la méthode Item, comme l’indique clairement le message d’erreur « Method invocation failed because [System.String[]] doesn't contain a method named 'Item’ ». L’exécution du script échoue donc sur tous les serveurs Windows 2008 ou antérieurs pour lesquels powershell n’a pas été mis à jour !

La résolution est aussi plutôt évidente, il suffit d’utiliser la syntaxe suivante (compatible avec toutes les versions de powershell) à la place :

$OS = $CurrVer[0] + "." + $CurrVer[1]

Passons maintenant au second problème.

Le moniteur est de type Event Reset, c’est-à-dire qu’il doit revenir en Healthy lorsqu’un événement indiquant un retour à la normal apparaît dans le journal d’événement ; par défaut l’événement 1048.

Il semble toutefois que cet événement soit incorrect, ou en tout cas qu’il ne soit pas le seul qui puisse être généré. Dans le cas de l’environnement où j’ai constaté le bug, cet événement n’est jamais généré mais par contre un événement 1044 qui semble valider le même retour à la normal est lui bien présent.

Il faut donc rajouter cet événement au moniteur.

Malheureusement, pour nos deux problèmes, il s’agit d’un management pack scellé. Il est donc impossible de modifier directement le script de la découverte ou la configuration du moniteur.

La solution consiste alors à créer un management pack correctif, qui implémentera donc les bonnes versions de ces workflows et désactivera les versions d’origines erronées.

Et pour ceux qui ne se sentent pas l’âme d’un développeur, un tel Management Pack réalisé par mes soins est disponible ici : Microsoft.Windows.DHCPServer.Fix.xml

Note : ce management pack a été testé dans un environnement spécifique, rien ne garantit qu’il fonctionnera ou qu’il ne posera aucun problème dans le vôtre. Prenez donc le temps de le valider avant de le déployer en production !

Windows Server 2008 R2 : Impossible d'activer la découverte réseau

Vous est il déjà arrivé de ne pas réussir à activer la découverte réseau sur votre serveur ? 

Pas d'inquiétude cela peut arriver si certains services ne sont pas démarrés.

Contexte

Voici ce que l'on trouve lorsque l'on se rend dans "Panneau de configuration\Réseau et Internet\Centre Réseau et partage\Paramètres de partage avancés"

 

Ici lorsque l'on coche la case "Activer la découverte de réseau" puis "Enregistrer les modifications"

 

 

Si l'on retourne dans le menu "Paramètres de partage avancés" nous nous apercevons que dans le profil que nous venons juste de modifier, la case "Activer la découverte de réseau" n'est pas sélectionné et que celle qui l'est n'est autre que "Désactiver la découverte de réseau"

 

 

Solution

Ce phénomène est lié au fait que certains services ne sont pas démarrés, voici la marche à suivre.

Lancez la console "services.msc" et démarrez les services suivants:

  1. Découverte SSDP -->  Pour les OS Anglais (SSDP Discovery)
  2. Hôte de périphérique UPNP -->  Pour les OS Anglais (UPnP Device Host)

 

Maintenant vous pouvez retourner dans "Panneau de configuration\Réseau et Internet\Centre Réseau et partage\Paramètres de partage avancés" et enfin activer la découverte de réseau, elle ne changera plus.