vermin.eu.org

Miałem kiedyś pecha i włożyłem USB BT dongle (jak to na polski przełożyć?) przed instalacją oprogramowania Widcomm. Oczywiście różnica w wykorzystaniu sprzętu, a dokładniej ról jakie może przyjąć komputer wyposażony w ów gwizdek jest zależna głównie od oprogramowania - oczywiście na generycznym sofcie MS mnóstwo rzeczy nie działa. Niestety próba zainstalowania post factum sterowników widcomm’a nie przynosiła pożądanych rezultatów, (stworzenia z komputera zestawu słuchawkowego z nagrywaniem treści rozmowy), i pomimo drobnego wysiłku (a nuż restarcik, a nuż wyrzucenie standardowego urządzenia bluetooth działającego na sterach MS, a zmiana portu USB, a restart serwisów BT) nie przynosiła rezultatów. Podpisane sterowniki MS rządziły. Rozwiązanie okazało się banalne - wystarczyło w urządzeniu, które się pojawiło (generic bluetooth device) zmienić, po uprzedniej zmianie polityki podpisywania sterowników na ignore, sterowniki na CSR USB BT device. Komputer chwilę pomielił… i nagle znikły standardowe wynalazki MS a pojawiły się w końcu widcommowe cuda. Szkoda tylko, że znikło circa 15 minut bezcennego ostatnio wolnego czasu

Użytkownik próbował zainstalować drukarkę udostępnioną drukarkę na komputerze odpiętym od domeny - Windows XP przy próbie podpięcia zagłaszał błąd “na tym komputerze włączona jest zasada zapobiegająca łączeniu się z tą kolejką wydruku”. Próby znalezienia zdarzenia w eventlogu spierzchły na niczym, zautoryzowane podłączenie do zdalnego komputera działało, uprawnienia na komputerze współdzielącym prawidłowe… Już miałem odpalać mmc i szukać jakiejś dziwnej zasady, kiedy zaświeciło mi rozwiążanie. Cóż, użytkownik po prostu nie miał prawa instalować driverów… Przelogowanie na admina lokalnego, zainstalowanie drukarki i automagicznie już może się do drukarki podłączyć.

Czy ten komunikat nie mógł być jednak ciut bardziej naprowadzający? Znów 5 minut czasu przepadło bez sensu

Ostatnio (dopiero), musząc wykonać operacje na dużej ilości plików, odkryłem jak przydatne jest polecenie for w cmd.exe

1. Wykonaj jakąś operację na zestawie plików - w tym wypadku pobierz odpowiednie dane z plików XLS

wykonuje skrypt getData.vbs na wszystkich plikach Excela w bieżącym katalogu.
Wzięcie zmiennej %i w cudzysłów, pozwala na rozwiązanie problemu ze spacjami w nazwie pliku. Jak widać sama zmienna został tu zmodyfikowana - modyfikator ~f rozwija zmienną plikową do pliku z pełną ścieżką.

2. Wykonaj jakąś operację na plikach umieszczonych w podkatalogach

Ta wspaniała komenda przyda się, gdy zgraliśmy kilka stron z obrazkami i chcemy te obrazki właśnie przenieść szybko do katalogu z obrazami. For przejdzie przez wszystkie podkatalogi i dla zbiorów spełniających warunek wykona operację przeniesienia plików.

3. For potrafi przejść przez plik typu csv i wydobyć z niego odpowiednie informacje

Dzięki temu z pliku /etc/passwd (w którym znajdują się zazwyczaj takie informacje jak Name:Password: UserID:PrincipleGroup:Gecos: HomeDirectory:Shell) pod windowsem możemy wydobyć username (%i), id (%j), id grupy (%k). Pozostałe tokeny (*) znajdują się w zmiennej %l

4. Można też spingować hosty w zadanym zakresie - tutaj przejdziemy pojedyńczo przez całą podsieć 192.168.123.[1-254]

lub od końca

To tylko przykłady tego, co może to polecenie, a dzięki ogromnej ilości parametrów potrafi wiele - od niedawna to mój szwajcarski scyzoryk pod Windows.

Miesiąc temu pojawił się hotfix, który ma pomóc w sytuacji, kiedy system 2003 przestaje odpowiadać w momencie, gdy jest za dużo operacji dyskowych. Problem leży w sterowniku ntfs.sys, który czasem się przywiesza.
Fajnie, że pojawiła się poprawka, ale wciąż po głowie tłuką mi się pytania - dlaczego operacje dyskowe (szczególnie dyskietkowe) potrafią przyblokować system? I dlaczego jeśli błąd jest w sterowniku do NTFS to nie pojawił się chociażby hotfix także do XP? Strange…

Jeśli używamy SBSa, to łącząc się z jego witryną możemy pod Windows załadować automagiczny programik, który nam sam skonfiguruje połączenie z siecią SBS. Oczywiście to żadna magia, chociaż w widoku połączeń sieciowych pod XP widać, coś co się nazywa magaer połączeń sieciowych. To samo można uzyskać dodając nowe połączenie i zestawiając normalne połączenie VPN.

Skoro można zestawić VPN, to czemu nie zrobić tego spod linuxa? To do roboty.
Po pierwsze instalujemy pakiecik pptp-linux, a następnie przystępujemy do jego banalnej konfiguracji.

1. W /etc/ppp/options.pptp dodajemy linię
   lock noauth nobsdcomp nodeflate

   ,

2. W /etc/ppp/chap-secrets dodajemy domenową nazwę logowania oraz hasło w następującej formie
   domena\\login PPTP hasło *
3. Tworzymy plik /etc/ppp/peers/nazwa_tunelu, w którym wpisujemy:
   pty “pptp serwer –nolaunchpppd”
   name domena\\login
   remotename PPTP
   require-mppe-128
   file /etc/ppp/options.pptp
   ipparam nazwa_tunelu
4. Teraz wystarczy wystartować tunel komendą pon nazwa_tunelu lub też, w celu zwiększenia diagnostyki pon nazwa_tunelu debug dump logfd 2 nodetach

Tunel zamykamy komendą poff. Niestety sam pon konfiguruje tunel, niemniej nie ustawia routingów, nie ustawia serwerów DNS - trzeba się tym zająć na własną rękę. Ponieważ dla mnie skonfigurowany tunel ma się automatycznie podnosić się przy starcie maszyny - wystarczyło do /etc/network/interfaces dodać następujące linijki rozwiązujące problemy trasowania.

Do /etc/if-up.d trzeba dodać mały skrypcik (jak napiszę to zamieszczę) który sprawdza czy interfejs ppp jest podniesiony i jeśli tak, to dodaje do /etc/resolv.conf linijkę zawierającą namiary tegoż nameserwera. Oczywiście w if-down.d trzeba zamieścić regułkę odwrotną, wyjmującą tegoż NSa z listy.

Źródło: PPTP

Exchange ma taką dziwną cechę, że bardzo długo się zamyka - szczególnie długo zamyka się Exchange na kotrolerze domeny lub w sytuacji gdy kontroler wolniej komunikuje się z siecią. Wynika to z faktu, że w momencie gdy poczta idzie spać, zaczyna wymieniać mnóstwo informacji z AD. Nie jest to za bardzo skoordynowane, stąd właśnie ten długi czas zamykania serwera. Okazuje się, że można ten czas skrócić poprzez jedną, bardzo prostą komendę:

. Zabicie system attendant service zdecydowanie przyspiesza zamknięcie Exchange.

Sprawdź sam - Da SBS Code.

Produkcja: Microsoft. FIlm zaaprobowany dla wszystkich SMB przez Microsoft.

Uwaga dla estetów: Ballmer w swojej roli powinien zostać ocenzurowany.
Uwaga dla linuxowców: Ciężki marketing Microsoftu.

Na blogu Road to Know Where zebrano listę 150 programów użytkowych Microsoftu (część jeszcze z Microsoft Research), pomocnych w zarządzaniu, bajerów i iinych drobiazgów. Część z nich była bardziej lub mniej znana, ale to bardzo miłe, że w końcu ktoś to zebrał.

Lista jest naprawdę długa - od typowych dodatków XP, przez wszelakie narzędzia dla admina i powerusera, kończąc na multimediach i wygaszaczach. Można tam naprawdę sporo dla siebie znaleźć…

Edit: Wywołany do tablicy przez Krzycha, postanowiłem napisać, co mi osobiście przypadło do gutu z tej kolekcji:

Alt-Tab replacement: używam na systemie klienckim często, ponieważ daje szybką możliwość spojrzenia na jaką aplikację właściwie się przełączam, szczególnie jeśli mam kilka odpalonych instancji i ktoś nazwał okienka tak samo

Power Calculator: czyli kalkulator pokazujący co liczyłem i mający możliwość wpisywania formuł
Mount ISO Files Virtually: fajny, bo nie instaluje się jak daemon tools, ale pozwala ładować i wyładowywać sterownik na gorąco - na dodatek działa bez instalacji programu.

Port Reporter: sprawdza co słucha na którym porcie.
VirtualWiFi: czyli kilka różnych (SSID) sieci LAN na jednej karcie.

Do desktop tuningu miły jest TweakUI, czasem porywam się na jakiś zestaw tapetek - ale po chwili i tak zmieniam na zupełnie inną kolekcję. Nie wiem dlaczego MS wydając pakiety tematyczne (Nature, Ontario, Polska Złota Jesień) nie wydał także tematów do Luny. Zdecydowanie dla mnie obniża to ich wartość - ale tak to jest jak coś się wymyśli a potem nie wie po co to było. Z AeroGlass będzie tak samo.

MBSA, czy też Virtual PC to oczywiście często używane narzędzia - ale z zupełnie innych powodów niż desktop tuning. MSRT, Windows Defender, Desktop Search - nie używam, polegam na innym sofcie.

Z powyższych korzystam często - z reszty, sporadyczniej, jeśli wogóle. O części nie wiedziałem i będę testował. Może rozszerzę swój zasób narzędzi?

Masz Bluetooth w komputerze, masz bezprzewodową słuchawkę. Wyłączyłeś microsoftowe sterowniki (Menadżer urządzeń), zainstalowałeś sterowniki WIDCOMMa i działają (znów Menadżer urządzeń). Uruchomiłeś panel zarządzania bluetooth, wyszukałeś zestaw, sparowałeś go z komputerem. Połączyłeś się z serwisem Headset słuchawki i zacząłeś słyszeć upiorną muzyczkę: (traalalla-lala, sraallala-la). (traalalla-lala, sraallala-la). (traalalla-lala, sraallala-la). Yeah działa! Szybko przechodzisz do panelu sterowania, dźwięki (traalalla-lala, sraallala-la) i urządzenia, i w audio zmieniasz (traalalla-lala, sraallala-la) ustawienia na bluetooth audio (traalalla-lala, sraallala-la). Wydaje się (traalalla-lala, sraallala-la) ok. Włączasz foobara (traalalla-lala, sraallala-la) (czy tam cokolwiek), odpalasz ulubione MP3… (traalalla-lala, sraallala-la). (traalalla-lala, sraallala-la). Co jest? Szybka weryfikacja (traalalla-lala, sraallala-la) ustawień. Przecież wszystko jest ok! Powtarzamy (traalalla-lala, sraallala-la) procedurę. Restartujemy podsystem (traalalla-lala, sraallala-la) bluetoth, restartujemy słuchawkę (przez chwilę cisza). (traalalla-lala, sraallala-la) (traalalla-lala, sraallala-la). Wkurzeni naciskamy wyłącznik zestawu…

I’m your dream, make you real
I’m your eyes when you must steal
I’m your pain when you can’t feel
Sad but true

Zapomniałem. Szukałem zbyt nisko poziomowo. Potrzebuję urlopu… teraz.

Microsoft zdecydował się, żeby wycofać SBS R2, który miał status RTM i właściwie to już tam był! Powód? Podczas audytu oprogramowania okazało się, że część kodu R2 jest w wersjach… nie zakończonych (beta?). Płyty dotarły ponoć jedynie partnerów (OEM, System Builder, Dystrybutorzy), więc w zasadzie to tylko “drobne” opóźnienie (chociaż znów u tych wymienionych proces tworzenia obrazów, testów i takich tam rozpocznie się od nowa…).

Przy okazji wizyty na blogu MS Smallbiz, rzuciła mi się w oczy tabela kosztów upgradu SBSa z 2003 SP1 do R2. Powiem w skrócie - porażka! I to totalna! Nie dość, że R2 w wersji premium to w zasadzie nowy SQL 2005 (ok, dla niektórych to może być ważne i warte ceny - ale jak dla mnie większość znanych mi app wciąż wymaga i wspiera SQL Server 2000), WSUS (który jest DARMOWY) no i rozszerzenie CALi (przydatne naprawdę jedynie w dużych wdrożeniach SBSa - no bo kogo stać na drugą instancję normalnie cenionego Exchange?)

A najśmieszniejsze jest, że jeśli kupiło się OEM to upgrade do R2 jest za darmo - w ramach takiego pseudo Software Assurance - Technology Upgrade Program. No tak - tylko kto poważny kupuje OEM oprogramowania, jakby nie było serwerowego, znając jego ograniczenia (weź zrób cold-backup albo szybko przenieś na inną maszynę…)? PORAŻKA, ot co

Po zalogowaniu się na konto Administratora widzimy sobie SQL Service Manager - szkoda tylko, że całkowicie pusty. Rozwiązanie tego jest banalne. Wyłączyć go i włączyć ponownie - i wyrzucić go ze startu automatycznego. Wtedy zadziała.

Tylko po co do cholery on wobec tego startuje automatycznie? Ja chcę opóźnione ładowanie programów (które jest Windows Vista)!

Na SBSie po instalacji standardowo stoją conajmniej dwie instancje SQL Server - jedną z nich jest SBSMONITORING, drugą SHAREPOINT. Jesli mamy ISA Server to dodatkowo jest jeszcze MSFW. Jest tego od groma, a jak można się zorientować na mojej małej stronce o SBSie, z instancjami (pseudo) SQL Servera na SBS są zazwyczaj problemy - po pierwsze na pewno jakieś są zainstalowane, po drugie działają i zabierają pamięć, po trzecie - co to jest kurcze blade? I to pytanie wcale nie jest takie bezpodstawne, bo postawienie dodatkowo SQL Servera z płytki Premium, WSUSa powoduje, że spokojnie mamy conajmniej 3 różne silniki… Więc który z nich obsługuje co?

Przystępujemy do pracy:
Najpierw sprawdzamy co właściwie u nas działa: task manager pokazuje, że procesy SQL istnieją (sqlservr.exe). Każda instancja (SBS Monitoring, Sharepoint, etc.) ma swój proces w ramach którego istnieje - jak sprawdzić, która to która?
Konsola: tasklist /svc i już widzimy który proces (numer PID jest tu wyróżnikiem) obsługuje jaką bazę. Teraz spokojnie możemy zobaczyć co sprawia problemy, (która instancja).

Teraz warto sprawdzić w zasadzie co jest obsługiwane przez co - czy wszystko przez SQL Server, czy może przez MSDE, a może przez (W)MSDE (a na pewno instancja MSSQL$SBSMONITORING nie powinna być na SQL Server). Znowuż - jak to zrobić?
Wchodzimy tam gdzie są logi (albo c:\program files\Microsoft SQL Server\nazwa$instancji\LOG albo tam gdzie są logi). Otwieramy plik z logami i jeśli mamy Desktop Engine on Windows NT 5.2, to NA TEJ INSTANCJI jest MSDE, jeśli Desktop Engine (Windows) on Windows NT 5.2 to WMSDE, jeśli Standard Edition on Windows NT 5.2, to mamy faktycznie SQL Server.

Dzięki temu będzie nam łatwiej rozwiązywać standardowy problem z pamięcią na odpowiedniej instancji

SBS 2003 ma wspaniałe narzędzie jakim jest SBS monitoring. Codzienny zwięzły raport w formacie HTML, który dostaje się na pocztę pozwala na szybko zorientować się co gryzie maszynę - tyle, że gryzie w sensie dosłownym, ponieważ w raporcie zawarte są jedynie krytyczne zdarzenia, względnie kilka liczników, którym można jedynie zredefiniować wartość od której działają (treshold). Jak narazie nie znalazłem możliwości, żeby wykonać fine tuning przesyłanych informacji. W związku z tym to rozwiązanie jest niestety dość ubogie i zmuszające do codzienngo czytania logów (które na szczęście można sobie dodać do przesyłanego maila i przeczytać na zdalnej maszynie).

Jedynym rozwiązaniem jakie znalazłem, jest oczywiście wspomniany kiedyś logparser. Dzięki niemu możemy wyciągnąć z dzienników zdarzenia o statusie warning, sformatować je do tabelki HTML i wysłać je wraz z codziennym raportem… Trochę to chyba działanie na około - ktoś zna lepszą drogę?

[update]
Taaak - chyba jest za gorąco (fajnie się pracuje w małym pokoju, w trzy osoby, bez klimatyzatora), bo całkowicie zapomniałem o Health Monitor, który oczywiście pozwala na bardzo granularną kontrolę nad tym, co się pojawia w raportach z logów - niemniej moje rozwiązanie też jest dobre

W dzisiejszym komunikacie prasowym Microsoft ogłosił przejęcie firmy Winternals, znanej najbardziej z postaci Marka Russinovicha, (o którym pisałem w tym artykule) i zestawu narzędzu sysinternals - w zasadzie podstawy do pracy dla admina, chcącego wiedzieć co dzieje się ‘pod maską’ systemu.

Zastanawia mnie, jak przejęcie tej bardzo znanej administratorom systemów Windows firmy wpłynie na narzędzia dostarczane z produktami serwerowymi? Szczególnie z rodziną systemów zarządzania infrastrukturą, (do której zalicza się WSUS, a przede wszystkim SMS), która to rodzina ewidentnie wraz z pojawieniem się koncepcji kontroli dostępu do sieci (NAC - Network Access Control) rośnie w siłę i znaczenie. Bardzo mnie zastanawia jak integracja bardzo przydatnego zestawu narzędzi z winternals wpłynie na stan systemu Windows? Czy staną się jakimś resource packiem? Czy też może będą nadal niezależnym produktem a Russinovich wzmocni brygadę zajmującą się bezpieczeństwem systemu? Zobaczymy.

Na razie widać ewidentnie, że Microsoft stawia coraz mocniej na zestaw narzędzi, który pozwoli zarządzać systemem z konsoli - powershell, który będzie to wszystko integrował oraz zestaw narzędzi, które pozwolą rozszerzyć możliwości diagnostyczne tego co jest oferowane w Resource Kit’ach. W sumie - oby tak dalej. Niech tylko jeszcze dadzą ssh…

Zainstalowanie w2k3 resource kit pozwala m.in. na dodanie dodatkowych informacji o użytkowniku poprzez skopiowanie acctinfo.dll do %systemroot%\system32 a następnie wykonanie komendy regsvr32 %systemroot%\system32\acctinfo.dll. Dzięki temu dostaniemy ładną wizualizację (w karcie użytkownika) rzeczy, które do tej pory wygrzebywaliśmy za pomocą adsiedit…

Źródło: EvolutiOn, uzupełnienie własne