Thursday, July 30th, 2009...11:09 pm

Ex2007SP2 – Krok w stronę virtual directory … no nie do końca

Jump to Comments

Pomiędzy wieloma sukcesami i porażakmi jedno się firmie, w której obecnie pracuję udało i to trzeba jej przyznać … nastraszyć użytkowników przed rozszerzaniem schematu usługi katalogowej. Problematyczny przekaz zaczął być nadawany gdzieś w okolicach Windows 2000, i jak to z przekazem – różnie zrozumiany i różnie przekazany osiągnął swój cel … użytkownika. I użytkownik przelękniony został i duża część z nich pozostaje przelękonia do dziś.

Implikacje tego są różne, od zapewnienia mi jako konsultantowi zajęcia przy przekonywaniu managementu że jednak to nic takiego i zrobić się da (za chwilę mała anegdotka) po wprowadzanie zmian w kodzie aby rozszerzenia schematu uniknąć w Service Pack bo to adopcję tychże skutecznie blokuje (dociekliwych odsyłam do Windows 2003 SP1 – nawet jakiś mini konkurs możemy zrobić o co mi chodziło 🙂 ).

Obiecana anegdotka z życia konsultanta; Razu pewnego właśnie takiemu zajęciu byłem oddany, czyli przekonywaniu managementu że schemat do Windows 2003 rozszerzyć się da. Przekonywanie było wielostopniowe, obejmowało moją analizę środowiska, analizę schematu pod kątem potencjalnych konfliktów, testy w labie … i odbywało się w kraju zamorskim (no powiedzmy zakanałowym).

Ostatnim akcentem było spotkanie z tymże management, który wysłuchawszy różnych argumentów, wyników analiz i konieczności biznesowej uzasadniającej wykonanie tej operacji zadał tylko jedno pytanie, skierowane jakby do mnie:

Management: A gdzie Pan będzie  w trakcie wykonwyania tej operacji?

Ja; Oczywiście w Polsce !

O ile wiem nie napotkali na żadne problemy :).

Wracając jednak na tor rozumowania tego wpisu. Na kolejne pokłosie tego zjawiska, czyli strachu przed schematu rozszerzaniem, przynajmniej według mnie, natrafiamy nieoczekiwanie w Exchange 2007 SP2 a więc i w kolejnych wersjach Exchange jak najbardziej też. Nosi to cudo nazwę: Dynamic Active Directory Schema Update and Validation, cytując:

The dynamic AD schema update and validation feature allows for future schema updates to be dynamic deployed as well as proactively preventing conflicts whenever a new property is added to the AD schema. Once this capability is deployed it will enable easier management of future schema updates and will prevent support issues when adding properties that don’t exist in the AD schema

(cc) origamidon

Lakonicznie jak narazie. Dzisiaj trochę przypadkiem wpadł mi w ręce opis działania tego mechanizmu i wynika z niego iż:

  • sterownik Exchange korzystający z katalogu przy próbie odczytu danych jest świadom (na podstawie danych ze storu), że dany atrybut jest dynamiczny
  • W przypadku odczytu danych, nawet jeżeli schemat nie został rozszerzony i taki atrybut nie istnieje, z poziomu Exchange uzyskana zostanie informacja że atrybut taki nie ma wartości (<not set> – ktoś pamięta moje pytanie z prezentacji na HHH odnośnie wartości boolean w AD?)
  • W przypadku próby zapisu do takiego atrybutu Exchange rzuci odpowiedni wyjątek, w końcu atrybut ten nie jest dostępny “fizycznie”.

Co to oznacza w parktyce. A więc w praktyce oznacza to tyle, że w przyszłości grupa produktowa może zaimplementować nowe rozszerzenie funkcjonalności, które będzie wymagało rozszerzenia schematu. Rozszerzenie to przyjdzie na przykład w formie roll-up update dla Exchange z dołączonym LDIF z rozszerzeniem schematu. Ci którzy będą chcieli z tej funkcjonalności skorzystać rozszerzą schemat i już. Inni zaś, będą mogli wdrożyć uaktualnienie, ale bez konieczności roszerzenia schematu. Efektem tego będzie brak możliwości skorzystania z tej nowej funkcji lub jej działanie jak w przypadku wartości  <not set> dla odpowiednich parametrów. Ale samo uaktualnienie Exchange będzie wdrożone.

Sytuacja taka będzie:

  • Bardzo wygodna dla grupy produktowej przy wypuszczaniu kolejnych uaktualnień dla Exchange
  • Elastyczna dla klienta, który będzie mógł z nowości korzystać lub nie, a kwestia rozszerzenia schematu nie będzie mu blokowała wdrożenia uaktualnienia w środowisku Exchange.  W szczególności gdy zespół zajmujący sie Exchange i katalogiem to dwie różne grupy ludzi.

Jedyny problem jaki widzę to ewentualna konieczność dokładniejszego (o ile już istnieje) przestrzegania zasad związanych z utrzymaniem schematu i jego dokumentacją (ręce do komentarzy kto takie ma opisane i wdrożone) aby wiedzieć co już zostało zaaplikowane a co nie.

PS dla samego siebie: I tym sposobem do listy zadań do wykonania dopisany został wpis w temacie “Schema governance”.

I co to ma wszystko wspólnego z tytułowym katalogiem wirtualnym?? A tyle, że podobna funkcjonalność to opcja dostępna w każdym ze znanych mi rozwiązań typu virtual directory. Oczywiście w tego typu rozwiązaniach nie sprowadza się ona tylko do możliwości odczytu bez powodowania wyjątku ale również do zapisu takiegoż atrybutu i rozszerzenia schematu w trybie on-line. I tak oto zalążek takiego mechanizmu pojawia się w Exchange.

Czy to dobrze czy to źle?  W zasadzie narazie nie ma co tego oceniać. Jeżeli o mnie chodzi to z chęcią bym to widział zaimplementowane raczej na poziomie usługi katlaogowej tudzież Web Service dla AD. Bardziej spójne i wyznaczyłoby też nowy kierunek rozwoju tej usługi.

Podejrzewam jednak, że jak to często bywa plany co do zmian się nie zgrały w czasie i zostało to zaimplementowane przez zespół Exchange aby rozwiązać ich obecne i przyszłe problemy z wdrożeniami uaktualnień. Ciekawe tylko czy ten kawałek funkcjonalności będzie nadal rozwijany … i w jakim kierunku. Zobaczymy.

A jak to wszystko będzie działoło … to też zobaczymy (i to można by powiązać z pewnym skeczem kabaretu Potem – z jakim, to też może być minikonkurs).

9 Comments

  • Z tym rozszerzaniem schematu to równocześnie w dwóch kierunkach Microsoft odniósł sukces: Po pierwsze użytkowników przestraszył tak jak napisałeś, a po drugie – nieco zmotywował programistów do myślenia. Jakieś 8 lat temu, to chyba niewiele było w przyrodzie aplikacji, które nie miałyby zapędów do dłubania w schemacie…
    Użytkownicy się tego przestraszyli a programiści nauczyli, że może da się inaczej i że istnieją lepsze miejsca na przechowywanie danych. Przynajmniej ich części.
    Ale sukces faktycznie jest i trudno go nie zauważyć. 😉

  • Myślę że to nie do końca tak … to znaczy
    – nie ma nic złego w tym, że aplikacje przechowują dane w katalogu. W końcu do tego jest. Z drugiej strony pytanie czy wszystkie dane … i tutaj architekt takiego rozwiązania powinien pomyśleć chwilę czy napewno to ma sens i co zyskuje dzięki temu że te dane w katalogu umieści.
    – teraz … to raczej nie Microsoft wpłynął na programistów tylko fakt, że klienci mieli opory przed wdrażaniem oprogramownia, które rozszerzało schemat spowodował że ISV przestali tak chętnie z tego rozwiązania korzystać.

    Inna sprawa że firmy tworzące oprogramowanie podchodziły do sprawy lekko bardzo i na przykład używały tych samych OID należących do kogoś innego – i to nie tylko małe firmy ale te i większe też. Co dodatkowo komplikowało sprawę zarówno z punktu widzenia klienta (bo mam problemy przy wdrożeniu i nigdy nie wiadomo co się stanie) jak i po stronie firmy (bo nasz software nie wdraża się w prosty sposób i klienci nie chcą go używać).

    Czyli nakłada nam się tutaj:
    1/ Strach przed rozszerzeniem schematu u klienta
    2/ Brak ( w większości wypadków ) procesu i procedur związanych z utrzymaniem w ryzach zmian w schemacie, co zminimalizowałoby problem z punktem 1.

    No i tak to …

  • Ależ ja nie mam wątpliwości, że to klienci wymusili na twórcach oprogramowania sensowne praktyki. Wytyczne Microsoftu to nie jest coś, co programiści czytają. A słupki sprzedaży przełożą się na jakość kodu albo firma zniknie.

  • … skoro mini konkurs…
    “na słowo działało – na słowo przestało” heh już dawno nie słyszałem/widziałem odniesienia do Ich twórczości.

  • @Tomasz-etora
    No mi bardziej chodziło o skecz z Dratewką i
    (…) Oj… (Król dobrze wiedział, co smok mu może pokazać!) O jak on mi strasznie pokaże! Oj, jak ja okropnie zobaczę! (…)

    Ale skojarzenie też dobre :). Niestety nagrody innej niż uścisk dłoni w wypadku spotkania nie mogę obiecać :).

  • Mi się zawsze jedno kojarzy:
    Będzie Pan zadowolony! 🙂

  • @Bastiusz
    Ty to chyba masz jakieś doświadczenia z konsultantami 🙂 … ale to jest inny kabaret :). Znaczy cytat jest z innego kabaretu a nie konsultanci :).

  • Tomku to ja Ci powiem skąd się bierze obawa klientów (patrząc z Twojej perspektywy) przed rozszerzaniem schematu AD. Najlepiej na przykładzie rozmowy z bardzo sympatycznym konsultantem :
    klient : Hmm, a co będzie jak się z jakiegoś powodu nie uda rozszerzenie schematu ? Jaki jest najgorszy scenariusz ?
    konsultant : No trzeba wtedy wykonać procedurę Forest Recovery.
    klient : Aha, a robił pan to już kiedyś w produkcji w środowisku porównywalnym do naszego ?
    konsultant : Hmmm, nie.

    Oczywiście klient powinien posiadać procedury (przetestowane) recovery swojego środowiska itp, ale tu już inny temat.

  • @Papi
    Hej … kopę lat :). A co do rozmowy z konsultantem 🙂 niewątpliwie sympatycznym … to wyciągasz nieprawidłowe wnioski tudzież nie zadajesz dalszego ciągu pytań:

    (…)
    Klient: a ile razy rozszerzał Pan schemat ?
    Konsultant: ło matko panie, co tydzień, w zasadzie już nie pamiętam. Ostatnio chyba w zeszły czwartek
    Klient: a ile razy wynikły problemy tego powodu wymagające odtworzenia lasu
    Konsultant: nigdy panie. zero …
    (…)

    I tutaj dochodzimy do tego, że operację rozszerzenia schematu można dobrze przygotować i przetestować. Ryzyko wystąpienia problemu jest raczej znikome (proponuje ćwiczenie polegające na zastanowieniu się jakie problemy związane z roszerzeniem schematu mogą skutkować potrzebą odtworzenia tej partycji katalogu), mechanizmy katlaogu skutecznie zabezpieczaja przed duplikatami OID, duplikaty nazw nie stanowią takiego problemu, można je skorygować. Uprawnienia??? Uszkodzenie fizyczne bazy??

    Operacje odtworzenia lasu też można przygotować i przetestować. Testowanie jej w warunkach producyjnych jest dosyc problematyczne, ale w środowisku lboratoryjnym da się ją dosyć dobrze odwzorować.

    Na marginesie już tylko, jedyne przypadki związane z forest recovery o jakich slyszalem nie byly zwiazane z odtworzeniem schematu a z innymi problemami.

    Z innej beczki … a przed podnoszeniem poziomu funkcjonalnego lasu to już obaw takich nie ma 🙂 … a procedura cofnięcia operacji jest dokładnie taka sama :).

    Widzę że nad tematem trzeba się pochylić edukacyjnie :).

Leave a Reply