Buchungsanfrage abgelehnt: „Die Ressource akzeptiert keine Besprechungen, die länger als 1440 Minuten dauern“

Problem

Eine Ressource lässt sich in Exchange 2016/2019 nicht länger als einen Tag lang (1440 Minuten) buchen. Für Autos oder Leihgeräte sind mehrere Tage oder Wochen aber notwendig.

Lösung

Das ist richtig, die maximale Standartzeit für gebuchte Ressourcen ist 24 Stunden.

Früher gab es mal das Cmdlet Get-MailboxCalendarSettings, mit dem man die Buchungszeit (MaximumDurationInMinutes) einstellen konnte. Dieser Befehl wurde aber (ganz ohne die übliche „Deprecated“ Meldung) abgelöst. Hier sind die neuen.

Einstellung (für die Ressource „Auto*“) anzeigen

[PS] C:\>Get-CalendarProcessing -Identity vw* | fl maximumd*

MaximumDurationInMinutes : 1440

Einstellung ändern

[PS] C:\>Set-CalendarProcessing -Identity vw* -MaximumDurationInMinutes 2147483647

Der Wert ist ein Int32, 2147483647 also das Maximum. Knapp 4000 Jahre reichen aber auch für langfristiges ausleihen aus.

VMware vSphere VCSA/vCenter Liste über VMs mit Betriebssystemen ausgeben

Manchmal braucht man eine schnelle Liste über die laufenden Gast-Betriebssysteme (und -Versionen) in einer vCenter-Instanz. In meinem speziellen Fall benötigte ich vor allem die konfigurierten Betriebssysteme und die tatsächlich laufenden Gäste, um nach einer Migration die Einstellungen für die ESXi-Hosts auz zu räumen.

Nach ein bisschen Bastelei nutze ich nun diesen PowerCLI Einzeiler. Das Script erstellt einfach eine Liste über Name, Konfiguriertes OS und das gemeldete OS aller Gastsysteme.

Lösung

Liste aller OS in einem vCenter via Powershell erstellen:

Get-VM | Get-View -Property @("Name", "Config.GuestFullName", "Guest.GuestFullName") | Select -Property Name, @{N="Eingestellt";E={$_.Config.GuestFullName}},  @{N="Läuft";E={$_.Guest.GuestFullName}} | Format-Table -AutoSize
So sieht die Ausgabe des Befehls aus.

Powershell Scripts starten in der Aufgabenplanung nicht (Ergebnis 0x1)

Problem

Im Taskplaner (Aufgabenplanung) angelegte Powershell-Scripte (*.ps1) starten trotz „richtigem“ Aufruf (%System32%\WindowsPowerShell\v1.0\powershell.exe …) nicht und geben das Ergebis 0x1 zurück

Lösung

Meistens ist die ExecutionPolicy schuld. Mal ist es der 32bit-Powershell-Interpreter, dann wieder 64bit. Die Aufgabenplanung startet per Default x64, aber beide Interpreter haben eigene Policys. Es kann auch eine lokale- oder nichtlokale Profileinstellung sein oder Policy-Changes nach einem Update Es gibt viele Ursachen. Es hat sich daher bewährt, die Policy pro Script zu umgehen:

powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File \\<SERVER>\<FREIGABE>\<SCRIPT>.ps1

-NoProfile Stell sicher, das das Script ohne ein lokales Profil ausgeführt wird und somit immer „kollisionsfrei“ bleibt. Außerdem vermeidet man so den langsamen Overhead sämtlichen Profilcodes/aliases/Snipplets/Imports.
-NoLogo Lässt das Startlogo weg. Hilfreich wenn man den vollständigen Output umleitet. Und total gut fürs Admin-Gefühl.
-NonInteractive Umgeht Wartezeiten für Benutzereingaben, indem es letztere weglässt; genauer: durch ein ‚exit 100‘ ersetzt. Das Script hängt also nicht mehr bei Prompts, sondern beendt siche selbst mit dem Fehler 0x100.
-ExecutionPolicy Bypass Umgehen die lokale Executionpolicy. ‚unrestricted‘ ist natürlich ebenfalls möglich. Wir empfehlen aber ‚Bypass‘, weil das Probleme mit globalen Konfigurationsänderungen der Policys (jetzt und in Zukunft) umgeht.

VMware ESXi/vCenter: Wann war eine VM das letzte mal eingeschaltet?

Manchmal ist es hilfreich zu wissen, wann ein VMware Gast zuletzt eingeschaltet gewesen ist. Es soll ja schon mal vorkommen das „tote“ virtuelle Maschinen jahrelang auf der Infrastruktur liegen aber eigentlich nicht mehr gebraucht werden.

Lösung

Es gibt keine „eingebaute“ Möglichkeit, Einschaltdaten von VMs nachzuschlagen. Am einfachsten ist es aber, das Ereignisprotokoll rückwärts nach dem letzten „Power on“ Event zu durchsuchen.

An der PowerCLI Powershell geht das beispielsweise so:

Get-VM GASTNAME | Get-VIEvent -Types Info -MaxSamples 1000 | Where-Object {$_.fullFormattedMessage -match "Power On"} | %{Write-Host $_.vm.name $_.createdTime | Out-Default}

Wobei hier „MaxSamples“ ein Beispiel ist; möglicherweise muss man mehr Events durchsuchen. Wenn man beispielsweise oft Sicherungen von Gästen via VCB erstellt, reichen 1000 Events nicht aus.

Ohne die Angabe „GASTNAME“ gibt es eine Liste aller verbundenen virtuellen Maschinen.

Office 365 Exchange Online Powershell unter Windows 10 Verbindung herstellen

Die Office 365 Exchange Online Powershell benötigt eigentlich keine Powershell Modul-Installation, weil zu Exchange nur eine Remote-Session hergestellt wird.

Anders sieht da aus, wenn man die MFA (Mehr-Faktor-Authentifizierung) eingeschaltet hat. Dazu unten mehr.

Exchange Online Powershell ohne MFA

$credential = Get-Credential
$exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $exchangeSession -DisableNameChecking -AllowClobber

Das erste Kommando fragt die Credentials ab und speichert diese in der Variable $credential, das zweite verwendet diese für die Verbindung und das dritte importiert die Remote-Sitzung.

Exchange Online Powershell mit 2FA (Mehr-Faktor Authentifizierung)

Hierfür muss man zuerst doch noch manuell ein Modul herunterladen, das „Exchange Online Remote PowerShell-Modul„. Man findet den Download für die Offline-Installation innerhalb seines Office 365 Portals in der EAC. Mann kann diese Spezial-Powershell aber auch direkt ohne Umwege herunterladen und starten; der Link dazu steht weiter unten.

Office 365 Portal > Exchange Administrator Center (EAC) > Hybrid > „Konfigurieren“ (‚Das Exchange Online-PowerShell-Modul unterstützt mehrstufige Authentifizierung.‘)

Hat man das Modul heruntergeladen und installiert, sollte man einmal sein WinRM-Konfiguration testen. Ein lauffähiges WinRM-System mit eingeschalteter Basic-Authentifizierung (Default) ist Voraussetzung.

WinRM-Konfiguration in der Powershell „als Administrator“ anschauen:

winrm get winrm/config/client/auth

Sollte da „Basic = false“ in der Ausgabe stehen, muss man zwingend Basic-Auth einschalten:

winrm set winrm/config/client/auth @{Basic="true"}

Dann kann man auch schon endlich fast eine Verbindung herstellen; dazu das „Microsoft Exchange Online Powershell Module“ im Startmenü öffnen. Dier hier ist der direkte Download-Link zur Exchange Shell:

https://cmdletpswmodule.blob.core.windows.net/exopsmodule/Microsoft.Online.CSE.PSModule.Client.application

In der neuen Exchange-Powershell tippt man dann:

Connect-EXOPSSession -UserPrincipalName <[email protected]>

Und schon stehen einem die altbekannten CMDlets wie Get-Mailbox, Get-DistributionGroup oder Get-MailboxPermission zur Verfügung.

Office 365 Powershell Zugänge unter Windows 10 (1809+)

Nachdem der letze Beitrag zum Thema Office 365 Powershell ja mittlerweile veraltet ist, hier die aktuelle Methode eine Verbindung zu Office 365 herzustellen.

„Heute“ nutzt man direkt die AzureAD Module die man via NuGet installiert und nicht mehr die MSOnline „Extra“ Shell.

Installation des AzureAD Module (Lizenzen, Office 365 Benutzer …)

  1. Öffnen der Powershell „Als Administrator“ und das Modul installieren:
PS C:\> Install-Module -Name AzureAD

Nicht vertrauenswürdiges Repository
Sie installieren die Module aus einem nicht vertrauenswürdigen Repository. Wenn Sie diesem Repository vertrauen, ändern
 Sie dessen InstallationPolicy-Wert, indem Sie das Set-PSRepository-Cmdlet ausführen. Möchten Sie die Module von
'PSGallery' wirklich installieren?
[J] Ja  [A] Ja, alle  [N] Nein  [K] Nein, keine  [H] Anhalten  [?] Hilfe (Standard ist "N"): j
PS C:\>

2. Herstellen der Verbindung zum AzureAD (Office 365)

PS C:\> Connect-AzureAD

Account                     Environment TenantId                             TenantDomain    AccountType
-------                     ----------- --------                             ------------    -----------
<UPN>> AzureCloud  affeaffe-b00b54e0e-a0c4-a5b16ca62f5b <DOMAIN> User
PS C:\>

… fertig. Und schon kann man mit den AzureAD-CMDlets wie Get-AzureADUser, Get-AzureADUserLicenseDetail und allen anderen loslegen.

Eine Liste aller CMDlets gibt es mit:

Get-Command -Module AzureAD

Windows Server 2016 RDS Effekte (Black Screen, Startmenü defekt)

Problem:

Ein Terminal Server (RDS Session Host) zeigt nach einiger Zeit verschiedene Effekte, wie z.B. „schwarzer Bildschirm nach der Anmeldung“, „nicht mehr funktionierendes Startmenü“, allgemeine Performance- oder Anmeldeprobleme.

Dies betrifft übrigens nicht zwingend nur RDS-SHs, sondern prinzipiell alle Windows Server 2016 Maschinen, auf Terminalservern (insbesondere mit User Profile Disks, UPDs) ist das ganze aufgrund potenziell größerer Anmelde-/Benutzeranzahl nur deutlich wahrscheinlicher anzutreffen.

Lösung:

Schuld könnte ein Bug sein, welcher dafür sorgt, dass bei der Benutzeranmeldung erstellte Firewall-Regeln beim löschen des Benutzerprofils (hier kommen die UPDs ins spiel, unter Einsatz dieser wird das Profil nämlich bei der Abmeldung automatisch wieder vom Server gelöscht) nicht mehr entfernt werden.

Das verursacht einen Registry-Bloat in 

HKLM:\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules

und/oder

HKLM:\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System

Sind diese Keys bereits „überfüllt“, kann es gut sein, dass sich die Werte nicht mehr per GUI (regedit) entfernen lassen – der Key lädt schlichtweg ewigkeiten. Abhilfe schafft folgendes PowerShell-Script:

$profiles = get-wmiobject -class win32_userprofile
Clear-Host
Write-Host "`n`n`n`n`n`n`n`n"
Write-Host "Getting Firewall Rules..."
$Rules1 = Get-NetFirewallRule -All | 
  Where-Object {$profiles.sid -notcontains $_.owner -and $_.owner }
$Rules1Count = $Rules1.count
Write-Host "" $Rules1Count "Rules`n"

Write-Host "Getting Firewall Rules from ConfigurableServiceStore..."
$Rules2 = Get-NetFirewallRule -All -PolicyStore ConfigurableServiceStore | 
  Where-Object { $profiles.sid -notcontains $_.owner -and $_.owner }
$Rules2Count = $Rules2.count
Write-Host "" $Rules2Count "Rules`n"

$Total = $Rules1.count + $Rules2.count
Write-Host "Deleting" $Total "Firewall Rules:" -ForegroundColor Green

$Result = Measure-Command {

  $start = (Get-Date)
  $i = 0.0

  foreach($rule1 in $Rules1){

    # action
    Remove-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules" -Name $rule1.name

    # progress
    $i = $i + 1.0
    $prct = $i / $total * 100.0
    $elapsed = (Get-Date) - $start
    $totaltime = ($elapsed.TotalSeconds) / ($prct / 100.0)
    $remain = $totaltime - $elapsed.TotalSeconds
    $eta = (Get-Date).AddSeconds($remain)

    # display
    $prctnice = [math]::round($prct,2) 
    $elapsednice = $([string]::Format("{0:d2}:{1:d2}:{2:d2}", $elapsed.hours, $elapsed.minutes, $elapsed.seconds))
    $speed = $i/$elapsed.totalminutes
    $speednice = [math]::round($speed,2) 
    Write-Progress -Activity "Deleting Rules ETA $eta elapsed $elapsednice loops/min $speednice" -Status "$prctnice" -PercentComplete $prct -SecondsRemaining $remain
  }

  foreach($rule2 in $Rules2) {

    # action  
    Remove-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System" -Name $rule2.name

    # progress
    $i = $i + 1.0
    $prct = $i / $total * 100.0
    $elapsed = (Get-Date) - $start
    $totaltime = ($elapsed.TotalSeconds) / ($prct / 100.0)
    $remain = $totaltime - $elapsed.TotalSeconds
    $eta = (Get-Date).AddSeconds($remain)

    # display
    $prctnice = [math]::round($prct,2) 
    $elapsednice = $([string]::Format("{0:d2}:{1:d2}:{2:d2}", $elapsed.hours, $elapsed.minutes, $elapsed.seconds))
    $speed = $i/$elapsed.totalminutes
    $speednice = [math]::round($speed,2) 
    Write-Progress -Activity "Deleting Rules from ConfugurableServiceStore ETA $eta elapsed $elapsednice loops/min $speednice" -Status "$prctnice" -PercentComplete $prct -secondsremaining $remain
  }
}

$end = Get-Date
Write-Host end $end 
Write-Host eta $eta

Write-Host $result.minutes min $result.seconds sec

Achtung: bei einem bereits länger laufenden Terminalserver, kann das Script schonmal so ein paar Stunden brauchen um alle Regeln zu entfernen. (In unserem Fall knapp 4 Stunden für etwa 95000 Regeln.)

Aus Performancegründen löscht das Script die Registry-Werte direkt, anstatt das Remove-NetFirewallRule Cmdlet zu verwenden.

Quelle: https://social.technet.microsoft.com/Forums/en-US/8dad5b1e-8236-4792-85fe-8725d74bbbcb/start-menu-not-coming-up-server-2016-rds?forum=winserverTS