PI Services

Le blog des collaborateurs de PI Services

Skype for Business - Retour d'expérience sur la mise en place de la téléphonie 3/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. Voici la troisième partie qui traitera des solutions connexes à Skype for Business afin d'augmenter le catalogue de fonctionnalités de la solution.

Solutions connexes

Skype for Business n'a pas par défaut une solution pour l'ensemble des besoins téléphonique d'une société. Il existe des solutions tierces qui s'intègrent avec Skype. En voici quelques-unes.

ACD

Les ACD (ou Automatic Call Distribution) sont des dispositifs (logiciels ou matériels) qui permettent la gestion d'un centre d'appels. Ces centres d'appels peuvent être des accueils, des relations patron / secrétaire, un service support...

Par défaut, Skype intègre les Response Groups. Cette fonctionnalité permet de faire des groupements d'appels. Malheureusement cette fonctionnalité est limitée et ne permet pas de répondre à tous les besoins. 

J'ai pu tester deux solutions d'ACD lors de mes projets qui sont :

 Logs et facturation

Il est possible d'activer dans Skype for Business les rapports de surveillance. Pour cela, il faut configurer le rôle SQL Reporting Services sur un serveur Back-End. Ces logs tracent l'ensemble des communications des utilisateurs (chat, partages, appels entrants, sortants...).

Bien que ces logs existent, pour faire de la facturation sur les appels sortants ils sont peu exploitables. Il y a alors deux possibilités, faire appel à une solution tierce (comme Periscope GC http://www.cvt.com.au/periscopegcskypefb ou UC Analytics http://www.mindcti.com/uc-analytics/) ou développer un rapport personnalisé dans SQL Reporting Services.

Conclusion

De nombreux éditeurs ont développés des solutions supplémentaires pour Skype for Business. Microsoft recense l'ensemble des applications tierces compatibles sur le site http://apps.skypeforbusiness.com/.

Ce billet termine mon retour d'expérience sur la téléphonie à travers Skype for Business. J'espère qu'il vous a été utile. 

Active Directory: Windows Server 2008 DCPROMO en erreur

Problème:

Sur Windows Server 2008 quand vous réalisez la rétrogradation d'un contrôleur de domaine à simple serveur membre, vous pouvez rencontrer une erreur de type :

"Operations which require contacting a FSMO operation master will fail until this condition is corrected"

Ce problème se produit quand la commande essaie de contacter le maître d'infrastructure et qu'elle echoue pour une des raisons suivantes:

  • La ou les partitions mentionnées dans le message d'erreur ne sont plus existantes.
  • Le maître d'infrastructure pour la ou les partitions mentionnées, a été rétrogradé de force ou est hors ligne (hors réseau ou éteint).

Solution:

Dans le premier cas de figure Microsoft préconise un nettoyage des métadonnées de la partition orpheline en utilisant l'outils Dsmgmt (cf: http://technet.microsoft.com/en-us/library/cc730970(ws.10).aspx ).

Dans le deuxième cas de figure il suffit de spécifier un propriétaire du rôle maître d'infrastructure qui est "En ligne", pour cela vous pouvez exécuter le script suivant à l'aide de la commande :

cscript fixfsmo.vbs DC=DomainDnsZones,DC=VotreNomDeDomaine,DC=XXX (Remplacez XXX par votre extension: fr, com, lan, biz...)

Le script:

Le script ci-dessous permet de modifier l'attribut "fSMORoleOwner" dans le domaine spécifié dans la ligne de commande.

'-------fixfsmo.vbs------------------
const ADS_NAME_INITTYPE_GC = 3
const ADS_NAME_TYPE_1779 = 1
const ADS_NAME_TYPE_CANONICAL = 2

set inArgs = WScript.Arguments

if (inArgs.Count = 1) then
    ' Assume the command line argument is the NDNC (in DN form) to use.
    NdncDN = inArgs(0)
	Else
    Wscript.StdOut.Write "usage: cscript fixfsmo.vbs NdncDN"
	End if
	
if (NdncDN <> "") then

' Convert the DN form of the NDNC into DNS dotted form.
    Set objTranslator = CreateObject("NameTranslate")
    objTranslator.Init ADS_NAME_INITTYPE_GC, ""
    objTranslator.Set ADS_NAME_TYPE_1779, NdncDN
    strDomainDNS = objTranslator.Get(ADS_NAME_TYPE_CANONICAL)
    strDomainDNS = Left(strDomainDNS, len(strDomainDNS)-1)
	
	Wscript.Echo "DNS name: " & strDomainDNS
    
	' Find a domain controller that hosts this NDNC and that is online.
    set objRootDSE = GetObject("LDAP://" & strDomainDNS & "/RootDSE")
    strDnsHostName = objRootDSE.Get("dnsHostName")
    strDsServiceName = objRootDSE.Get("dsServiceName")
    Wscript.Echo "Using DC " & strDnsHostName

    ' Get the current infrastructure fsmo.
    strInfraDN = "CN=Infrastructure," & NdncDN
    set objInfra = GetObject("LDAP://" & strInfraDN)
    Wscript.Echo "infra fsmo is " & objInfra.fsmoroleowner
	
	' If the current fsmo holder is deleted, set the fsmo holder to this domain controller.
    if (InStr(objInfra.fsmoroleowner, "\0ADEL:") > 0) then
	' Set the fsmo holder to this domain controller.
	objInfra.Put "fSMORoleOwner",  strDsServiceName
	objInfra.SetInfo
	
	' Read the fsmo holder back.
	set objInfra = GetObject("LDAP://" & strInfraDN)
	Wscript.Echo "infra fsmo changed to:" & objInfra.fsmoroleowner
	
    End if
	
End if	

 

Une fois le script exécuté vous devriez pouvoir rétrograder votre contrôleur de domaine, si toutefois le problème persistait il faudra passer par la console ADSI Edit.

SCOM – SQL – Requête d’inventaire des overrides

La requête ci-dessous permet de lister tout les overrides de manière ‘clarifiés’ afin d’identifier les objets a la source de ces overrides, les paramètres concernés et les management pack sources et de destination.

Les paramètres @Startdate et @EndDate permettent de spécifier une fenêtre de temps concernant les dates de création et de dernière modification des overrides.

 

 

declare @StartDate  datetime declare @EndDate    datetime set @EndDate = GETDATE() set @StartDate = DATEADD(day,-60,@EndDate)   SELECT DISTINCT MP.MPFriendlyName AS 'Management Pack' , aov.ParentType AS 'Type' ,(CASE        WHEN AOV.OverrideType = 'RuleProperty' THEN R.RuleName        WHEN AOV.OverrideType = 'MonitorProperty' THEN M.MonitorName        WHEN AOV.OverrideType = 'RuleConfiguration' THEN R.RuleName        WHEN AOV.OverrideType = 'MonitorConfiguration' THEN M.MonitorName  END) AS 'NameType', mt.DisplayName AS ContextDisplayName , aov.OverrideableParameterName , aov.Value, (CASE Enforced        WHEN '0' THEN 'False'        WHEN '1' THEN 'True'   END) AS 'Enforced'   , aov.LastModified   , aov.TimeAdded   ,(CASE   WHEN AOV.OverrideType = 'RuleProperty' THEN              (CASE R.RuleEnabled              WHEN '0' THEN 'False'              WHEN '2' THEN 'True'              WHEN '3' THEN 'True'              WHEN '4' THEN 'True'              END)     WHEN AOV.OverrideType = 'MonitorProperty' THEN              (CASE M.MonitorEnabled              WHEN '0' THEN 'False'              WHEN '2' THEN 'True'              WHEN '3' THEN 'True'              WHEN '4' THEN 'True'              END)     WHEN AOV.OverrideType = 'RuleConfiguration' THEN              (CASE R.RuleEnabled              WHEN '0' THEN 'False'              WHEN '2' THEN 'True'              WHEN '3' THEN 'True'              WHEN '4' THEN 'True'              END)                WHEN AOV.OverrideType = 'MonitorConfiguration' THEN              (CASE M.MonitorEnabled              WHEN '0' THEN 'False'              WHEN '2' THEN 'True'              WHEN '3' THEN 'True'              WHEN '4' THEN 'True'              END) END) AS 'Enable_by_default', MPSTORE.MPFriendlyName AS 'MP Stored'   FROM AllOverrideView AS aov LEFT OUTER JOIN Rules AS R WITH (nolock) ON aov.TargetId = R.RuleId AND (aov.OverrideType = 'RuleProperty' OR aov.OverrideType = 'RuleConfiguration') LEFT OUTER JOIN Monitor AS M WITH (nolock) ON aov.TargetId = M.MonitorId AND (aov.OverrideType = 'MonitorProperty' OR aov.OverrideType = 'MonitorConfiguration') LEFT OUTER JOIN  ManagementPack AS MP WITH (nolock) ON (CASE                                                                                               WHEN AOV.OverrideType = 'RuleProperty' THEN R.ManagementPackId                                                                                               WHEN AOV.OverrideType = 'RuleConfiguration' THEN R.ManagementPackId                                                                                               WHEN AOV.OverrideType = 'MonitorProperty' THEN M.ManagementPackId                                                                                               WHEN AOV.OverrideType = 'MonitorConfiguration' THEN M.ManagementPackId                                                                                               END) = MP.ManagementPackId INNER JOIN ManagementPack AS MPSTORE WITH (nolock) ON MPSTORE.ManagementPackId = aov.ManagementPackId LEFT OUTER JOIN ManagedTypeView AS mt WITH (nolock) ON mt.Id = aov.ContextId LEFT OUTER JOIN ManagedTypeView AS mtv WITH (nolock) ON mtv.Id = aov.ContextObjectId   WHERE (MP.MPFriendlyName IS NOT NULL) AND (aov.LastModified BETWEEN @StartDate AND @EndDate) OR (MP.MPFriendlyName IS NOT NULL) AND (aov.TimeAdded BETWEEN @StartDate AND @EndDate)   ORDER BY aov.TimeAdded DESC

Clients disparaissant aléatoirement dans la console WSUS

Contexte

Lors du déploiement d'un nouveau serveur WSUS, des serveurs ou postes de travail apparaissent et disparaissent de la console sans raison logique au premier abord.

Explication

Si les clients apparaissent et disparaissent de la console par intermittence, le soucis vient probablement du SUSClientID.

Cette situation peut arriver quand un serveur est cloné et que les clés de registre liées au SUSclientID ne sont pas modifiées, ou dans le cas des postes de travail, le problème peut se poser si les postes sont déployés via une image système mal configurée (pas de sysprep). 

Résolution

La solution a ce problème est relativement simple une fois que les différents clients concernés ont été identifiés.

Sur chaque client concerné, supprimez clés de registre suivantes:

  • SusClientId
  • SusClientIDValidation

Ces clés sont situées à la racine de la ruche: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate

Ouvrez ensuite une invite de commande en mode administrateur et exécutez les commandes suivantes:

  • wuauclt.exe /resetauthorization / detectnow
  • wuauclt.exe /detectnow

Il faut refaire ces actions sur chaque poste client/serveur concerné.

Les clients devraient ensuite remonter sans soucis dans la console WSUS.

 

Centraliser les ADMX dans le Group Policy Central Store

 

Dans le cadre de la gestion des GPO, il arrive de temps en temps d'avoir des temps de chargement très long lorsque que l'on tente d'accéder à certains paramètres dans la console Group Policy Management, ce problème est peut être lié à des ADMX qui ont été chargés dans la console depuis un poste client et qui ne sont pas accessibles lorsque vous ouvrez la console.

 

Afin de régler ce problème qui peut être récurrent et gênant lors de l'administration des GPOs, il est conseillé de créer une banque centrale contenant les différents fichiers ADMX.

Afin de créer le magasin Central pour les fichiers .admx et .adml (les .adml sont les fichiers de langue correspondant aux .admx), créez un dossier nommé PolicyDefinitions à l’emplacement suivant sur un contrôleur de domaine :

\\contoso.com\SYSVOL\contoso.com\policies

Après avoir copié tous les fichiers .admx et .adml, le dossier PolicyDefinitions sur le contrôleur de domaine doit contenir les fichiers .admx et un ou plusieurs dossiers contenant les fichiers spécifiques à une langue .adml.

Les fichiers étant contenu dans le SYSVOL qui est répliqué, il ne devrait plus y avoir de lenteurs liées aux .admx lors de l'ouverture de la console GPMC. 

Erreur lors du gpprep lors d'une migration AD 2003 vers AD 2016

 

Dans le cadre d'une migration depuis des contrôleurs de domaines Windows Server 2003 vers des contrôleurs de domaine en Windows Server 2016 après avoir effectué l'extension du schéma ainsi que le forestprep et le domainprep avec succès, le gpprep échoue avec l'erreur suivante:

Gpprep operation 3 failed.

Upgrade of domain Group Policy Objects failed.

Adprep encountered a Win32 error.
Error code: 0x41 Error message: Network access is denied.

Le cas initial dans lequel cette erreur a été rencontrée est le suivant:

  • Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui n'est pas contrôleur de domaine et qui est en WORKGROUP et un compte ayant les droits suffisants. En effet l'upgrade de schéma depuis un serveur en workgroup est possible en spécifiant les crédentials et les foret/domaine en paramètres sur les différentes commandes.

L'upgrade a ensuite été de nouveau tentée dans le cadre suivant:

  • Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui n'est pas contrôleur de domaine et qui est membre du domaine.

Résultat: Même erreur que dans le cas initial.

Enfin, l'upgrade a été lancée dans l'environnement suivant:

  • Extension du schéma, forestprep, domainprep, gpprep exécutés depuis un serveur Windows Server 2016, qui a été promu contrôleur de domaine au préalable et donc membre du domaine.

Résultat: Gpprep réussi.

Le fait que le GPPREP échoue, n'est pas un point bloquant pour le passage vers AD 2016, cependant il pourrait y avoir des répercussions sur les différentes GPO existantes si les modifications réalisées par le GPPREP ne sont pas appliquées correctement.

Il est également possible de faire l'ensemble des opérations depuis un serveur 2016 qui n'est pas encore contrôleur de domaine, et si le gpprep échoue, le relancer plus tard, une fois le serveur promu en tant que contrôleur de domaine.

 

SQL Server–Supprimer l’un des fichiers utilisé par la TempDB

Contexte

Lors de la suppression d’un des fichiers utilisé par la base TempDB, l’opération échoue avec l’erreur suivante :

Msg 5042, Level 16, State 1, Line 1
The file 'tempdev2' cannot be removed because it is not empty.

Explication

Ce comportement est provoqué par le fait que le fichier est actuellement utilisé par SQL, il faut donc vider le fichier avant de pouvoir le supprimer.

Une solution possible est le redemmarage de l’instance SQL, ce qui va regenerer la base TempDB, moyennant une coupure de service.

Résolution

Afin d’éviter toute coupure de service, il est possible d’executer le script SQL suivant pour vider puis supprimer un fichier utilisé par la TempDB :

USE [tempdb]
GO
DBCC SHRINKFILE('tempdev2', EMPTYFILE)
GO
ALTER DATABASE [tempdb] REMOVE FILE [tempdev2]
GO

Sources

https://tenbulls.co.uk/2016/01/13/problem-removing-files-from-tempdb/

SQL Server–Reconfigurer les plans de maintenances après avoir renommé une instance SQL

Introduction

Après avoir renommé un serveur SQL, les plans de maintenances existants échouent avec l’erreur suivante :

Réalisation

1. Lister les procédures stockées en exécutant le script suivant sur la base MSDB et récupérer la valeur “ID” :

SELECT  x.*,
        LocalServerConnectionString = cm.value('declare namespace DTS="www.microsoft.com/SqlServer/Dts";DTS:ObjectData[1]/DTS:ConnectionManager[1]/@DTS:ConnectionString', 'varchar(1000)')
FROM (
    SELECT  id, name, packageXML = CAST(CAST(packagedata AS VARBINARY(MAX)) AS XML)
    FROM dbo.sysssispackages
    WHERE id IN (SELECT id FROM dbo.sysmaintplan_plans)
) x
CROSS APPLY packageXML.nodes('declare namespace DTS="www.microsoft.com/SqlServer/Dts";/DTS:Executable/DTS:ConnectionManagers/DTS:ConnectionManager[@DTS:ObjectName="Local server connection"]') p(cm)

Voici un exemple de résultat :

image

2. Modifier la valeur “Data Source” à l’aide du script suivant :

UPDATE dbo.sysssispackages SET packagedata = CAST(CAST(REPLACE(CAST(CAST(packagedata AS VARBINARY(MAX)) AS VARCHAR(MAX)), 'OldServerName', 'NewServerName') AS XML) AS VARBINARY(MAX))
WHERE id = ‘ID'

Modifier les valeur en rouge :

  • OldServerName : Ancien nom de l’instance SQL telle qu’indiquée dans la partie “Data Source” de la colonne “LocalServerConnectionString” de la requête exécutée précédemment,
  • NewServerName : Nouveau nom de l’instance SQL,
  • ID : GUID de la tâche planifiée à reconfigurée telle qu’indiquée dans la colonne“ID” de la requête exécutée précédemment.

Vérification

  • Valider en exécutant la requête listant les procédure stockées que le nom de la nouvelle instance apparaît bien dans la partie “Data Source” de la colonne “LocalServerConnectionString”,
  • Exécuter le plan de maintenance et valider qu’il s’exécute correctement.

Liens Utiles

KEMP – Ré-écriture d’URL

Introduction

Lors de la publication d’une application WEB via KEMP, vous pouvez être amené à publier l’application en utilisant une URL différente de celle utilisée en interne.

Cet article explique la configuration à mettre en place afin de publier une application sous différents noms sans avoir à créer les bindings correspondant sur le serveur WEB.

Contexte

Une application nommée “APPLI1” est utilisée en interne via l’URL “https://appli1.internaldomain.dom”, le domaine publié en externe est nommé “https://appli1.externaldomain.com”.

L’application “APPLI1” ne supportant pas l’utilisation de bindings multiples, le KEMP de publication doit donc

  1. recevoir depuis l’extérieur les demandes provenant de l’URL “https://appli1.externaldomain.com”
  2. transmettre ces demandes en interne vers l’URL “https://appli1.internaldomain.dom”

Réalisation

Afin de mettre en place la réécriture d’URL, il faut créer les règles suivantes :

HTTP Header Modifications Rule :

image

Cette règle seras utilisée pour transformer l’URL “appli1.externaldomain.com” en “appli1.internaldomain.dom”

Cette règle doit être appliquée au niveau de la VIP dans “Advanced Properties\HTTP Header Modification”

image

Content Matching Rule :

image

Cette règle est utilisée afin que la VIP réponde à l’URL “*.externaldomain.com/*”

L’option content switching doit être activée depuis “Advanced Properties\Content Switching”

image

Cette règle doit être appliquée au niveau de la VIP dans “Real Servers\Rules” pour chaque serveur devant répondre à l’URL externe

image

Dans le cas où l’URL interne serait également publiée, il faut penser à activer la “default” content switching rule niveau de la VIP dans “Real Servers\Rules” pour chaque serveur devant répondre à l’URL externe et interne, la default rule doit toujours être positionnée en dernier :

image

Windows Server 2012 R2 : Erreur lors du déploiement du rôle RDS

Lors du déploiement du Rôle RDS sur Windows Server 2012 R2, il se peut que vous rencontriez l'erreur suivante :

"Le serveur est en attente de redémarrage et doit être redémarré."

 

Cette erreur se présente lorsque si vous avez récemment passé une mise à jour ou installer un rôle ou une fonctionnalité sans redémarrer.

Si même après avoir redémarré cela ne change rien, vérifier si la clé de registre suivante existe :

"HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations"

Si elle existe faites un backup de votre registre, puis supprimez la clé.

Normalement vous pouvez maintenant installer le Rôle RDS sans soucis.