 Windows Scripting Host
WSH czyli Windows Host Script, to mechanizm pozwalający uruchamiać skrypty bezpośrednio z Explorera - klikając na nich, lub z linii komend - jak normalny program. Uruchamiany skrypt jest obsługiwany przez odpowiednią bibliotekę ActiveX. Dzięki temu skrypt może być napisany w dowolnym języku - standardowo VBscripcie lub JavaScripcie, po zarejestrowaniu dodatkowych bibliotek również w Pythonie i Perlu, ale można poszukać i innych bibliotek. Innymi słowy, w systemie Windows 2000 standardowo instalowane są dwa programy - wscript.exe i cscript.exe. Rozszerzenia takie jak .vbs czy .js są skojarzone właśnie z nimi. Wscript daje możliwość uruchamiania skryptów niejako w trybie okienkowym, cscript w trybie konsolowym. Aby ułatwić życie programiście, pliki skojarzone są domyślnie z wscript.exe. Tryb uruchomienia (konsolowy/graficzny) wybieramy ustawiając odpowiedni parametr przy uruchomieniu. Ustawieniem domyślnym jest na tryb okienkowy. Z resztą wystarczy napisać wscript /? i wszystko będzie jasne.
Przykład:
- załóż plik z rozszerzeniem .vbs
- wpisz: WScript.echo "coś tam wpisz - może standarodwe hello world?"
- zapisz i uruchom w Explorerze.
Powinno pojawić się na ekranie okienko - messagebox - z tekstem jaki wpisałeś. Teraz odpal konsolę i ustaw opcje trybu uruchamiania wscript na konsolowy (wscript //h:cscript). Dwa razy kliknij na swoim skrypcie i zobaczysz, że na chwilę odpaliło się okno konsoli. Proponuję teraz z linii komend uruchomić program - zupełnie jak normalnego exe'ka - wpisując jego nazwę. Teraz różnica jest chyba jasna?
—eby nie ograniczać się tylko do jednego języka to samo dla JScriptu:
- załóż plik z rozszerzeniem .js
- wpisz: WScript.echo ("cos tam wpisz - moze standarodwe hello world?");
- zapisz i uruchom w Explorerze.
Jak widać można pisać to samo w języku najłatwiejszym dla piszącego - różnią się składnią zapisu.
Więcej ogólnych informacji można znaleźć w pomocy Windows 2000 w temacie WSH overview.
Active Directory Service Interfaces
Przy pracy jaką jest administracja na pewno wykorzystamy ADSI - Active Directory Service Interfaces - który jest standardem definiującym kolekcję abstrakcyjnych interfejsów programistycznych (COM), dzięki którym każdy może w łatwy sposób operować na różnych serwisach katalogowych (Directory Services) i odwoływać się do nich, za pomocą jednorodnego zbioru interfejsów.
Najbardziej znanym API jest ODBC (Open Data Base Connetivity), które pozwalają programistom pisać aplikacje działające z każdą bazą, która tylko obsługuje ODBC. ADSI jest analogicznym narzędziem do pracy z serwisami katalogowymi.
Mówiąc bardziej po ludzku: Novell, Microsoft i pewnie kilka innych firm, oferują organizację struktury sieci jako drzewo katalogowe zwane Directory Services. W przypadku Novella będzie to eDirectory (kiedyś NDS), w przypadku Windows Active Directory itd. W każdym takim drzewie występują pewne wspólne charakterystyczne obiekty - np. użytkownik (user). Dzięki ADSI można odwoływać się do takich obiektów z poziomu skryptu, w jednorodny sposób. Jest to powłoka pośrednicząca pomiędzy natywnymi funkcjami konkretnego providera a nami.
Bardzo dokładny opis (z którego wzięte są powyższe obrazki) można znaleść w płytowym wydaniu MSDN, lub online na stronach Microsoftu.
Common Object Model
Common Object Model - w skrócie COM. Dla osób znających angielski polecam lekturę strony Gopalan Suresh Raj'a, na której wszystko jest bardzo dokładnie wytłumaczone. Poniżej spróbuję streścić jej zawartość:
Od dawna dąży się do obiektowości (obiektowe języki programowania, obiektowe bazy danych etc.), ponieważ takie podejście ułatwia programowanie/projektowanie i umożliwia wymianę informacji pomiędzy obiektami. COM jest próbą stworzenia systemu operacyjnego, zbudowanego z binarnych obiektów, które mogą wymieniać się między sobą informacjami, używać publicznych metod i ustawiać/sprawdzać pola nie korzystając z protokołów/mechanizmów wyższych warstw (DDE, TCP/IP, sockets, memory-mapped I/O, named pipes). Komponenty stworzone w architekturze COM dają możliwość komunikacji się dwu (lub więcej) niezależnych obiektów - choćby pracujących na innych komputerach - poprzez wywoływanie metod tychże obiektów.
W architekturze COM, w jakiej jest zbudowany Windows 2000/XP, system operacyjny pełni rolę centralnego rejestru obiektów (polecam zajrzeć sobie do gałęzi rejestru HKCR/TypeLib oraz HKCR/CLSID). Jego zadaniem jest utworzenie obiektu jeśli wystąpi takie żądanie, kasowanie, kiedy już nie jest potrzebny oraz obsługa komunikacji pomiędzy obiektami. Kolejną zaletą takiej budowy jest fakt, iż jeśli zupdate'uje się pojedynczy obiekt COM do nowej wersji, nie trzeba przekompilowywać całej aplikacji, ponieważ jest zbudowana wykorzystując istniejące w systemie obiekty.
Obiekty COM są niezależne - nie należą do żadnej aplikacji. Aplikacje mogą jedynie wykorzystywać metody i parametry udostępniane przez dany obiekt. Jeśli nie znają ich nazw, mogą się o nią zapytać.
Dodatkowe informacje znajdują się na stronach Microsoftu.
ActiveX
ActiveX jest ogólnie rzecz ujmując częścią technologii COM, która wyewoluowała z OLE (Object Linking and Embedding) - oficjalnie jest trzecią wersją OLE. Innymi słowy ciężko jest konkretnie powiedzieć czym jest ActiveX - po prostu technologią opatentowaną przez Microsoft, próbującą połączyć kilka technologii w jedną. Zazwyczaj mówi się o kontrolkach ActiveX, które tą technologię implementują. Kontrolki ActiveX - czyli obiekty COM z pakietu ActiveX - są zaprojektowane w celu ułatwienia dystrybucji komponentów w sieciach rozległych oraz umożliwienie sterowania poprzez przeglądarkę WWW. Kontrolki takie mogą być w razie potrzeby automatycznie ściągniete i zainstalowane przez przeglądatkę, przy czym technologia Active-X zawiera implementację certyfikatów i autoryzacji. Active-X jest trochę podobne do appletów Javy z kilkoma podstawowymi różnicami:
- Active-X daje większe możliwości ale kosztem bezpieczeństwa, ponieważ korzysta z bezpośredniego dostępu do systemu operacyjnego (po to certyfikaty i autoryzacja);
- nie jest językiem programowania, a raczej zbiorem zasad informujących w jaki sposób aplikacje mają wymieniać się informacjami (COM);
- działa tylko na platformach Windows.
Dodatkowe informacje znajdują się na stronach Microsoftu.
Skrypt
Skrypt to mikro-program, którego się nie kompiluje. Parser (program analizujący) odpowiedzialny za uruchomienie skryptu, kolejno wykonuje komendy, które się w nim znajdują. Nie ma fazy pre- i postprocesingu.
Mówiąc w skrócie, jeśli często wykonuje się zestaw jakichś komend, można je spisać (zgrupować) w jednym pliku, żeby sobie uprościć życie.
Nie wszystko złoto co się świeci
Po przeczytaniu powyższych informacji, można by pomyśleć, że cały ten system jest genialny i bez zarzutu. Jest to oczywiście nieprawdą. Po pierwsze wszystko to jest teorią. Jak daleko jest od teorii do praktyki chyba nie muszę pisać. To, co się dzieje we wnętrzu Windowsa, zostanie owiane mgiełką tajemnicy do końca świata z prostego powodu - jest to jeden wielki kocioł (podobno nad Windows XP pracowało 6o.ooo osób!!!) - mówiąc bardzo delikatnie. Nie wszystko działa tak, jak by to wynikało z opisu czy intuicji, nie wszystko da się odnaleźć i nie wszystko jest w ogóle udostępnione, a są i takie rzeczy, których tak naprawdę nie ma (jeśli nie zrozumiałeś - nie martw się: nikt tego nie rozumie). Największym problemem jest bezpieczeństwo tego całego systemu, a to głównie przez ActiveXy, które umożliwiając bezpośredni dostęp do systemu poprzez Internet Explorera, są potencjalną dziurą (exploity, setki programików i skryptów dostępnych w setkach miejsc są dowodem na to, że nie tylko potencjalną). O ile więc jest to niewątpliwie wspaniały pomysł i bardzo dobry kierunek rozwoju dla systemów operacyjnych, o tyle należy zawsze pamiętać o drugiej stronie lustra, po której czycha świat wizji i zakręconych iluzji.
Jak napisać ten advanced script o którym w tytule? Czy skrypty w Windows dają duże możliwości? czy Bill Gates kontroluje świat przez ActiveXy? O tym i o wielu innych rzeczach dowiecie się w dalszej części...
W pierwszej części było trochę objaśnień skrótów. Teraz krótko o idei jak to wszystko działa i przejdę do ciekawszych kwestii, czyli samych skryptów.
Idea jest bardzo przyjemna - można ją porównać do klocków lego albo lepiej do małego programu z dużą ilością wtyczek. Tym programem jest WSH, który ma swoją specyficzną budowę i funkcjonalność. Za wykonanie funkcji zaczynających się od WScript odpowiada właśnie on:
WScript.echo "tą funkcję obsłużył WSH 'sam w sobie'"
Na tym opiera się cały szkielet pisanych skryptów, ale nie daje w zasadzie żadnych możliwości. Ponieważ jednak nadaliśmy naszemu plikowi konkretne rozszerzenie - standardowo vbs lub js - mamy pełne możliwości jakie daje nam wybrany język skryptowy, za pośrednictwem odpowiedniej biblioteki.
Dim i
i = 10
Za interpretację tego kawałka odpowiedzialny jest parser VBasic Script Edition. Trochę oszukałem. Tak na prawdę to nie jest do końca w ten sposób, ale zrozumienie takiej idei w zupełności wystarczy i nie jest to zbyt odległe od prawdy. Ciekawsze i tak się dopiero zaczyna. Jeśli chcę sprawdzić jakieś dane użytkownika w domenie muszę odwołać się do Active Directory. Do tego stworzony jest interfejs - ADSI, co można porównać do wtyczki:
Dim oDomain
set oDomain = getObject("LDAP://pjwstk.edu.pl/DC=pjwstk,DC=edu,DC=pl")
W tym momencie utworzyłem obiekt, którym będę mógł manipulować za pomocą interfejsów ADSI. Skąd wiedział, że to ma być ADSI? Bo przecież napisane jest "LDAP://". Na podstawie tego ciągu automatycznie wywołanie przeniesione jest do biblioteki odpowiedzialnej za komunikację z AD. Z definicji przedstawionych na początku powinieneś[naś] pamiętać, że ADSI jest uniwersalnym interfejsem do komunikacji z usługami katalogowymi - jak sama nazwa wskazuje. Do bazy użytkowników w Windows 2000 można się dostać za pośrednictwem dwóch providerów - WinNT oraz LDAP. Jeśli chciałbyś modyfikować użytkowników na serwerze Novellowym musiałbyś użyć providera NDS (nie mam takiego serwera, ani potrzeby, więc nie testowałem).
Którego providera używać - WinNT czy LDAP? Jest to jedno z tych pytań, na które nie ma jednoznacznej odpowiedzi. —aden z interfejsów nie ma pełnej funkcjonalności. Active Directory jest bazą LDAP, poza tym interfejs LDAP daje więcej możliwości, więc poleciłbym używanie tego właśnie. Jednak pewne czynności, które są bardzo proste za pomocą WinNT, wymagają więcej wysiłku przy użyciu LDAP. A są i takie, których nie da się za jego pomocą zrealizować (np. podłączenie się do komputera lokalnego - na którym przecież AD nie działa).
W podobny sposób mogę tworzyć obiekty przeróżnych typów - ich obsługą zajmą się odpowiednie biblioteki - czy będzie to plik bazy danych czy arkusz Excela. Po to właśnie są interfejsy. Oto przykład jak za pośrednictwem ActiveX można działać na plikach Excela:
set oExcel = wscript.CreateObject("Excel.Application")
oExcel.workbooks.open("C:|temp|test.xls")
WScript.echo oExcel.ActiveSheet.Cells(1,1).Value
oExcel.quit
W powyższym przykładzie WSH za pośrednictwem tzw. kontrolek ActiveX - czyli interfejsu ActiveX - otwiera plik przygotowany w Excelu, oraz wypisuje wartość pierwszej komórki na ekran. Od razu powiem, że dzięki podobnej metodzie można sobie wygenerować całościowy raport w Excelu razem z wykresami itp. nad czym zamierzam w przyszłości popracować i czego nie omieszkam opublikować, jeśli mi się uda.
Schema Management
Ze względu na charakter mojej pracy, w dalszej części artykułu znajdą się informacje głównie o wykorzystaniu skryptów w celach administracyjnych - modyfikacje użytkowników itp. Zanim zacznie się pisać skrypty modyfikujące cokolwiek, warto by wiedzieć, co w ogóle można modyfikować. Aby dowiedzieć się jakie atrybuty mają obiekty w ActiveDirectory należy wykonać dwie czynności:
- zarejestrować bibliotekę %systemroot%|system32|schmmgmt.dll (regsvr32 %systemroot%|system32|schmmgmt.dll)
- uruchomić snap-in "schema management" (%systemroot%|system32|schmmgmt.msc).
Pokrótce co tam widać: Wypisane są tam wszystkie klasy (Classes) oraz atrybuty (Attributes) dostępne w schemacie dla danej domeny. Jeśli chcemy zobaczyć, co możemy zrobić z użytkownikiem, należy rozwinąć Classes i kliknąć obiekt user. Po prawej stronie wyświetlą się wszystkie atrybuty dostępne dla danego obiektu. Każdy atrybut ma pięć cech:
- Name - nazwa atrybutu;
- Type - typ, może być Mandatory lub Optional;. Artybuty typu Mandatory (obligatoryjne) są wymaganym minimum podczas tworzenia obiektu. Np. możemy nie ustawiać imienia użytkownika, ale musimy podać jego samą nazwę konta (accountname) - czyli nazwę obiektu SAM (Security Accounts Manager Account Name);
- System: - czy jest atrybutem systemowym czy nie; do końca jeszcze nie wiem co to jest, ale wydaje mi się, że jeśli schemat zostanie rozszerzony o jakieś klasy, to klasy te nie będąc systemowymi będą oferować niesystemowe atrybuty - wkrótce to sprawdzę;
- Description: - beznadziejny, niewiele mówiący opis atrybutu;
- Source Class: - jako że jest to w pełni obiektowa struktura, klasy mogą implementować inne klasy - to pole pokazuje z jakiej klasy dziedziczony jest dany atrybut.
Aby dowiedzieć się więcej na temat atrybutu możemy go poszukac w części Attribiutes i poza jego nazwą i skromnym opisem możemy sprawdzić coś całkiem ciekawego: Syntax, co jak często się zdarza Microsoftowi jest nazwane dość myląco - jest to po prostu typ danej.
Zauważyłem, że WSH nie potrafi sobie radzić ze zmiennymi typu Large Integer, mimo że w dokumentacji jest np. funkcja CLng konwertująca liczbę do typu Long. Jak się okazało po głebszych poszukiwaniach - VBScript nie obsługuje 64bit Integer'ów. Próba wyświetlenia parametru takiego typu spowoduje błąd. Przykład:
set oUser=("LDAP://moja.domena.com/CN=user,CN=user,DC=moja,DC=domena,DC=com")
WScript.echo oUser.lastLogon
spowoduje błąd
[ścieżka do pliku](nr linii, nr wiersza) Microsoft JScript/VBscript runtime error: Type mismatch
Zmienne tego typu można wyświetlić pisząc:
WScript.echo oUser.lastLogon.lowPart&oUser.lastLogon.highPart
Aby wykorzystać taką zmienną należy ręcznie przeliczać każdą z "połówek" całej liczby.
Na koniec kilka stron poświęconych skryptom, które przyda się odwiedzić:
Przede wszystkim polecam jednak korzystanie z MSDNa - informacje tam zawarte są dość suche (poza artykułami oczywiście), ale przy odpowiedniej wprawie szybko można znaleźć informacje. Można go również zainstalować lokalnie (jeśli oczywiście wykupiło się subskrypcję MSDN).
To, co najmniej przyjemne, może stać się jedną z przyjemniejszych rzeczy. Mówię oczywiście o porównaniu tych najbardziej repetytywnych czynności administracyjnych jak np. zakładanie kont, a pisaniu wszelkiego rodzaju skryptów, które zrobią to za nas. Tak jak wspominałem wcześniej, będę się zajmował wykorzystaniem WSH niemal wyłącznie do celów administracyjnych. Zacznę od wcześniej wymienionego przykładu, czyli zarządzanie użytkownikami.
Aby rozpocząć prace nad pisaniem skryptów związanych z użytkownikami w Windows 2000, trzeba wiedzieć kilka podstawowych rzeczy o LDAPie. Podstawową informacją jest czym jest w ogóle LDAP. Jak sama nazwa wskazuje, Lightweight Directory Access Protocol jest standardem dostępu do usług katalogowych. Można z przymrużeniem oka zrozumieć to jako standard dostępu do bazy danych, opisującej obiekty naszej sieci.
Chyba zapomniałem napisać po co w ogóle mowa o LDAPie? ActiveDirectory jest usługą katalogową, która stanowi trzon całej domeny Windows 2000+. Dostęp do AD można uzyskać za pomocą jakiegoś protokołu - jest nim LDAP. Tyle teorii na razie zupełnie wystarczy.
Aby zmodyfikować obiekt użytkownika, pierwszą rzeczą, którą trzeba zrobić, to odpalić ADUAC. W Active Directory For Users And Computers bardzo ładnie widać całą strukturę domeny. Osoby, które miały okazję popracować na Windows NT 4.0, w której cała struktura sprowadza się do placka ziemniaczanego, będą potrafiły w pełni docenić nowy image domeny. W końcu wszystko jest poukładane logicznie i fizycznie i możemy ten układ w zależności od potrzeb modyfikować.
Kontenery i inne
W Active Directory są dwa podstawowe rodzaje obiektów - kontenery i ... niekontenery. Kontener jest obiektem grupującym. Kontenery dzielą się na: OU (Organizational Units czyli Jednosktki Organizacyjne) oraz CN. Tu pierwsza niespodzianka - CN, czyli Common Name to oznaczenie zwykłych obiektów. Ale jest rodzaj kontenera, który jest po prostu kontenerem i ma właśnie oznaczenie CN (Container). To nie moja wina. Poza tym są różne inne obiekty różnej klasy widoczne pod nazwą CN.
Ja bym nie zrozumiał o co mi chodzi, więc bardzo szybko przykład, zanim się ktoś załamie:
LDAP://chlewik.com/CN=pysiaczek,CN=users,DC=chlewik,DC=com W tym zapisie widać wszystko co trzeba, czyli po rokładzie gramatycznym zdania mamy następujące części mowy:
- LDAP:// - które pokazuje, że będziemy się posługiwać protokołem LDAP,
- chlewik.com - tą część można pominąć jeśli mamy w ustawieniach TCP/IP ustawione odpowiednie rozszerzenie domeny. Dla nabrania dobrych nawyków - polecam pisać.
- CN=pysiaczek - to użytkownik o którego nam chodzi. CN, że pozwolę sobie przypomnieć, to Common Name i w tym przypadku oznacza ostateczny liść drzewa. Dla niewtajemniczonych ta botaniczna metafora jest standardowa i nie jestem jej autorem. W każdym razie AD ma budowę drzewiastą, kontenery są gałęziami, a na końcu najsmaczniejsze, czyli obiekty-liście.
- CN=users - to nazwa kontenera. Tutaj CN pojawia się, jak widać, w innym kontekście. To niezbyt dobre słowo na tą okazję (o contextach może będzie więcej później), więc ujmijmy to tak: CN w tym przypadku oznacza nazwę kontenera. Kontener Users jest standardowo zakładanym w AD (w angielskojęzycznej wersji, żeby nie było niejasności) i będą się tam standardowo pojawiać konta użytkowników i grup.
- DC=chlewik,DC=com - DC czyli Domain Controller. Ponieważ nazewnictwo domenowe DNS ma również budowę drzewiastą, zapis bardzo ładnie się tu przekłada na taką strukturę. Ktoś mógłby zapytać, po co trzeba było wcześniej wpisywać "chlewik.com" skoro jest to tu teraz napisane jak byk. Otóż pierwsza część pozwala jednemu mechanizmowi odnaleźć kontroler domeny, odpowiedzialny za dalszą autentykację (tak jakby zrobić "nslookup chlewik.com"). Druga część to po prostu normalny zapis wg. standardu określonego przez protokół LDAP
Jeśli porówna się to co jest wyżej, z tym co widać w ADUAC, to nie powinno być problemu z zapisaniem ścieżki jakiegokolwiek obiektu w AD. Skoro więc już jesteśmy spakowani, można ruszać w dalszą drogę. Warto byłoby teraz się czegoś o tym obiekcie dowiedzieć:
set oUser=getObject("LDAP://chlewik.com/CN=pysiaczek,CN=users,DC=chlewik,DC=com")
WScript.echo oUser.cn&" "&oUser.name&" "&oUser.emailGeneralnie w wscripcie nie trzeba pisać set, żeby np. nadać stringowi jakąś wartość. Set używa się, kiedy słowo - np. oUser ma się stać odniesieniem do obiektu. Funkcja getObject jest na tyle sprytna, że na podstawie dalej występującego LDAP: wie jakich mechanizmów użyć, żeby się do tego obiektu podłączyć. Następnie mogę wypisać kilka informacji na temat danego użytkownika. Skąd wiedzieć jakie dany obiekt ma atrybuty zostało opisane wcześniej (ad. schemat).
Pierwsza zmiana
Zanim zaczniemy coś zmieniać, jeszcze jeden szczegół, na który warto zwrócić uwagę. Jak to bywa z obiektami, mają swoje właściwości i metody. Dla tych, którzy nie mają pojęcia co to znaczy - pola informacyjne (np. imię) oraz funkcje dla obiektu (np. zmień hasło). Podstawowymi metodami są get i put, które można wywołać dla niemal wszystkich atrybutów. Np. jeśli chce się pobrać lub zmienić imię powinniśmy wykonać:
wscript.echo oUser.get "name"
oUser.put "name", "Zdzichu"
oUser.setInfo
wscript.echo oUser.get "name"
oUser.setPassword "nowehaslo"
oUser.setInfo
Jeśli przewiniesz kawałek w górę, zobaczysz: WScript.echo oUser.name
Uprzedzając pytanie: taka forma jest również poprawna, a to dla tego, że w momencie, gdy odwołujemy się do atrybutu tak jak do metody, niejawnie wywoływana jest metoda get lub put.
oUser.get "name" to to samo co oUser.name
oUser.put "name","cos" to to samo co oUser.name="cos" Kolejną rzeczą na jaką trzeba zwrócić uwagę to metoda setInfo. Ta niepozorna metoda to dość znaczący mechanizm. W skrócie: ze względów optymalizacyjnych, wszelkich operacji dokonujemy na informacji o obiekcie trzymanej w pamięci podręcznej. Dopiero metoda setInfo powoduje, że wszelkie zmiany są aktualizowane w domenie. Tu oczywiście również nie obejdzie się bez ciekawostek. Gdyby spróbować założyć konto użytkownika, poustawiać wszystkie atrybuty, zmienić hasło itd., po czym na końcu wykonać setInfo, konto zostanie utworzone, ale bez hasła. Możliwe, że również bez kilku innych rzeczy, ale nie jestem w stanie tego wszystkiego sprawdzić. A to z tego powodu, że pewne metody, pomimo, iż wykonywane są na kopii w pamięci cache, coś tam sobie sprawdzają bezpośrednio w AD. Dokładny mechanizm nie jest mi znany i nie znalazłem jak do tej pory artykułu, który by to technicznie wyjaśniał. Pozostaje najstarsza z metod - prób i błędów - i mam nadzieję, że ją trochę ułatwiłem.
Po co babrać się w tym wszystkim?
Przykładowy scenariusz: Początek pracy, poniedziałek, godzina 8:00. O 10:00 ktoś w sekretariacie się budzi, że warto by chyba przesłać listę nowych użytkowników. Masz w ciągu 10 min pozakładać konta ze wszystkimi danymi.
Oto plik, którego stworzenie zajmuje nieco więcej niż 10min - ale da się zmieścić w 30min. Lista nowych użytkowników wygląda tak.
Skrypcik ten powinien być w pełni zrozumiały dla osoby, która zna trochę VB oraz pilnie przestudiowała tę i poprzednią stronę artykułu. Warto zwrócić uwagę na obsługę błędów. W tym skrypcie ona nieco kuleje, ale przypominam, że ma on być zrobiony "na szybko".. set ouser=odomain.getobject("user","CN="&es)
if err.number = 0 then
Przed założeniem użytkownika warto sprawdzić czy już takowy nie istnieje, i ewentualnie tylko uaktualnić jego dane. Jeśli próba podbindowania zwróci nam 0, znaczy to, że iście taki użytkownik już jest. Nie dodanie na początku programu linijki ON ERROR RESUME NEXT spowoduje, że jeśli takiego użytkownika nie będzie, błąd będzie różny od 0 i wykonanie programu zostanie wstrzymane.
Podczas obsługi błędów nie wolno również zapominać o err.clear, ponieważ nie jest w żadnym razie robione automatycznie, co spowoduje propagacje błędu na późniejsze próby jego obsługi. Przykład: ouser.name="kaźmiesz"
if err.number <>0 then wscript.echo "błąd nadawania imienia"
ouser.setPassword "masło"
if err.number <>0 then wscript.echo "błąd ustalania hasła"
ouser.setinfo
W tym programie są dwa podstawowe błędy:
- jeśli błąd powstanie podczas nadawania imienia, zostanie wypisany komunikat zarówno o źle nadanym imieniu, jak i haśle - błąd jest obsłużony nieprawidłowo, ponieważ powinna się pojawić zaraz potem linijka 'err.clear'.
- Drugi błąd to taki, że informacja o błędzie pojawi się najprawdopodobniej po wykonaniu 'setInfo', i to tam powinna się pojawić się obsługa błedu.
Na zakończenie jeszcze dwa tipsy:
-
Jeśli chcesz znaleźć opis błędu w MSDNie to raczej przyda ci się wyświetlanie go w postaci hex(err.number)
-
Pomimo operacji xlsf.quit proces Excela nie zawsze zostaje zamknięty. Zauważyłem, że tak się dzieje najczęściej w momencie, gdy otwarty jest dodatkowo jeszcze jeden proces Excela.
Jeśli ktoś może uzupełnić moje braki informacji lub chciałby skrytykować czy pochwalić moje teksty, lub po prostu doczytał do tego miejsca - proszę o kontakt. |