Exchange 2019 per scheduled Task in Maintenance Mode setzen (Server 2022)

[telber1 0]

Tach allerseits,

 

auch ein Exchange 2019 auf Server 2022 in einem Exchange DAG möchte gerne automatisch aktualisiert werden. Ich habe zwei Powershell-Skripte erstellt. Eines, um den Exchange vor den Updates in den Maintenance Mode zu setzen:

 

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Set-ServerComponentState -Identity "SERVERNAME" -Component HubTransport -State Draining -Requester Maintenance
Suspend-ClusterNode "SERVERNAME"
Set-MailboxServer "SERVERNAME" -DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer "SERVERNAME" -DatabaseCopyAutoActivationPolicy Blocked
Set-ServerComponentState "SERVERNAME" -Component ServerWideOffline -State Inactive -Requester Maintenance

 

Das andere, um den Server nach den Updates wieder aus dem Maintenance Mode zu holen, kann ich bei Bedarf posten. Das Problem ist das gleiche. Das Powershell läuft nicht korrekt, wenn ich es über scheduled Task einrichte. Ich wähle einen User, der lokale Adminrechte hat, wähle Run whether user is logged on or not und setze ein Häckchen bei Run with highest privileges.

Actions / Start a program

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Parameter

-ExecutionPolicy Bypass -command "& 'PfadzumSkript.ps1' -force"

 

Das Skript wird zwar ausgeführt, jedoch scheinen die Rechte zu fehlen. Diese Befehle zeigen, dass der Server noch nicht im Maintenance Mode ist:

Get-ServerComponentState -Identity "SERVERNAME"
get-clusternode

Wenn ich das Skript über eine Powershell als lokaler Admin ausführe, funktioniert es. Wie kriege ich das über die scheduled Task hin?

 

Grüsse

 

bearbeitet 12. Juni 2023 von telber1
2 optionen kursiv gestellt

[cj_berlin 1.329]

Moin,

für die Exchange-spezifischen Befehle ist es irrelevent, welche Rechte der verwendete User auf irgendeiner Maschine hat - er muss in einer entsprechenden Exchange-Rolle sein, damit das funktioniert. Für Cluster-spezifische Befehle gilt das gleiche - er braucht Rechte am Cluster, nicht nur am aktuellen Node.

[testperson 1.711]

Hi,

 

ansonsten bau doch mal ein Logging in das Script ein. Du könntest bspw. einfach mal mit

• Start-Transcript (Start-Transcript (Microsoft.PowerShell.Host) - PowerShell | Microsoft Learn)
• Stop-Transcript (Stop-Transcript (Microsoft.PowerShell.Host) - PowerShell | Microsoft Learn)

anfangen.

 

Warum nimmst du den "-Command" Parameter und nicht "-File <LW>:\<Pfad zum>\Script.ps1"?

 

Gruß

Jan

[telber1 0]

Hi,

 

ich danke euch. Ich kann den scheduled Task auch unter meinem User laufen lassen, der hat alle Rechte. Der Task macht aber leider trotzdem nichts.

[testperson 1.711]

Moin,

 

hast du denn einmal am Anfang das Start-Transcript eingefügt und am Ende entsprechend Stop-Transcript? In den "Logs" findet sich dann auch gar nichts oder steht da "Ich mache leider trotzdem nichts".

 

Ändert sich etwas, wenn du dich per Remote PowerShell im Script mit dem Exchange verbindest anstatt die Snap-Ins zu laden (Connect to Exchange servers using remote PowerShell | Microsoft Learn)?

 

Gruß

Jan

[telber1 0]

Moinsen,

 

danke. In den Logs steht nichts, da die Datei eben nicht erstellt wird. Wie soll dieses Verbinden via remote PowerShell funktionieren über einen Scheduled Task? Wie kann ich die aktuellen Logindaten in die Variable

$UserCredential = Get-Credential

laden? Dazu weiss ich bisher, dass das nicht möglich ist, oder schon?

 

 

[Lukikum 8]

Moin telber,

ich hatte einen ähnlichen Fehler und konnte es dann fixen indem ich den Pfad angepasst habe.

Unter dem Punk "Action" "Start a program" habe ich folgendes:

Program/script:
C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe

Add arguments:

-command ". '%exchangeinstallpath%\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Pfad\Skriptname.ps1

LG
Lukas

[testperson 1.711]

vor 24 Minuten schrieb telber1:

In den Logs steht nichts, da die Datei eben nicht erstellt wird.

Dann wird das Script gar nicht erst gestartet.

 

vor 25 Minuten schrieb telber1:

Dazu weiss ich bisher, dass das nicht möglich ist, oder schon?

Du benötigst an der Stelle keine Credentials solange der ausführende User des Tasks passende Rechte hat.

[telber1 0]

Ich danke euch. Das Problem konnte ich lösen, indem ich im Task selber ein Batchfile aufrufe mit diesem Inhalt:

 

Powershell.exe -File  skript.ps1