HAPROXY neuer Check für check_mk in ps1 / py / bash / go

Ich hatte mal wieder mit haproxy zu tun, leider hatte diese niemand in das Monitoring eingepflegt.
Ist natürlich doof wenn immer die Sessions voll laufen und keiner was merkt.
Lange Rede kurzer Sinn ;-)
Python & Powershell reagieren gleich wenn
$WIPass = '' bzw WIPass = ''
wird der check ohne auth ausgeführt. Sollte eure Statusseite nicht über ssl erreichbar sein, sollte man noch die ssl checks rauswerfen ! Unter Powershell einfach diese Zeilen auskommentieren
SkipCertificateCheck
unter Python bitte das aus den Zeilen entfernen
, verify=False
Hier ist der Check in Powershell / Python und Bash.
Ich empfehle die Python Version ;-)
checkmk-haproxy-localcheck in powershell / python und bash

Office 365 : Benutzer kann in einer shared Mailbox keinen Ordner verschieben

Hatte heute das Problem das ein Benutzer in einem shared Postfach keinen Ordner verschieben konnte. Er hat immer diese Meldung erhalten.

o365-mailboxfolderpermission
Mit diesem Snippet hab ich das gefixt
$ParaFolderPermission = @{
    Identity = 'SHARED_MAILBOX@DOMAIN:\Calendar'
    AccessRights = 'Editor'
    SharingPermissionFlags = 'Delegate,CanViewPrivateItems'
    # set to $false if test work 
    WhatIf = $true
    User = 'USERNAME@DOMAIN'
}
Add-MailboxFolderPermission @ParaFolderPermission
Wenn WhatIf auf $true gesetzt ist, wird der Vorgang nur getestet aber nicht ausgeführt !
Auszug von Microsoft Docs
Die Option WhatIf weist den Befehl an, auf den Sie angewendet wird, aber nur, um die Objekte anzuzeigen, die von der Ausführung des Befehls betroffen wären, und welche Änderungen an diesen Objekten vorgenommen würden. Der Parameter ändert diese Objekte nicht wirklich. Wenn Sie die Option WhatIf verwenden, können Sie erkennen, ob die Änderungen, die an diesen Objekten vorgenommen werden, Ihren Erwartungen entsprechen, ohne dass diese Objekte geändert werden müssen.

Microsoft DOCS
https://docs.microsoft.com/de-de/exchange/troubleshoot/user-and-shared-mailboxes/private-items-not-display
https://docs.microsoft.com/de-de/exchange/whatif-confirm-and-validateonly-switches-exchange-2013-help

Teams / Office 365 : Aufzeichnen von Meetings nicht möglich - Teil 2

Nachdem ich ja den Eintrag gemacht hatte wie man das mit Powershell fixen kann gingen komischerweise die Linux und die Mac Clients. Diese konnten Meetings aufzeichnen, jedoch gab es unter Windows 10 weiterhin Probleme das Meetings nicht aufgezeichnet werden konnten. Ich konnte das auf den Punkt "new meetings experience" zurückführen. Im aktuellen Client (11.12.2020) gibt es hier Probleme Meetings aufzunehmen. Wir haben das dann bei den betroffenen Clients deaktiviert und schon lief das recording ohne Probleme.

MS-Teams recording

Teams / Office 365 : Aufzeichnen von Meetings nicht möglich

Problem : Die Recording Funktionalität von Microsoft Teams ist ausgegraut.
Leider hab ich nur einen Screenshot wo das nicht mehr der Fall ist ;-)

Teams Recording
Lösung : Erstmal muss die Verbindung zu MS Teams aufgebaut werden.
# connect to MS Teams
Import-Module MicrosoftTeams
$sfbSession = New-CsOnlineSession
Import-PSSession $sfbSession
Anzeigen kann man die Einstellungen der Policy mit dem Befehl :
# get teams policy
Get-CsTeamsMeetingPolicy -Identity Global
Powershell Teams Policy
Dann kann man das mit dem Powershell Schnipsel fixen :
# set AllowRecordingStorageOutsideRegion 
Set-CsTeamsMeetingPolicy -Identity Global -AllowRecordingStorageOutsideRegion $True

Erklärung :
Bei uns liegt es daran das Teams bereits in der Germany Location ist der Service Stream aber selbst dort noch nicht verfügbar ist. Dieser ist im Moment nur in der Europe Region verfügbar. Die Einstellung sorgt dafür das Teams auch außerhalb Germanys die aufgezeichneten Daten ablegen darf. Was hier bedeutet unsere Recordings liegen auf Servern in der Europa Region

Exchange Online / Office 365 : Erstellen einer dynamischen Verteilerliste

Um uns die Arbeit etwas zu erleichtern haben wir unseren internen E-Mail Verteiler auf eine DynamicDistributionGroup in Exchange Online umgestellt. Das erspart uns die Arbeit neue Mitarbeiter immer manuell in den Verteiler aufzunehmen, außerdem reduziert es die Fehler (oder das vergessen die neuen User hinzuzufügen). Da wir in unserer Umgebung auch einige Funktionspostfächer haben mussten diese ausgeschlossen werden.

Erstmal habe ich eine Verteiler Gruppe erstellt in der ich die ganzen Funktionspostfächer aufnehme.
New-DistributionGroup -Name 'NODYNDIS'
Set-DistributionGroup -Identity 'NODYNDIS' -HiddenFromAddressListsEnabled $True
Mit einem ADD Befehl kann man neue Funktionspostfächer hinzufügen.
Add-DistributionGroupMember -Identity 'NODYNDIS' -Member 'user-email@domain'
Dann brauchen wir den DN der Gruppe für den Filter in der dynamischen Gruppe
Get-Group -Identity 'NODYNDIS' | Select-Object -ExpandProperty DistinguishedName

CN=NODYNDIS,OU=xxx,OU=xxx,DC=xxx,DC=xxx,DC=xxx
Dann kann man die dynamische Gruppe erstellen.
New-DynamicDistributionGroup -Name 'TESTVERTEILER' -RecipientFilter {((RecipientTypeDetails -eq 'UserMailbox') -and -not (MemberofGroup -eq 'CN=NODYNDIS,OU=xxx,OU=xxx,DC=xxx,DC=xxx,DC=xxx') -and -not (UserAccountControl -eq 'AccountDisabled, NormalAccount'))}
Kurz zur Erklärung der Filter :
(RecipientTypeDetails -eq 'UserMailbox')  : Es muss sich um ein Benutzer Postfach handeln
-and -not (MemberofGroup -eq 'CN=NODYNDIS,OU=xxx,OU=xxx,DC=xxx,DC=xxx,DC=xxx') : und nicht Mitglied dieser Gruppe
-and -not (UserAccountControl -eq 'AccountDisabled, NormalAccount') : User darf nicht deaktivert sein
Anzeigen aller Empfänger in dem dynamischen Verteiler
$mygroup = Get-DynamicDistributionGroup "TESTVERTEILER"
Get-Recipient -RecipientPreviewFilter $myGroup.RecipientFilter | Select Name,PrimarySmtpAddress

Infos :
Filterbare Eigenschaften für RecipientFilter
New-DynamicDistributionGroup
New-DistributionGroup
Set-DistributionGroup


Office 365 : Probleme beim Zugriff auf One Drive aus der UI heraus

Problem : Wir hatten hier einige User in unserem Tenant die aus dem Portal nicht auf ihr One Drive zugreifen konnten. Die Fehlermeldungen waren nicht wirklich hilfreich. Es sind immer wieder solche Fehler aufgelaufen.
one drive errors
Ein Ticket bei Microsoft hat uns dann die Lösung gebracht, auch wenn wir es nicht 100% nachvollziehen können. Vermutlich wird durch das Get-SPOSite ... | Select Owner ein neues provisioning angetriggert der dann das Feld füllt und dann auch der Zugriff aus der UI funktioniert. Ok einfach in Kurz .. davor ging es nicht danach konnte der User zugreifen ;-)
Lösung : Das Provisioning auslösen mit diesem Powershell Befehl
Get-SPOsite https://contoso-my.sharepoint.com/personal/user1_contoso_onmicrosoft_com | Select-Object -Property Url, Owner

Wir haben das alles nochmal in ein Skript geschrieben das noch andere Sachen checkt & korrigiert :-)
Hier gehts zum Skript : jhochwald/FixPersonalSPOSite.ps1

“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)