Office 365: Fehler beim Lokalisierungsvorgang „Die Standardordner können nicht lokalisiert werden“

Problem

Bei einigen Nutzern wird unter Office 365 sowohl in Outlook als auch in der Outlook Web App der Ordnername „Inbox“ anstatt „Posteingang“ angezeigt. Das gilt auch für die anderen Ordner, also Outbox, Calendar, Deleted Objects und so weiter.

office365-standartordnernamen-inbox-umbenennenDie „richtige“ Lösung, die Ordner nach dem passenden Namensschema umzubenennen funktioniert aber nicht. Man versucht über OWA > Optionen > Allgemein > „Region und Zeitsone“ den Hake bei „Standardordner umbenennen“ zu setzen und erhält nach dem Klick auf „Speichern“ diese Fehlermeldung:

Fehler beim Lokalisierungsvorgang für die Standardordner von Postfach „EURFOOBARA003.prod.outlook.com/Microsoft Exchange Hosted Organizations/TENANT.onmicrosoft.com/whatever“: Die Standardordner können nicht lokalisiert werden.

Dasselbe Ergebnis zeigt die die Powershell bei der Verwendung von

Set-MailboxRegionalConfiguration <UserIdentity> -LocalizeDefaultFolderNam

und auch Outlook mit dem berühmten /resetfoldernames Parameter.

Lösung

Ordnernamen von Systemordnern („Gesendete Objekte“, „Postausgang“, „Posteingang“ …) dürfen nicht doppelt vorkommen. In 100% aller Fälle (bei uns) gab es einen Ordner mit dem selben Namen schon. Ob der beim importieren als Unfall erschienen ist (Outlook macht da manchmal nicht nachvollziehbare Verdoppelungs-Phänomene) oder manuell erstellt wurde ist irrelevant. Wenn die doppelten Ordner aber entfernt sind, klappt es auch mit dem /resetforldernames sofort.

Windows 8/8.1/10 als Terminalserver verwenden

Problem

Zwei Benutzer müssen (abwechselnd oder gleichzeitig) auf ein Tool zugreifen das aus den 80ern stammt und nicht Netzwerkfähig ist. Ein Terminalserver lohnt dafür aber nicht und es muss auf jeden Fall dieser eine Rechner sein. Kommt bei Kartenlesern, Abrechnungssystemen und ähnlichem schon mal vor.

Lösung

windows10-als-terminalserverWindows 8/8.1 (und Windows 10 bisher) lässt sich problemlos als Terminalserver für mehrere Benutzer verwenden. Das ist zwar (bestimmt) total illegal aber technisch erst einmal kein Problem. Selbstverständlich gibt es für diese Funktion keinen Support und das System ist immernoch ein Windows 8, kein Server. Mehr Serverrollen gibt es also nicht. Allerdings ist auch die Spiegelung von Sitzungen problemlos möglich.

Die einfachste Möglichkeit ist die RDP Wrapper Library. Die schaltet sich als zwischen den Servicehost und die termsrv.dll und manipuliert die Aufrufe entsprechend. Das System hat sich bisher als „Update-Sicher“ und äußerst stabil herausgestellt.

Server 2012R2 RDP Sitzung Spiegeln (Remoteüberwachung)

Problem

server2012r2-spiegelen-ueberwachenIm Windows Server 2012 hat Microsoft die Funktion „Remoteüberwachung“ zum spiegeln von Benutzern vollständig entfernt. Ob absichtlich oder Unfall – ärgerlich ist das allemal. Glücklicherweise wurde das „Spiegeln“ oder zu neudeutsch „Shadowing“ mit dem Server 2012R2 wieder eingeführt. Leider auch hier nicht über den schnellen Klick im Taskmanager, sondern an der Kommandozeile (und auf Terminalservern im Servermanager).

Lösung

Man benötigt zuerst die Sitzungs-ID der Session, die es zu spiegeln gilt:

Alle Sitzungen anzeigen

C:\>query USER  /SERVER:<SERVERNAME>

Bestimmte Sitzung anzeigen:

C:\>query USER <USERNAME> /SERVER:<SERVERNAME>

Mit der entsprechenden ID lässt sich die Session dann mit dem eingebauten RDP-Client spiegeln:

C:\>mstsc /shadow:<SessionID> /control

Bessere Lösung

Dieses Script automatisiert den Vorgang und lässt sogar das direkt Remote-Spiegeln zu. Es wird eine Liste der aktiven Sitzungen präsentiert und man tippt nur noch die Nummer ein.

Achtung, die Remote-Spiegelung (zum Beispiel von einem Admin-Client) funktioniert nur wenn der Server lizenziert (RDSCAL) ist. Lokal klappt das hingegen immer.

@echo off
title Remoteueberwachung
REM --- Wie heisst der Server?
set termserver=localhost

REM --- Session IDs auslesen
query session /server:%termserver% & echo.
set /p sessionid=Die Session-ID eingeben oder mit q Beenden ...
if %sessionid%==q @exit
start mstsc /v:%termserver% /shadow:%sessionid% /control

SQL Server Management Studio „.NET Framework Error“ (Unable to read the list of previously registered servers on this system)

Problem

Das SQL Management Studio (alle Versionen ab 2008) startet nicht nur noch mit einer Fehlermeldung:

Microsoft.SqlServer.Management.RegisteredServers.RegisteredServerException: Unable to read the list of previously registered servers on this system.
Re-register your servers in the 'Registered Servers' window.
Microsoft.SqlServer.Management.Sdk.Sfc.SfcSerializationException:
Deserialization operation on /RegisteredServersStore/ServerGroup/CentralManagementServerGroup has failed.

Wenn das SQL Server Management Studio dann aber gestartet ist, kann man sich zwar verbinden, sieht aber keine Inhalte. Stattdessen erscheint der Fehler

Value cannot be null.

Oder auf Deutschen Systemen:

Wert darf nicht null sein.

Lösung

Das Temp-Verzeichnis der %TEMP% Variable ist nicht gesetzt, der Paf existiert nicht oder ist nicht beschreibbar. Auf dem System auf dem ich mich grade herumtreibe konnte ich den Fehler daher schnell beheben:

mkdir %TEMP%

Office 2013 auf Office365 offline herunterladen/installieren oder im Netzwerk verteilen

OfficeSetupDas Setup für die Office 2013 Programme aus Office 365 (die Clickstream-Installation) ist sehr einfach erledigt und bei einer schnellen Internetverbindung in relativ kurzer Zeit passiert.

Wie aber installiert man mehrere Computer in einem Netzwerk? Oder einen PC mit langsamer Internetanbindung? Microsoft hat diesen Fall immerhin vorgesehen, wenn auch nicht unbedingt einfach zugänglich gemacht. Es wäre ja auch VIEL zu einfach, wenn ein Admin das Officepaket herunterladen und direkt installieren könnte *kopfschüttel*. wie auch immer, so funktioniert die Office 365 Netzwerkverteilung (neudeutsch ‚On Premise deployment‘).

Lösung

  1. Das „Office Deployment Tool for Click-to-Run“ herunterladen und den Inhalt der Datei mit 7Zip auf den deployment UNC-Netzwerkshare (\\server\foobar) auspacken. Eine Installation ist NICHT notwendig.
  2. Die configuration.xml wie folgt bearbeiten:
    <Configuration>
     <Add SourcePath="\\server\foobar\ordner\" OfficeClientEdition="32" >
     <Product ID="O365ProPlusRetail">
     <Language ID="de-de" />
     <ExcludeApp ID="InfoPath" />
     </Product>
     </Add>
     <Updates Enabled="TRUE" UpdatePath="\\dcw1\install$\office365\" />
     <Display Level="None" AcceptEULA="TRUE" />
    </Configuration>

    Es ist hier auch möglich, das Setup noch weiter anzupassen:

    1. Office-Apps von der Installation ausnehmen
    2. Office-Apps hinzufügen (Visio, Project …)
    3. Setup-Optionen (EULA, Logging …)
  3. Das Setup zum Herunterladen der Office-Click-to-Run Setupdateien auffordern (das Paket ist etwa 1.4gb groß):
    setup.exe /download <pfad>\configuration.xml
  4. Aus diesen Ordner kann man dann das Officepaket nun lokal im Netzwerk installieren:
    setup.exe /configure <pfad>\configuration.xml

Wird das Setup mit „/download“ aufgerufen, werden die Dateien auf der Netzwerkfreigabe (oder dem lokalen Laufwerk) gespeichert. Wenn das Setup dann zum Installieren mit „/configure configuration.xml“ gestartet wird, holt der Installer die notwendigen Dateien ebenfalls vom selben Ort ab. Mehr Details zu dem Tool gibt es bei Microsoft unter http://technet.microsoft.com/en-us/library/jj219422.aspx.