Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Création d’une web app linux php dans AZURE depuis le portail azure

Pour réaliser ce tutoriel, il vous faudrait un compte actif dans Azure. Connectez-vous sur le portail Azure https://portal.azure.com . 

1. Création d’un plan de service d’application (plan app service). Ce plan de service devrait être sous Linux. Ajouter un nom du service plan, créer un nouveau groupe de resource, et mettre Linux pour le Système d’exploitation.

Le plan de service d’application a été créé avec succès comme indique ci-dessous:

2. Sélectionner « web app » et tapper web app puis sélectionner « web app » et cliquer sur le bouton créer.

Entrer un nom pour cette application web, sélectionner Linux pour l’OS.

NB: vous pouvez configurer le conteneur, dans l’exemple ci-dessous php est utilisé.

La web app a été créé avec succès comme indiqué :

Pour déployer une site depuis github, selectionner la web app puis ‘option de déploiment »

 

Ajouter une source de déploiement, dans ce tutoriel , nous allons utiliser github. Ajouter votre compte github puis sélectionner votre projet. 

Une fois la configuration terminée, Cliquer sur OK.

Retourner dans option de déploiement, puis cliquer sur synchronisation. 

Le projet github est désormais synchro avec la web app azure: 

 

 

 

 

SCOM – Requête SQL des Heartbeat Failure par Primary Management Server

 

La requête ci-dessous permet de lister depuis la base OperationsManager, avec un paramètre J-n, les alertes Heartbeat Failure des agents, par Primary Server, en affichant la durée de l’alerte, son eventuel ticket associé, son status et le status du maintenance mode de l’objet.

 

 

/****** HEARTBEAT FAILURE FOR AGENTS PRIMARY MANAGED BY SPECIFIC MS WITH DURATION, STATUS AND OBJECT MAINTENANCE MODE STATUS ******/

Use OperationsManager

DECLARE @PrimaryServer	VARCHAR(50)
DECLARE @startdate	datetime
DECLARE @Offset	int
DECLARE @enddate	datetime
DECLARE @seconds int
DECLARE @AlertPattern VARCHAR(50)
DECLARE @TicketPattern VARCHAR(50)

SET @PrimaryServer = 'MyPrimaryMS' – Provide a name of Primary if you need to filter on.
SET @enddate = GETDATE()
SET @Offset = 4 – Provide number of days to look back (limited to operational db retention
SET @startdate = DATEADD(day,-@Offset,@enddate)
SET @AlertPattern = 'heartbeat'
SET @TicketPattern = 'Ticket_Number'	-- Provide string pattern that must be found in each ticket


;

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() 
AND TargetBME.IsDeleted <> '1'  -- AND THE PRIMARY SERVER IS NOT WAITING TO BE DELETED
AND SourceBME.IsDeleted <> '1' -- AND THE AGENT IS NOT WAITING TO BE DELETED
)


-- Get alert

SELECT
PrimaryServer 
,AlertStringName
,MonitoringObjectDisplayName AS Computer
,(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)) as DownDateTime
,(DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)) as RestoredDateTime

,Duration = (
	SELECT CONVERT(varchar, (DateDiff (s, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)), (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)))) / 86400 ) + ' days ' + 
	CONVERT(varchar, (DateDiff (s, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)), (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)))) % 86400 / 3600) + ' hours ' +
	CONVERT(varchar, (DateDiff (s, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)), (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)))) % 86400 % 3600 / 60) + ' min ' +
	CONVERT(varchar, (DateDiff (s, (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)), (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeResolved)))) % 86400 % 3600 % 60 % 60) + ' sec ' 
	
	)

,TicketID = CASE
	WHEN TicketID is null THEN 'NO_TICKET'
	WHEN TicketId not like '%'+@TicketPattern+'%' THEN 'NO_TICKET'
	ELSE TicketID
	END
,Alert_ResolutionState = CASE
	WHEN AV.ResolutionState = '255' THEN 'Closed'
	WHEN AV.ResolutionState = '254' THEN 'Resolved'
	WHEN AV.ResolutionState = '251' THEN 'Blackout'
	WHEN AV.ResolutionState = '250' THEN 'Scheduled'
	WHEN AV.ResolutionState = '249' THEN 'Acknowledge'
	WHEN AV.ResolutionState = '248' THEN 'Assigned to Engineering'
	WHEN AV.ResolutionState = '247' THEN 'Awaiting Evidence'
	WHEN AV.ResolutionState = '3' THEN 'Notified'
	WHEN AV.ResolutionState = '0' THEN 'New'
	END
,'Object_was_InMM' = CASE
	WHEN av.MonitoringObjectInMaintenanceMode = '0' THEN 'NO'
	WHEN av.MonitoringObjectInMaintenanceMode = '1' THEN 'YES'
	END
FROM [dbo].[AlertView] av
INNER JOIN [OperationsManager].[dbo].[MTV_HealthService] as MTV_HS on MTV_HS.DisplayName = MonitoringObjectDisplayName
INNER JOIN PrimaryRelation on PrimaryRelation.SourceEntityId = MTV_HS.BaseManagedEntityId
WHERE name like '%'+@AlertPattern+'%'
AND (DATEADD(hh,DATEDIFF(hh,getutcdate(),getdate()),av.TimeRaised)) between DATEADD(day,-@Offset,@enddate) and @enddate
--AND PrimaryServer like '%'+@PrimaryServer+'%' -- Uncomment to see agents managed from specific primary server

Quest RUM : Bien préparer ses machines avant une migration

Bonjour à tous !

Comme vu dans le billet précédent, la plupart des erreurs rencontrées sur RUM proviennent plus de votre infrastructure (IP manquantes/non à jour dans les zones DNS, découverte réseau Windows désactivée, …) que de RUM en lui même.

Afin de minimiser ces erreurs, sur les postes concernés par la migration, il convient de mettre en place un certain nombre de pré-requis que nous allons détailler ci-dessous.

Les pré-requis

Droits d’accès administratifs sur les postes de travail

Le serveur RUM utilise deux comptes de services distincts :

  • Le compte de service du service RUM Controller
    • Il correspond au compte renseigné lors de l’installation du logiciel RUM
    • Il peut être configuré depuis la console RUM en allant dans le menu Tools -> Manage Controller Credentials

  • Le compte de service du service Dell Migration Manager RUM Agent Service
    • Il correspond au compte utilisé par l’agent RUM quand il est installé sur un poste
    • ll peut être configuré depuis la console RUM en allant dans le menu Project -> Manage Domains Credentials

Le compte de service du service Controller RUM doit faire partie du groupe local Administrateurs du serveur RUM.

Le compte de service du service Dell Migration Manager RUM Agent Service doit faire partie du groupe local Administrateurs sur tous les postes devant être migrés.

Le firewall Windows/d’Entreprise

Pour la liste complète des ports, je vous renvoie à ce lien : What firewall ports need to be opened for Migration Manager for AD / Resource Updating

Pour la partie qui nous intéresse, à savoir le poste à migrer, il faut bien entendu une connectivité à minima vers les serveurs Active Directory des domaines sources et cibles.

La liste des ports à ouvrir entre un poste client et un serveur RUM est quelque peu longue, la faute au RPC Dynamique.

Vous devrez donc ouvrir de manière bi-directionnelle, entre un poste et un serveur RUM, les ports suivants :

  • 135-139
  • 445
  • 1024-65535

La résolution de noms d’hôtes

Le poste doit être capable de résoudre les noms d’hôtes pour les domaines sources et cibles donc il faut penser à ajouter des redirecteurs conditionnels sur les serveurs DNS utilisés par vos postes clients.
Une fois les redirecteurs mis en place, la résolution de nom FQDN est assurée sur les postes ciblés.

Mais RUM utilisant également des noms d’hôtes courts, le poste doit être capable de les résoudre aussi.

Pour cela, il faut configurer sur les postes ciblés le paramètre de Liste de recherche de suffixes DNS comme ceci :

  • Nom de domaine du domaine AD source
  • Nom de domaine du domaine AD cible

Astuce : Ce paramètre peut aussi être mis en oeuvre sur votre serveur RUM si vous voulez travailler avec des noms d’hôtes courts (non FQDN).

Les services Windows

Sur les postes à migrer, les services Windows suivants doivent être démarrés et configurés en mode Démarrage automatique :

  • Server
  • Workstation
  • Netlogon
  • Remote Procedure Call
  • Remote Procedure Call Locator
  • Remote Registry
  • Function Discovery Provider Host
  • SSDP Discovery
  • UPnP Device Host

Mise en place des pré-requis

Deux méthodes peuvent être utilisées afin de mettre en place les pré-requis décrits précédemment :

  • Par GPO
  • Par script

Par GPO

Voici un exemple de GPO pouvant être déployée sur les postes du domaine source :

Par Script

Voici un exemple de script pouvant être utilisé sur les postes du domaine source :

A savoir : La commande net localgroup ne supporte pas l’ajout d’un groupe étant composé de plus de 20 caractères (NET.EXE /ADD command does not support names longer than 20 characters)

REM Set startup type for services
sc config RpcSs start= auto
sc config SSDPSRV start= auto
sc config upnphost start= auto
sc config fdPHost start= auto
sc config RpcLocator start= auto
sc config Netlogon start= auto
sc config RemoteRegistry start= auto
sc config LanmanServer start= auto
sc config LanmanWorkstation start= auto

REM Start services
net start RpcSs
net start SSDPSRV
net start upnphost
net start fdPHost
net start RpcLocator
net start Netlogon
net start RemoteRegistry
net start LanmanServer
net start LanmanWorkstation

REM Disable Firewall on Domain profile
netsh advfirewall set DomainProfile state off

REM Add group to local Administrators group
net localgroup Administrateurs XXX\CORP-QUEST-ADMIN /ADD

REM Set DNS Suffix Search list
REG ADD HKLM\System\CurrentControlSet\Services\TCPIP\Parameters /v SearchList /t REG_SZ /f /d "domaine_source_fqdn,domaine_cible_fqdn"