Azure AD Connect: Powershell-Befehle zur Einrichtung

Bei weiteren Azure AD Connect Einrichtungen stiess ich auf folgende, nützliche Befehle:

Export aller aktuellen UPN Anmeldenamen, und Proxy-Adressen:

Get-ADUser -Filter {Enabled -eq $true} -SearchBase "OU=Users,DC=DOMAIN,DC=local" -Properties * | Where {$_.proxyAddresses} | select SAMAccountname,UserPrincipalName, @{L='ProxyAddress_1'; E={$_.proxyaddresses[0]}},@{L='ProxyAddress_2';E={$_.ProxyAddresses[1]}},@{L='ProxyAddress_3';E={$_.ProxyAddresses[2]}},@{L='ProxyAddress_4';E={$_.ProxyAddresses[3]}},@{L='ProxyAddress_5';E={$_.ProxyAddresses[4]}},@{L='ProxyAddress_6';E={$_.ProxyAddresses[5]}} | export-csv C:\Temp\ExportV1.csv

 

Anpassen sämtlicher UPN Anmeldenamen:

Import-Module ActiveDirectory
$oldSuffix = "DOMAIN.local"
$newSuffix = "URI.ch"
$ou = "OU=Users,DC=DOMAIN,DC=local"
$server = "SERVER"
Get-ADUser -SearchBase $ou -filter * | ForEach-Object {
$newUpn = $_.UserPrincipalName.Replace($oldSuffix,$newSuffix)
$_ | Set-ADUser -server $server -UserPrincipalName $newUpn
}

 

Advertisements

PowerShell: Erstelle Verzeichnisse pro Benutzer aus AD, und setze Berechtigungen

Obige Anforderung wurde an mich gestellt. Wie immer „quick and dirty“.

Das Script basiert auf den Modulen „NTFSSecurity“ (File System Security PowerShell Module), danke schonmal dafür.

Beschrieben ist das ganze gut auf der Technet-Gallery Seite, und hier.

Das Module habe ich unter C:\Program Files\WindowsPowerShell\Modules „installiert“ (simples Filecopy). Danach kann das Modul via

Import-Module NTFSSecurity

importiert werden.

Mein Script sieht wie folgt aus:

# Create Folders based on a AD OU
# Scripted by M. Wildi, IN4OUT it solutions ag, 5000 Aarau
# v 1.0 16.08.2017
# ###########################################################################
# Import Module
# Module from https://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85
Import-Module NTFSSecurity

# set Variables
$CustClass = "DT2017"
$CustRootDir = "\\FILESERVER\Share\share\root\"
$CustDir = $CustRootDir + $CustClass
# Create Base Dirs
md $CustDir
md $CustDir\_Public

# Set Permissions
Get-Item $CustDir | Disable-NTFSAccessInheritance
Get-NTFSAccess $CustDir | Where-Object {$_.Account -like "DOMAIN\GROUP"} | Remove-NTFSAccess
Get-Item $CustDir | Add-NTFSAccess -Account "DOMAIN\$CustClass" -AccessRights ReadAndExecute -AppliesTo ThisFolderSubfoldersAndFiles

Get-Item $CustDir\_Public| Disable-NTFSAccessInheritance
Get-NTFSAccess $CustDir\_Public| Where-Object {$_.Account -like "DOMAIN\GROUP"} | Remove-NTFSAccess
Get-Item $CustDir\_Public| Add-NTFSAccess -Account "DOMAIN\$CustClass" -AccessRights FullControl -AppliesTo ThisFolderSubfoldersAndFiles
Get-Item $CustDir\_Public| Add-NTFSAccess -Account "DOMAIN\GROUP2" -AccessRights FullControl -AppliesTo ThisFolderSubfoldersAndFiles

Get-ADUser -Filter * -SearchBase "OU=$CustCLass,OU=OU1,OU=Users,OU=CUSTOMER,DC=CUSTOMER,DC=intern" -Properties * | 
ForEach-Object {
md $CustDir\$($_.SamAccountName)
Get-Item $CustDir\$($_.SamAccountName) | Disable-NTFSAccessInheritance
Get-NTFSAccess $CustDir\$($_.SamAccountName) | Where-Object {$_.Account -like "DOMAIN\$CustClass"} | Remove-NTFSAccess
Get-Item $CustDir\$($_.SamAccountName) | Add-NTFSAccess -Account "DOMAIN\$($_.SamAccountName)" -AccessRights FullControl -AppliesTo ThisFolderSubfoldersAndFiles
Get-Item $CustDir\$($_.SamAccountName) | Add-NTFSAccess -Account "DOMAIN\GROUP2" -AccessRights FullControl -AppliesTo ThisFolderSubfoldersAndFiles
}

Einrichten und erste Schritte mit Azure AD Connect

Installation gemäss dieser Anleitung.

Update 07.02.2018: Achtung Warnung: in einem Falle startete sich der Server nach dem Setup neu!

Update 21.03.2018: Während dem Setup muss für unser normales Setup (Single Sign On), „Passthrough-Authentifizierung“ und „Einmaliges Anmelden aktivieren“ aktiviert sein.

Ich habe für meine (spezielle) Umgebung die Option „Custom Setting“ gewählt. Ich hatte zwei AD Domänen, welche aber von einem Server aus abgefragt werden konnten.

Dazu habe ich im O365 einen Benutzer „svc_ADConnect_KUNDE“ erstellt, welcher die Rolle „Globaler Administrator“ besitzt.

In beiden AD’s habe ich je einen Benutzer „svc_AzureADConnect“ erstellt, welcher jeweils Organisations- und Domänenadministrator ist.

Ich musste unsere „non-routable Domains“ beide jeweils mit dem öffentlichen Domainnamen erweitern/ersetzen. Dies ist hier beschrieben.

Ich musste das AD zuerst bereinigen, da die Benutzer teils falsche, teils gar keine Attribute gesetzt hatten:

Get-ADUser -Filter * -SearchBase "OU=OU1,DC=DOMAIN,DC=intern" -Properties * |
ForEach-Object {
 Set-ADUser -Identity $_ -DisplayName ("$($_.Surname) $($_.GivenName)")
}

Get-ADUser -Filter * -SearchBase "OU=OU1,DC=DOMAIN,DC=intern" -Properties * |
ForEach-Object {
 Rename-ADObject -Identity $_ -NewName ("$($_.Surname) $($_.GivenName)")
}

Get-ADUser -Filter * -SearchBase "OU=OU1,DC=DOMAIN,DC=intern" -Properties * |
ForEach-Object {
 Set-ADUser -Identity $_ -UserPrincipalName ("$($_.GivenName).$($_.Surname)@domain.ch")
}

Get-ADUser -Filter * -SearchBase "OU=OU1,DC=DOMAIN,DC=intern" -Properties * |
ForEach-Object {
 Set-ADUser -Identity $_ -SamAccountName ("$($_.GivenName).$($_.Surname)")
}

Mit folgendem Befehl kann die AD Sync forciert werden:

Start-ADSyncSyncCycle -PolicyType Initial

Ergänzung 9. August 2017:

Bei den weiteren Tests stellte sich heraus, dass die Benutzer aus O365 mit der „onmicrosoft.com“-Adresse Mails versenden (also diese als primäre Adresse hinterlegt haben). Dies kann nicht in O365/Azure geändert werden, sondern muss im on-premise AD ergänzt werden:

Get-ADUser -Filter * -SearchBase "OU=OU1,DC=DOMAIN,DC=intern" -Properties * |
ForEach-Object {
 Set-ADUser -Identity $_ -Add @{'ProxyAddresses'=@("SMTP:$($_.GivenName).$($_.Surname)@DOMAIN.ch","smtp:$($_.GivenName).$($_.Surname)@DOMAINCH.onmicrosoft.com")}
}

Siehe auch Artikel: Office 365 Azure AD Sync

Remote Desktop Server: Finde Benutzer zu RD Profile Disk SiD

Wenn mal eine RD Profile Disk ausfindig gemacht werden muss:

Hier gibts ein gutes Script dazu. Einfach das Script, gefolgt vom (UNC) Pfad der RD Profile Disks ausführen, und schon spuckt es einem die AD Benutzer mit zugehöriger SiD aus.

Das ganze basiert auf folgendem Befehl:

$securityidentifier.translate( [security.principal.ntaccount]

Get-WindowsUpdateLog unter Windows 10 schlägt fehl (SymSrv.dll)

Wenn ihr unter Windows 10 die Windows Update Komponenten troubleshooten wollt, hilft euch das (unter Windows 7 bis 8.1 sehr hilfreiche) C:\Windows\WindowsUpdate.log nicht weiter:

Get-WUL02

Also schnell die PowerShell Console gestartet, und

Get-WindowsUpdateLog

eingegeben.

Äääätsch: geht nicht:

Get-WUL01

Copy-Item : Der Pfad "C:\Program Files (x86)\Windows Defender\SymSrv.dll" kann nicht gefunden werden, da er nicht
vorhanden ist.
In C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:56 Zeichen:5
+ Copy-Item -Path $SYMSRV_DLL_PATH -Destination $WORKDIR -Force -Er ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : ObjectNotFound: (C:\Program File...nder\SymSrv.dll:String) [Copy-Item], ItemNotFoundExce
 ption
 + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyItemCommand

Kurze Recherche, mit vielen abenteuerlichen Anleitungen, dies zu „beheben“… führte dann zur (einfachen, simplen und ebenso doofen Lösung): Bitte PowerShell Console nicht im x86-Modus, sondern im 64-Bit Modus starten!