Wenn der SCCM Distribution Point bockt…
Sonntag, 31. Oktober 2010, 21:30
Abgelegt unter: Erkenntnisse | Tags: , , , ,

Vor einiger Zeit wurde ich von einem Kollegen mit dem Problem konfrontiert, dass bei der Installation eines Softwarepaket über den System Center Configuration Manager 2007 der Download mittendrin ohne klar ersichtlichen Grund hängenbleibe. Doch wenn man im Advertisement von „Download content from distribution point and run locally“ auf „Run program from distribution point“ umstelle, könne das Paket problemlos installiert werden. Dies betreffe jedoch nur die eine Site, in einer anderen Site unserer Sitestruktur könne zudem dasselbe Paket problemlos auf beide Arten installiert werden. „Für den Installer dieser Applikation spiele es keine Rolle, ob er lokal oder über einen UNC-Pfad ausgeführt werde; beides funktioniere problemlos, wie er getestet habe. Und die verwendeten Dateien in den Paketen seien doch in allen Fällen und auf allen Distribution Points dieselben und stammten vom selben Source-Verzeichnis“, konstatierte der verzweifelte Kollege. „Ja schon, aber….“, begann meine Antwort.

Auch wenn die Dateien tatsächlich in allen Fällen dieselben sind, ist der Weg, wie die Dateien vom Server zum Client transportiert werden, grundverschieden. Im Falle des „Run program from distribution point“ greift der Client via SMB (d.h. normalen Fileserver-Zugriff) auf den Distribution Point zu. Im Falle von „Download content from distribution point and run locally“ will der Client jedoch die Dateien via BITS (d.h. den „Background Intelligent Transfer Service“) vom Server beziehen, womit auch der IIS („Internet Information Server“ des Distribution Point ins Spiel kommt. Somit liegt der Verdacht nahe, dass es sich beim vorliegenden Problem gar nicht um ein SCCM, sondern ein IIS-Problem handelt.

Denn der IIS blockt standardmässig bestimmte Dateierweiterungen, womit Dateien dieser Typen in der IIS-Standardkonfiguration nicht via BITS heruntergeladen werden können. Dies wird auch im Technet-Artikel „Konfigurieren von Windows Server 2008 für Standortsysteme“ beschrieben:

Wenn an BITS-fähige Verteilungspunkte verteilte Paketquelldateien Dateierweiterungen enthalten, die in IIS 7.0 standardmäßig blockiert sind, muss der Abschnitt „requestFiltering“ der Datei „applicationHost.config“ so geändert werden, dass die erforderlichen Dateierweiterungen zugelassen werden.

Und dies geschieht auf folgende Art und Weise: In der Datei „applicationHost.config“ im Verzeichnis „%windir%\System32\inetsrv\config\“ des Distribution Points muss der Abschnitt „<requestFiltering>“ gesucht werden. In diesem Abschnitt sind Einträge in der folgenden Art zu finden:

<add fileExtension=".mdb" allowed="false" />

Wird hier „false“ durch „true“ ersetzt, die Datei „applicationHost.config“ danach gespeichert und der IIS neu gestartet, können nun auch Dateien mit der Endung „.mdb“ über BITS übertragen werden. Und so kann diese Einstellung für jeden benötigten Dateityp vorgenommen werden. Kandidaten in unserer Umgebung waren primär Dateierweiterungen wie „.config“, „.java“, „.mdb“ und „.ldf“. Natürlich lässt sich dies auch gleich pauschal lösen, indem alle entsprechenden Zeilen auskommentiert oder gelöscht werden, denn für alle nicht aufgeführten Dateitypen ist der Transfer gemäss der Default-Einstellung erlaubt. Man muss sich einfach bewusst sein, dass man durch derartige Anpassungen die Angriffsfläche des Servers vergrößert, zumal die Änderungen für alle Websites auf dem jeweiligen Server gelten.

Ganz abgesehen davon, dass man bei der Installation eines neuen Siteservers selten im voraus weiss, welche Dateitypen dann tatsächlich benötigt werden, verschweigt der besagte Technet-Artikel jedoch einen Punkt, der uns schon mehrfach Probleme verursacht hat:

Es gibt nicht nur bestimmte Dateiendungen, die standardmässig geblockt werden, sondern auch Pakete, welche ein Unterverzeichnis „bin“ haben, können in der IIS-Standardkonfiguration nicht via BITS heruntergeladen werden. Hierzu findet man in derselben Datei „applicationHost.config“ etwas weiter unten einen Abschnitt „hiddenSegments“ mit den dazugehörenden Einträgen in der Form:

<add segment="bin" />

Wird diese Zeile (resp. die passende Zeile bei anderen blockierten Verzeichnisnamen) gelöscht, die geänderte Datei gespeichert und der IIS neu gestartet, können danach auch Pakete mit „bin“-Verzeichnissen über BITS ausgeliefert werden.

Dass in unserem Problemfall der Download von einem Distribution Point geklappt hat und vom anderen nicht, lag schlicht und einfach daran, dass die notwendigen Modifikationen der Datei „applicationHost.config“ auf dem einen Server bereits vorgenommen, auf dem anderen jedoch unterlassen wurden.

Bei der Aufarbeitung dieser Thematik als Blogbeitrag bin ich noch über weitere Blogs bzw. Diskussionen gestossen, welche ähnliche Probleme beschreiben. Diese habe ich in unserem Umfeld zwar nicht direkt angetroffen, doch ich denke, dass die abschliessende Erwähnung dieser Beiträge und Links in diesem Zusammenhang durchaus Sinn macht:



Der Fall des nicht funktionierenden Server-Manager
Samstag, 16. Oktober 2010, 23:13
Abgelegt unter: Der gelöste Fall | Tags: , , , ,

Als ich auf einem unserer Server (mit Windows Server 2008 R2) per Remote-Desktop einloggte, wurde wie üblich gleich der Server Manager gestartet. Doch anstatt mir irgendwelche Daten unter „Roles“ und „Features“ zu zeigen, meinte dieser lapidar: „Error.“ Bei den Fehlerdetails wird folgendes angegeben: „Unerwarteter Fehler beim Aktualisieren von Server-Manager: Der Remoteprozeduraufruf ist fehlgeschlagen. (Ausnahme von HRESULT: 0x800706BE)“. [engl.: „Unexpected error refreshing Server Manager: The remote procedure call failed (Exception from HRESULT: 0x800706BE)“]

Server Manager Error: Exeption from HRESULT: 0x800806BF

Als ich nach Hinweisen zu diesem Fehler suchte, der übrigens auf unseren Servern mit Windows Server 2008 R2 schon mehrfach zugeschlagen hat, fand einen Thread in den Windows Server Foren von Microsoft, bei welcher dieses Problem diskutiert wurde. Als Lösung wird dort folgendes vorgeschlagen:

Please follow the instructions from the following website to download and run System Update Readiness Tool on your computer.
http://support.microsoft.com/kb/947821

If the issue is not resolved after running the tool, please check the result of CheckSUR.log (%windir%\logs\cbs\checksur.log) and ServerManager.log (inside C:\Windows\Logs)

Obwohl ich mir auf Anhieb keinen Reim auf die Zusammenhänge zwischen einem „System Update Readiness Tool“ und einem nicht funktionierenden Server Manager machen konnte, schaute ich mir den KB-Artikel 947821 an und lud mir das dort referenzierte und knapp 100MB grosse Tool für den Server 2008 R2 herunter und startete dieses per Doppelklick, worauf der „Hotfix for Windows (KB947821)“ installiert wurde. Dies dauerte eine geraume Zeit und wurde schlussendlich mit „Installation complete“ quittiert.

Darauf startete ich erneut den Server Manager: Fehlanzeige! Immer noch dieselbe Fehlermeldung! Also konsultierte ich das beschriebene CheckSUR.log, das im Verzeichnis %windir%\logs\cbs zu finden ist.

CheckSUR.log

In diesem Log stachen mir zwei Dinge ins Auge: Erstens wurde eine „CBS MUM Corruption 0x00000000“ in einem bestimmten File gefunden (was auch immer das heissen soll), zweitens wurde weiter unten genau zum betreffende MUM-File (und dem offenbar dazugehörenden CAT-File) angemerkt, dass das „Repair File“ fehle:

Unavailable repair files:
servicing\packages\Package_for_KB2387149_RTM~31bf3856ad364e35~amd64~~6.1.1.1.mum
servicing\packages\Package_for_KB2387149_RTM~31bf3856ad364e35~amd64~~6.1.1.1.cat

Was die zwei fehlenden Repair-Files mit meinem nicht funktionierenden Server Manager zu tun haben sollten, war mir keineswegs klar. Und was diese Meldungen nun tatsächlich bedeuten sollten, hatte ich erst recht keinen blassen Schimmer. Also suchte ich weiter und fand die Anleitung „Advanced guidelines for diagnosing and fixing servicing corruption“ bei MSDN, die mir hier etwas weiterhalf: Diese Meldungen sollten wohl heissen, dass das Systemupdate-Vorbereitungstool zwei Dateien eines Patches erkannte, die wohl nicht korrekt im Servicing-Store abgelegt waren:

If you get the Unavailable repair files message, this indicates that some of the inconsistent files found by the tool cannot be fixed as the correct versions of the replacement files are not carried by the tool.

Und zum Glück sind in dieser Anleitung auch die Schritte zur Lösung des Problemes beschrieben:

Get the files required from other sources. The options available can be found in the “Options for obtaining files” section below.

Da es sich bei den fehlenden Files offenbar um Dateien zum Update KB2387149 handelt, habe ich dieses Update – es handelte sich in meinem heutigen Fall um das Sicherheitsupdate für den Windows Server zum Security Bulletin MS10-074, welches am 11. Oktober 2010 publiziert worden ist – manuell heruntergeladen und in einen temporären Ordner entpackt, wobei die Platzhalter <…> in nachfolgendem Befehl mit den passenden Werten zu ersetzen und der Ordner, wohin die Files ausgepackt werden sollen, vorgängig anzulegen sind:

expand <...pfad zu...>\<...Update...>.msu /f:* c:\<...Auspackziel...>

Als nächstes habe ich das CAB-File entpackt, welches nun in diesem Ordner zu finden war:

expand <...pfad zu...>\<...Update...>.cab /f:* C:\<...Auspackziel...>

Und da lagen nun in diesem zweiten Ordner die beiden Dateien, die im CheckSUR.log als „unavailable“ bezeichnet wurden, vor mir. Wie die Anleitung „Advanced guidelines for diagnosing and fixing servicing corruption“ beschreibt, kopierte ich die beiden Dateien nun in das passende Verzeichnis:

All files of type *.mum and *.cat should be placed in the %windir%\Temp\CheckSUR\servicing\packages directory

Danach habe ich das Systemupdate-Vorbereitungstool erneut gestartet und die Dateien wurden sauber in den Servicing-Store übernommen, wie das neue CheckSUR.log bestätigt:

CheckSUR.log bestätigt erfolgreiche Reparatur

Auch der Server-Manager konnte sofort danach wieder ohne Probleme ausgeführt werden:

Der Server Manager funktioniert wieder!

Weshalb der Server-Manager nicht mehr funktionieren wollte, habe ich immer noch keinen blassen Schimmer… Und weshalb dieses Problem überhaupt aufgetreten ist, weiss ich noch weniger. Tatsache ist einfach, dass ich dieses Problem bisher noch jedesmal auf genau diese Weise lösen konnte:

  • Als ich das erste Mal mit diesem Problem konfrontiert wurde, habe ich Stunden damit verbracht, den Server Manager des betroffenen Servers wieder funktionstüchtig zu machen.
  • Als dieses Problem zum zweiten Mal zuschlug, konnte ich mit Hilfe einiger Notizen vom ersten Fall das Problem rascher lösen, wobei ich mir dabei detailliertere Aufzeichnungen machte.
  • Ich hoffe, das es nun mit Hilfe dieses Beitrages, den ich heute anlässlich des dritten Vorkommnisses nebenher erstellt habe, auch weiteren Lesern gelingt, das offenbar häufiger auftretende Problem zügig lösen zu können.

Nachtrag vom 9.11.2010:

Heute hat Microsoft den KB-Artikel 2461206 „You are unable to view Roles and Features and receive error code 0x800706BE in Server Manager“ zu dieser Problematik publiziert.



Wenn noch SCCM-Pakete auf einem gelöschten Distribution Point liegen…
Freitag, 15. Oktober 2010, 21:32
Abgelegt unter: Erkenntnisse | Tags: , , ,

Kürzlich entfernte ich einen nicht mehr gebrauchten Distribution Point. Dies ging ruckzuck: Flugs im „Site Management“ unter den „Site Systems“ der entsprechenden Site den betreffenden Server ausgewählt und die Rolle „ConfigMgr Distribution Point“ entfernt. Fertig!

Fertig? Nein, leider nicht ganz…

Der Distribution Point wurde überall aus den Listen entfernt und man konnte auf diesem auch keine Pakete mehr verwalten. Auf den ersten Blick schien alles in bester Ordnung zu sein. Auf den zweiten Blick hingegen…

Immer wieder tauchten seither Fehlermeldungen auf, dass ein bestimmtes Paket auf dem betreffenden Distribution Point nicht bereitgestellt oder entfernt werden konnte. Und wenn man dann die betreffenden Pakete in der Konsole betrachtete, war tatsächlich der betreffende Distribution Point noch im „Package Status“ aufgelistet, zumeist mit einem Status „Removal Pending“. Dabei war doch dieser Distribution Point längst gelöscht und der entsprechende Server ausrangiert und entsorgt.

Was nun?

Ein entsprechender Artikel „How to Remove a Distribution Point“ aus dem Microsoft Technet half etwas weiter, da dort folgendes dokumentiert ist:

1. Remove all distribution package folders and the SMSPKGSIG signature folder from the distribution point computer.
Important: You must manually remove these components before removing the distribution point role.

Tja, hinterher ist man immer schlauer. Bloss war es etwas schwierig für mich, diese Anweisung nachträglich umzusetzen, da der Distribution Point längst weg war.

Da ich vermutete, dass ich nicht der einzige bin, der einen Distribution Point gelöscht hat, bevor er die Packages von diesem Distribution Point entfernt hatte, suchte ich weiter und fand einen Thread in den System Center Foren von Microsoft, bei welcher dieses Problem diskutiert wurde. Als Lösung wurde dabei auf einen Beitrag im „System Center WebLog by Russ Slaten“ verwiesen, dessen Titel „Removing a retired DP from all your packages“ vielversprechend aussah.

Dieser Beitrag beschreibt, dass das Entfernen der Rolle „Distribution Point“ nicht auch automatisch die Pakete von diesen Distribution Point entferne. Man müsse vorgängig die Pakete vom Distribution Point entfernen, was ziemlich mühsam werden kann, wenn man eine grössere Menge von Paketen auf dem betreffenden Distribution Point bereitgestellt hat. Netterweise stellt Russ Slaten bei dem betreffenden Beitrag ein VB-Skript bereit, mit dem diese Aufgabe automatisiert durchgeführt werden kann. Die Angabe der Namen des Site Servers und des leerenden Distribution Points als Parameter bei Aufruf seines Skriptes „SMSDPClean.vbs“ reichen, und schon würden alle Pakete vom betreffenen Distribution Point entfernt werden.

Wie ich dann leider herausfinden musste, funktioniert dieses Skript problemlos, zumindest solange der Distribution Point noch nicht vom Netzwerk entfernt wurde. Das Skript deckt zwar mit einer kleinen vorzunehmenden Modifikation den Fall ab, dass ein Distribution Point schon gelöscht wurde, doch in meinem Falle mit dem bereits entsorgten Distribution Point half das Skript nicht wirklich weiter.

Langsam aber sicher fragte ich mich, weshalb beim Entfernen der Rolle „Distribution Point“ keine entsprechenden Warn- oder Fehlermeldungen erscheinen, die darauf hinweisen, dass man diese Rolle nicht entfernen solle bzw. könne, da diesem Distribution Point noch Packages zugewiesen seien. Wehmütig dachte ich an den Assistenten, der beim Löschversuch einer Collection erscheint, der auf detaillierteste Weise beschreibt, was alles geschehen wird, wenn man diese Collection löscht.

Jegliches Sinnieren über mögliche Unzulänglichkeiten der SCCM-Konsole half mir jedoch nicht weiter. Ich hatte ein Problem, und das sollte gelöst werden! Also las und suchte ich weiter und stiess auf den Artikel „Deletion of Orphaned Distribution Points“ von Brett Wilms in seinem „System Management Blog“. Und dieser Beitrag half tatsächlich weiter!

Doch bevor ich die Lösung des Problemes präsentieren kann, ist nun ein Warnhinweis fällig:

Die direkte Modifikation einer SCCM-Datenbank wird von Microsoft grundsätzlich nicht unterstützt, ausser sie erfolgt direkt auf Anweisung der Microsoft Support Services. Die beschriebene Lösung hat beim Autor dieses Artikels funktioniert und wird als Beispiel publiziert, wie die Problematik gelöst werden könnte. Die unsachgemässe Anwendung der beschriebenen Lösung kann negative Folgen auf eine SCCM-Umgebung haben. Testen Sie die beschriebene Lösung unbedingt in Ihrer Testumgebung, bevor sie diese auf eigene Verantwortung und eigenes Risiko in Ihrer Produktionsumgebung anwenden. Bitte wenden Sie diese Lösung in Ihrer Umgebung nur genau dann an, wenn Sie wissen was sie tun, und kontaktieren Sie die Microsoft Support Services bei jeglicher Unsicherheit.

Mit Hilfe des SQL Server Management Studio konnte ich mit Hilfe der nachfolgenden beiden Queries sehen, welche Einträge zum fraglichen Distribution Point noch in der Datenbank vorhanden waren, wobei natürlich <DistributionpointName> durch den Namen des gelöschten Distribution Points zu ersetzen ist:

SELECT * FROM PkgServers WHERE NALPath like '%<DistributionpointName>%'

SELECT * FROM PkgStatus WHERE PkgServer like '%<DistributionpointName>%'

Als ich mich davon überzeugt hatte, dass diese beiden Queries tatsächlich genau (und nur!) die Einträge zum gelöschten Distribution Point lieferten, und ich mich zudem vergewissert hatte, dass ich ein korrektes und aktuelles Backup der betreffenden Site vorliegen hatte, wagte ich es, die folgenden beiden Queries zu starten, um die Spuren des gelöschten Distribution Points in der Datenbank zu beseitigen:

DELETE FROM PkgServers WHERE NALPath like '%<DistributionpointName>%'

DELETE FROM PkgStatus WHERE PkgServer like '%<DistributionpointName>%'

Und tatsächlich: Seither sind die Fehlermeldungen verschwunden.



SCCM-Protokolle und Trace32.exe
Samstag, 9. Oktober 2010, 21:11
Abgelegt unter: Tipps & Tricks | Tags: , ,

In meinem letzten Beitrag habe ich beschrieben, wie man am einfachsten bestimmte SCCM-Logfiles finden kann. Wenn man derartige Logfiles mit dem Editor (notepad.exe) öffnet, dann schaut das ganze schon ziemlich übersichtlich aus:

Protokollausschnitt, angezeigt mit notepad.exe

Zum Glück gibt es jedoch ein äusserst hilfreiches Werkzeug namens „trace32.exe“, das jedem SCCM-Administrator bekannt sein sollte. Trace32.exe ist Bestandteil des „System Center Configuration Manager 2007 Toolkit„. Damit wird das Logfile schon deutlich lesbarer:

Derselbe Protokollausschnitt, angezeigt mit Trace32.exe

Wie das Bild zeigt, lassen sich mit Trace32 mit der Funktion „Highlight“ beliebige Texte hervorheben. Es reicht dazu aus, den gewünschten Suchtext im Dialogfenster einzutragen und schon werden auch in einer langen Protokolldatei alle Zeilen hervorgehoben, welche den entsprechenden Suchtext enthalten. Ob nun nach irgendeinem Fehlercode, einer bestimmten Paketnummer oder einer sonstigen Zeichenkette gesucht werden soll, bleibt den Bedürfnissen des Administrators überlassen.

Ebenso können im Öffnen von Protokolldateien mehrere Protokolle auf einmal gewählt werden und diese dann mit der Option „Merge selected files“ zusammengeführt werden. Das ist inbesondere dann hilfreich, wenn z.B. an einem Vorgang mehrere SCCM-Komponenten beteiligt sind und man so eine konsolidierte Ansicht erhalten kann.

Mit Trace32.exe können jedoch nicht nur nachträglich irgendwelche Protokolle angeschaut werden. Da Trace32.exe die Ansicht nachführt, sobald neue Protokolleinträge geschrieben werden, wird es auch möglich, Vorgänge in Echtzeit mitzuverfolgen. Wer sich also schon immer gefragt hat, was sein SCCM-Siteserver zur Zeit gerade macht, kann die entsprechenden Protokolle mit trace32.exe öffnen. So erhält man sofort einen guten Einblick, ob beispielsweise das Paket LAB0013C nun tatsächlich auf die Distribution Points verteilt wird, oder ob dies – wie im obigen Beispiel ersichtlich – immer noch fehlschlägt, ohne dass gewartet werden muss, bis die entsprechende Fehlermeldung in der Konsole sichtbar wird.

Sieht man nun eine entsprechenden Eintrag im Protokoll, für den man sich besonders interessiert, und klickt diesen an, um diesen in voller Länge im unteren Detailfenster lesen zu können, hält die automatische Verfolgung sogleich an. Gerade wenn die betreffende Komponente sehr aktiv ist, kann man dann schön sehen, wie der Scrollbalken am rechten Fensterrand immer weiter nach oben rutscht, da unten immer weitere Einträge hinzugefügt werden.

Hat man den Detaileintrag fertig gelesen (und vielleicht auch wegkopiert), möchte man vielleicht gerne wieder ans Ende des Protokolles springen und vor allem auch die automatische Verfolgung wieder aktivieren. Klar: man kann den Scrollbalken nach unten ziehen und sieht dann den neuesten Eintrag, doch die Nachverfolgung wird so nicht wieder aktiviert. Doch einen entsprechenden Menübefehl sucht man vergebens…

Dabei ist es so einfach: Tastenkombination „Ctrl-End“ drücken und schon läuft die Anzeige wieder weiter!



Die Suche nach dem passenden SCCM-Protokoll
Montag, 4. Oktober 2010, 21:54
Abgelegt unter: Tipps & Tricks | Tags: , ,

Wenn ich mit dem System Center Configuration Manager arbeite, werfe ich immer mal wieder einen Blick in den „Site Status“. Und leider kommt es immer wieder vor, dass ich dort nicht nur grüne Häckchen, sondern auch gelbe Ausrufezeichen oder sogar rote Kreuze bei einer oder mehreren Komponenten sehe.

Werde ich aus den entsprechenden Status Messages nicht gleich schlau, möchte ich mal schnell einen Blick in die dazugehörende Protokolldatei werfen. Doch welches der unzähligen Logfiles gehört nun tatsächlich zur betreffenden Komponente? Hinter welchem kryptischen Dateinamen verbirgt sich das gesuchte Protokoll? Ist das nun ciamgr.log oder aikbmgr.log oder gar cscnfsvc.log? Und wo ist das gesuchte Protokoll auf dem betroffenen Server noch gleich zu finden?

Hier gibts einen kleinen Trick, den mir vor einiger Zeit mal ein Microsoft Premier Field Engineer gezeigt hat:

  1. Klappe den untersten Punkt „Tools“ in der SCCM-Konsole auf
  2. Starte den „ConfigMgr Service Manager“
  3. Suche die betroffene Komponente in der Liste
  4. Klicke diese mit der rechten Maustaste an und wähle „Logging…“

Und siehe da: hier steht der komplette Pfad mitsamt Name der gesuchten Protokolldatei!



Fehlermeldung beim Verschieben einer OU im Active Directory: „Zugriff verweigert“
Freitag, 1. Oktober 2010, 21:16
Abgelegt unter: Tipps & Tricks | Tags: , , , ,

Heute meldete sich ein Administrator-Kollege bei mir mit dem Problem, dass er eine OU verschieben möchte, dabei aber immer folgende Fehlermeldung erhalte:

Active Directory-Domänendienste:

Das Objekt <Name der OU> konnte aufgrund folgenden Problems nicht verschoben werden:
Zugriff verweigert

„Ich habe wohl nicht alle benötigten Rechte dazu“, meinte er lakonisch. Doch auch als ich als Domänen- (bzw. sogar Enterprise-)Administrator die OU verschieben wollte, durfte ich dieselbe Fehlermeldung auf meinem Bildschirm bewundern…

Dabei ist des Rätsels Lösung ganz einfach: Zum Verschieben einer OU benötigt man das Löschrecht am Ausgangsort und das Schreibrecht am Zielort.

Seit dem Windows Server 2008 existiert die Option „Objekt vor zufälligem Löschen schützen“ (engl: „Protect object from accidental deletion“), die in der Management-Konsole „Active Directory Benutzer und -Computer“ erst dann sichtbar wird, wenn die Option „Erweiterte Features“ (zu finden im Menü „Ansicht“) aktiviert wurde. Diese Option wird standardmässig auf Organisationseinheiten gesetzt und bewirkt nichts anderes, als dass in den Sicherheitseinstellungen das Recht „Löschen“ der Gruppe „Jeder“ verweigert wird. Da eine explizite „Verweigerung“ eines Rechtes alle erteilten Zugriffsrechte wirkungslos macht, kann auch ein Domänen-Administrator eine so geschützte OU nicht löschen, bis er das entsprechende Häckchen entfernt.

Und nun müsste auch klar sein, weshalb sich eine OU nicht einfach so verschieben lässt: Das benötigte Löschrecht am Ausgangsort fehlt, da dieses von der Option „Objekt vor zufälligem Löschen schützen“ verweigert wird.

Und so muss das Häckchen bei „Objekt vor zufälligem Löschen schützen“ auch dann entfernt werden, wenn die OU verschoben werden soll.

Mit Vorteil setzt man das besagte Häckchen nach erfolgter Verschiebung am Zielort wieder neu, damit der Schutz vor versehentlichem Löschen wieder gegeben ist.