PI Services

Le blog des collaborateurs de PI Services

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.

 

Powershell : Découverte des postes en DHCP et IP fixes

Qui n'a jamais été confronté à un conflit d'adresse IP dans son réseau?

Le plus énervant quand cela arrive c'est de déterminer qui a une IP fixe sur sa machine alors que l'ensemble du parc est censé être en DHCP.

Afin de se se faciliter la tâche et de ne pas devoir passer sur chaque poste voici un script qui va vous permettre de savoir quels postes sont éteints, quels postes sont en DHCP et surtout lesquels ne le sont pas et avec quelle adresse IP (ou plutôt l'ensemble des configurations de chaque carte réseau).

Les Outils :

Pour ce faire vous aurez besoin d'un fichier texte avec les informations suivantes:

  • La première ligne doit s'appeler "Ordi"
  • le reste du fichier contient le nom de vos machines

Exemple :

Dans mon cas le fichier s'appelle DHCP.txt (le nom sera réutilisé dans le Script)

Une fois que le fichier est créé passons à la seconde partie le script:

Dans votre cas il suffira de modifier les lignes:

  • 3
  • 10
  • 17
  • 18
  • 19 
# Script pour détecter l'état des cartes réseaux

$CSV = "C:\Users\XXX\Documents\DHCP.txt"  # Ici on déclare le chemin d'accès au fichier créé plus tôt

# Import du fichier
Import-Csv -Path $CSV | ForEach-Object {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt

# Test de connexion afin de vérifier que le poste est démarré
If ((Test-connection $Postes -count 2 -Quiet) -eq "True") {

# Déclaration des variables
$Postes = $_.ordi
$Destination = "C:\Users\XXX\Documents\Audit\DHCP\$Postes.txt" # Attention Ici lorsque vous modifiez le chemin ne supprimez pas $Postes.txt
$Poste_DHCP = "C:\Users\XXX\Documents\Audit\OK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes en DHCP
$Poste_Off = "C:\Users\XXX\Documents\Audit\NOK.txt" # Ici on déclare le chemin et le fichier dans lequel seront inscrit les postes éteints

# Récupération des paramètres de la ou des cartes réseaux
Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | ForEach-Object {
$IP = $_.IPAddress
$DHCP = $_.DHCPEnabled
if (($DHCP -eq $False) -and ($IP -ne $null)) {Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Postes | Select-Object -Property ServiceName,Description,DHCPEnabled,IPEnabled,IPAddress | fl | Out-File $Destination}
Elseif (($DHCP -eq $True) -and ($IP -ne $null)) {Write-Output "Le poste $Postes est en DHCP" | Add-Content -Path $Poste_DHCP}
}
}
Else {
Write-Output "Le poste $Postes est éteint" | Add-Content -Path $Poste_Off
}}

 

En espérant que cela vous servira.

Azure Stack - TP2 v2, VPN et Windows 7

 

La sortie il y a quelques jours de la seconde version de la TP2 d’Azure Stack (dite “refresh”) a enfin été pour moi l’occasion de tester ce produit qui s’annonce très prometteur (pour rappel, il s’agit de la possibilité de déployer Azure dans votre Datacenter).

Je ne reviendrais pas ici sur le détail de son déploiement, il existe déjà de nombreux articles à ce sujet.

Notez simplement que cette seconde édition de la TP2 apporte le support du PaaS (par exemple pour déployer des bases SQL) ainsi qu’un script de déploiement amélioré : j’ai pu réaliser l’installation du début à la fin sans erreur, alors qu’une précédente tentative avec la TP2 d’origine s’était avérée nettement plus réticente. Cette nouvelle version nécessite une réinstallation complète du POC (il n’est pas possible de mettre à jour depuis la TP2 d’origine) et est disponible ici : https://azure.microsoft.com/en-us/blog/new-azure-paas-services-available-for-azure-stack-technical-preview-2-tp2/

Attention cependant, une étape manuelle reste nécessaire à la fin du déploiement si vous avez utilisé une IP statique, autrement votre infrastructure deviendra inutilisable au bout de 10 jours : https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=AzureStack&announcementId=f35560ea-b0d2-4be0-b407-e20fe631d9fe

Une fois déployée, vous avez deux possibilités pour accéder au portail web Azure Stack :

- Vous connecter à la VM console (mas-con01) via la console Hyper-V ou en Bureau à distance depuis votre serveur hôte puis ouvrir le raccourci « Microsoft Azure Stack Portal » qui se trouve sur le bureau

- Créer une connexion VPN vers votre infrastructure Azure Stack afin d’y accéder directement depuis votre poste client.

Cette seconde possibilité est évidemment la plus pratique, mais je me suis heurté à un problème : la procédure proposée sur Technet ( https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-connect-azure-stack chapitre « connect with VPN ») ne fonctionne pas sous Windows 7, même en ayant installé Powershell 5, en raison de l’absence des cmdlet powershell dédiés au VPN.
Comme je ne disposais que d’un poste sous Windows 7 dans l’environnement où a été réalisé ce déploiement de test, j’ai eu recours à une solution de contournement :

Dans le centre réseau et partage, cliquez sur Configurer une nouvelle connexion ou un nouveau réseau :

clip_image002

Sélectionnez Connexion à votre espace de travail :

clip_image004

Sélectionnez Utiliser ma connexion Internet (VPN) :

clip_image006

Indiquez l’adresse IP de votre réseau de la VM MAS-BGPNAT01. Il s’agit de l’IP indiquée dans le paramètre -NatIPv4Address si vous avez réalisé un déploiement avec une adresse statique. Indiquez également un nom explicite, AzureStack par exemple, et cochez la case Ne pas me connecter maintenant (il faudra faire des modifications à la configuration par défaut avant qu’elle puisse fonctionner).

clip_image008

Indiquez les détails du compte azurestack\azurestackadmin puis cliquez sur créer :

clip_image010

Rouvrez maintenant les propriétés de cette connexion VPN :

clip_image012

Dans l’onglet Gestion de réseau, sélectionnez Propriétés internet version 4, cliquez sur Propriétés. Cliquez sur Avancé dans la fenêtre qui s’ouvre, puis décochez Utiliser la passerelle par défaut :

clip_image014

A l’aide de la commande route print, récupérez le numéro de l’interface réseau AzureStack :

clip_image016

Ajoutez les deux routes statiques suivantes (où « XX » est le numéro récupéré juste avant) :

route add 192.168.105.0 mask 255.255.255.224 192.168.200.225 IF XX -p

route add 192.168.102.0 mask 255.255.255.224 192.168.200.225 IF XX -p

Enfin, si votre navigateur (Internet Explorer vivement recommandé, le portail fonctionne assez mal avec Firefox et Chrome ! ) passe par un proxy pour accéder à internet, pensez à en exclure toutes les url du domaine azurestack.local et de ses sous-domaines (*.azurestack.local ), autrement vous ne pourrez pas charger (ou pas complètement) le portail !

clip_image018

 

Voilà, vous pouvez maintenant vous connecter au VPN, puis ouvrir votre navigateur à l’adresse http://portal.azurestack.local et commencer à découvrir Azure Stack!

SCOM - La console plante depuis les patchs de sécurité d’Octobre

Quoi de plus frustrant pour reprendre le travail que de se retrouver face à son outil préféré devenu soudain inutilisable?

Si depuis quelques jours, votre console SCOM fait des siennes et plante à chaque fois que vous tentez d’accéder à une vue de type “état” (telle que Windows Computers par exemple), avec l’erreur suivante :

image

Et qu’en même temps, vous retrouvez un message d’erreur similaire au suivant dans votre journal d’évènements Application :

Faulting application name: Microsoft.EnterpriseManagement.Monitoring.Console.exe, version: 7.1.10226.1177, time stamp: 0x5697e092 Faulting module name: ntdll.dll, version: 6.3.9600.18438, time stamp: 0x57ae642e Exception code: 0xc0000374 Fault offset: 0x00000000000f1b70 Faulting process id: 0xfac Faulting application start time: 0x01d2254a42863351 Faulting application path: <C:\Program Files\Microsoft System Center 2012 R2 \Operations Manager\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

Le coupable est tout trouvé, il s’agit des patchs de sécurité Windows du mois d’Octobre, en particulier MS16-118 et MS16-126 (concernant Internet explorer notamment), comme le confirme la KB suivante : https://support.microsoft.com/en-us/kb/3200006

Il ne vous reste plus qu’à appliquer sur les machines hébergeant vos consoles SCOM (serveurs SCOM, postes d’administration, serveurs Citrix…) le hotfix proposé.

Attention, ce hotfix n’est pas spécifique à SCOM et sa dénomination dans le catalogue Microsoft peut donc être trompeuse : il s’agit par exemple de “Mise à jour pour Internet Explorer 11 pour Windows Server 2012 R2 (KB3200006) “ dans le cas du hotfix pour Win 2012 R2.

L’installation de ce hotfix ne nécessite normalement pas de redémarrage, mais si le problème persiste après l’installation cela aidera à le résoudre définitivement.