Verständnisfrage Exchange Shell

[rakli 13]

Hallo,

 

ich verstehe Teile von folgende Befehl nicht:  :confused:

 

Get-Mailbox | where { $_.CustomAttribute1 -match "Manager" } |
Set-CASMailbox -activesyncmailboxpolicy(Get-ActiveSyncMailboxPolicy "Contoso").Identity

 

1. Warum steht da "-activesyncmailboxpolicy(Get-ActiveSyncMailboxPolicy "Contoso").Identity und nicht  einfach -activesyncmailboxpolicy "Contoso"
    
2. Und welche Bedeutung hat das ).Identity ?

(Der Befehl ist aus der Technet Exchange 2013)

 

Rakli

[Dukel 436]

Wieviel Erfahrung hast du in Powershell?

Das .identity ist eine Property des Objekts der Activesyncpolicy von "Contoso". Wenn die Identity und die Default Property von Get-ActiveSyncMailboxPolicy das selbe ist, dann geht auch dein Vorschlag.

Bei manchen Daten ist die Identity z.B. eine interne ID und nicht der Name.

[RobertWi 81]

Moin,

 

ergänzend:

 

Der Befehl Set-CASMailbox benötigt für den Parameter "ActiveSyncMailboxPolicy" einen Input vom Type "Microsoft.Exchange.Configuration.Tasks.MailboxPolicyIdParameter".

 

Die Hilfe sagt dazu:

The ActiveSyncMailboxPolicy parameter specifies the Exchange ActiveSync mailbox policy for the mailbox. You can use any value that uniquely identifies the Exchange ActiveSync mailbox policy. For example:

• Name

• Distinguished name (DN)

• GUID

The name of the default Exchange ActiveSync mailbox policy is Default.

 

Wenn Du nun einfach einfach -activesyncmailboxpolicy "Contoso", dann benutzt Du einen String und die Shell muss den String in ein Objekt vom Type MailboxPolicyIdParameter konvertieren.

 

Das kann gehen, muss aber nicht (in diesem Fall erwartet ich, dass es funktioniert, ist aber ungetestet, wobei die Hilfe mit Beispiel 2 meine Vermutung bestätigt).

 

Schauen wir uns den Type vom Member Identity von "Get-ActiveSyncPolicy" an. Der gibt ein Objekt vom Type "Microsoft.Exchange.Data.Directory.SystemConfiguration.MobileMailboxPolicy" aus, da sehen wir:

 

[PS] C:\>Get-ActiveSyncMailboxPolicy "Default" | Get-Member | Where-Object { $_.Name -eq "Identity" }

 

 

   TypeName: Microsoft.Exchange.Data.Directory.SystemConfiguration.MobileMailboxPolicy

 

Name     MemberType Definition

----     ---------- ----------

Identity Property   Microsoft.Exchange.Data.ObjectId Identity {get;}

 

Auch hier muss eine Konvertierung stattfinden, es ist aber wahrscheinlicher, dass zwei Exchange-Objekte konvertiert werden können (zumal der Zielfeld diesen Input erwartet), als ein String in ein Exchange Objekt.

 

Der Rest ist schnöde PowerShell Technik:

 

(Get-ActiveSyncMailboxPolicy "Contoso").Identity

 

Die runden Klammern sind ein Vorrangsteuerung, d.h. es wird zuerst der Befehl Get-ActiveSyncMailboxPolicy "Contoso" ausgeführt und das Ergebnisse (ein Objekt vom Type MobileMailboxPolicy) an dieser Stelle eingesetzt. .Identity ist der Zugriff auf die Eigenschaft Identity dieses Objektes.

 

Das mit der Vorrangsteuerung finde ich in der PowerShell genial und auch genial einfach gelöst. In anderen Scipting Sprachen hätte man die Ausgabe von Get-ActiveSyncMailboxPolicy erst in einer Variablen speichern müssen, in der Shell spart man sich das.

 

Echte Sorgen dagegen macht mit der Operator "-match" in Deinem Beispiel. Der wird zwar in diesem Fall funktionieren, aber schon ein "ungewöhnliches" Zeichen und man erhält vollkommen andere Ergebnisse. Ich erkläre in Kursen immer wer nicht genau weiß, was der tut, sollte ihn lieber weglassen und stattdessen mit -like arbeiten.

 

Wo kommt das Beispiel her, das würde ich dann intern mal als Verbesserung weitergeben?

bearbeitet 27. August 2014 von RobertWi

[rakli 13]

Danke Robert für die ausführliche Erläuterung, der Zusammenhang "-activesyncmailboxpolicy "Contoso" und "(Get-ActiveSyncMailboxPolicy "Contoso").Identity" ist mir jetzt klar.

 

Den Befehl fand ich hier http://technet.microsoft.com/de-DE/library/aa997929(v=exchg.150).aspx unter den Punkt "Ändern der Postfachrichtlinie für mobile Geräte für mehrere Benutzer in einem Arbeitsschritt"

bearbeitet 27. August 2014 von rakli

[RobertWi 81]

Danke. Ich habe das als Feedback übermittelt, dass lieber -like als -match in Beispielen benutzt werden sollte.

[Dukel 436]

In dem Beispiel kann man auch -eq nutzen. Es kommt ganz drauf an, was man sucht.

-eq ist für eine genaue Suche, -match für eine ungefähre suche, und -like eine regex suche.

 

http://www.computerperformance.co.uk/powershell/powershell_conditional_operators.htm

http://www.windowspro.de/script/vergleichsoperatoren-powershell-eq-lt-gt-contains-match

 

 

The Difference Between PowerShell's -Like and -Match

$Person ="Guy Thomas 1949"
$Person -Like "Th*"

# Result PS> False

 

$Person ="Guy Thomas 1949"
$Person -Match "Th*"

# Result PS> True

[RobertWi 81]

-eq ist für eine genaue Suche, -match für eine ungefähre suche, und -like eine regex suche.

 

Was soll eine "ungefähre" Suche sein?

 

-match ist eine RegEx Suche

-like ist eine Platzhaltersuche

 

Steht übrigens auch so in deinem zweiten Link.

 

Allerdings steht da auch, dass "*" bei -match eine Wildcard sei. Das ist falsch. "*" ist bei -like eine Wildcard, bei -match ist das aber ein Quantifier, der für 0 oder mehr Treffer steht ({0,}). Der macht in vielen Fällen das gleiche, aber eben nicht immer.

PS C:\> $person = "Guy Thomas 1949"
PS C:\> $person -like "Th*"
False
PS C:\> $person -like "Gu*"
True
PS C:\> $person -like "Gu*1949"
True
PS C:\> $person -match "Gu*"
True
PS C:\> $person -match "Gu*1949"
False

 

Man beachte den Unterschied zwischen -like "Gu*1949" (= True) und -match "Gu*1949" (= false).

 

Das liegt daran, dass Suchen mit RegEx (-match) im Normalfall "greedy" (=gierig) sind. Die finden ALLES, was nach dem Metacharacter kommt. Bei -like ist er dagegen ungierig, findet also nur bis zum ersten anderen Treffer.

 

Das hier wäre identisch:

 

 

PS C:\> $person -like "Gu*1949"
True
PS C:\> $person -match "(Gu)*?1949"
True

 

Und richtig lustig wird es, wenn man nach den Zeichen suchen will, die in einem RegEx eine besondere Bedeutung haben:

 

 

 

PS C:\> $test2 = "Adam+Eva"

PS C:\> $test2 -like "+Eva"

False

PS C:\> $test2 -like "*+Eva"

True
PS C:\> $test2 -match "*+Eva"
"*+Eva" wird analysiert - Quantifizierer {x,y} nach nichts.
In Zeile:1 Zeichen:1
+ $test2 -match "*+Eva"
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: ( [], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException
 

PS C:\> $test2 -match ".*+Eva"
".*+Eva" wird analysiert - Geschachtelter Quantifizierer +.
In Zeile:1 Zeichen:1
+ $test2 -match ".*+Eva"
+ ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException

 
PS C:\> $test2 -match ".+Eva"
True

 

Wer jetzt nichts mehr versteht merkt sich einfach das, was ich oben schriebe: Wenn ich nicht weiß, wie-match genau funktioniert, ist -match vermutlich falsch.

bearbeitet 27. August 2014 von RobertWi

[Dukel 436]

Ja stimmt. Hatte Regex und Wildcard vertauscht.

Das Problem wird für viele bei -like sein, dass ohne * gesucht wird.

 

 

PS C:\Users> $test = "Adam+Eva"
PS C:\Users> $test -like "Eva"
False
PS C:\Users> $test -match "Eva"
True

 

Meiner Erfahrung nach sind die Anwender mit match glücklicher als mit like (solange man nicht den Unterschied kennt und differenzieren kann).

Ich teste sowieso immer meine Queries und führe danach das das aus was ich machen will.

[RobertWi 81]

Das Problem wird für viele bei -like sein, dass ohne * gesucht wird.

Meiner Erfahrung nach sind die Anwender mit match glücklicher als mit like (solange man nicht den Unterschied kennt und differenzieren kann).

Meine Erfahrung: Wer den Unterschied kennt und differenzieren kann, der weißt auch, dass man bei like mit "*" sucht.

 

Sehr viele adaptieren aber nur Beispiele, die sie im Internet finden.

 

Und wenn dort ein -like "*Manager*" steht, können die daraus problemlos ein -like "*+Eva*" machen.

 

Steht dort aber -match "Manager" schlägt der Versuch fehl, das in -match "+Eva" umzuwandeln.

 

-like hat eben nur zwei Zeichen (wobei ich ? noch nie wirklich verwendet habe), die ich kennen muss. Bei -match sind das gut 20, auch noch in verschiedenen Möglichkeiten. 

 

Mit der richtigen Übung ist das kein Problem, aber ich habe in Workshops oft Leute, die Anfänge sind und keine Scripting Erfahrung haben. Dann wären RegEx garantiert zu hoch.