Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

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