Fragt das Directory Services Team

Fragt das Directory Services Team

  • Comments 5
  • Likes

Hallo zusammen,

durch Zufall kamen heute zwei Kollegen (Barbara / Deutschland und Craig / USA) darauf, daß wir beide unsere Teamblogs verlinken könnten. Nun gut dachten wir - ein Link ist Ehrensache und wurde auf der linken Seite unseres Blogs eingebaut. Bestürzt mußten wir dann jedoch gerade feststellen, daß uns der gute Ned einen ganzen Artikel gewidmet hat. Da dürfen und wollten wir natürlich nicht nachstehen. ;-)

Das "Ask the Directory Services Team" Blog ist ein wirklich geniales Blog, welches hervorragende Artikel veröffentlicht. Diese sind immer einen Blick wert. Wer also auch ein wenig Englisch spricht, wird hier sicher seine Freude haben. Der Live Translator ist ansonsten vielleicht eine Alternative - obwohl hier sicherlich ab und an wirkliche Blüten der Übersetzungskunst zu finden sind. ;-)

Viel Spaß und ein Dankeschön an Craig und Ned!

Euer "Aktives Verzeichnis" Team.

Comments
  • HALLO zusammen,

    u. a. via "http://forums.technet.microsoft.com/en-US/winserverManagement/thread/63e392b6-817e-4162-a7c5-30ca44a842e2/" (und eigentlich via Eurer amerik. Schwester-Blogsite) kam ich hierher :-).

    So: Seit ungefähr zwei Monaten benutze ich das RSAT unter einem vollständig (Autoupdate) aktualisierten Vista Business x86-deutsch; eigentlich bin ich bisher alles in allem sehr zufrieden damit, soweit es das alltägliche Administrieren eines Active Directory anlangt; ich glaube, ich habe nun (leider) den ersten Bug gefunden: verbinde ich mich mit dem DNS-RSAT-Tool auf einen W2k3-SP2-DNS (ebenfalls vollständig gepatcht) auf dem u. a. "Nicht-Active-Directory-integrierte" DNS-Zonen laufen, also absolute "Legacy DNS-Zones", und will da dann via [Eigenschaften] dieser Zone eine IP eines Secondary-DNS eintragen, der diese Zone empfangen soll, dann kommt immer die Fehlermeldung bei der Bestätigung, dass das die falsche IP wäre, was aber definitiv schonmal deswegen nicht stimmt, weil wenn ich dasselbe von einer XP-SP3-Prof.-Workstation aus via "Adminpak" durchführe, funktioniert das Ganze anschliessend astrein und die Zone wird übertragen usw. Ich kann via RSAT-DNS-Tool ja noch nicht mal diejenige IP 1.0.0.0 löschen, die sich beim nächsten Aufruf dieser Zonen-Eigenschaften mittels RSAT dann urplötzlich findet (übrigens habe ich das zwischenzeitlich verifiziert: auf dem WS03-DNS findet man dann tatsächlich einen Secondary-Eintrag "1.0.0.0" in der Registry des WS03-DNS); vielleicht hat das ja alles etwas mit IPv6 zu tun, weil einmal beim Abspeicherversuch auch die Meldung kam, dies sei keine IPv6-Zone... (was sie auch nicht ist).

    Heute morgen dann habe ich beim Microsoft-Support angerufen - dessen klare Ansage: da es sich hier (also bei RSAT) um ein kostenloses Tool handelt, wird das nur dann ein kostenloser Support-Case bleiben, wenn am Schluss dann auch ein regelrechter Bug durch Microsoft attestiert wird, anderenfalls würde es teuer...

    Via Web-Recherche wird man aktuell wahrscheinlich nicht grade viele berichtete Bugs der (deutschen) RSAT finden (mangels Verbreitung!?), wohl aber 'ne Menge berichteter Unzulänglichkeiten; eine, die auch mich ziemlich nervt, sind bspw. die fehlenden Registerkarten "Sitzungen" u. "Terminaldiensteprofil" in dem entsprechenden Active Directoy-Benutzer u.Computer-RSAT-Tool zur Verwaltung von AD-Benutzern, oder die rückwärtsgewandte Auflistung von IP-Einträgen in DNS-Zonen (wieder wie bei NT4 ;-((, wo die aufsteigende Auflistung z. B. so aussieht: IP 1.0.0.1, 1.0.0.100, 1.0.0.2 usw. das war ja beim Adminpak damals  endlich verbessert).

    Fragen hierzu: gibt es bei Microsoft schon Bestrebungen, den RSAT-DNS-Bug zu fixen ...und - wg. den fehlenden diversen Administrations-Möglichkeiten bei RSAT insgesamt im Vergleich zum aktuellsten Adminpack.msi - wisst Ihr vielleicht, dass da schon 'ne RSAT-Aktualisierung irgendwo in der Pipeline hängt!?

    DANKE! :-))

  • Hallo zurück,

    vielen Dank für Deinen Beitrag.

    Grundsätzlich versuchen wir hier in unserem Blog so viele Informationen wie möglich zu geben, jedoch können wir keinen Support bieten, wie wir es in unserer "Arbeitszeit" tun. Daher ist der von Dir gewählte Weg, eine offizielle Anfrage bei uns zu öffnen, in jedem Fall der korrekte. Daher auch unser Hinweis zu diesem Thema im "about", siehe http://blogs.technet.com/deds/about.aspx .

    Ich möchte daher nur ein, zwei grundlegende Sätze zu Deinen Fragen schreiben: Grundsätzlich durchlaufen unsere Applikationen und Dienste ein ausführliches Testing vor der Freigabe. Sollte es dann doch zu Fehlern oder Problemen in bestimmten Konstellationen kommen, ist Microsoft bemüht, die Probleme entsprechend zu fixen. Jedoch werden hierbei Prioritäten gebildet, so daß ggf. ein bestimmter Fehler (gerade bei kostenlosen Tools) zu einem späteren Zeitpunkt adressiert werden kann, als es unter Umständen bei Serverapplikationen oder sicherheitskritischen Fehlern der Fall ist. Dies ist keine Regel, kann aber vorkommen.

    Natürlich werden auch die RSAT Tools weiter entwickelt, auch wenn diese kostenlos herunterzuladen sind.  Mit Vista SP1 kam beispielsweise eine neue RSAT Konsole, die derzeit meines Wissens auch die aktuellste ist (ebenfalls die im Windows Server 2008, die  auf dem gleichen Stand wie die Vista SP1 Version vorliegt).

    Zu der konkreten Frage der fehlenden Tabs, hat das von Dir angesprochene Blog unserer Kollegen einen Artikel zu bieten: http://blogs.technet.com/askds/archive/2008/03/31/rsat-and-aduc-getting-the-terminal-services-tabs-to-appear-in-ad-users-and-computers.aspx . Dabei ist jedoch zu beachten, daß diese "Bearbeitung" der MMC nicht offiziell supportet ist.

    Viele Grüße, Fabian.

  • HALLO Fabian,

    erstmal ein dickes DANKESCHÖN! für Deine schnelle (und lange) Antwort! Also das mit dem "händischen" Nachrüsten der Terminalserver-Tabs beim RSAT-AD-User-Tool hab' ich natürlich auch gelesen ...aber was ich nicht versteh: da bringt Microsoft damals (mit ziemlicher Verspätung!) ENDLICH auch für Admins mit Vista den so oft geforderten Nachfolger vom Adminpak ...und dann ist der Einsatz - wie sich immer mehr herausstellt - nur mit der grössten Vorsicht und am besten noch mit einer Art "Backup-Legacy-Admin-Workstation unter XP" zu handeln ... und das jetzt schon seit (wenn ich mich recht erinnere) April dieses Jahres, denn da kam ja glaub ich die RSAT-RTM heraus - und Microsoft scheint m.E. immer noch nicht die wirkliche Brisanz eines evtl. in wichtigsten Kernfunktionalitäten buggy Admin-Tools zu erkennen.

    Ich bspw. hab' es bis jetzt noch nicht gewagt, PRODUKTIVE, bestehende GPOs mit der im RSAT-Zusammenhang ja ebenfalls erneuerten GPMC zu bearbeiten ...wenn's DA auch in die Hose geht - na dann Prost Mahlzeit; also nehme ich immer noch (wie wohl viele) sicherheitshalber meine XP-Installation und deren Adminpak für wirklich wichtige Admin-Arbeiten am AD ...das darf natürlich NIE ein Controller mitkriegen, der würde bestimmt nur mit dem Kopf schütteln (vielleicht nicht ganz zu Unrecht...).

    Und deswegen verstehe ich Microsoft zumindest in diesem Punkt nun wirlkich nicht. Und dazu dann diese Geschichte, das Kostenrisiko eines RSAT-Support-Cases dem Anwender mit erhobenem Zeigefinger vor Augen zu führen ("Wollen Sie wirklich einen eigenen Case dazu eröffnen!?"). Naja... Schaun mer mal ;-))

  • Ein "Hallo!" von Olaf!

    Ich klinke mich an der Stelle mit ein, da ich ähnliche Diskussionen mit Kunden schon führen durfte. Also, hier kommt die Kavallerie! ;)

    Wenn ich aus unserer Sicht - der Sicht des Support Teams - spreche, dann stehen wir zwischen den Stühlen: die Kunden auf der einen Seite, die Entwicklergruppe auf der anderen Seite. In vielen Fällen stehen wir hinter den Kunden und vertreten deren Interessen bei den Entwicklern. Ich möchte ein wenig ausholen um ein paar Hintergründe sichtbar zu machen indem ich jetzt ein wenig aus dem Nähkästchen plaudere.

    Wir führen für die unterschiedlichen Produkte Datenbanken, in denen Anfragen an die Produktgruppe verwaltet werden. Dabei handelt es sich keineswegs nur um Bugs (also Fehler im Code) sondern auch Anfragen zu neuen Features oder zu Änderungen am vorhandenen Design.  Uns stehen für solche Anfragen definierte Wege (Prozesse) offen. Wenn wir also eine solche Änderung adressieren wollen, dann wird das vom Support Techniker nach seinen Recherchen an einen sogenannte "Escalation Engineer" weitergegeben, der dann das Problem anhand des Quellcodes untersucht und - sofern möglich - eine entsprechende Codeänderung ausarbeitet. All dies geschieht noch innerhalb unseres Teams. Diese Analyse wird dann an die Produktgruppe weitergeleitet indem es in die oben erwähnten Datenbanken eingetragen wird. Die Produktgruppe wiederum bespricht dies um abzuwägen ob und/oder wie die angestrebte Änderung umgesetzt werden kann und wie diese Änderung dann ggf. publiziert wird (z.B. als frei herunterladbarer  Fix, als "quick fix" der über den Support angefordert werden muss, als Bestandteil des kommenden Service Packs oder über andere Kanäle).

    Nun werden aber von den Entwicklern oder auch von Mitarbeitern aus anderen Abteilungen Programme (nennen wir sie mal der Einfachheit halber "Tools") entwickelt, die es - warum auch immer - nicht in den Lieferumfang des Produktes "geschafft" haben. Die Gründe hierfür können vielfältig sein und ich will an dieser Stelle bewusst nicht weiter darauf eingehen. Solche Tools werden dann außerhalb des Produktes zum Download bereitgestellt. Sie durchlaufen daher auch nicht das gleiche, sehr aufwendige Testprozedere, welches die "normalen" Produkte durchlaufen. Das bedeutet nicht, dass kein Testing stattfindet aber eben nicht im gleichen Umfang. Daher kann es durchaus sein, dass ein solches Tool in einem Szenario eingesetzt wird, welches nicht getestet wurde. Daher rührt die eingeschränkte Unterstützung durch den Support. Mit der Zeit finden solche Tools auch den Weg in das Produkt. So zum Beispiel mit RoboCopy (http://technet.microsoft.com/en-us/library/cc733145.aspx) geschehen.

    Für uns als Supportmitarbeiter ergibt sich bei diesen Tools ein entscheidender Unterschied zu den normalen Produkten: der oben beschriebene Eskalationspfad existiert für diese Tools in dieser Form nicht! Zwar gibt es auch dafür eine Datenbank aber es existieren keine verbindlichen oder nur eingeschränkte Zusagen seitens der Entwickler darüber, wie im Falle einer angestrebten Änderung verfahren wird. Da die Entwickler dieser Tools in der Hauptsache an der (Weiter-) Entwicklung des Produktes beschäftigt sind, erklärt sich daraus auch die Notwendigkeit der unterschiedlichen Prioritäten. Wir sind uns alle einig, dass ein Bug oder eine entdeckte Sicherheitslücke (z.B. in der Policy Engine) dringender zu beheben ist als eben die Pflege eines solchen Tools.

    Nun besteht aber für Kunden auf Basis eines Support-Vertrages die Möglichkeit auch Anfragen zu solchen Tools zu eröffnen. Die kurze Antwort auf eine solche Anfrage könnte im Kern in etwa lauten: "Dieses Tool wird vom Support nicht unterstützt, wir werden die Information weiterleiten.". Natürlich würden wir das nicht so kurz und knapp weitergeben, sondern hübsch verpackt kommunizieren :) Wir würden uns mit so einer Aussage auf sicherem Eis bewegen was die Supportbestimmungen angeht, aber wir wären damit nicht wirklich kundenfreundlich.  Daher finde ich den Hinweis auf die möglicherweise anfallenden Kosten absolut angebracht um den Kunden vor einer "bösen Überraschung" zu schützen. Denn stellt sich im Verlauf der Anfrage heraus, dass der Code des Tools funktioniert und wir hier z.B. auf  eine Limitierung der Funktionalität gestoßen sind, dann wäre dies wirklich nicht als Bug zu verstehen und damit erst einmal für den Kunden kostenpflichtig. Dies gilt gleichermaßen für Tools als auch für die eigentlichen Produkte.

    Ein an den Haaren herbeigezogenes Beispiel: Wer meint, dass der Desktophintergrund aus karierten Maiglöckchen bestehen MUSS, dem werden wir nach einer ausführlichen Recherche bestätigen, dass in Windows kein Code existiert, der karierte Maiglöckchen als Desktophintergrund generiert. Ist das ein Bug? Ganz sicher nicht. Das wäre dann der Fall, wenn sich auf dem Desktop anstatt der laut Code angestrebten karierten Maiglöckchen die karierten Tulpen tummeln. Somit hätten wir es mit einem fehlenden Feature zu tun, welches der Kunde anfordern kann...denkt nicht einmal dran... ;)

    Nun mag man erwarten, dass dies dem Kunden ja nicht zwangsläufig berechnet werden muss und die Kulanz hier greifen könne. Dem muss ich entgegnen, dass mit der Bearbeitung einer Anfrage ein nicht unerheblicher Zeitaufwand entsteht. Die potentielle Masse an solchen "Kulanzfällen" würde die Kosten rasch aufsummieren. Ganz zu schweigen davon, dass man schwerlich eine Grenze zwischen Kulanz und nicht Kulanz ziehen kann.

    Sicher haben die RSAT-Tools Ihren Stellenwert aber wir dürfen nicht vergessen, dass es sich trotzdem "nur" um ein zusätzliches Tool handelt. Auch wenn es dem Admin das Leben oft erleichtert. Worum es uns hier im Blog (bzw. in diesem Thread im Besonderen) geht, ist ein Verständnis dafür zu schaffen, wie sich eine solche Situation für uns als Supportmitarbeiter darstellt. Wenn mir das gelungen ist, dann sollte deutlich geworden sein, dass wir an dieser Situation im Allgemeinen nichts ändern können und damit auch keine Grundlage für eine tiefergehende Diskussion haben. Wir bewegen uns schon jetzt gewaltig "off topic" von dem, was wir mit diesem Blog erreichen wollen und ich zitiere hier aus unserem "About" (http://blogs.technet.com/deds/about.aspx):

    Mit diesem Teamblog möchten wir eine Ergänzung zu den üblichen Knowledgebase-Artikeln sein. Aus unserer täglichen Erfahrung mit komplizierten Fällen, haben wir einen großen Erfahrungsschatz angehäuft, den wir so mit Euch teilen wollen. Gerade die Tipps und Vorgehensweisen aus der Praxis, die sich nur bedingt in KB-Artikel, Whitepaper oder andere Publikationsformen bringen lassen, sind aus unserer Sicht sehr wertvoll. Bevor wir hier gar nichts machen, haben wir uns im Sinne unserer Kunden entschieden diesen Teamblog aufzusetzen und ihn mit „Notizen aus dem deutschen Domain Team“ anzureichern... wobei sich deutsch auf deutschsprachig bezieht.

    In diesem Sinne appelliere ich daran, dass wir uns wieder den eigentlichen Themen dieses Blogs zuwenden und uns nicht tiefer in diese Sache verrennen. Danke!

    Gruss

    .olaf

  • Re-Hallo Olaf! :-))

    Danke für Deine umfassende Antwort, ich schau dann ab und an mal nach "entwanzten" RSAT-Updates/Upgrades/-Nachfolgern, Patches hierfür usw. usf.

    RDP-SRV-Sessions: ab jetzt wieder my best friend!

    Gruss

    Thomas

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment