Supprimer un controler récalcitrant de la Database

Dans un environnement “Hors Prod” nous avons rencontré un problème sur un Controller, en effet ce dernier était encore inscrit dans la ferme mais le DSName n’était plus renseigné et le MachineName contenait le SID du controller en lieu et place du nom.

 

Bien sûr une suppression dans Studio n’était pas possible 🙁

 

En googlelant nous sommes tombés sur un poste de JGSPIERS.COM “Remove orphaned Delivery Controller from XenApp XenDesktop Site“, qui via un script PowerShell (EvictiScript.ps1 ; modifier au préalable les variables $DBName $EvictedSID)  va générer un fichier evict_.txt contenant le script sql à exécuter sur le serveur SQL hébergeant votre Database.

Une fois ces étapes réalisées, notre Controller est bien supprimé de la Database (tout du moins en partie mais ça nous le verrons plus bas dans ce billet), en effet nous ne le voyons plus via un Get-BrokerController.

 

Le script de nettoyage a bien supprimé le Controller non résolu

En regardant de plus près dans la Database (une recherche sur le SID), nous avons constaté que le SID du Controller supprimé était encore présent dans la Database (901 occurrences). Le script sql permettant de faire une recherche de chaine de caractère au sein d’une base est ci-dessous.

 

USE DATABASE_NAME
 DECLARE @SearchStr nvarchar(100) = YOUR SID
 DECLARE @Results TABLE (ColumnName nvarchar(370), ColumnValue nvarchar(3630))</pre>
SET NOCOUNT ON

DECLARE @TableName nvarchar(256), @ColumnName nvarchar(128), @SearchStr2 nvarchar(110)
SET @TableName = ''
SET @SearchStr2 = QUOTENAME('%' + @SearchStr + '%','''')

WHILE @TableName IS NOT NULL

BEGIN
SET @ColumnName = ''
SET @TableName =
(
SELECT MIN(QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME))
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
AND QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME) > @TableName
AND OBJECTPROPERTY(
OBJECT_ID(
QUOTENAME(TABLE_SCHEMA) + '.' + QUOTENAME(TABLE_NAME)
), 'IsMSShipped'
) = 0
)

WHILE (@TableName IS NOT NULL) AND (@ColumnName IS NOT NULL)

BEGIN
SET @ColumnName =
(
SELECT MIN(QUOTENAME(COLUMN_NAME))
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = PARSENAME(@TableName, 2)
AND TABLE_NAME = PARSENAME(@TableName, 1)
AND DATA_TYPE IN ('char', 'varchar', 'nchar', 'nvarchar', 'int', 'decimal')
AND QUOTENAME(COLUMN_NAME) > @ColumnName
)

IF @ColumnName IS NOT NULL

BEGIN
INSERT INTO @Results
EXEC
(
'SELECT ''' + @TableName + '.' + @ColumnName + ''', LEFT(' + @ColumnName + ', 3630)
FROM ' + @TableName + ' (NOLOCK) ' +
' WHERE ' + @ColumnName + ' LIKE ' + @SearchStr2
)
END
END
END

SELECT ColumnName, ColumnValue FROM @Results

 

Une fois le script exécuté on obtient la liste de toutes les occurrences trouvées au sein de notre Database

Un petit coup de nettoyage ? 🙂

 

 

Nous avons donc supprimé les 901 occurrences de la base (avec un dump de la Database au préalable), puis nous avons publié des applications, créé des Machines Catalog/Delivery Group, Policy etc… etc… , et enfin lancé un test sur le site qui s’est terminé sans erreur 🙂 .

Comme nous souhaitions passer en 7.15 LTSR nous avons saisi l’occasion afin de tester la migration 7.6 LTSR vers 7.15 LTSR à partir d’une base nettoyée “au savon de Marseille”.

Pour info, les étapes pour une migration sont décrites dans le docs.citrix.com “Upgrade a deployment“.

Allez Go…..

 

La migration du premier Controller s’est terminée sans problème.

 

La on se dit que tout va bien….

 

On lance Studio (sur le même controller) et la une belle erreur.

 

C’est quoi cette histoire de SADate (surtout que nos licences ont une SA valide pour la 7.15 LTSR)

 

En rentrant le nom du DDC fraichement migré dans le champs “Enter the address of the Controller……..” et en cliquant sur le bouton Connect, Studio s’ouvre mais tourne dans la vide. Côté event (sur le Controller) nous avons une belle erreur 1007 dans le journal “Application”.

 

 

Log Name: Application
Source: Citrix Configuration Service
Date: 20/11/2017 15:50:43
Event ID: 1007
Task Category: None
Level: Error
Keywords:
User: NETWORK SERVICE
Computer
Description:
Otherwise unhandled exception in WCF call : System.ServiceModel.FaultException: Failed to retrieve site record. Error: InvalidSignature
at Citrix.Configuration.Logic.ConfigurationLogic.GetEnabledFeatures()
at Citrix.Fma.Sdk.ServiceCore.ServiceCore.CheckedCall[T](String name, Func`1 operation, Func`2 defaultValue, Enum code)

 

Rapidement on s’aperçoit que cette erreur relève du bug, en effet après voir migrer le deuxième Controller en 7.15 LTSR nous n’avons plus rencontré d’erreur.