Archiv der Kategorie: PowerShell

Super Simples DynDNS (DDNS) Update via PowerShell

Veröffentlicht am von — Keine Kommentare ↓

Manchmal muss man nur „schnell mal eben“ eine IP-Adresse im DNS via DynDNS aktualisieren. Zum Testen, für schnelle Hostname-Verbindungen, um einen PC erreichbar zu machen oder ähnliches. Dynamisches DNS hat auch in der heutigen Zeit noch eine große Bedeutung.

Wie aktualisiert man also einen DDNS Namen an der Kommandozeile?

Lösung

Sehr schnell und sehr einfach, ohne Fehlerhandling:

# Supersimpler DDNS Client für PowerShell von ugg.li

# --- configuration ---
$updateURL = "UPDATEURL zB. http[s]://dynupdate.no-ip.com:8245/ducupdate.php"
$hostname = "HOSTNAME.EXAMPLE.COM"
$username = "USERNAME"
$password = "PASSWORD"

# --- IPs holen (v4 und v6) ---
$ipv6 = (Resolve-DnsName myip.opendns.com -Server 2620:119:35::35 -Type AAAA).IPAddress
$ipv4 = (Resolve-DnsName myip.opendns.com -Server 208.67.222.222 -Type A).IPAddress

# --- update DNS (v4 und v6) ---
curl.exe --user "${username}:${password}" "${updateURL}?hostname=${hostname}&myip=${ipv4}&myip6=${ipv6}"

Das Script holt sich die anfragenden (z.B. NAT) Adresse via DNS, genauer via openDNS. Schneller und sicherer (z.B. bei multihomed Hosts) ist das kaum möglich.

Natürlich gibt es auch jede Menge DDNS-Clients („DUC“ oder „NUC“) die das übernehmen können und mehr oder weniger komfortabel zu handhaben sind.

Im Wesentlichen ist dieser Schnipsel ein „aus der Not geborener“ Einzeiler der nach und nach ein bisschen gewachsen ist. Bisher gibt es keinen Plan, hieraus eine „echte“ Software mit Caching und so weiter zu machen.

Alle Systemvariablen in der PowerShell anzeigen

Veröffentlicht am von — Keine Kommentare ↓

Mein Hand->Stirn*klatsch* Moment des Tages war grade, als ich (nach viel zu viel googlen) realisierte, dass man nicht alle PowerShell Systemvariable auswendig können muss.

Genau wie die Registry, das Filesystem, Zertifikate und so weiter sind auch die (System-)Variablen ($env) ein ganz normales PS „Drive“ und dort aufzulisten und zu nutzen.

Alle Variablen auflisten

In der PS alle Systemvariablen anzeigen:

PS C:\> gci env:*

Oder etwas mehr fancyness:

PS C:\> Gci env:* | Sort-Object name

… und dann kann man die aufgelisteten Variablen verwenden. Beispielweise:

PS C:\> $env:computername

Ein Gruppenrichtlinienobjekt (GPO) auf alle Organisationseinheiten (OUs) mit bestimmtem Namen unterhalb eines DNs anwenden (linken)

Veröffentlicht am von — Keine Kommentare ↓

Problem

Als Windows-Administrator wird man mit Aufgaben konfrontiert, die recht einfach klingen. Bis man sie sehr oft von Hand ausführen muss.

Ein Beispiel aus der Praxis:
„Erstelle eine neue GPO und verlinke diese auf alle OUs, die ‚Würstchen‘ heißen, unterhalb von OU=Speisekarte“.

Oder anders formuliert: Verknüpfe eine Gruppenrichtlinie auf alle 3673409 OUs mit diesem Namen.

Das ist in der Gruppenrichtlinienverwaltung technisch gar kein Problem; sofern die Anzahl übersichtlich ist (und die OUs nicht über mehrere Ebenen verteil sind). Man klickt sich durch die AD-Verwaltungskonsole, öffnet Eigenschaften, fügt die GPO hinzu … und wiederholt das sehr oft.

Lösung

Das kann man glücklicherweise ganz gut mit der PowerShell automatisieren.

Dieser Schnippsel durchsucht mit -like alle OUs unterhalb eines angegebenen DN nach einem bestimmten Begriff und verlinkt automatisch die gewünschte GPO dazu.

$BaseDN = "OU=UNTERSTRUKTUR,DC=EXAMPLE,DC=COM"
$Suchbegriff = "WÜRSTCHEN"
$GPO = Get-Gpo -Name "NEUE_GRUPPENRICHLINIE"

Get-ADOrganizationalUnit -SearchBase $BaseDN -Filter * -SearchScope Subtree |
    Where-Object { $_.Name -like "*$Suchbegriff*" } |
    ForEach-Object {
    New-GPLink -Guid $GPO.id -Target $_.DistinguishedName -LinkEnabled Yes
    }

Mit diesen Zeilen wird aus ermüdender Klickarbeit eine schnelle Aktion.

Microsoft Azure AD Connect Sync Fehler „permission-issue“ mit „Connected data source error code: 5“

Veröffentlicht am von — 2 Kommentare ↓

Wir hatten einen spannenden AADConnect (Entra ID Connect) Fehler zu suchen. Manche Microsoft 365 Gruppen wurden nicht (mehr) korrekt in das lokale AD zurückgeschrieben. Der Fehler lautete, natürlich ohne weitere Details, „Zugriff verweigert“ (permission-issue). Der Hinweis der „Connected data source error code: 5“ ist zwar ein Indiz, aber keine Lösung.

Lösung

Was die Ursache dazu war, ist nicht bekannt. Aber es sind die AD-Berechtigungen für das Synchronisationskonto auf den betroffenen Objekten. In diesem Fall „Generisches Lesen/Schreiben“ von allen Attributen einer Objekttypgruppe (und von deren Unterobjekten).

Auf dem AADConnect-Server in einer PowerShell (als Administrator) ist der Fehler schnell behoben:

# AAD Connect PS-Modul importieren
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

# Sync-Account-Namen besorgen
Get-ADSyncADConnectorAccount
# (den "ADConnectorAccountName" kopieren)

# Berechtigungen schreiben
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName "<ADConnectorAccountName>" -ADConnectorAccountDomain EXAMPLE.LOCAL

Beispiel:

Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountName "MSOL_1111aaaa1111" -ADConnectorAccountDomain mydomain.local

FSLogix automatisch aktualisieren (FSLogix autp Update) [UPDATE]

Veröffentlicht am von — Keine Kommentare ↓

Update: Im FSLogix-Paket haben sich Pfade geändert, die unnötige Fehlermeldung zu Beginn ist entfernt und die Pfade sind angepasst.

Leider ist FSLogix nicht in Windows-Update(s) enthalten. Der Admin einer RDS-Farm muss also selbstständig für seine Updates sorgen.

Da es aber in der Tat häufiger mal Updates für FSLogix gibt (Siehe Hotfix-Liste), die beispielsweise Fehler mit der Microsoft Office 365 Aktivierung beheben, lohnt es sich diese auch wirklich zu installieren. Man kann das Setup in derselben Version auch mehrfach ausführen, es wird nur installiert, wenn wirklich etwas Neues dabei ist.

Der Vorgang ist prinzipiell einfach: Neue Version herunterladen, ZIP-Datei auspacken, App-Installer ausführen und Server neu starten. Wäre das nicht toll, wenn das auch automatisch geht?

Lösung

Bei dem letzten Einsatz, der das Problem „Leeres Microsoft 365 Anmeldefenster“ behebt, ist ein PowerShell Script das selbiges tut entstanden. Einsatz auf eigene Gefahr ☺️

# Update FSLogix to "latest"
# [email protected]
#
# Achtung: BOOTET bei Erfolg den Server neu, ohne Rueckfrage!

# Aktuelle FSLogix-Version liegt hier
$FslogixUrl= "https://aka.ms/fslogix_download"

# Download landet hier
if ( Test-Path "C:\Windows\Temp\fslogix\install" ) { Remove-Item "C:\Windows\Temp\fslogix\install" -Force -Recurse }
mkdir "C:\Windows\Temp\fslogix\install" -Force | Out-Null
Write-Host "Download von" $FslogixUrl "... (180Mbyte)"
# Ausblenden der ProgressBar macht den Download 5x schneller
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri $FslogixUrl -OutFile "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -UseBasicParsing

# Auspacken
Write-Host "Auspacken von C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip ..."
Expand-Archive -LiteralPath "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -DestinationPath "C:\Windows\Temp\fslogix\install" -Force -Verbose
Set-Location "C:\Windows\Temp\fslogix\install\x64\release"

# Installieren + Neustart
Start-Process "FSLogixAppsSetup.exe" -ArgumentList "/install /quiet" -Wait -Passthru