PI Services

Dans le cadre d’un déploiement d’Orchestrator 2012 contenant des Runbook Servers dans un réseau isolé (DMZ) du reste de l’infrastructure, le déploiement des Integration Packs peut devenir problématique.

En effet, ces derniers sont normalement enregistrés dans le Management Server (Register IP) puis poussés vers les Runbook Servers et Runbook Designers (Deploy IP) à travers le réseau à l’aide de la console Deployment Manager, située sur le serveur hébergeant le rôle Management Server.

Lorsque les flux réseau sont bloqués, il n’est donc pas possible de pousser les Integration Packs vers leur destination

Deux solutions sont alors disponibles : installer les IP localement sur les serveurs en DMZ, ou ouvrir les flux nécessaires.

Installation locale

Prenons l’exemple de l’intégration pack pour Active Directory.

Il est dans un premier temps nécessaire de l’enregistrer (Register IP) tout à fait classiquement, je ne détaillerais donc pas cette étape ici :

Lors de ce processus, l’Integration Pack est copié sous forme de fichier MSI dans le dossier C:\Program Files (x86)\Common Files\Microsoft System Center 2012\Orchestrator\Management Server\Components\Objects :

Copiez ce fichier vers le Runbook Server ou le Runbook Designer de DMZ, puis exécutez-le.

L’installeur se déroule et se ferme sans aucune intervention de votre part, mais une fois terminé, l’Integration Pack doit être visible dans le Deployment Manager et ses activités doivent apparaitre dans le Runbook Designer (il est nécessaire de le relancer s’il était déjà ouvert) :

Ouverture des flux

Là aussi, il est tout d’abord nécessaire d’enregistrer l’Integration pack de façon classique (Register IP)

Lors du déploiement par la console Deployment Manager, les protocoles utilisés sont SMB et WMI, c’est-à-dire les habituels ports 135 et 445 en TCP, qu’il faudra donc ouvrir entre votre LAN et la DMZ où se trouvent vos Runbook Servers ou Runbook Designers.

Il est bien entendu également nécessaire d’ouvrir ces ports dans un éventuel firewall (Windows ou autre), ainsi que d’autoriser l’accès réseau à l’exécutable %SystemRoot%\SysWOW64\OrchestratorRemotingService.exe ; autrement le déploiement ne fonctionnera pas.

Le déploiement se fait ensuite via la console Deployment Manager de la même manière que si les serveurs cible étaient dans le LAN.

Complément

Attention toutefois, dans le cadre de l’utilisation d’un environnement Orchestrator disposant de serveurs Runbook à la fois dans le LAN et dans la DMZ : il devient alors primordial de bien déterminer quel Runbook devra tourner sur quel serveur, soit à l’aide des propriétés du Runbook à exécuter, soit via l’activité Invoke Runbook du runbook parent qui appelle le Runbook à exécuter (il est dans ce cas possible d’en indiquer plusieurs en les séparant par des point-virgules) :

Contexte

Depuis le milieu de l’année dernière, la nouvelle version de Lync Server est sortie sous le nom de Skype for Business 2015.

Nous allons voir dans ce billet comment upgrader nos serveurs Lync 2013 vers Skype for Business 2015.

Prérequis

L’upgrade de Lync 2013 requiert certains prérequis :

• Vérifier la présence de Microsoft .Net Framework 3.1 (avec HTTP Activation)
• Vérifier la présence de Microsoft .Net Framework 4.5 (avec HTTP Activation)
• Vérifier la présence de Windows Identity Foundation
• Vérifier la présence de PowerShell 3.0
• Installer le correctif suivant en fonction du système d’exploitation
  Windows Server 2008 R2 https://support.microsoft.com/en-us/kb/2533623
  Windows Server 2012 https://support.microsoft.com/en-us/kb/2858668
  Windows Server 2012 R2 https://support.microsoft.com/en-us/kb/2982006
• Installer les dernières mises à jour de Lync Server 2013
• Installer l’ensemble des mises à jours Windows Server disponibles
• Mettre à jour SQL Server vers la version 2012 SP1 minimum
• Avoir un serveur d’administration dans le domaine sans aucun composants Lync Server
• L’ISO de Skype for Business Server 2015

Lorsque Lync 2013 est présent dans une architecture il n’est pas nécessaire de faire une extension de schéma Active Directory pour installer Skype for Business 2015.

Installation

Vérification de la réplication

Lancer la commande Get-CsManagementStoreReplicationStatus pour vérifier que la réplication fonctionne correctement.

Installation des outils Skype for Business 2015 sur le serveur d’administration

Monter l’ISO de Skype for Business Server 2015 et exécuter le setup.exe qui se trouve dans le dossier Setup\amd64\

On remarque que l’étape Prepare Active Directory est déjà faite. Cliquer sur Install Administration Tools et suivez les différentes étapes de l’installation.

Préparation de la topologie

Lancer le Topologu Builder et télécharger la topologie existante.

Dans la topologie, localiser le pool des serveurs Front-End dans la partie Lync Server 2013. Sur le pool, faire un clic-droit et choisir Upgrade to Skype for Business Server 2015…

Un message nous invite à confirmer la mise à niveau.

Le pool de Front-End est désormais visible sur la topologie dans la partie Skype for Business Server 2015

Faire la même opération pour tous les autres pools déployés (Edge, Persistent Chat…).

Publier la topologie pour que ces changements soient pris en compte.

Mise à jour des serveurs

Maintenant que la nouvelle topologie est faite, il est possible de mettre à jour les serveurs.
Dans ce cas précis, l’update des serveurs se fera dans cet ordre : Front-End, Persitent-Chat, Edge.

Sur le serveur Front-End lancer le setup.exe qui se trouve sur l’ISO de Skype for Business Server 2015. Un assistant d’upgrade apparait et met à jour automatiquement le serveur avec les informations qu’il a récupéré de la topologie.

Une fois l’installation terminée, un message nous informe qu’il faut lancer la commande Start-CSPool.

Attention, si le pool contient plusieurs serveurs Front-End, il faut tous les mettre à jour avant de lancer la commande.

Recommencer l’opération pour l’ensemble des serveurs Lync Server 2013.

Remarque : Avant de mettre à jour les serveurs Edge, il est nécessaire d’exporter la configuration depuis un serveur Front-End et de l’importer sur les serveur Edge en utilisant les commandes PowerShell suivantes :

• Export-CsConfiguration –FileName “C:\temp\Configration.zip”
• Import-CsConfiguration –FileName ‘C:\temp\Configuration.zip” –LocalStore

Vérification

Une fois l’ensemble des serveurs mis à jour, lancer la commande Get-CsManagementStoreReplicationStatus pour vérifier que la réplication fonctionne. On remarque que la version des serveurs est passée de 5.0.x à 6.0.x.

Contexte

Depuis le client Skype Entreprise 2016 lorsque vous souhaitez afficher les conversations archivées qui se trouvent dans Outlook vous obtenez l’erreur suivante : Votre profil Outlook n'est pas correctement configuré.

Explication

Si l’on regarde la configuration du client Skype, on remarque que la connexion MAPI n’est pas active :

Si l’on utilise le même compte sur un client Skype for Business 2015 (Suite Office 2013), la connexion se faite correctement :

D’après Microsoft, l’erreur provient de la nouvelle méthode de mises à jour du cache MAPI. Dans les versions antérieures à 2016, les connexions MAPI étaient écrites dans le registre et le client Skype allait lire ces informations.

Source : https://support.microsoft.com/en-us/kb/3147130

Solution

La solution consiste à écrire manuellement dans le registre la configuration nécessaire au client Skype pour sa connexion MAPI.

Premièrement nous allons récupérer le LegacyDN de notre compte via l’outil de configuration automatique de la messagerie d’Outlook.

Ensuite deux possibilités :

• Télécharger l’outil de fix de Microsoft à ce lien
• Faire la modification manuellement

Via l’outil de Microsoft

Télécharger et lancer l’outil. Séléctionner Advanced pour lancer l’outil en mode administrateur.

Copier le LegacyDN (sans <LegacyDN> et </LegacyDN>) et cliquer sur Next.

Fermer le client Skype et relancer-le.

Manuellement

Dans la base de registre, trouver la clé KEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\9375CFF0413111d3B88A00104B2A6676\

Rechercher quelle sous-clé contient les informations du compte, dans le cas présent c’est la clé 00000002. Il faut ensuite repérer la valeur de Service UID.

Localiser la clé KEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\<Service UID>

Dans notre cas KEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\ 5b07c5bbc8f4f0438cf8c44ec42c4d46.

Ajouter une nouvelle valeur de type String nommée 001e6603 et contenant la valeur du LegacyDN (sans <LegacyDN> et </LegacyDN>).

Fermer le client Skype et relancer-le.

Contexte

Le client Skype for Business 2016 crash au lancement et l’erreur suivante est présente dans le journal d’évènement :

• Source : Application Error
• Event ID : 1000
• Faulting application name: lync.exe, version: 16.0.6001.1061, time stamp: 0x56a8bfee
  Faulting module name: KERNELBASE.dll, version: 6.3.9600.18202, time stamp: 0x569e7eb1
  Exception code: 0xe06d7363
  Fault offset: 0x0000000000008a5c
  Faulting process ID: 0x16dc
  Faulting application start time: 0x01d172df68ee6f51
  Faulting application path: C:\Program Files\Microsoft Office\root\Office16\lync.exe
  Faulting module path: C:\Windows\system32\KERNELBASE.dll
  Report ID: a7d53f58-ded2-11e5-8280-4437e6b7c370
  Faulting package full name:
  Faulting package-relative application ID:

Explication

Le problème provient de l’installation de Microsoft Office qui se trouve être en 32 bits, alors que l’architecture de l’ordinateur repose sur du 64 bit.

Pour vérifier l’architecture de l’ordinateur, il faut se rendre dans les propriétés systèmes (Panneau de configuration, Système) :

Pour vérifier la version d’Office installée, lancer Word, dans Compte cliquer sur A propos de Word. Dans la fenêtre d’information se trouve la version exacte.

Solution

Désinstallé entièrement Microsoft Office et bien prendre soin de supprimer le dossier :

• C:\Program Files (x86)\Microsoft Office

Ensuite relancer l’installation de Microsoft Office en utilisant une version 64 bits.

Une fois Office installé en 64 bits, le client Skype se lance normalement. Il est possible de voir que la version installée est bien en 64 bits.

Il peut s’avérer nécessaire de changer les credentials des comptes de service utilisés par Orchestrator, lors d’incidents habituels dans le cycle de vie du produit (perte du mot de passe, politique de sécurité…).

Cependant, cela nécessite une reconfiguration à plusieurs niveaux :

Compte de service Orchestrator

Le premier niveau est le changement de credentials du compte utilisé pour exécutez les services Orchestrator (Management Service, Runbook Services…)

Dans un premier temps, il faut remplacer les mots de passe des services qui se trouvent sur chaque serveur hébergeant un rôle Orchestrator (Management, Runbook…).

Tout ou partie des services suivants peuvent être présents, en fonction des rôles attribués au serveur :

Pour modifier le compte utilisé par ces services, double-cliquez sur chacun d’eux et ouvrez l’onglet Log On :

Indiquez le nouveau login et/ou mot de passe puis cliquez sur OK.

Il est ensuite également nécessaire de modifier le compte utilisé par le pool d’application IIS :

Dans la console IIS Manager, ouvrez les Applications Pools et sélectionnez System Centez 2012 Orchestrator Web Features.

Faire un clic-droit et sélectionnez Advanced Settings.

Dans le champ Identity, cliquez sur l’icône « … »

Cliquez sur Set

Indiquez le nouveau login et/ou mot de passe du compte de service, puis cliquez sur OK dans chacune des fenêtres ouvertes.

Compte d’accès à la base SQL

Le second niveau concerne la modification des credentials du compte utilisé par Orchestrator pour se connecter à sa base SQL : il ne s’agit pas nécessairement du compte de service utilisé précédemment.

Lorsqu’il est modifié, la configuration d’Orchestrator doit être également modifiée sur l’ensemble des serveurs exécutant le rôle Runbook Server et/ou le rôle Web Service.

Runbook Server

Lancez la console Data Store Configuration :

Indiquez le nom du serveur SQL dans le champ Server et les credentials de connexion à l’instance SQL dans les champs Authentication Credentials., puis cliquez sur Next.

Cochez Use an existing data store et sélectionnez la base Orchestrator, puis cliquez sur Finish.

N’oubliez pas de répéter cette opération sur chacun des serveurs de Runbook.

Web Service

Le fichier de configuration du webservice est chiffré, il est donc nécessaire de le déchiffrer avant de le modifier.

Ouvrez un prompt de commande en mode administrateur et exécutez la commande

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pdf "connectionStrings" "D:\Program Files (x86)\Microsoft System Centez 2012 R2\Orchestrator\Web Service\Orchestrator2012"

Dans la console IIS Management, ouvrez l’arborescence Sites/Microsoft System Centez 2012 Orchestrator Web Service/Orchestrator2012.

Ouvrez la configuration des Connection Strings

Ouvrez Orchestrator Context et modifiez les informations de connexion à la base de données (serveur, instance, credentials…) en fonction du besoin.

Chiffrez à nouveau le fichier de configuration à l’aide de la commande C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "D:\Program Files (x86)\Microsoft System Centez 2012 R2\Orchestrator\Web Service\Orchestrator2012"

Enfin, redémarrez IIS à l’aide de la commande iisreset.exe

Ca y est, nous avons désormais fait le tour de cette procédure, assez fastidieuse il est vrai… et malheureusement pas automatisable sous forme de runbook

Nous allons voir comment configurer l’adressage IP d’un serveur Nano lors de son premier démarrage.

Monter le vhdx de votre image Nano.

Aller dans la lettre de lecteur monté contenant votre image Nano

Positionner vous dans le répertoire I:\Windows.

Créer le répertoire Setup si celui ci n’existe pas.

Créer maintenant dans i:\Windows le répertoire Scripts

Créer dans le répertoire Scripts un fichier portant le nom setupcomplete.cmd

Lors du premier démarrage de votre image Nano, le script setupcomplete.cmd sera exécuté.

Ainsi, vous pouvez à partir de ce script, configurer l’interface réseau de votre serveur Nano.

Exemple :

Nous allons configurer sur notre serveur Nano l’adresse IP 192.168.1.11/24 avec comme adresse DNS le 192.168.1.10.

Pour cela, nous allons enregistrer les lignes de commandes suivante dans le setupcomplete.cmd :

PowerShell -Command "& {if ($env:computername -eq 'NANO'){netsh interface ip set address 'Ethernet' static 192.168.1.11 255.255.255.0 192.168.1.254}}"
PowerShell -Command "& {if ($env:computername -eq 'NANO'){netsh interface ipv4 add dnsserver "Ethernet" address=192.168.1.10 index=1}}"

Ejecter votre VHD depuis l’explorateur Windows.

Lancer votre serveur Nano.

Le script SetupComplete.cmd s’exécute (car il s’agit du premier lancement du serveur Nano depuis sa génération).

Authentifier vous

Nos paramètres IP se sont correctement configurés.

Contexte

L’une des tâches régulièrement exécutées par un DBA est de restaurer ou d’attacher des bases entres différentes instances SQL. Lors de ce type d’opération, il est fréquent de rencontrer des erreurs d’authentification du type :

• Error 15023 : User already exists in the current database,
• Error 4064 : Cannot open user default database. Login failed,
• The database <VOTREBASE> is not accessible. (Object Explorer). A la vue de ces erreurs, un DBA peux être tenté de retirer manuellement les utilisateurs des différentes bases de données pour les ajouter, cette action – bien que fastidieuse – résoudrais le problème décrit, il existe néanmoins des solutions intégrées à SQL pour détecter et mapper les utilisateurs orphelins (orphaned users).

 

Explication du problème

Les utilisateurs orphelins apparaissent lorsque le SID d’un utilisateur d’une base de donnée ne correspond pas au SID du même utilisateur qui est renseigné dans la base master.

Le SID d’un utilisateur apparait donc à deux niveaux :

• Au niveau instance : dans les vues système '”sys.server_principals” et “sys.syslogins” présentes dans la table Master,
• Au niveau base de donnée : dans la table système sysusers.

Le SID d’un utilisateur (identifiant unique) sert à mapper un utilisateur d’une base de donnée au login renseigné dans l’instance SQL, donc lors de la restauration d’une base de donnée vers une instance SQL différente, il faut penser à re-mapper les utilisateurs orphelins.

Résolution

Afin de re-mapper les utilisateurs orphelins sans avoir à passer sur chaque utilisateur manuellement, on peux s’aider de sp_change_users, cette commande prends trois paramètres différents :

• Report pour détecter les utilisateurs orphelins :

• Update_one pour mapper manuellement un utilisateur de la base à un login de l’instance :

  USE <YOURDATABASE> GO sp_change_users_login @Action='update_one' @UserNamePattern='User1' @LoginName='User1' GO

• Auto_fix pour mapper automatiquement un utilisateur de la base à un login de l’instance et pour créer le login si absent de l’instance :

  USE <YOURDATABASE> GO sp_change_users_login @Action='auto_fix' , 'User1', null, 'Password' GO

Ce petit script va vous permettre de récupérer dans une variable un tableau de l’ensemble des process tournant sur le poste avec leurs ID et leurs propriétaire

$process=gwmi win32_process
$array=@()
foreach ($p in $Process)
{
    $temp=new-object psobject
    $temp |add-member -MemberType NoteProperty -name "ProcessName" -Value $p.name
    $temp |add-member -MemberType NoteProperty -name "ProcessID" -Value $p.ProcessID
    $temp |add-member -MemberType NoteProperty -name "User" -Value $p.getowner().user
    $array+=$temp
}

Exemple :

Ainsi, pour killer des processus, vous pouvez maintenant ajouter la contrainte par identification du propriétaire du Processus.

Exemple :

Nous allons killer les process Spotify de l’utilisateur ato

Tout d’abord on récupère les Processus respectant cette contrainte dans notre variable:

$array |? {$_.processname -eq "Spotify.exe" -and $_.user -eq "ato"}

Et ensuite, on les Kill grâce à leurs identifiants :

$array |? {$_.processname -eq "Spotify.exe" -and $_.user -eq "ato"} |%{stop-process -Id $_.processID}

Résultat : Plus de musique   (les processus Spotify de l’utilisateur ato ont été arrêtés).

Il peut être utile de disposer du nom d’utilisateur qui exécute un Processus.

Exemple en GUI :

Cependant en PowerShell, à l’aide de la commande Get-Process, nous ne disposons pas des utilisateurs.

Exemple en PS :

Il existe différente méthodes pour voir les processus sous PS.

Nous allons maintenant utiliser un appel wmi pour afficher les processus via la commande :

gwmi win32_process

Exemple :

En utilisant l’appel wmi, nous avons une propriété nous permettant de connaitre l’utilisateur propriétaire du processus que nous n’avons pas via la commande get-process

Exemple de récupération du propriétaire du processus Spotify à l’aide de la propriétée getowner :

(gwmi win32_process |? {$_.name -match "spotify"} |select -index 0).getowner().user

Nous avons maintenant récupéré le propriétaire du processus.

Contexte

Le post suivant explique comment récupérer des droits sysadmin sur un serveur de base de données suite à la perte du mot de passe du compte SA.

Afin de réaliser cette procédure il faut :

• Un compte administrateur local,
• Planifier un créneau d’interruption durant la récupération des droits SA.

Récupération des droits sysadmin

1. Démarrer l’instance SQL en “single user mode” (ou monouser) avec la commande suivante depuis le répertoire “C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn” :

Il est également possible d’exécuter l’opération avec l’instance démarrées en “minimal configuration” avec le switch –f.

2. Une fois la base de données démarrée en mode “single user” il est possible d’utiliser l’outil SQLCMD pour récupérer les droits sysadmin, exécuter la commande suivante :

3.Une fois connecté depuis SQLCMD, il faut créer un nouvel utilisateur (User1 dans l’exemple suivant) à qui affecter les droits sysadmin à l’aide des commandes suivantes :

4. Redémarrer l’instance SQL (avec la commande SQLServr.Exe) puis se connecter avec le login User1 afin de modifier le mot de passe du compte SA.