Powershell Scripts können auf dem Exchange nicht ausgeführt werden

[Gerber_]

Hi Community,

ich habe gerade ein Problem auf einem Exchange Server 2013. Ich wollte in der Exchange Management Shell ein Powershell Script ausführen, allerdings bekomme ich immer die Fehlermeldung (siehe Anhang).

Ich habe bereits die Execution Policy wie folgt umgestellt:

"Set-ExecutionPolicy unrestricted"


Allerdings ohne Erfolg.

Auch habe ich bereits in den GPOs nachgesehen, ob dies wirklich wie in der Meldung beschrieben gesperrt ist. Auch hier ist nichts zu sehen. Es ist lokal auf dem Exchange, so wie auf dem DC keine GPO konfiguriert, welche die Software beschränkt.


Hat jemand von euch eine Idee hierzu?

Danke im Voraus.



Grüße Phil

 

[Muffknutscher]

Bist du als Admin angemeldet? Hast du die PS als Admin gestartet? Nochmals die Benutzerrechte geprüft?

Mal das: Get-ExecutionPolicy ausführen und schauen was ausgespuckt wird.

Ansonsten mit diesen Befehlen die Policy umgehen:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass -Force;

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted -Force;

Edith: Das könnte auch noch helfen:
set-executionpolicy remotesigned

 

[Gerber_]

@Muffknutscher

Danke dir für die schnelle Antwort.
Jap, bin als Domain Admin angemeldet. Powershell ebenfalls nochmals als Administrator gestartet.

Edit:

leider alles Ohne Erfolg.
Ich habe nochmals die Set-executionpolicy RemoteSigned getestet

Auch den Befehl zum Current User:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted -Force;

Leider immer die gleiche Meldung.

Ergänzung (7. Juni 2019)

Eventuell hilft dies euch weiter:



Ich versuche das Script mit den Exclusions für den AV am Exchange Server 2013 auszulesen.
Das Script erstellt 3 Text Dateien mit den jeweiligen Dateien, PFaden und Prozessen:



https://gallery.technet.microsoft.com/office/Generate-Antivirus-f1a9a59e

 

[Muffknutscher]

Schau noch mal in den GPO's oder auf dem EX, vielleicht ist doch was hinterlegt, bzw. sollte eingeschaltet werden:

 

[Gerber_]

Danke dir.

Auch hier habe ich nochmals nachgeprüft und beim Exchange in den lokalen Einstellungen die Skriptausführung erlaubt (Alles ausführen).

Keine Besserung, weiterhin der gleiche Fehler.

 

[IT_Nerd]

Etwa so:

Hm, die Basics hat @Muffknutscher ja bereits thematisiert, hast du dich mal mit einem Blick auf die Properties von EMS vergewissert, was unter Target da für den Aufruf der PS eingetragen ist? %systemroot%\SYSTEM32\ oder %systemroot%\SYSWOW64?

Unter EMS (Elevated) bitte mal dies hier eingeben:

PS C:\Users\Administrator> Get-ExecutionPolicy
Unrestricted

PS C:\Users\Administrator> if ([System.IntPtr]::Size -eq 8) {
>>     write-host 64,":64bit Session"
>> }
>> else {
>>     write-host 32,":32bit Session"
>> }
>>
64 :64bit Session

Was wird im Output angezeigt?

Hier könnte ebenfalls ein Problem mit dem WOW64 File System Redirecting vorliegen, der einfachte Weg dieses Problem zu lösen wäre meiner Ansicht nach in die orginären PS die Exchange Erweiterungen zu laden und an das Skript zu übergeben =>die Skripts welche mit den Tools installiert werden, z. B. RemoteExchange.ps1.

Ausprobieren!

IT_Nerd

 

[Gerber_]

@IT_Nerd

Danke dir für die Antwort.
Ich werde deine Punkte gleich am Dienstag testen und Rückmeldung geben.

Auch den Output werde ich durchgeben.

Grüße Phil

 

[morcego]

Die Powershell braucht einfach ein paar Einstellungen, damit die unternehmensweit einsetzbar ist. Wenn man jetzt mit einfachen direkt editierbaren ps1 arbeiten will, dann bietet sich ein zentrales Modul an:
1. Die GPOs müssen passend gesetzt werden. Die Ausführungsrichtlinie wird gesetzt und es wird die vorbereitete profile.ps1 auf die Rechner kopiert. Wichtig! Das sind Rechner-GPOs, die müssen auf die OU mit den Rechnern angewendet werden. Die Freigabe von der die profile kommt muss für Rechner lesbar sein.
2. Auf dem Server der die PS ausführen können soll, muss im Servermanager die IE-Sicherheit deaktiviert werden. Sonst bekommt man beim Start der Shell Abfragen ob man das wirklich will. Das ist für Skripte Mist. Geht bestimmt auch per GPO.
3. Die profile.ps1 muss angepasst werden um der Freigabe zu entsprechen.

<#
    .Synopsis
        Erweitert die lokale Powershell Session um die verfügbaren Module
#>

[string]$MyModuls = "\\Server\Freigabe\Repository\WindowsPowerShell"

if ( Test-Path -path $MyModuls\Modules) {
    $env:PSModulePath += ";$MyModuls\Modules"
    Get-ChildItem -Path $MyModuls\Modules -Directory | ForEach-Object {
        Import-Module $_ -ErrorAction SilentlyContinue

        if (Get-Module -ListAvailable -Name $_.Name) {
            Write-Host $_.Name -ForegroundColor Green
        } else {
            Write-Host $_.Name.ToString() "konnte nicht geladen werden" -ForegroundColor Red
        }
    }
    $env:Path += ";$MyModuls\Skripts"
    }
else {
    $env:PSModulePath += ";$env:userprofile\Documents\MyPowershell\Modules"
    Get-ChildItem -Path $env:userprofile\Documents\MyPowershell\Modules -Directory | ForEach-Object {
    Import-Module $_
   
    if (Get-Module -ListAvailable -Name $_.Name) {
            Write-Host $_.Name -ForegroundColor Green
        } else {
            Write-Host $_.Name.ToString() "konnte nicht geladen werden" -ForegroundColor Red
        }
    }
    $env:Path += ";$env:userprofile\Documents\MyPowershell\Skripts"
}

4. gpupdate /force anwenden, dann müsste die profile kopiert werden und dann sind die Sachen verfügbar.

Ich habe das auch eben auf dem Exchange geprüft, mein Modul kommt in der Exchange-Shell ganz brav mit hoch. Die Dateistruktur im Modul kann dann angepasst werden. Im Modul liegen alle Cmdlets, im Skripte-Ordner dann zusammengesetzte Funktionen aus den einzelnen Cmdlets für irgendwelche Aufgaben.

 

[Muffknutscher]

@morcego echt jetzt? Es ist pfingsten und Wochenende und du gammelst auf eurem Exchange rum? Ich hab schon die erste Flasche Weisswein drin und entspanne, aber löblich das du am WE hilfst!

 

[Gerber_]

Guten Morgen,

danke euch für die Hilfe, auch über Pfingsten .

@IT_Nerd

Unter dem Punkt Target ist folgendes hinterlegt:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto -ClientApplication:ManagementShell "

Ich habe dann deinen zweiten Tipp versucht und über die Powershell die Exchange Module geladen.
ich habe das Script "RemoteExchange.ps1" ausgeführt, welches korrekt ausgeführt wurde.

Nach dem ich dann wieder versucht habe das Exclusion Script auszuführen, wurde die gleiche Fehermeldung mit "UnauthorizedAccess" angezeigt.

@morcego
Deine Antwort bezieht sich auf das laden der Exchange Module in der Powershell, richtig?

 

[morcego]

Nein, meine Antwort bezieht sich auf das Bereitstellen eigener Powershell Skripte in einem Unternehmensnetzwerk. Die Untermenge Exchange-Shell wird dabei mit abgefrühstückt. Dein Skript muss dann auch in den zentralen Skiptpfad wie in die profile.ps1 "ermittelt" und der Shell hinzugefügt hat. Ein Aufruf über C:\Scripting entfällt dann, es wird immer nur der direkte Name im Aufrufer verwendet. Quasi -command "Make-something.ps1".

Ich würde auch fast behaupten, dass der -command Teil als letztes im Aufruf stehen muss. Ein -noninteractive womöglich auch noch davor. Zumindest rufe ich so meine Sachen in der Aufgabenplanung auf.

 

[IT_Nerd]

Bin noch dran an deinem Problem (das wird doch irgendwie zu lösen sein)

also mein derzeitiges "Problem/Hindernis"

- aktuell zwei größere Projekte (ja Mann, die Rente) -von daher zeitlich etwas eingeschränkt

- Win Server 20xx mache ich seit Jahren nur noch im "Nebenjob" -Butter auf's Brot eher im Bereich IBM Z. Kann das Szenario da mir aktuell kein Exchange Server zur Verfügung steht erst Mo nächste Woche bei einem Kollegen nachstellen.

THX 4 understanding/your patience

IT_Nerd

 

[Gerber_]

@IT_Nerd

Danke dir für deine Info und danke für deine Hilfe.

Kein Thema, bin ja sehr sehr dankbar, dass du dich überhaupt noch damit beschäftigst.

Ich würde auch einfach gerne aus Interesse herausfinden, wieso dies nicht so funzt wie es soll.

Edit:

Heute früh habe ich nochmals ein Neustart vom Exchange Server durchgeführt, allerdings ohne Erfolg.
Die Fehlermeldung bleibt die gleiche.

Grüße Phil

 

[IT_Nerd]

Hi,

kein Problem, interessiert mich halt auch persönlich (müssen ja nicht immer gleich so "Granaten" wie RPC Server konnte nicht gestartet werden, CAU oder CDPSvc/dem zugeordneten Dienst sein)

Hab das Ganze kurzerhand mal unter "K" wie Kollegenhilfe abgeheftet

IT_Nerd

 

[morcego]

Wurde die Powershell nun mal zwischenzeitlich passend per GPO und Skriptpfaden konfiguriert wie ich das beschrieben habe, oder wird jetzt auf den Sankt-Nimmerlein-Antworttag gewartet?

 

[IT_Nerd]

Hi,

bist du in der Zwischenzeit in der ganzen Sache irgendwie weiter gekommen? Ansonsten könnte ich dir zwecks Fortsetzung einen temporären Workaround anbieten -im Anschluss daran müssten wir allerdings mal deine akt. GPO's mit RSOP/Ähnlichem unter die Lupe nehmen.

Hab gestern wg. einer Störung auf einem Linux Server eine Art "Notfall" reinbekommen -befinde mich gerade auf dem Heimweg -in Hotelbetten kann ich irgendwie nicht richtig schlafen..

In meinen Serviceverträgen ist bei einem Störfall unter Reaktionszeit immer "Next Business Day" ausgewiesen - der von mir in Rechnung gestellte Aufpreis bei einer kürzeren ist allerding auch nicht zu verachten.

Schau morgen Abend mal hier vorbei

IT_Nerd


@morcego

nee, wir warten lieber auf den besagten Tag (LOL). Den fachlichen Anspruch deiner Posts will ich mit keiner Silbe in Abrede stellen (Thumbs Up) -mal in Erwägung gezogen, dass der TE evtl. ja nicht so 'ne Leuchte wie du bist?

BTW -iss übrigens ein Fehler in dem PS-Script (...)

 

[Gerber_]

Moin,

@morcego

na klar warte ich auf den Antwort Tag...
Ne natürlich nicht. Ich habe gerade andere Projekte im laufen, welche durchaus wichtiger als das ausführen der Scripts auf einem Exchange sind, der sonst reibungslos seinen Dienst ausführt.

Aber Freitag ist sicherlich mit dem Brückentag ein gut ausgewählter Tag um mich wieder an die Thematik zu setzen und deinen Weg zu testen.

Ich muss allerdings noch hinzu sagen, es ist auf alle Fällle nicht mein erster Exchange Server, den ich betreue .
In keinem dieser (oder Kollegen) ist solch ein Fehler bekannt.

@IT_Nerd

Siehe oben. Ich bin leider noch nicht hinzu gekommen und wie gesagt ist dies nicht ein Problem, welches mit 180 Prozent priorisiert wird.

Und auch deine Thematik mit den Reaktionszeiten kann ich durchaus nachvollziehen . Trifft mich zwar nicht als Chef aber als Mitarbeiter

Du hast einen Fehler im PS Script entdeckt? Denn kannst doch glecih mal loswerden wenn du magst

Naja und das mit der Leuchte werde ich jetzt mal gekonnt ignorieren ...

Grüße Phil

 

[morcego]

Die letzte Reaktion war einfach Tage her, da kann man ja mal nachfragen ob es Erfolge gab.
Ich gucke ja nun auch praktisch täglich vorbei um zu sehen ob sich was tut oder ob man was beitragen kann.
Mein Beitrag war hoffentlich ausführlich genug gestaltet, ich kenne es ja selber nur zu gut wenn bestimmte Sachverhalte im Technikbereich schlecht oder nicht ausreichend beschrieben werden und man stundenlang rumfriemelt.

 

[Gerber_]

@morcego

Na klar ist auch perfekt, dass du dies so machst. Solche Leute braucht das Forum...

Ich bin dein Post gerade nochmals durchgegangen. Kurz zum Verständnis:

Ich habe es richtig verstanden, dass die lokale Powershell, auf die die GPO (Computer) greift um die Module wie z.B. Exchange Modul erweitert wird, damit auch in dieser Powershell die Exchange CMDlets ausgeführt werden können?

Über die GPOs werde ich einmal die Scriptausführung erlauben und das Profile.ps1 Script an die Clients verteilen, richtig?

Muss ich dann am Client noch etwas bestimmtes durchführen (außer gpupdate /force) ?

Was genau bringt mir dann das Profile Script auf dem Client?
Dies sorgt dafür, dass die Module automatisch beim Start der Powershell geladen werden?
---

Grüße Phil

 

[morcego]

Wir fangen mal hinten an. Du hast Arbeit investiert und besitzt einige Powershell Skripte oder gar ein Modul die auf deinem Rechner laufen. Jetzt möchtest du für administrative Zwecke wie das Installieren von Software oder Updates von Programmteilen in der gesamten Domäne darauf zugreifen.

• Die Skripte auf jeden Rechner kopieren ist unhandlich und schwierig bei Codeupdates
• Die Powershell ist restriktiv eingestellt und lässt nicht einfach Skripte von überall zu.

Also nimmst du deine Skripte und kopierst die in eine zentrale Freigabe wie in den Bildern gezeigt, zB \\server\share\Repository\Powershell\Skripte
Super, zentral verfügbar. Aber wenn du die Powershell auf dem Client oder Server startest, sind die Skripte nicht verfügbar. Jetzt kommt die profile.ps1 ins Spiel. Es gibt vier Orte wo die liegen kann, die weitreichendste Stelle ist der Programmordner der Powershell selbst auf dem Rechner "explorer $pshome".
Damit die profile auf die Rechner kommt, wird die von einer GPO beim Login an den Rechner verteilt.

In der profile.ps1 steht drin, was die Powershell zum Sessionbeginn macht. In dem Falle erweitert sie ihre unterstützten Pfade
"$envSModulePath += ..." und "$envath += ..." um den zentralen Modul- und Skriptordner.
Heißt ganz simpel: alle Skripte die in den zentralen Pfaden liegen sind jetzt direkt benutzbar wie "mein-skript.ps1" oder "Do-MyCmdlet". Ein Aufruf per Pfad ist nicht mehr nötig.

Abschließend muss die Sicherheit geregelt werden, das macht die zweite GPO zur ExecutionPolicy. Im Prinzip sind die Skriptpfade Vertrauenswürdige Pfade aus denen Skripte ausgeführt werden dürfen (wie VBA Makros in Office). Deshalb genügt es in der GPO RemoteSigned als Richtlinie auszuführen. Unrestricted ist nicht notwendig.
Für Clients bist du hier fertig. Wenn die GPOs angewendet wurden, die profile.ps1 verfügbar ist, dann läuft es.

Bei Servern muss entweder per GPO oder händisch die Internetsicherheit deaktiviert werden. Das ist im Servermanager > lokaler Server > Verstärkte Sicherheitsrichtlinie für IE (Administratoren). Weiß der Geier wieso die Powershell am Rechtesystem des IE hängt, jedenfalls muss die deaktiviert werden. Ab dann läuft es auch auf Servern.

Für Exchange müsste der Aufruf der Exchange Shell glaube ich, bei anderen Sachen reicht das Hinzufügen der SnapIns. Als Beispiel bei uns, "unwichtige" Server per Veeam Zip sichern. Im Skriptpfad liegt eine VeeamZip.ps1. Da drin steht dann nur:

Add-PSSnapin VeeamPSSnapin

Find-VBRHvEntity -Name "<Servername>" | Start-VBRZip -Folder "Path" -Compression 6 -AutoDelete In2Weeks

Und das wird über die Aufgabenplanung getriggert. -command muss der letzte Parameter sein, das steht irgendwo in der PS-Doku.