Löschen von public Folder Mailboxen schlägt fehl

Ich wollte einen Exchange-Server migrieren, und währenddessen die noch vorhandenen onPrem-Mailboxen der PublicFolder löschen. Die PublicFolder waren schon lange migriert, aber die Postfächer hat irgendjemand nicht gelöscht ;).

Der Vorgang wäre hier schön beschrieben.

Doch Exchange wollte nicht:

Get-Mailbox -PublicFolder | where {$_.IsRootPublicFolderMailbox -eq $False} | Remove-Mailbox -PublicFolder

Es konnten keine aktiven Postfächer für öffentliche Ordner gefunden werden. Entweder wurden keine Postfächer für
öffentliche Ordner bereitgestellt, oder sie wurden im HoldForMigration-Modus bereitgestellt. Wenn Sie aktuell keine
Migration ausführen, erstellen Sie ein Postfach für öffentliche Ordner.
+ CategoryInfo : NotSpecified: (:) [Remove-Mailbox], ObjectNotFoundException
+ FullyQualifiedErrorId : [Server=SRV,RequestId=a6c72a8d-c6cb-4c15-a5cc-068977ab21b4,TimeStamp=18.04.2024 19:
28:51] [FailureCategory=Cmdlet-ObjectNotFoundException] 159E9A7C,Microsoft.Exchange.Management.RecipientTasks.Remo
veMailbox
+ PSComputerName : srv.domain.local

Die Einstellungen schienen aber alle OK:

Get-OrganizationConfig | fl RemotePublicFolderMailboxes,PublicFoldersEnabled
RemotePublicFolderMailboxes : {}
PublicFoldersEnabled        : Remote

Ich fand heraus, dass ich die Mailboxen mit folgendem Befehl löschen kann:

Remove-Mailbox -PublicFolder -Identity "PFMBX01" -Force

Ich habe dann den Befehl aus der Anleitung hier angepasst:

Get-Mailbox -PublicFolder -ResultSize Unlimited | ?{$_.IsRootPublicFolderMailbox -ne "True"} | Remove-Mailbox -PublicFolder -Force

und:

Get-Mailbox -PublicFolder | ? {$_.IsRootPublicFolderMailbox -eq "True"} | Remove-Mailbox -PublicFolder -Force

So konnte ich die Public Folder Mailboxen erfolgreich löschen.

Exchange 2013: RIP

Heute durfte ich den letzten von mir betreuten Exchange Server 2013 entfernen!

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.