Last Login von AD Computers finden

Mit folgendem einfachen Befehl kann die letzte Anmeldezeit von AD-Computern angezeigt werden:

 Get-ADComputer -Filter * -Properties * | Sort LastLogonDate | FT Name, LastLogonDate -Autosize
Advertisements

Namespace „Microsoft.Policies.WindowsStore“ ist bereits als Ziel für eine andere Datei im Speicher definiert

Das Problem tritt auf, wenn die GPO-Definitionen (siehe Group Policy Definitions) aktualisiert werden, und zuvor alte Files vorhanden waren.

Das Problem ist, dass Microsoft Dateinamen angepasst hat, und der GPO Editor nun mehrere Dateien für dieselben Einstellungen vorfindet.

Die Lösung ist entsprechend einfach: die alte Datei „winstoreui.admx“ in den PolicyDefinitions löschen.

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
}

 

Group Policy Definitions

Mit den Group Policy Definitions gibt Microsoft ja zu einem neuem Betriebssystem jeweils die aktuell gültigen Definitionen mit. Nachdem ein Kollege von mir diese Definitionen bei einem Kunden vom Stand „Windows 10 1607“ auf „Windows 10 1709“ aktualisierte, erhielten wir im GPO Editor folgende Fehlermeldung:

GPO

Richtlinienpräsentationsemelement "CSE_NOBACKGROUND" ... Präsentation "CSE_Drives" ... nicht vorhanden.

Das Problem: Microsoft hat gepatzt! In den „Administrative Templates“ für Windows 10 1703 und Windows 10 1709 fehlt (mindestens) das File „GroupPolicyPreferences.adml“ im Unterordner der entsprechenden Sprache. Nun gibt es zwei Szenarien:

  1. Die Version 1703 oder 1709 wurde als erste Version installiert
  2. Die Version 1703 und / oder 1709 aktualisierte eine bestehende Version

In erstem Szenario muss die Datei zuerst aus einer älteren Version kopiert werden (Links siehe am Ende des Artikels). Anschliessend muss diese noch angepasst werden (siehe Szenario zwei).

Im zweiten Szenario muss die Datei GroupPolicyPreferences.adml im Unterordner der entsprechenden Sprache, angepasst werden:

In Zeile 950 folgende Zeile einfügen (Deutsch):

<checkBox refId="CSE_NOBACKGROUND">Während regelmäßiger Hintergrundverarbeitung nicht übernehmen</checkBox>

GPO2

Original Englisch (Zeile 945):

 <checkBox refId="CSE_NOBACKGROUND">Do not apply during periodic background processing</checkBox>GPO3

Administrative Templates (.admx) for Windows 10 (1607) and Windows Server 2016

Administrative Templates (.admx) for Windows 10 Creators Update (1703)

Administrative Templates (.admx) for Windows 10 Fall Creators Update (1709)

Installation Azure AD Connect schlägt fehl

Eine frische Installation des Azure AD Connect Clients schlägt mit dem Fehler „Synchronization Service kann nicht installiert werden“ fehl.

Im Anwendungs-Eventlog ID 906

 "Error installing msi package 'Synchronization Service.msi'.
Full log is available at 'C:\ProgramData\AADConnect\Synchronization Service_Install-DATE-TIME.log'
. Extracted error message: ActionStart(Name=ProcessMachineDcomPermission,,)

Folgende Schritte (danke flyppdevportal.com) verhalfen zur Lösung:

  1. Login to the server
  2. Go into Component Services > Computers > My Computer
  3. Right click and select Properties.
  4. Click on COM Security tab.
  5. Under Access Permissions, select Edit Limits, don’t make any change, click OK to close.
  6. Under Launch and Activation Permissions, select Edit Limits, don’t make any change, click OK to close.
  7. Under Launch and Activation Permissions, select Edit Defaults, don’t make any change, click OK to close.
  8. Then click OK to close My Computer Properties.

Danach konnte der Wizard erfolgreich abgeschlossen werden.

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.

Edit: Im Laufe der Zeit stellte sich diese Namensgebung als nicht ideal dar. Ich habe mich deshalb für folgende neue Namensgebung entschieden (AADC = AzureADConnect):
Lokaler AD-Benutzer: „svc_AADC_local_KUNDE@DOMAIN.TLD“
O365 Benutzer: „svc_AADC_O365_KUNDE@DOMAIN.TLD“

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