AzureMfaNpsExtnConfigSetup.ps1 kommt nicht mit deutschen Systemen klar

Wenn ich das Script ausführe, erhalte ich folgende Fehlermeldung:

Ausnahme beim Aufrufen von "SetAccessRule" mit 1 Argument(en): "Manche oder alle Identitätsverweise konnten nicht
übersetzt werden."
In C:\Program Files\Microsoft\AzureMfa\Config\AzureMfaNpsExtnConfigSetup.ps1:92 Zeichen:2 
$acl.SetAccessRule($buildAcl) #Add Access Rule
 ~~~~~~~~~
 CategoryInfo : NotSpecified: (:) [], MethodInvocationException
 FullyQualifiedErrorId : IdentityNotMappedException 

Nach der Analyse des Scripts, hat Microsoft hier mal wieder bei den Sprachen gepatzt. Die original Zeile:

Dies musste ich auf folgendes anpassen:

Der Benutzer „NETWORK SERVICE“ hat die SID „S-1-5-20“. Damit konnte ich den korrekten Namen auf dem deutschen System idenfizieren.

PowerShell: NuGet kann nicht installiert werden

Ich musste bei einem Kunden NPS f. MFA über Azure aktivieren. Dazu muss ein Script der „NPS Extension for Azure MFA“ ausgeführt werden:

.\AzureMfaNpsExtnConfigSetup.ps1

Dieses Script brach aber in meinem Fall ab:

AUSFÜHRLICH: Der NuGet-Anbieter wird installiert.
AUSFÜHRLICH: Der Anbieter "Bootstrap" wird für die Paketsuche verwendet.
AUSFÜHRLICH: Finding the package 'Bootstrap::FindPackage' 'NuGet','','2.8.5.201','''.
WARNUNG: Es kann kein Download von URI "https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409" nach ""
durchgeführt werden.
AUSFÜHRLICH: Cannot download link 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409', retrying for '2' more
times.
AUSFÜHRLICH: Cannot download link 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409', retrying for '1' more
times.
AUSFÜHRLICH: Cannot download link 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409', retrying for '0' more
times.
WARNUNG: Die Liste der verfügbaren Anbieter kann nicht heruntergeladen werden. Überprüfen Sie Ihre Internetverbindung.
PackageManagement\Install-PackageProvider : Für die angegebenen Suchkriterien für Anbieter "NuGet" wurde keine
Übereinstimmung gefunden. Der Paketanbieter erfordert das PackageManagement- und Provider-Tag. Überprüfen Sie, ob das
angegebene Paket über die Tags verfügt.
In C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7405 Zeichen:21
 …     $null = PackageManagement\Install-PackageProvider -Name $script:N …
 ~~~~~~~~~~~~~ CategoryInfo          : InvalidArgument: (Microsoft.Power…PackageProvider:InstallPackageProvider) [Install-Pac
 kageProvider], Exception
 FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro
 vider

Eine kurze Recherche brachte folgendes Problem zutage:

Powershell verwendet verschiedene Protokolle. Welche verwendet werden dürfen, kann konfiguriert werden. Mit dem folgenden Befehl kann die aktuelle Einstellung abgefragt werden:

[Net.ServicePointManager]::SecurityProtocol

Bei mir war der Output folgender:

Ssl3, Tls

Für die Installation, bzw. die Verbindung zum Repository wird aber TLS 1.2 benötigt. Dies kann wie folgt :

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::TLS12

Der Befehl kann auch wie folgt lauten:

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::TLS12

Das Ergebnis ist dasselbe.

Diese Einstellung gilt aber nur für die aktuelle Session. Sobald PowerShell neu gestartet wird, gilt wieder die alte Einstellung.

Dies könnte über folgende Registry Keys angepasst werden:

.NET 4.x
Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord
Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v4.0.30319’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord

.NET 3.5
Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft.NetFramework\v2.0.50727’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord
Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v2.0.50727’ -Name ‘SchUseStrongCrypto’ -Value ‘1’ -Type DWord

Ich habe dies aber nicht ausgeführt.

Supportqualität von Microsoft M365

Ich habe in letzter Zeit (zu) oft Kontakt mit dem MS Support bezüglich M365 (Exchange Online, Office Apps,…). Leider lässt die Qualität des Supports sehr zu wünschen übrig. Ich erhalte zwar Support in relativ gutem Deutsch, aber schlechtes Englisch und dafür bessere Qualität wäre mir lieber…

Oft werden falsche / nicht passende PowerShell-Befehle zugestellt, oder die Supporter sind auf einen Anruf (durch sie initiiert) schlecht/gar nicht vorbereitet, was lange Wartezeiten verursacht.

Stellvertretend dafür ein Screenshot aus einem der vielen Support-Datenzusammensuch-tool, welches MS verwendet:

Fehler beim erstellen einer Usermailbox für einen bestehenden User

Wir hatten einen Kunden, welcher nachträglich einen Exchange-Server erhielt. Ich installierte Exchange 2019 in die Domäne, und erstellte während dem Setup eine neue Exchange Organisation.

Als ich nun für die bestehenden AD-Benutzer Mailboxen erstellen wollte, erhielt ich folgenden Fehler:

Fehler bei Active Directory-Vorgang mit SERVER.DOMAIN.local. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Insufficient access rights to perform the operation. Active Directory-Antwort: 00002098: SecErr: DSID-03150F94, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Ich vermutete bereits ein Problem mit den Berechtigungen auf den bestehenden Benutzern. Und siehe da, die Benutzer hatten die Berechtigungsgruppe „Exchange Trusted Subsystem“ nicht hinterlegt:

sorry für die schlechten Screenshots – ich wünschte, Microsoft würde die Fenster endlich grösser machen…

Also habe ich die Berechtigungen auf der OU der betroffenen Benutzer hinzugefügt, und vererben lassen:

  • Eigenschaften der betroffenen OU
  • Security > Advanced
  • Add
  • Principal = Exchange trusted subsystem > OK
  • Applies to = „This object and all descendant’s objects“
  • Unter „Permissions“, „Modify permissions“ aktivieren
  • OK

Die Benutzer erhielten die Berechtigung aber weiterhin nicht. Auf den Benutzerobjekten war die Vererbung nicht aktiv:

Das wollte ich natürlich nicht für alle Benutzer einzeln aktivieren. Hier kommt PowerShell zur Hilfe:

Mit folgendem Befehl kann der aktuelle Status ausgelesen werden (achtung: quick&dirty):

$AdUsers = Get-ADUser -SearchBase "OU=Users,OU=OU1,DC=domain,DC=local" -Filter * -Properties ntsecuritydescriptor,admincount
foreach ($Aduser in $AdUsers)
{
$AdUserName = $AdUser.Name
$AdUserRule = $AdUser | select -expand ntsecuritydescriptor | select areaccessrulesprotected
$AdUserAdminCount = $AdUser.AdminCount
Write-Host $AdUserName
Write-Host $AdUserRule
Write-Host $AdUserAdminCount
}

True = Vererbung deaktiviert
False = Vererbung aktiviert
AdminCount = muss zuerst gelöscht werden. Details folgen in einem späteren Post.

AdminCount löschen:

$AdUsers = Get-ADUser -SearchBase "OU=Users,OU=OU1,DC=domain,DC=local" -Filter *
foreach ($AdUser in $AdUsers)
{
set-aduser $AdUser -remove @{adminCount=1}
}

SecurityDescriptor auf „False“ setzen:

$AdUsers = Get-ADUser -SearchBase "OU=Users,OU=OU1,DC=domain,DC=local" -Filter * -Properties ntsecuritydescriptor
foreach ($AdUser in $AdUsers)
{
$user = get-aduser $AdUser -properties ntsecuritydescriptor
$user.ntsecuritydescriptor.SetAccessRuleProtection($false,$true)
set-aduser $AdUser -replace @{ntsecuritydescriptor=$user.ntsecuritydescriptor}
}

Exchange 2019 Deinstallation: System.ComponentModel.Win32Exception: Zugriff verweigert

Ich musste einen Exchange 2019 deinstallieren, dabei trat folgender Fehler auf:

Der folgende Fehler wurde generiert, als "$error.Clear();
$regPath='HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall';
$PackageGUIDRegEx = "{9BBCB5[0-9a-fA-F]{2}-AAC3-4BF5-[0-9a-fA-F]{4}-A4D51A19BF14}";
$InstallPath = (Get-ItemProperty
'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\setup').MsiInstallPath;
if(test-path ($regPath))
{
Write-ExchangeSetupLog -info ("Removing " + $RoleLanguagePackType + " Language Packs.");
Get-ChildItem ($regPath) | foreach{
if($_ -match
"(?$PackageGUIDRegEx)") {
$langPackPackageCode = $matches['ProductCode'];
if($langPackPackageCode -ne $null -and $langPackPackageCode.Length -ne 0) {
Write-ExchangeSetupLog -info ("Removing package $langPackPackageCode");
$language =
$langPackPackageCode.Substring(20,4);
$logFilePath = [IO.Path]::Combine($RoleLogFilePath,"Uninstall") + '.' + $language + '.' + "OwaPlus" + "." + $RoleLogDateTime + ".msilog";
uninstall-MsiPackage -ProductCode ($langPackPackageCode) -LogFile ($logFilePath);
};
};
};
Get-Childitem -Path $InstallPath -include ".Localized.js",".Localized.min.js" -recurse | foreach ($_) {remove-item $_.fullname};
Write-ExchangeSetupLog -info "Remove Language Packs completed.";
};
" ausgeführt wurde: "System.UnauthorizedAccessException:
Zugriff verweigert ---> System.ComponentModel.Win32Exception: Zugriff verweigert
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Management.Automation.Utils.NativeDirectoryExists(String path)
bei
System.Management.Automation.SessionStateInternal.IsItemContainer(CmdletProvider providerInstance, String path, CmdletProviderContext context)".
The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the :\ExchangeSetupLogs folder.

Ich verbrachte einige Stunden mit der Problemsuche, fand aber keine Lösung.

Ein paar Tage später führten wir Wartung an diesem Server durch, installierten die aktuellsten Microsoft Updates und starteten den Server neu. Danach konnte die Deinstallation erfolgreich abgeschlossen werden:

Ok – erledigt 🙂

Autodiscover-Verhalten von Outlook beeinflussen

Das gehört hier eigentlich schon lange rein. Denn der MS-Artikel https://docs.microsoft.com/en-us/outlook/troubleshoot/domain-management/unexpected-autodiscover-behavior ist in dieser Hinsicht unklar und unübersichtlich.

Hier eine Übersicht.

Die Einstellungen sind hier zu machen:

HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover

16.0 = Outlook 2016/2019/365
15.0 = Outlook 2013
14.0 = Outlook 2010
12.0 = Outlook 2007

Mögliche Einstellungen sind:

PreferLocalXML
ExcludeHttpRedirect
ExcludeHttpsAutoDiscoverDomain
ExcludeHttpsRootDomain
ExcludeScpLookup
ExcludeSrvRecord
ExcludeLastKnownGoodURL (*)
ExcludeExplicitO365Endpoint (**)
(*) only applies to Outlook 2010 version 14.0.7140.5001 and later versions
(**) only applies to Outlook 2016 version 16.0.6741.2017 and later versions

Es muss ein DWORD Key mit dem Wert 1 (= entsprechende(r) Einstellung/Ausschluss ist aktiv)

Ggf. muss dies auch in diesem Pfad hinterlegt werden:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\x.0\Outlook\AutoDiscover

Hintergrund-Info:

Outlook benutzt folgende Methoden um sich zu konfigurieren, in dieser Abfolge:

  • SCP lookup
  • HTTPS root domain query
  • HTTPS Autodiscover domain query
  • Local XML file
  • HTTP redirect method
  • SRV record query
  • Cached URL in the Outlook profile (new for Outlook 2010 version 14.0.7140.5001 and later versions)
  • Direct Connect to Office 365 (new for Outlook 2016 version 16.0.6741.2017 and later versions)

OneNote: geöffnete Notizbücher auf mehrere Clients syncen

Ich benutze OneNote beruflich wie privat sehr intensiv. Beruflich liegen die Files in unserer private cloud. Wir verwenden ein Notizbuch pro Kunde.

In Zeiten des HomeOffice benötige ich den Zugriff auf diese Notizbücher von mehreren PC’s (und RD Servern) aus. Darum habe ich mich gefragt, ob sich diese Liste eventuell synchronisieren liesse.

Nunja, synchronisieren ist übertrieben. Aber mit folgenden Schritten können die Einträge von einem Client auf einen anderen übertragen werden:

reg export "HKCU\SOFTWARE\Microsoft\Office\16.0\OneNote\OpenNotebooks" D:\Temp\OneNoteRegEx.reg

Mit folgendem Befehlt kann die Datei dann wieder importiert werden:

reg import D:\Temp\OneNoteRegEx.reg

Cool.

Powershell personalisieren

Immer wenn ich wieder auf einen neuen Client oder Server verbinde, muss ich mir Powershell einrichten. Hiermit dokumentiere ich meine Vorgehensweise:

Powershell starten, dann oben links auf das Symbol und „Standardwerte“ (oder englisch „Defaults“).

Folgende Einstellungen passe ich an:

Register „Options“
Buffer Size = 999
Quick Edit = Aktiv

Register „Layout“
Screen Buffer Size; Width = 150; Height = 9001

Register „Colors“
Screen Background > Opacity = 70
(sieht cool aus 😉 )

Powershell schliessen und wieder starten.

Outlook 2019 / 365: „Cannot expand the folder“

Gewisse Outlook Clients meldeten beim öffnen von freigegeben Postfächern folgende Meldung:

Cannot expand the folder. The set of folders cannot be opened. You do not have permissions to log on.

Ich prüfte die Berechtigungen, doch die waren korrekt. Nach einiger Suche habe ich festgestellt, dass Outlook dieses Postfach in Exchange Online (outlook.office365.com) sucht!

Wir haben dieses Verhalten bereits bei Outlook-Clients, welche auf unsere HEX-Umgebung zugreifen müssen, festgestellt. Aber hier handelt es sich um einen Kunden, welcher nur onPrem hat. Microsoft scheint hier O365 (bzw. nun ja M365) rein drücken zu wollen.

Also via internem DNS diese Verbindung unterbunden:

Läuft!

Azure AD Connect: „Run profile ‚Full Import‘ does not have run steps“

Eines schönen Morgens erhielt ich die Meldung, dass neue AD-Objekte nicht mehr ins Azure AD synchronisiert werden. SSO funktionierte glücklicherweise, sonst hätte sie mir die Hütte eingerannt :).

Ich prüfte den „Synchronization Service“ (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe), welcher mir offenbarte, dass er seit einiger Zeit nicht mehr synchronisierte (kein Fehler, aber keine aktuellen Einträge!).

Das Eventlog war auskunftsfreudiger:

System.Management.Automation.CmdletInvocationException: Run profile ‚Full Import‘ does not have run steps. —> System.InvalidOperationException: Run profile ‚Full Import‘ does not have run steps.
bei Microsoft.IdentityManagement.PowerShell.Cmdlet.InvokeADSyncRunProfileCmdlet.ProcessRecord()

Wieder zurück im „Synchronization Service“-Tool, dort auf „Connectors“. Da sind zwei Connectors vorhanden, einer mit dem Namen der internen Domäne, und der zweite mit dem Namen der O365-Domäne „*.onmicrosoft.com – AAD“. Im internen Connector fehlten unter „Configure Run Profiles“ tatsächlich sämtliche Profile!

Glücklicherweise lassen sich diese relativ einfach manuell erstellen:

  1. Profil anwählen (z.b. „Full Import“), dann „New Step“
  2. Type entsprechend wählen (siehe unten) > Next
  3. Connector Configuration
    • Partition = interne Domain
    • Batch size = (siehe unten)
    • Page size = 500
    • Timeout = 120
  4. Finish

Dies muss für alle Profile ausgeführt werden.

ProfileTypeBatch size
Full ImportFull Import (Stage Only)50
Full SynchronisationFull Synchronisation0
Delta ImportDelta Import (Stage Only)50
Delta SynchronisationDelta Synchronisation0
ExportExport30

Ausserdem muss unter „Connectors“, der interne angewählt, und dann mit „Properties“ konfiguriert werden:

„Configure Directory Partitions“ > internes AD wählen/aktivieren

Achtung: falls nicht das gesamte AD synchronisiert werden sollte, müssen nun im Azure AD Connect Client noch die gewünschten OU’s ausgewählt werden, da sonst das gesamte AD synchronisiert wird!

Sync starten mit

Start-ADSyncSyncCycle -PolicyType Initial