PI Services

Le blog des collaborateurs de PI Services

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.

 

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. 

 

PowerShell - Sauvagardé de manière sécurisée des identifiants.po

 

Pour des scripts ayant besoin d'exécutés des cmdlet ayant besoin d'identifiant (la connexion à office 365 par exemple) de manière planifier il faut pouvoir sauvegardé ces identifiants de manière sécurisée.

Voici comment faire :

Dans un premier temps il faut générer un fichier sécurisé contenant les identifiants

 

$Cred = Get-Credential "$env:USERNAME@$env:USERDNSDOMAIN"
Export-Clixml -Path $env:USERPROFILE\Documents\Cred.xml -InputObject $Cred

Le fichier Cred.xml n'est fonctionnel que sur l'ordinateur sur lequel il a été généré.

Dans un second temps, on va l'importer.

$Cred = Import-Clixml -Path $env:USERPROFILE\Documents\Cred.xml

 

Par example : voici comment faire une connexion à Exchange online

$Cred = Import-Clixml $env:USERPROFILE\Documents\Cred.xml
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession $Session

 

SCOM – SQL – Requete des Unreachable Computer pour un groupe specifique

La requete sql suivante affiche les evenement de type Unreachable Computer pour les machines membres d’un groupe spécifique, pour une période donnée, avec les infos de cause et de User associés.

 

/**** Unreachable Computer Event from Specific Group  ****/   Use OperationsManagerDW   DECLARE @startdate     datetime DECLARE @enddate      datetime DECLARE @computergroup1     VARCHAR(50)   SET @startdate = '2017-01-01 00:00:00' SET @enddate = '2017-01-31 00:00:00' SET @computergroup1 = 'My_Group'     SELECT apv.ParameterValue as SystemName ,(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) as DownDateTime, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),arsv.StateSetDateTime)) as RestoredDateTime, adv.CustomField2 as OutageType, adv.CustomField3 as RootCause, adv.CustomField4 as Reason, adv.DBLastModifiedByUserId as UserID FROM Alert.vAlert av JOIN Alert.vAlertDetail adv on av.AlertGuid = adv.AlertGuid JOIN Alert.vAlertResolutionState arsv on av.AlertGuid = arsv.AlertGuid JOIN Alert.vAlertParameter apv on av.AlertGuid = apv.AlertGuid WHERE AlertName = 'Failed to Connect to Computer' AND arsv.ResolutionState = '255' --AND adv.CustomField2 IS NOT NULL AND (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.RaisedDateTime)) between @startdate and @enddate AND apv.ParameterValue IN ( SELECT vManagedEntity.DisplayName FROM  vManagedEntity INNER JOIN vRelationship ON vManagedEntity.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId INNER JOIN vManagedEntity AS ManagedEntity_1 ON vRelationship.SourceManagedEntityRowId = ManagedEntity_1.ManagedEntityRowId WHERE (ManagedEntity_1.DisplayName = @computergroup1) )   UNION ALL   SELECT vme.displayname, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.StartDateTime)) as DownDateTime, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.EndDateTime)) as RestoredDateTime, 'OutageType' = CASE   vmm.PlannedMaintenanceInd   WHEN '1' THEN 'Scheduled'   WHEN '0' THEN 'Unscheduled' END, 'RootCause' = CASE   vmmh.ReasonCode   WHEN '0' THEN 'Other (Planned)'   WHEN '1' THEN 'Other (Unplanned)'   WHEN '2' THEN 'Hardware: Maintenance (Planned)'   WHEN '3' THEN 'Hardware: Maintenance (Unplanned)'   WHEN '4' THEN 'Hardware: Installation (Planned)'   WHEN '5' THEN 'Hardware: Installation (Unplanned)'   WHEN '6' THEN 'Operating System: Reconfiguration (Planned)'   WHEN '7' THEN 'Operating System: Reconfiguration (Unplanned)'   WHEN '8' THEN 'Application: Maintenance (Planned)'   WHEN '9' THEN 'Application: Maintenance (Unplanned)'   WHEN '10' THEN 'Application: Installation (Planned)'   WHEN '11' THEN 'Application: Unresponsive'   WHEN '12' THEN 'Application:  Unstable'   WHEN '13' THEN 'Security Issue'   WHEN '14' THEN 'Loss of network connectivity (Unplanned)' END, vmmh.Comment as Reason, vmmh.userid as UserID FROM vMaintenanceMode vmm JOIN vManagedEntity vme on vmm.managedentityrowid = vme.managedentityrowid JOIN vMaintenanceModeHistory vmmh on vmm.maintenancemoderowid = vmmh.maintenancemoderowid WHERE vme.FullName LIKE '%HealthServiceWatcher%' AND (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),vmm.StartDateTime)) between @startdate and @enddate AND vme.displayname IN ( SELECT vManagedEntity.DisplayName FROM  vManagedEntity INNER JOIN vRelationship ON vManagedEntity.ManagedEntityRowId = vRelationship.TargetManagedEntityRowId INNER JOIN vManagedEntity AS ManagedEntity_1 ON vRelationship.SourceManagedEntityRowId = ManagedEntity_1.ManagedEntityRowId WHERE (ManagedEntity_1.DisplayName = @computergroup1) ) ORDER BY DownDateTime DESC

SCOM – SQL – Requete d’info etendue sur les agents Scom

La requete suivante affiche des infos etendues sur les agents Scom, avec le détails des Primary et Failover Servers.

 

/****** Scom Agent Extended Infos ******/   Use OperationsManager   WITH PrimaryRelation (SourceEntityId,agent,PrimaryServer,TargetEntityId) AS ( SELECT R.SourceEntityID,SourceBME.DisplayName as Agent,TargetBME.DisplayName as PrimaryServer, R.TargetEntityID FROM Relationship R WITH (NOLOCK) JOIN BaseManagedEntity SourceBME ON R.SourceEntityID = SourceBME.BaseManagedEntityID JOIN BaseManagedEntity TargetBME ON R.TargetEntityID = TargetBME.BaseManagedEntityID WHERE R.RelationshipTypeId = dbo.fn_ManagedTypeId_MicrosoftSystemCenterHealthServiceCommunication() ) , FailoverRelation (SourceEntityId,agent,FailoverServer,TargetEntityId) AS ( SELECT R.SourceEntityID,SourceBME.DisplayName as Agent,TargetBME.DisplayName as FailoverServer, R.TargetEntityID FROM Relationship R WITH (NOLOCK) JOIN BaseManagedEntity SourceBME ON R.SourceEntityID = SourceBME.BaseManagedEntityID JOIN BaseManagedEntity TargetBME ON R.TargetEntityID = TargetBME.BaseManagedEntityID WHERE R.RelationshipTypeId = dbo.fn_ManagedTypeId_MicrosoftSystemCenterHealthServiceSecondaryCommunication() )     SELECT                    MTV_HS.[DisplayName]                   ,PrimaryRelation.PrimaryServer                   ,FailoverServer                   ,Failover_State = CASE                                WHEN FailoverRelation.FailoverServer IS NULL THEN 'NO FAILOVER'                                ELSE FailoverRelation.FailoverServer                                END                   ,[Port]       ,[InstallTime]       ,[MaximumQueueSize]       ,Patch = CASE                     WHEN [PatchList] like '%UR4%' THEN 'RU4'                                WHEN [PatchList] like '%UR8%' THEN 'RU8'                                WHEN [PatchList] like '%UR11%' THEN 'RU11'                                WHEN [PatchList] = '' THEN '[NO_DATA]'                                END       ,[IsManuallyInstalled]       ,[Version]       ,[ActionAccountIdentity]       ,[ProxyingEnabled]       ,[HeartbeatInterval]       ,[NumberOfMissingHeartBeatsToMarkMachineDown_27AD2E30_EFE0_1A73_8C9D_F0A22B073227] as NumberOfMissingHeartBeatsToMarkMachineDown                   ,MTV_OS.DisplayName as OS                   ,MTV_OS.CSDVersion_AFE62B62_74FC_2F06_D8A0_DEE31F14CD33 as ServicePack                   ,MTV_OS.LogicalProcessors_5CAE4847_F75B_01D0_156E_1658D557B739 as Logic_CPU                         FROM [OperationsManager].[dbo].[MTV_HealthService] as MTV_HS   INNER JOIN  [dbo].[MTV_Microsoft$Windows$OperatingSystem] as MTV_OS on MTV_HS.DisplayName = MTV_OS.PrincipalName     INNER JOIN PrimaryRelation on PrimaryRelation.SourceEntityId = MTV_HS.BaseManagedEntityId   LEFT OUTER JOIN FailoverRelation on FailoverRelation.SourceEntityId = MTV_HS.BaseManagedEntityId       WHERE IsAgent = '1'