Warum sehe ich diese Fehler in meinem SSRS Powershell-Skript in einer Umgebung, aber nicht in einer anderen Umgebung?

Question

Ich habe ein Powershell-Skript, an dem ich für SSRS-Berichtsverwaltungsaufgaben nach der Migration arbeite.

In diesem speziellen Szenario haben wir eine DEV-Umgebung (wo ich hauptsächlich getestet habe), die eine einzelne Instanz von SSRS hostet, und eine Prod-Umgebung, die eine skalierte Implementierung über 4 Knoten ist.

ich Powershell neu bin (entdeckte es nur 2 Tagen ...) und das Skript, das ich habe, ist ziemlich einfach:

Clear-Host  

$Username = "domain\myUsername" 
$Password = "myPassword" 

$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList @($Username,(ConvertTo-SecureString -String $Password -AsPlainText -Force)) 

# Dev Connection String 
$webServiceUrl = 'http://DEVwebServer.domain.com/reportserver/reportservice2010.asmx?WSDL' 

# Prod Connection String 
# $webServiceUrl = 'http://PRODwebServerNode1.domain.com/reportserver/reportservice2010.asmx?WSDL' 

$rs = New-WebServiceProxy -Uri $webServiceUrl -Credential $Cred 
  
$reports = $rs.ListChildren("/Some Folder Under Root", $true) | Where-Object { $_.TypeName -eq "Report" } 

$type = $ssrsProxy.GetType().Namespace; 
$schedDefType = "{0}.ScheduleDefinition" -f $type; 
$schedDef = New-Object ($schedDefType) 

$warning = @(); 

foreach ($report in $reports) { 

    $sched = $rs.GetExecutionOptions($report.Path, [ref]$schedDef); 
    $snapShotExists = $rs.ListItemHistory($report.Path); 


    if($sched -eq "Snapshot") { 
     Write-Host "Following report is configured to run from Snapshot:" -ForegroundColor Yellow 
     Write-Host ("Report Name: {0}`nReport Path: {1}`nExecution Type: {2}`n" -f $report.Name, $report.Path, $sched) 

     if ($snapShotExists) { 
      Write-Host "Does Snapshot Exist..?`n" -ForegroundColor Yellow 
      Write-Host "Yes!`tNumber of Snapshots: " $snapShotExists.Count -ForegroundColor Green 
      $snapShotExists.CreationDate 
      Write-Host "`n------------------------------------------------------------" 
     } 
     elseif (!$snapShotExists) { 
      Write-Host "Does Snapshot Exist..?`n" -ForegroundColor Yellow 
      Write-Host ("No!`n") -ForegroundColor Red 
      Write-Host "Creating Snapshot.......`n" -ForegroundColor Yellow 
      $rs.CreateItemHistorySnapshot($report.Path, [ref]$warning); 
      Write-Host "Snapshot Created!`n" -ForegroundColor Green 
      $snapShotExists.CreationDate 
      Write-Host "`n------------------------------------------------------------" 
     } 
    } 
} 

Der Zweck des Skripts einfach ist, alle rekursiv iterieren Überprüfen Sie in den Berichten für den angegebenen Ordner in der Variablen $ reports, ob der Ausführungstyp auf "Snapshot" festgelegt ist, ob überprüft wird, ob ein "History-Snapshot" vorhanden ist, und falls noch keiner vorhanden ist, erstellen Sie einen.

Wenn ich dies in Dev laufe funktioniert es ganz gut, aber wenn ich in ART laufen bekomme ich folgende Fehler für jeden $ Bericht in meiner foreach-Schleife wiederholt:

Alle Ideen, warum dieser würde in einer und nicht in der anderen arbeiten und wie kann man diesen Fehler überwinden?

Answer 1

konnte ich diese Arbeit auf die Prod Instanz erhalten, indem sie einige Anpassungen mit this answer als Leitfaden: mein Aufruf an New-Webservice

Durch Aktualisieren einer Klasse und Namespace-Flag hinzuzufügen, ich aktualisieren konnte das Skript auf folgende Weise:

... 
# Add Class and Namespace flags to New-WebServiceProxy call 
$rs = New-WebServiceProxy -Class 'RS' -Namespace 'RS' -Uri $webServiceUrl -Credential $Cred 
  
$reports = $rs.ListChildren("/Business and Technology Solutions", $true) | Where-Object { $_.TypeName -eq "Report" } 

# Declare new "ScheduleDefintion object using the Class declared in the New-WebServiceProxy call 
$schedDef = New-Object RS.ScheduleDefinition 
$warning = @(); 

foreach ($report in $reports) { 

    # Referencing the "Item" property from the ScheduleDefinition 
    $execType = $rs.GetExecutionOptions($report.Path, [ref]$schedDef.Item) 

... 

ich glaube nicht das Hinzufügen der Klasse und Namespace-Flaggen auf dem New-Webservice Anruf war genau das, was es tat, wie ich glaube, es ist nur ein sauberer Weg, um sicherzustellen, Erhalte den richtigen Namespace vom WebService. Vielleicht nur ein bisschen Zucker.

ich glaube, der Schlüssel Änderung der „Item“ Eigenschaft aus der Zeitplandefinition Objekt wurde sicherstellen, dass, obwohl ich nicht sicher bin, warum es so, ohne dabei ...