Zum Inhalt wechseln


Foto

PS: MS Updates Reportin -> Invoke-Command


  • Bitte melde dich an um zu Antworten
10 Antworten in diesem Thema

#1 Kuddel071089

Kuddel071089

    Senior Member

  • 325 Beiträge

 

Geschrieben 19. Juni 2017 - 09:57

Hallo zusammen,

 

ich bin gerade dabei mir einen Update-Report aller unserer WIndows Server zusammenzubauen.

 

Die Spalten sollen am Ende wir folgt ausgefüllt werden:

Servername;Datum der letzten Installation;Neustart nötig;Betriebssystem

 

Für die Update-Infos verwende ich das PS-Modul "PSWIndowsUpdate".

Da diese ja noch nciht auf jedem Server ist, muss ich es vorher noch verteilen und importieren. Das funktioniert auch.

 

Leider bekomme ich die Infos aus der Remote-Abfrage nicht weiterverarbeitet.

 

BIs jetzt habe ich folgendes

cls



$servers = @("test-server2")



foreach($server in $servers) {

#Check ob das Modul auf dem Server installiert ist. Ansonsten wird es kopiert

IF(!(Test-Path "\\$server\C$\Windows\System32\WindowsPowerShell\v1.0\Modules\PSWindowsUpdate\*")) {copy-item "\\testserver1\D$\PSWindowsUpdate" -Recurse "\\$server\C$\Windows\System32\WindowsPowerShell\v1.0\Modules"}


Invoke-Command -ComputerName $server -ScriptBlock {Import-Module PSWindowsUpdate}

Invoke-Command -ComputerName $server -ScriptBlock {$wuabfrage = Get-WUHistory | Select-Object -first 1}

#Check, ob ein Reboot nötig ist

Invoke-Command -ComputerName $server -ScriptBlock {$reboot = Get-WURebootStatus}

#Entfernung von "localhos: " aus der Varaible

$reboot = $reboot -replace "localhost: ", ""



#Abfrage des Betriebssystems

$serverinfos = Get-ADComputer $server -Properties * | Select operatingsystem



#Output

"$($wuabfrage.ComputerName);$($wuabfrage.Date);$reboot;$($serverinfos.operatingsystem))"

}

Ich hoffe ihr könnt mir weiter helfen.

 

Vielen Dank schon einmal


Bearbeitet von Kuddel071089, 19. Juni 2017 - 09:58.


#2 Dukel

Dukel

    Board Veteran

  • 9.300 Beiträge

 

Geschrieben 19. Juni 2017 - 10:04

Du musst die Daten in der Remote Abfrage zurückgeben und im Lokalen Script speichern.

 

https://msdn.microso...ut/about_remote


Stop making stupid people famous.


#3 Kuddel071089

Kuddel071089

    Senior Member

  • 325 Beiträge

 

Geschrieben 19. Juni 2017 - 11:11

Danke für den Tip. Habe es jetzt umgestellt.

cls

$servers = @("testserver2")



foreach($server in $servers) {
#Check ob das Modul auf dem Server installiert ist. Ansonsten wird es kopiert
IF(!(Test-Path "\\$server\C$\Windows\System32\WindowsPowerShell\v1.0\Modules\PSWindowsUpdate\*")) {copy-item "\\testserver1\D$\PSWindowsUpdate" -Recurse "\\$server\C$\Windows\System32\WindowsPowerShell\v1.0\Modules"}


Invoke-Command -ComputerName $server -ScriptBlock {Import-Module PSWindowsUpdate}
 
#Invoke-Command -ComputerName $server -ScriptBlock {$wuabfrage = Get-WUHistory | Select-Object -first 1}
$wuabfrage = Invoke-Command -ComputerName $server -ScriptBlock {Get-WUHistory | Select-Object -first 1}


#Check, ob ein Reboot nötig ist
$reboot = Invoke-Command -ComputerName $server -ScriptBlock {Get-WURebootStatus}
#Entfernung von "localhost: " aus der Varaible
$reboot = $reboot -replace "localhost: ", ""

#Abfrage des Betriebssystems
$serverinfos = Get-ADComputer $server -Properties * | Select operatingsystem

#Output
"|$($wuabfrage.ComputerName)|$($wuabfrage.Date)|$reboot|$($serverinfos.operatingsystem))|"
}

Leider bekomme ich jetzt beim Befehl "Get-WURebootStatus" einen Fehler

Eine Instanz der COM-Komponente mit der CLSID {C01B9BA0-BEA7-41BA-B604-D0A36F469133} konnte aufgrund des folgenden Fehlers nicht von der IClassFactory erstellt werden:
80070005 Zugriff verweigert (Ausnahme von HRESULT: 0x80070005 (E_ACCESSDENIED)).
    + CategoryInfo          : NotSpecified: ( :) [New-Object], UnauthorizedAccessException
    + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.NewObjectCommand
    + PSComputerName        : testserver2

Bearbeitet von Kuddel071089, 19. Juni 2017 - 11:13.


#4 Dukel

Dukel

    Board Veteran

  • 9.300 Beiträge

 

Geschrieben 19. Juni 2017 - 12:26

Bestimmte Sachen gehen mit PSWindowsUpdate nicht remote. Hierfür gibt es Invoke-WUInstall (oder so ähnlich), mit dem man ein Script remote ausführen kann (per Task Scheuler), das Ergebnis z.B. in eine Datei schreiben und später abholen kann.


Stop making stupid people famous.


#5 MurdocX

MurdocX

    Board Veteran

  • 584 Beiträge

 

Geschrieben 19. Juni 2017 - 18:06

Als kleinen Tipp: Nutze "-AsJob" und frage die Daten dann wieder ab. Des Weiteren kannst du alle Abfragen in ein Invoke-Command packen, um viel Zeit zu sparen  ;)


Mit freundlicher Unterstützung
Jan


#6 Kuddel071089

Kuddel071089

    Senior Member

  • 325 Beiträge

 

Geschrieben 17. Juli 2017 - 09:29

Ich habe die Abfrage jetzt übrigens hinbekommen.

 

Für alle AD Server bekomme ich alle Infos super ausgelesen.

 

Leider haben wir auch noch Server, die nicht Mitlgied in der AD sind (historisch bedingt / Novell eDir bis 2014).

 

Wie kann ich jetzt von diesen Server die Infos abfragen ?

 

Gestartet wird das Skript auf einem AD-Mitgliedsserver mit deinem AD-Admin-Account.

 

Ich müsste also bei den anderen Servern den lokalen Administrator verwenden (hat bei allen Servern das gleiche PW).

 

Leider stehe ich gerade voll auf dem Schlauch



#7 MurdocX

MurdocX

    Board Veteran

  • 584 Beiträge

 

Geschrieben 17. Juli 2017 - 09:48

Probiers mal mit dem Parameter "-Credential"  ;)


PS: Du darfst dich auch gerne in die CmdLets einlesen. Microsoft stellt für jedes CmdLet eine Dokumentation mit Parameter detailliert online.


Mit freundlicher Unterstützung
Jan


#8 Kuddel071089

Kuddel071089

    Senior Member

  • 325 Beiträge

 

Geschrieben 18. Juli 2017 - 10:04

Probiers mal mit dem Parameter "-Credential"  ;)


PS: Du darfst dich auch gerne in die CmdLets einlesen. Microsoft stellt für jedes CmdLet eine Dokumentation mit Parameter detailliert online.

 

Leider gibts es bei den Commandlets "Get-WUHistory" und "Get-WURebootstatus" keinen Parameter Crendential.

 

Wenn ich es per Invoke-Command machen, funktionieren meine Crendetials nicht mehr.

 

Das OS konnte ich Remote abfragen

$servers = @("Server1","Server2")



foreach($server in $servers) {
#Admin-Credentials
$adminuser = "$server\Administrator"
$password = "xxxxxxxxx"
$secstr = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $adminuser, $secstr
 
$os = Get-WmiObject -class Win32_OperatingSystem -computername $server -Credential $server\$user $pw
$os = "$($property.Caption)"


#9 tesso

tesso

    Board Veteran

  • 2.252 Beiträge

 

Geschrieben 18. Juli 2017 - 20:51

Wenn ich es richtig sehe sind "Get-WUHistory" und "Get-WURebootstatus" keine CmdLets, sondern einfache Skripte.

 

Wie sieht der Aufruf via Invoke-Command aus? Und wie die Fehlermeldung?


Bearbeitet von tesso, 18. Juli 2017 - 20:51.


#10 Kuddel071089

Kuddel071089

    Senior Member

  • 325 Beiträge

 

Geschrieben 02. August 2017 - 09:23



Wenn ich es richtig sehe sind "Get-WUHistory" und "Get-WURebootstatus" keine CmdLets, sondern einfache Skripte.

 

Wie sieht der Aufruf via Invoke-Command aus? Und wie die Fehlermeldung?

 

Ich scheitere leider schon an der Remote-Anmeldung.

 

Zum test wollte ich den Befehl "Get-Host" remote ausführen.

 

Sprich:

Invoke-Command -ComputerName Test-Server -ScriptBlock {get-host} -Credential Administrator

Im Credential Popup versuche ich es dann mit:

User: Test-Server\Administrator
PW: xxxxx

Fehlermeldung:

[Test-Server] Beim Verbinden mit dem Remoteserver "Test-Server" ist folgender Fehler aufgetreten: Die Anforderung kann von WinRM nicht verarbeitet werden. Bei Verwendung der

Kerberos-Authentifizierung ist der folgende Fehler mit Fehlercode 0x80090311  aufgetreten: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung

verfügbar.  

. Mögliche Ursachen:

  - Der angegebene Benutzername oder das angegebene Kennwort ist ungültig.

  - Kerberos wird verwendet, wenn keine Authentifizierungsmethode und kein Benutzername angegeben werden.

  - Kerberos akzeptiert Domänenbenutzernamen, aber keine lokale Benutzernamen.

  - Der Dienstprinzipalname (Service Principal Name, SPN) für den Remotecomputernamen und -port ist nicht vorhanden.

  - Der Clientcomputer und der Remotecomputer befinden sich in unterschiedlichen Domänen, zwischen denen keine Vertrauensbeziehung besteht.

 Wenn Sie die oben genannten Ursachen überprüft haben, probieren Sie folgende Aktionen aus:

  - Suchen Sie in der Ereignisanzeige nach Ereignissen im Zusammenhang mit der Authentifizierung.

  - Ändern Sie die Authentifizierungsmethode; fügen Sie den Zielcomputer der Konfigurationseinstellung "TrustedHosts" für WinRM hinzu, oder verwenden Sie den HTTPS-Transport.

 Beachten Sie, dass Computer in der TrustedHosts-Liste möglicherweise nicht authentifiziert sind.

  - Führen Sie den folgenden Befehl aus, um weitere Informationen zur WinRM-Konfiguration zu erhalten: "winrm help config". Weitere Informationen finden Sie im Hilfethema

"about_Remote_Troubleshooting".

    + CategoryInfo          : OpenError: (Test-Server:String) [], PSRemotingTransportException

    + FullyQualifiedErrorId : AuthenticationFailed,PSSessionStateBroken


#11 MurdocX

MurdocX

    Board Veteran

  • 584 Beiträge

 

Geschrieben 02. August 2017 - 10:02

Schon mal ausgeführt?

winrm qc

Update

 

"Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar."
 
DNS-Einstellungen auf dem zu erreichenden Host richtig konfiguriert?

Mit freundlicher Unterstützung
Jan