– Jan's Cloud – online Gedankenstütze ;)

8. Juli 2018

Auf Active Directory Start in Hyper-V VM warten

Filed under: Hyper-V,PowerShell,Windows Server — Schlagwörter: , , , , — Jan Mischo @ 11:10

Den vollständigen Start des Active Directory in einer Hyper-V VM abwarten

Das gestern vorgestellt Script „RebootAndWaitForServer“ wartet nur „stumpf“ bis die Hyper-V VM gebootet ist und der Prozess „winlogon.exe“ sowie der Dienst „LSM“ läuft. Stellt man jetzt eine Umgebung auf der grünen Wiese bzw. einen PoC oder eine Demoumgebung bereit, benötigt man unter Umständen einen Domänen Controller. Ein DC sollte nicht nur automatisch ausgerollt, sondern auch noch entsprechend konfiguriert werden. Die Konfiguration ist allerdings, logischerweise, erst möglich wenn die Active Directory Dienste gestartet und betriebsbereit sind. Auch hier gab es auf GitHub (WaitFor-ActiveDirectory) bereits eine Funktion, die in verschiedenen Tests nicht zuverlässig lief. In prduktiven Umgebungen sollte es diese Problem natürlich gar nicht erst, da immer mindestens zwei Domain Controller betrieben werden sollten, von denen einer immer erreichbar ist.

Das folgende Script liest die Uptime der Hyper-V VM aus, zieht diese vom aktuellen Datum ab und durchsucht dann die Ereignisanzeige „Active Directory Web Services“ in der VM auf die Instanz-Id „1073743024“.

WaitForAD

WaitForAD

WaitForAD PowerShell

WaitForAD PowerShell

<# WaitForAD
Beispiel für die Variablen:
    [string]$VMName = "SERVER-VM01"
    [System.Management.Automation.PSCredential] $tempCred = new-object -typename System.Management.Automation.PSCredential ("Domain\Admin", (ConvertTo-SecureString P@ssw0rd! -AsPlainText -Force))

Oder ggfs. die Variablen abfragen:
    $VMName = Read-Host "Bitte den Namen des virtuellen Computers eingeben"
    $tempCred = Get-Credential
#>

function WaitForAD {
    param (
        [Parameter(Mandatory=$true)]
        [String]
        $VMName,

        [Parameter(Mandatory=$true)]
        [System.Management.Automation.PSCredential]
        $Credentials

    )
    $VM = Get-VM -Name $VMName
    $Uptime = $VM.Uptime.TotalSeconds
    $Date = $(Get-Date).AddSeconds(-($Uptime))
    Write-Host "[$($VMName)]:: Auf Active Directory warten" -ForegroundColor Yellow -NoNewline
    Invoke-Command -VMName $VMName -Credential $Credentials -ArgumentList $Date -ScriptBlock {
        param($Date)
        do {
            do {
                Write-Host "." -ForegroundColor Yellow -NoNewline
                Start-Sleep -Seconds 5
                $AD = get-service ADWS, DNS, KDC, NETLOGON, NTDS
            } until ($AD[0].Status -eq "running" -and $AD[1].Status -eq "running" -and $AD[2].Status -eq "running" -and $AD[3].Status -eq "running" -and $AD[4].Status -eq "running")
            Write-Host "." -ForegroundColor Yellow -NoNewline
            Start-Sleep -Seconds 5
            $Event = Get-EventLog -LogName "Active Directory Web Services" -Source ADWS -After $Date -InstanceId 1073743024 -Newest 1
        } until ($Event.Message -match "Die angegebene Verzeichnisinstanz wird nun von Active Directory-Webdiensten bedient" -or $Event.Message -match "Active Directory Web Services is now servicing the specified directory instance")
    }
    Write-Host " -> Ok!" -ForegroundColor Yellow
}

[string]$VMName = "SERVER-VM01"
[System.Management.Automation.PSCredential] $tempCred = new-object -typename System.Management.Automation.PSCredential ("Domain\Administrator", (ConvertTo-SecureString P@ssw0rd! -AsPlainText -Force))

WaitForAD $VMName $tempCred

Link zum Download: WaitForAD

Aint nobody got time for dat

Aint nobody got time for dat

17. August 2017

Get-ADPrincipalGroupMembership Fehler bei Gruppen mit Slash

Fehler beim Auslesen von Gruppenmitgliedschaften mit Get-ADPrincipalGroupMembership bei Gruppen mit „/“ (Slash) im Namen

Bei der Erstellung eines PowerShell Scriptes welches basierend auf Gruppenmitgliedschaften verschiedene Exchange-Eigentschaften der User setzen sollte ergab sich ein Problem mit dem CMDLet Get-ADPrincipalGroupMembership:

Get-ADPrincipalGroupMembership Fehler

Get-ADPrincipalGroupMembership Fehler

 

 

 

 

 

Get-ADPrincipalGroupMembership: Der Client konnte die Anforderung aufgrund ein es internen Fehler nicht verarbeiten. Wenn Sie weitere Informationen zum Fehler erhalten möchten, aktivieren Sie entweder IncludeExceptionDetailInFaults (entweder über das ServiceBehaviorAttribute oder das <serviceDebug>-Konfigurationsverhalten) für den Client, um die Ausnahmeinformationen zurück an den Server zu senden, oder aktivieren Sie die Ablaufverfolgung gemäß der Microsoft .NET Framework 3.0 SDK-Dokumentation, und prüfen Sie die Serverablaufverfolgungsprotokolle.
Bei xxxxx Zeichen:41
+ if ( (Get-ADPrincipalGroupMembership <<<< $User.DistinguishedName) xxxxx ) {
+ CategoryInfo: NotSpecified: (CN=xxxxx\,…xxxxx,DC=xxxxx :ADPrincipal) [Get-ADPrincipalGroupMembership], ADException
+ FullyQualifiedErrorId: Der Client konnte die Anforderung aufgrund eines internen Fehler nicht verarbeiten. Wenn Sie weitere Informationen zum Fehler erhalten möchten, aktivieren Sie entweder IncludeExceptionDetailInFaults (entweder über das ServiceBehaviorAttribute oder das <serviceDebug>-Konfigurationsverhalten) für den Client, um die Ausnahmeinformationen zurück an den Server zu senden, oder aktivieren Sie die Ablaufverfolgung gemäß der Microsoft .NET Framework 3.0 SDK-Dokumentation, und prüfen Sie die Serverablaufverfolgungsprotokolle.,Microsoft.ActiveDirectory.Management.Commands.GetADPrincipalGroupMembership

Dieser Fehler tritt scheinbar auf, sobald der User Mitglied einer Gruppe mit einem „/“ ist. In diesem Fall hieß die Gruppe „02 Lohn / FiBu“. Nach der Umbenennung der Gruppe in „02 Lohn FiBu“ ließ sich das PowerShell Script mit CMDLet Get-ADPrincipalGroupMembership problemlos ausführen.

 

29. Mai 2015

Logfiles (z.B. IIS, SMTPSend oder SMTPReceive) älter als X Tage per Script löschen

Filed under: Citrix,Exchange,IIS,Storefront,Windows Server — Schlagwörter: , , , , , , — Jan Mischo @ 07:51

Da es bei einigen Kunden, insbesondere auf den Exchange Servern, immer mal wieder zu Speicherproblemen kam und die Kunden sich renitent gegen ein Monitoring zur Wehr setzen, habe ich kurzherhand ein kleines Script geschrieben, welches die Logs älter 14 Tage löscht.

ACHTUNG: Mit diesem Script auf keinen Fall die Transaktionsprotokolle „aufräumen“! Sollte das Volume mit der Exchange Datenbank vollgelaufen sein hilft nur ein Backup der Exchange Datenbank mit einem entsprechenden Backup Programm (z.B. Windows Server Sicherung) oder ein kurzes aktiveren der Umlaufprotokolierung. Auf lange Sicht bleibt allerdings nur der Einsatz einer kompatiblen Exchange Backup Software!

ForFiles Speicherbelegung vorher

ForFiles Speicherbelegung vorher

 

 

 

 

 

 

 

 

 

FORFILES /P "C:\inetpub\logs\LogFiles\W3SVC1" /S /M *.* /D -14 /C "CMD /C del /Q @FILE"
FORFILES /P "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive" /S /M *.* /D -14 /C "CMD /C del /Q @FILE"
FORFILES /P "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpSend" /S /M *.* /D -14 /C "CMD /C del /Q @FILE"

Der Parameter /D -14 legt die Anzahl an Tagen fest.
ForFiles im Technet: https://technet.microsoft.com/de-de/library/cc753551%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

ForFiles wird ausgeführt

ForFiles wird ausgeführt

 

 

 

Das Ergebnis:

ForFiles Ergebnis

ForFiles Ergebnis

 

 

 

 

 

 

 

 

Das Script jetzt als Aufgabe planen und täglich / wöchentlich oder monatlich ausführen lassen und die Logs räumen sich automatisch auf.

Powered by WordPress