Revert to Parent Security en PowerShell

Bon un petit tip aujourd’hui: je n’ai rien trouvé de tel sur Stack ou autre. Le case study est un serveur SSRS dont toute les sécurités ont été cassées par des Content Manager peu scrupuleux. Comment réparer ce désastre sans avoir à vérifier tous les rapports? La solution: PowerShell et 3 méthodes du WebService de SSRS (ReportServer2010.asmx):

  • ListChildren(path) pour parcourir les descendants
  • GetPolicy(path, out inheritsParentSecurity) qui va donner les policies et surtout un booléen qui renseigne si l’élément adopte la sécurité de son parent ou pas
  • InheritParentSecurity(path) qui va restaurer la sécurité parente sur l’élément

Un bête parcours d’arbre dans une fonction récursive résoud rapidement le problème

Function RevertToParentSecurity ([string]$Path)
{
    $InheritParent = $true
    $CurrentPolicies = $Proxy.GetPolicies("$Path", [ref] $InheritParent)

    #If the current Path is not the root and it has custom policies applied, reset them
    if ( ( ! $InheritParent ) -and ( $Path -ne "/" ) )
    {
        Write-Host $Path -foregroundcolor "red"
        $Proxy.InheritParentSecurity($Path)
    }
    else
    {
        Write-Host $Path -foregroundcolor "green"
    }

    #If the current is a folder, recursive call on its children
    $ItemType = $Proxy.GetItemType("$Path")
    if ( $ItemType -eq "Folder" )
    {
        $Proxy.ListChildren("$Path", $false) | ForEach-Object {
            RevertToParentSecurity $_.path
        }
    }
}

Il suffit alors de l’appeler.
 

$WebServiceVersion = "2005"
$ReportServerUri = "http://localhost/ReportServer/ReportService$WebServiceVersion.asmx"
$Proxy = New-WebServiceProxy -Uri $ReportServerUri -Namespace SSRS.ReportingService$WebServiceVersion -UseDefaultCredential;
Write-Host Connected to $Proxy.Url
RevertToParentSecurity "/"

Voilà, si ça peut servir à d’autres et de vous éviter la prise de tête que ça m’a occasionné 🙂
Bonne soirée!

Publicités

[SSIS] Utiliser PowerShell pour remplacer DtUtil et le manifeste

Ceux qui lisent ce blog – merci à eux! – le savent, je ne supporte pas le manifeste de déploiement et utilise plutôt l’utilitaire DtUtil pour déployer mes packages.
Il arrive malheureusement que l’on me rétorque que le manifeste de déploiement dispose de nombreux avantages par rapport à mon utilitaire préféré.
…pour être honnête en réalité il n’en a que deux.

1) Il est plutôt joli
2) Il permet de modifier l’emplacement de la configuration dans le package

Si l’on omet le point numéro 1 (la cosmétique étant par nature subjective) on se dit que la seule chose sympatique que permet ce manifeste c’est d’éditer le lot pour changer sa node « Configuration ».

Quels seraient donc les specs de l’utilitaire « idéal »?

Il serait automatisable – ce qu’est DtUtil mais pas le manifeste – et pourrait déployer des configurations tout en modifiant leur chemin – ce que ne sait pas faire DtUtil. Il s’agirait donc d’un DtUtil capable de modifier un dtsx.

DtUtil et le manifeste supplantés par PowerShell!

L’API .NET SSIS et son objet Application permettent d’ouvrir un lot, de le modifier et de le déployer ou que ce soit (DTS, SQL, File), ils constituent donc une solution stable (pas d’édition de XML très sale) et… scriptable donc automatisable, grâce à PowerShell!

Un petit exemple

En trois temps:

1) On modifie le package

$app = new-object Microsoft.SqlServer.Dts.Runtime.Application
$pkg = $app.LoadPackage($oldPackagePath,$null)
$oldConfigPath = $pkg.Configurations[0].ConfigurationString
$pkg.Configurations[0].ConfigurationString = $newConfigPath

2)On déploie la configuration à sa destination

Copy-Item $oldConfigPath $newConfigPath

3) On déploie le package à sa destination (en fichier ici mais cela aurait pu être SQL)

$app.SaveToXml($newPackagePath,$pkg,$null)

Et voilà!

[SSAS] AMO et Powershell

Pour répondre à la question suivante « Comment scripter ce traitement qui se fait très bien sur ma base AS avec Management Studio? » vous pensez immédiatement que la réponse sera de se coltiner du XMLA exécuté avec ASCmd. Mais il y a une alternative plus sympa: pourquoi ne pas utiliser AMO avec…. PowerShell! Pour, par exemple, copier-coller une base AS – question à laquelle j’ai répondu il y a quelques minutes, j’ai mis au moins 2 minutes à écrire ce script mo-nu-men-tal:

$srv=New-Object Microsoft.AnalysisServices.Server
$srv.connect(« .\SQL2008R2 »)
$olddb=$srv.Databases.FindByName(« Adventure Works DW 2008 »)
$newdb=$olddb.Clone()
$newdb.Name= »Copie AW »
$newdb.ID= »Copie AW »
$srv.Databases.Add($newdb)
$newdb.Update([Microsoft.AnalysisServices.UpdateOptions]::ExpandFull)

Globalement n’importe quel code AMO en C# ou VB peut être traduit en PowerShell, et s’y j’y arrive vous pouvez le faire :). On peut y penser pour des procédures de déploiement par exemple, mais vous pouvez imaginer tout un tas de scenarii d’usage pour remplacer du XMLA amoureusement tapé à la main. Powershell et AMO c’est bon,mangez en.