Logon-Script: Gruppenmitgliedschaften per Batch auswerten

Ab und zu ist es hilfreich, Laufwerksverbindungen (oder ähnliches) anhand von ActiveDirectoy Gruppenmitgliedschaften einzurichten. Ist ein Benutzer Mitglied einer Gruppe soll er ein Laufwerk bekommen, ist er das nicht (mehr) soll das Laufwerk wieder verschwinden. Dieser Batch Script-Schnipsel übernimmt das:

REM ================================================================
REM /*
REM    Laufwerk X: - Gruppe "MP3-Sammlung"
REM */

net user /domain %username% | find/i "MP3-Sammlung"
if errorlevel 1 (
REM ----- Dieser Teil wird ausgefuert wenn NICHT Mitglied der Gruppe
net use x: /delete
) else (
REM ----- Dieser Teil wird ausgefuert wenn Mitglied der Gruppe
net use x: \servermp3sammlung
)

REM ================================================================

Neue Verteilerlisten in Exchange 2010 sind nicht von außen erreichbar

Exchange 2010 bringt eine neues Feature mit, welches mit geringem Aufwand erlaubt eine Verteilerliste von Mails von außen abzuschotten. Dummerweise ist dies bei neuen Verteilerlisten standardmäßig aktiv. Legt man nun unwissender Weise eine neue Verteilerliste an und trägt wie in Exchange 2003/2007 gewohnt E-Mail-Adresse und Mitglieder/Empfänger ein, ist die Liste innerhalb der eigenen Organisation problemlos erreichbar. Versucht man jedoch eine Mail von außen an die angegebene E-Mail-Adresse zu senden erhält man folgende Meldung (hier die Ausgabe des Microsoft Remote Connectivity Analyzer).

550 – Mailbox unavailable. The server response was: 5.1.1 User unknown

Um die Verteilerliste von außen erreichbar zu machen, ruft man die Eigenschaften der Verteilerliste auf und wählt dort im Tab Nachrichtenübermittlungseinstellungen per Doppelklick den Punkt „Einschränkungen für die Nachrichtenzustellung“ und entfernt den Haken bei „Authentifizierung aller Absender anfordern“.

Die Änderung wirkt sofort und ein erneuter Test von außen geht erfolgreich aus.

Windows Server 2008R2 mit Windows 7 Bug (CIFS)

Da dieser Bug mit einem „simple Workaround“ behoben werden kann, wird dieser Fehler vermutlich nie endgültig gefixt. Da das Problem beständig auftritt hier die Beschreibung und Lösung.

Seit geraumer Zeit ist es möglich, NTFS-Volumen in leere Ordner eines anderen NTFS-Volumens bereitzustellen. Das kann man aus verschiedenen Gründen tun, oft sieht man so eine Konstellation bei Fileservern die zwar eine einzelne Freigabe (oder einen großen DFS-Stamm) anbieten, diesen aber wegen der Fragmentierung, I/O-Last, Quoten oder Skalierungsproblemen auf mehrere LUNs (bzw. Laufwerke) aufteilen.

Der Fehler liegt nun im Windows 7 Explorer: Verbindet sich ein Client so eine Freigabe nun als Netzwerklaufwerk, verschwinden die bereitgestellten Ordner-Volumen darin sporadisch aus der Inhaltsansicht. Die Ordner mit den Volumen sind spontan einfach nicht mehr sichtbar. Der Zugriff ist (z.B. durch Pfadeintippen) noch möglich, aber die Ordner werden nicht mehr aufgelistet. Alle Programm die diese API verwenden (ja, auch die Shell und die Powershell) „sehen“ den Ordner nicht. Der Effekt ist reproduzierbar (bei ca. 80% aller Clients innerhalb von 48 Stunden) und beschränkt sich nicht auf Singlemounts, also auch wenn das Volumen zusätzlich auch einen Laufwerksbuchstaben hat. Einzig am Localhost ist der Effekt nie zu beobachten.

Die Lösung:

Un-Elegant wie hart, einfach den Explorer-Cache für Listing ausschalten. Das geht indem man in

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanWorkstationParameters

den (DWORD) Wert DirectoryCacheLifetime auf 0 setzt. Nach einem Reboot ist das Problem verschwunden.

Spannend: Der Effekt ist exklusiv der Kombination Windows7 mit Server2008R2 vorbehalten, andere Clients oder Server zeigen immer alle Inhalte an.

Windows läd nur TEMP-Benutzerprofil

Aus unterschiedlichen Gründen mag Windows manchmal seine Servergespeicherten Benutzerprofile nicht mehr laden. Wirre Eventlog-Fehlermeldungen sind die Folge, von Rechten und Verzeichnissen ist die Rede. Wenn das übliche debuggen entlang dieser Meldungen nicht mehr fruchtet, hilft oft das Profil einfach zurückzusetzen:

  • PC neu starten (Wichtig um alle Zweige zu entladen!)
  • Als lokaler Administrator anmelden und das betroffene Profil komplett löschen (oder von der Maschine schieben)
  • Registry öffnen:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
    
  • Löschen des Unterschlüssels mit dem Namen <SID>.bak

Die <SID> ist die Sicherheits-ID (SID) des Benutzerkontos, bei dem das Problem auftritt. Der Unterschlüssel SID.bak sollte einen Registrierungseintrag ProfileImagePath enthalten, der auf den ursprünglichen Profilordner verweist, bei dem das Problem auftritt.

Wenn das Profil noch intakt und alle Rechte korrekt sind (schlimmstenfalls nochmal drüber erben und den Besitzer nicht vergessen), den key state auf „0“ setzen, das .bak entfernen (nachdem man die ID mit dem temp-profil gelöscht hat) und rebooten. NICHT ab- und anmelden, sondern rebooten (denn dann wird die profilelist erst neu geladen).

Die Empfängerrichtlinie ‘Default Policy’ mit Postfach-Manager-Einstellungen kann nicht über die aktuelle Version der Exchange-Verwaltungskonsole verwaltet werden

Bei einer Migration von Exchange 2003 nach 2007/2010 kann es mal zu einem seltsamen Effekt kommen. Nach Abschluss der Postfachmigration wird ja in der Regel die „Default Policy“-Empfängerrichtlinie via

Set-EmailAddressPolicy „Default Policy“ -IncludedRecipients AllRecipients

umgestellt. Dies muss auch sein, da sich sonst die E-Mailadressrichtlinie (ab 2007 heisst das nicht mehr Empfängerrichtlinien, sondern Adressrichtlinie) nicht mit der EMC bearbeiten lässt. In der Regel klappt das auch. Manchmal gibt es aber den kreativ anmutenden Fehler:

Set-EmailAddressPolicy : Die Empfängerrichtlinie ‚Default Policy‘ mit Postfach-Manager-Einstellungen kann nicht über die aktuelle Version der Exchange-Verwaltungskonsole verwaltet werden

Liesst sich ein bisschen wirsch. Nach viel suchen kommt heraus: Der Postfach-Manager ist eine superselten genutzte Funktion von Exchange 2003. Inhalte aus Postfächern können damit automatisch bearbeitet werden, z.B. kann der fiese Admin alles was älter als 30 Tage ist damit löschen (oder ausdrucken oder so). Exchange 2007/2010 kennt das nicht mehr; Microsoft hat die Funktion an sich allerdings deutlich erweitert und der geneigte Admin kennt diese nun als „Richtlinien zum Verwalten von Nachrichtendatensätzen„. In meinem speziellen Fall stammen die Einstellungen von einer Exchange-nahen Faxlösung aus der frühen Steinzeit.

Lösung: Einfach alle alten Postfach-Managereinstellungen (beabsichtigt oder nicht) entfernen. Und das geht so:

  • Exchange Systemmanager (ja, das ding von 2003) öffnen
  • Rechte MT auf die „Default Policy“ und unter
  • „Eigenschaftenfenster ändern“ den Haken bei den Postfachmanagereinstellungen entfernen

Danach geht auch die Übernahme mir set-EmailAddressPolicy auch sofort.