Na przełomie kilku ostatnich tygodni, za sprawą Quizu 2008 i Heroes Happen Here, ilość osób korzystających z systemu Windows Server 2008 bez wątpienia znacznie się rozrosła. :-)

Najprawdopodobniej wzrośnie więc również liczba osób, które na tymże systemie spróbują zainstalować tak przesympatyczny program jakim jest Windows Live Writer. Niestety po ściągnięciu instalatora WLinstaller.exe i jego uruchomieniu, naszym oczom ukaże się poniższy komunikat:

Najwyraźniej plik instalacyjny produktów z rodziny Live nie jest zbyt "kompatybilny" z systemami serwerowymi. Na szczęście na tę przypadłość nie cierpi już właściwy instalator Windows Live Writer. Możemy go po prostu przekopiować z systemów klienckich (Vista, XP) i uruchomić na WS 2008. Lokalizacja pliku msi zawierająca WLW jest stała:

C:\Program Files\Common Files\WindowsLiveInstaller\MsiSources

Dla 64 bitowej wersji systemu, będzie to:

C:\Program Files (x86)\Common Files\WindowsLiveInstaller\MsiSources

Interesuje nas plik Install_{9176251A-4CC1-4DDB-B343-B487195EB397}.msi.

Instalatory innych produktów z rodziny Live, które również możemy znaleźć w powyższej lokalizacji (w zależności od zainstalowanych komponentów), to:

Windows Live Photo Gallery: Install_{257E440F-781F-459B-9A68-A0872B80C1D6}.msi
Windows Live Messenger: Install_{508CE775-4BA4-4748-82DF-FE28DA9F03B0}.msi
Windows Live Mail: Install_{184E7118-0295-43C4-B72C-1D54AA75AAF7}.msi
Windows Live Toolbar: Install_{D5A145FC-D00C-4F1A-9119-EB4D9D659750}.msi
Windows Live Sign-In Assistant: Install_{AFA4E5FD-ED70-4D92-99D0-162FD56DC986}.msi

W Windows Server 2003 możemy bez problemu, ręcznie zdefiniować 127.0.0.1 jako adres serwera DNS we właściwościach protokołu TCP/IP. Gdy to samo spróbujemy zrobić w systemie Windows 2000 Server, przywita nas taki komunikat:

Czyli interfejs graficzny nie pozwoli nam wpisać adresu zaczynającego się od 127, lub wyższego od 223.

Co w takim razie z netsh? Próba zmiany adresu serwera DNS zakończy się tak:

Jeżeli jednak rozpaczliwie chcemy ustawić ten loopback jako DNS w Windows 2000, to najprościej dokonamy tego modyfikując rejestr.

W kluczu 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ Interfaces\{GUID_naszej_karty}

wstawiamy odpowiednie adresy w "NameServer".

Teraz właściwości protokołu TCP/IP mogą wyglądać choćby tak:

Dlaczego w ogóle o tym piszę?

Chodzi oczywiście o konfigurację kontrolera domeny. Jeżeli przed uruchomieniem dcpromo, nie skonfigurujemy adresu preferowanego serwera DNS, to konfigurator sam wstawi adres 127.0.0.1 podczas procesu tworzenia AD i instalacji/konfiguracji serwera DNS. Tak jest w Windows Server 2003/2008. Jest tak również w Windows 2000 Server. Z tą jednak różnicą, że w 2003/2008 możemy adres 127.0.0.1 wpisać również ręcznie. Próba wpisania adresu klasy D (powyżej 223) wciąż będzie powodowała wyświetlenie poniższego komunikatu (także w Windows Server 2008).

BTW. Owszem, w niektórych firmach korzysta się jeszcze z systemu Windows 2000 Server. ;-)

W końcu są wyniki egzaminów beta... Jak pewnie wiele osób, również mam je zaliczone. :)

No i teraz muszę podejść do następnego egzaminu (z Visty: 70-620), żeby Enterprise Administrator się uprawomocnił. :) Już chyba wiem na co wykorzystam voucher wygrany w quizie. ;)

Aktorzy: gsecdump, msvctl, psexec.

Czyli po prostu ekspresowa eskalacja uprawnień. Oczywiście jak zawsze, muszą zostać spełnione pewne warunki. :)
Najprostszy scenariusz zakłada, że:

1. Mamy dostęp na poziomie lokalnego admina do komputera w domenie. Niestety wciąż zbyt często nie stanowi to żadnego problemu, gdy np. szeroko stosowaną praktyką jest dodanie Domain Users do grupy lokalnych administratorów. "Bo wtedy wszystko działa!" ;)

2. Na tej stacji chociaż raz zalogowane było konto należące do grupy Domain Admins.

Jeżeli nawet żaden DA (Domain Admin) nie był zalogowowany na komputerze do którego mamy dostęp, to zawsze możemy zacząć od hasza wbudowanego konta lokalnego administratora. Jakie jest prawdopodobieństwo tego, że w sieci hasło lokalnego administratora jest inne na każdej stacji? Minimalne. Często będzie ono takie samo również na serwerach. W ten sposób szybko można wejść w posiadanie hasza DA.

A więc:

1. jako admin na stacji: gsecdump -a
2. msvctl haszNależącyDoDomainAdmins run cmd
3. w nowym oknie cmd: psexec -s \\domain_kontroller -c gsecdump.exe -s

W ten sposób weszliśmy w posiadanie wszystkich haszy w domenie i możemy "podszyć się" pod każde z nich. Proponuję sprawdzić pod tym kątem swoją sieć. Oczywiście tylko jeżeli mamy na to pozwolenie. :)

Jak można się przed tym bronić? Przede wszystkim NIE DAJEMY UŻYTKOWNIKOM PRAW LOKALNEGO ADMINISTRATORA! Ogromna poprawa bezpieczeństwa i równocześnie znacznie więcej na naszej głowie. ;) W innym przypadku... ciężko...

Można zwiększyć nieco odporność na tego typu atak...

Przede wszystkim nie logować się gdzie popadnie z kont należacych do Domain Admins i w ogóle ograniczyć do minimum korzystanie z takich kont. Jeżeli już zaistnieje potrzeba logowania DA, to można robić to na wyznaczonej do tego stacji.
Rozumiem, że inne hasło lokalnego admina na każdym komputerze jest często nierealne, ale co z serwerami? ;-)

Dodatkowo - moim zdaniem - całkiem niezłym pomysłem może być odizolowanie od siebie komputerów użytkowników sieci poprzez zastosowanie np. IPsec i włączenie lokalnego firewalla. Tutaj akurat możemy wygrać znacznie więcej niż tylko zmniejszenie efektywności programów z rodziny "Pass-The-Hash". Skutecznie zminimalizuje to również zagrożenia płynące ze strony różnych wirusów i robaków korzystających z sieci do rozprzestrzeniania się.

No i oczywiście SRP (Software Restriction Policies) ze standardowym poziomem zabezpieczeń ustawionym na Disallowed. Wtedy user nie będzie mógł zbyt łatwo skorzystać między innymi z wymienionych powyżej narzędzi. Dzięki implementacji SRP również zyskamy DUŻO więcej niż tylko ochronę przed gsecdump. :)

Nie wyeliminuje to całkiem zagrożenia, ale z pewnością je utrudni. W sumie sam jestem ciekaw, jak najskuteczniej bronić się przed takim atakiem. :-)

Jedną ze zmian związanych z GPO w systemach Windows Server 2008 i Windows Vista jest koncepcja katalogu centralnego. (Central Store). Central Store jest po prostu katalogiem przechowywanym na udziale SYSVOL, w którym znajdują się wszystkie pliki szablonów administracyjnych (ADMX i ADML) w obrębie domeny.

Po uruchomieniu GPMC na Windows Server 2008 lub Windows Vista, pierwszym miejscem z którego nastąpi próba załadowania szablonów, będzie właśnie central store. W przypadku gdy system stwierdzi jego brak, kieruje się do lokalnych zasobów.

To rozwiązanie ma uporać się (między innymi) z kilkoma niedogodnościami charakterystycznymi dla procesu tworzenia i zarządzania politykami grup w systemach Windows 2000/XP/2003.

Jedną z tych niedogodności może być wzmożony ruch sieciowy związany z replikacją szablonów ADM. Inną, miejsce zarezerwowane na ich składowanie na kontrolerach domeny. Jeszcze inna niespodzianka czekała na nas, gdy dokonywaliśmy edycji GPO z systemów różniących się wersją językową. Poza tym, w sytuacjach gdy siecią zarządzała większa ilość Administratorów, mogły występować problemy z dokładnym określeniem, którą dokładnie wersję szablonu właśnie poddaliśmy edycji.

Do tej pory, w momencie utworzenia GPO, na SYSVOL zostawał zakładany katalog z GUID nowej GPO w nazwie. Nie zawierał on jednak jeszcze na tym etapie katalogu ADM w którym przechowywane  były szablony administracyjne. Kopiowanie następowało dopiero w momencie gdy dane GPO zostało otwarte w GPOE (Group Policy Object Editor).

Zestaw szablonów dla jednej GPO, to niecałe 4MB. Przy ok. pięćdziesięciu GPO, mówimy już o konieczności replikacji ok. 200 MB. W sytuacjach gdy lokacje w obrębie jednej domeny połączone są przy pomocy niezbyt wydajnych łącz, lub gdy łącza te są po prostu intesywnie wykorzystywane, rozmiar SYSVOL może mieć dość istotne znaczenie.

Jak już wspomniałem na początku, central store jest reprezentowany przez katalog o nazwie PolicyDefinitions w udziale sysvol na kontrolerach domeny. Cały proces tworzenia CS jest bardzo prosty...

1. Na kontrolerze domeny (preferowany jest tutaj DC pełniący rolę PDC Emulator, gdyż to właśnie do tego DC standardowo łączy się GPMC i GPOE), w poniższej ścieżce tworzymy główny katalog w którym składowane będą wszystkie szablony ADMX:

%systemroot%\sysvol\domain\policies\PolicyDefinitions

2. Tworzymy podfoldery dla wersji językowych plików ADML. Nazwy folderów nie są dowolne i możemy je znaleźć np. na liście Valid Locale Identifiers.

3. Kopiujemy pliki .admx z Visty (lub z Windows Server 2008) do folderu PolicyDefinitions na SYSVOL:

copy %systemroot%\PolicyDefinitions\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\

4. Kopiujemy pliki .adml do odpowiednich podfolderów utworzonych w katalogu PolicyDefinitions na SYSVOL:

copy %systemroot%\PolicyDefinitions\[MUIculture]\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\[MUIculture]\

Efekt końcowy powinien przedstawiać się następująco:

Powyższą procedurę musimy wykonać tylko raz, na jednym DC. Oczywiście konto użytkownika z którego będziemy wykonywać te kroki, musi być członkiem grupy Domain Administrators. Resztę zrobi za nas FRS (lub ewentualnie DFSR, jeżeli poziom funkcjonalny domeny został podniesiony do Windows Server 2008 i dokonaliśmy zmiany sposobu replikacji), który synchronizuje zawartość udziału sysvol na wszystkich kontrolerach w domenie.

Dodatkowa korzyść płynąca z posiadania magazynu centralnego w domenie, to łatwe udostępnianie i korzystanie z niestandardowych plików admx, które po skopiowaniu do CS, staną się automatycznie dostępne dla wszystkich osób administrujących GPO w naszej domenie.

Musimy pamiętać o tym, że od tej pory, edycji GPO powinniśmy dokonywać tylko z sytemów Windows Vista i Windows Server 2008. W innym przypadku, do katalogu edytowanej GPO znajdującym się na sysvol, skopiowany zostanie zestaw plików .adm.

W sytuacji gdy z jakichś powodów katalog PolicyDefinitions będzie niedostępny, wtedy Windows Vista i Windows Server 2008 automatycznie zaczną korzystać z plików .admx i .adml przechowywanych lokalnie.

Dobrze wiedzieć, że człowiek nie jest osamotniony w bólu... ;) A ja mam tylko jakieś marne 1200+ nieprzeczytanych wpisów w Google Readerze. :) Pełnia szczęścia. ;) http://blog.joeware.net/2008/03/13/1088/

Przyznaję, że wiadomość już może nie jest najświeższa, ale....

Kilka miesięcy temu pisałem o ciekawej prezentacji "Why I Can Hack Your Network in a Day!". Marcus Murray do zabawy z przekazywaniem haszy LM korzystał z MSVCTL. Jeżeli ktoś przegapił, to dobrze wiedzieć, że od października 2007, program ten jest dostępny publicznie.

http://truesecurity.se/blogs/murray/archive/2007/10/01/pass-the-hash-tool-msvctl-released-to-public.aspx

Poniżej dwa screeny. Pierwszy z laptopa (Host) na którym zainstalowany jest system Vista x64, a drugi został zrobiony na systemie wirtualnym w VMware Workstation (oczywiście na tym samym laptopie). Również Vista x64. Według Windows Experience Index dysk dostaje niezłego kopa na VM. ;)

Host:

Virtual Machine:

Na wszelakie konfiguracyjno-manualne zło:

net stop w32time

w32tm /unregister

[ewentualny reboot]

w32tm /register

net start w32time

Po przewaleniu tony artykułów o konfiguracji czasu w domenie (ntp, w32tm) i zastosowaniu zalecanych w nich kroków, to właśnie powyższa "procedurka" wykonana na kontrolerach zachowujących się "dziwnie", pozwoliła wybielić logi.

No... w każdym razie pomogła w przypadku poniższego trio :):

Skryptowy, prosty sposób na obliczenie ilości tygodni jakie upłynęły od interesującej nas daty:

Wscript.Echo DateDiff("ww","2008-01-01",Now())

Zdarzyło mi się zobaczyć takie coś, na czym nie bardzo ma się ochotę pracować. ;-)

Wspaniała rozdzielczość 640x480. Pewnie i wspaniała, ale nie w 2008 roku. ;-) Taki efekt można między innymi uzyskać po instalacji VMWare Tools w wyżej wymienionym systemie. Na szczęście również w Core mamy możliwość zmiany parametrów ekranu.

W tym celu uruchamiamy regedit i przechodzimy do klucza
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{GUID}\000

Musimy jeszcze tylko odnaleźć odpowiedni GUID, który reprezentuje interesujący nas sterownik graficzny.

W moim przypadku identyfikacja nie była zbyt trudna, co widać na załączonym obrazku ;-):

Interesują nas dwie zaznaczone powyżej wartości, czyli DefaultSettings.XResolution i DefaultSettings.YResolution.
Wystarczy już tylko zmienić je na np. 1024x768 i zrestartować system.

Wiem o tym przecież od lat. Mało tego, pamietam o tym od lat. A jednak. Zdarzyło się zapomnieć. Wielkiej tragedii co prawda nie było, ale po raz kolejny przekonuję się, że nie ma to jak spokojnie usiąść choćby na 5 minut i... najzwyczajniej w świecie dokonać podstawowej analizy problemu. Ale nie... myślenie przecież boli. ;) Najczęściej na własnym podwórku.

Tak jak sugeruje tytuł, chodzi o dystrybucję ISA FWC przy pomocy GPO. Sprawa banalnie prosta. Musiałem szybko rozpuścić paczkę na wszystkie stacje w domenie. Z relacji użytkowników ;) można było wyciągnąć wniosek, że na niektórych komputerach różne rzeczy nie działają, a powodem był właśnie brak FWC, który najwyraźniej na wybranych systemach nie został poprzez GPO zainstalowany. Wyglądało na to, że wspólnym czynnikiem była wersja OS. W tym przypadku Windows 2000 Professional (a mam jeszcze kilkadziesiąt stacji właśnie z tym systemem). Zakładając, iż problem leży "gdzieś głębiej" odsuwałem w czasie próby jego rozwiązania. Doszło już nawet do tego, że specjalnie przeszedłem się do kilku stacji i ręcznie zainstalowałem FWC. :-) Na początku nawet zajrzałem ;-) do logów, ale było czyściutko. BTW. to akurat już powinno dać mi do myślenia, a jednak...

Dzisiaj, po kolejnym meldunku "jeszcze tutaj nie działa", postanowiłem zajrzeć do źródła, czyli po prostu sprawdzić odpowiednie GPO. Olśnienie przyszło w momencie otwarcia GPMC. Wypadało tylko palnąć się porządnie w czoło. Problem nie miał nic wspólnego z tym, że systemem był Windows 2000 Professional. Szkopuł tkwił w wersji językowej systemu. Tak się akurat składa, że te W2K Pro są NL. :-) Naturalnie wszyscy już wiedzą o czym zapomniałem podczas konfiguracji Software installation. Brak jednej fajeczki. Tak więc ku pamięci:

Właściwości konkretnego msi -> zakładka "Deployment" -> Klik na "Advanced" -> fajeczka przy "Ignore language when deploying this package".

A na przyszłość... najwyższa pora zacząć się oswajać z bólem. ;-)

Tafiti to eksperymentalna nakładka na Live Search wykorzystująca Silverlight. Można to chyba potraktować tylko jako ciekawostkę i sobie pooglądać. :-)

Informacja dla wszystkich zainteresowanych pogłębianiem wiedzy na temat Windows Server 2008.

Na początku stycznia, na stronie https://www.quiz2008.pl/ ruszy rejestracja do quizu/testu z wiedzy dotyczącej właśnie tego systemu. Od zawsze wiadomo, że najlepszą formą nauki jest zabawa, dlatego wszystkich spragnionych jednego i drugiego (lub tylko jednego - wedle uznania ;) ) zapraszam do rejestracji. :-)

Ci, którzy chcą mieć większy wpływ na pytania z jakimi się zetkną w czasie trwania quizu, mogą przesyłać swoje propozycje do organizatorów.

Pozostaje życzyć wszystkim udanej zabawy. :-)

Ostatnio trafiła mi się możliwość małego 'dorobienia', czyli malutka fucha. ;-) Chodziło o rozbudowę małej sieci SBS o nową lokację. Jednym z elementów tej rozbudowy było postawienie dodatkowego DC na Windows Server 2003 R2.

Utworzyłem więc nowy Site, podsieć i przeniosłem tam nowy serwer. Rezultatem było pojawianie się co kwadrans w logach na SBS trzech zdarzeń. Event id 1311, 1312 oraz 1865. Dość szybko log 'Directory Service' zaczął wyglądać tak:

Logi na nowym DC były czyściutkie.

Rozwiązanie jest bardzo proste. SBS 'z pudełka' zakłada, że będzie działał w środowisku, w którym jest tylko jedna lokacja. Dlatego usługa 'Intersite Messaging' jest wyłączona. Wystarczy ją włączyć, aby 'dwukolorowe trio' opuściło nasze logi.

Jeżeli nie chcemy dzielić się z użytkownikami "tajemną wiedzą błyskawicznego odzyskiwania danych" ;-), znanej również pod nazwą "Shadow Copies", to możemy usunąć z systemów użytkowników zakładkę "Previous Versions" poniższym poleceniem:

regsvr32 /u twext.dll

Do zarządzania urządzeniami w systemie z linii poleceń, możemy wykorzystać Devcon. Alternatywa dla graficznego 'Device Manager'.

Po wpisaniu w cmd devcon help otrzymamy:

C:\>devcon help
Device Console Help:
devcon [-r] [-m:\\<machine>] <command> [<arg>...]
-r if specified will reboot machine after command is complete, if needed.
<machine> is name of target machine.
<command> is command to perform (see below).
<arg>... is one or more arguments if required by command.
For help on a specific command, type: devcon help <command>
classfilter          Allows modification of class filters.
classes             List all device setup classes.
disable             Disable devices that match the specific hardware or instance ID.
driverfiles         List driver files installed for devices.
drivernodes      Lists all the driver nodes of devices.
enable              Enable devices that match the specific hardware or instance ID.
find                  Find devices that match the specific hardware or instance ID.
findall               Find devices including those that are not present.
help                  Display this information.
hwids                Lists hardware ID's of devices.
install                Manually install a device.
listclass             List all devices for a setup class.
reboot               Reboot local machine.
remove             Remove devices that match the specific hardware or instance ID.
rescan               Scan for new hardware.
resources          Lists hardware resources of devices.
restart              Restart devices that match the specific hardware or instance ID.
sethwid             Modify Hardware ID's of listed root-enumerated devices.
stack                Lists expected driver stack of devices.
status               List running status of devices.
update              Manually update a device.
updateni            Manually update a device (non interactive).

Załóżmy, że naszym celem jest wyłączenie karty sieciowej. Sprawa niby jest prosta, a jednak czasami najwyraźniej sprawia mały kłopot. Można to załatwić naturalnie jedną "linijką", jednak tutaj bardziej chodzi o to, aby pokazać jak dojść do tego, co ma się w tej linijce znaleźć. ;-)

Listujemy urządzenia poleceniem devcon find *

Lista jest stosunkowo obszerna, więc podarujemy sobie wklejanie. Podczas jej przeglądania trafimy jednak na linijkę identyfikującą naszą kartę. Na przykład dla NICa VMWare, będzie to:

PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\4&239552F9&0&0088: VMware Accelerated AMD PCNet Adapter

Na przyszłość możemy już pójść na małe skróty i od razu zawęzić nasze poszukiwania poleceniem devcon find pci*

Identyfikatorem naszej karty jest więc PCI\VEN_1022. Teraz musimy ją jeszcze tylko wyłączyć poleceniem disable podając odpowiednią klasę i identyfikator.

devcon help disable pokaże nam składnię:

C:\>devcon help disable
devcon [-r] disable <id> [<id>...]
devcon [-r] disable =<class> [<id>...]
Disable devices that match the specific hardware or instance ID.
This command will only work for local machine.
Specify -r to reboot automatically if needed.
Examples of <id> are:
*                            - All devices (not recommended)
ISAPNP\PNP0501     - Hardware ID
*PNP*                     - Hardware ID with wildcards (* matches anything)
@ISAPNP\*\*           - Instance ID with wildcards (@ prefixes instance ID)
<class> is a setup class name as obtained from the classes command.
Devices are disabled if possible.

Potrzebujemy więc dwóch danych <class> i <id>. Id już znamy, a nazwę klasy uzyskamy po wydaniu polecenia devcon classes. Widzimy, że dla kart sieciowych będzie to Net.

Nasze urządzenie wyłączymy więc wpisując:

devcon disable = net pci\ven_1022

Efektem będzie:

C:\>devcon disable = net pci\ven_1022
PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\4&239552F9&0&0088: Disabled 

Możemy ponownie włączyć kartę, wpisując devcon enable = net pci\ven_1022

Sprawa jednak nieco się komplikuje w sytuacji, gdy w komputerze obecna jest większa ilość kart z tym samym chipsetem. Powyższe polecenia będą bowiem odpowiednio, wyłączać i włączać wszystkie karty o ID PCI\VEN_1022.

Na przykład po wylistowaniu urządzeń na VM z dwiema kartami sieciowymi, otrzymamy:

PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\4&239552F9&0&0088: VMware Accelerated AMD PCNet Adapter
PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\4&239552F9&0&1888: VMware Accelerated AMD PCNet Adapter

Wydanie polecenia devcon disable = net pci\ven_1022 zaowocuje wyłączeniem obu kart:

C:\>devcon disable = net pci\ven_1022
PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\4&239552F9&0&0088: Disabled
PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\4&239552F9&0&1888: Disabled
2 device(s) disabled.

Do tej pory identyfikowaliśmy urządzenia po Hardware ID. Rozwiązaniem problemu będzie skorzystanie z Instance ID. Wybieramy więc interesujący nas identyfikator. Załóżmy, że chcemy wyłączyć tylko kartę o Instance ID 4&239552F9&0&0088:

PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\4&239552F9&0&0088
PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\4&239552F9&0&1888

Osiągniemy to wydając polecenie:

devcon disable @*4*239552F9*0*0088

Znakiem '@' informujemy, że używamy właśnie Instance ID i zamieniamy wszystkie '&' na wildcard '*'.

Efektem będzie wyłączenie tylko wybranej przez nas karty.

Na stronie Microsoft Connect, w projekcie 'Network Monitor 3' dostępny jest pakiet beta "One Click Capture". Można powiedzieć, że to "przenośna" wersja Network Monitora v3.1, którą możemy zapisać na kluczu USB, a następnie uruchomić na innym komputerze. Efektem będzie automatyczne logowanie ruchu sieciowego do pliku przez 120 minut. Proces ten możemy w dowolnym momencie przerwać, wciskając "x".

Na blogu zespołu 'Microsoft.com Operations' można zapoznać się z listą dziesięciu, ich zdaniem najważniejszych, zmian w IIS 7.0.
A na miejscu pierwszym... oczywiście możliwości konfiguracyjne linii poleceń, czyli coś, co znalazło się chyba w ok. 40% pytań egzaminu 071-649. ;-)

MSCOM OPS Top 10 Changes In IIS7.0...

Zmuszony byłem ostatnio wyciągnąć klucz WPA z Windowsa 2000 Pro. Dostęp do "gwiazdek" już miałem. Pozostało jeszcze znaleźć sposób aby sprawdzić co się pod nimi kryje. Krótko mówiąc, przetestowałem kilka programików Freeware/Shareware, jednak żaden z nich sobie nie poradził. Tzn. prawie żaden. ;-) W końcu trafiłem na programik, który bez najmniejszych problemów wykonał to, czego od niego oczekiałem. Asterisk Logger odesłał "gwiazdki" w niebyt i umożliwił mi dostanie się do klucza. Z pewnością więcej programów również dałoby radę, jednak ja trafiłem właśnie na ten, więc o nim napisałem. :-) Oczywiście freeware. Jeden pliczek, 21KB.

Drugim programem, którego konkretna funkcjonalność mnie zaciekawiła, to Free Download Manager. Jak sama nazwa wskazuje, wiele za niego nie zapłacimy. ;-) Co konkretnie mi sie w nim spodobało? Otóż załóżmy, że chcemy ściągnąć plik zip, np. o wielkości 200MB, ponieważ wydaje nam się, że wewnątrz znajdziemy konkretny pliczek o rozmiarze powiedzmy 2MB. FDM umożliwia:
Po pierwsze, obejrzenie zawartości zipa zanim tak naprawdę zaczniemy ściąganie, więc możemy potwierdzić obecność interesującego nas pliku.
Po drugie, mamy możliwość zaznaczenia tylko tych plików znajdujących się w zipie, które nas interesują i tylko te pliki zostaną ściągnięte.

Nie wiem czy jest to popularna funkcjonalność w tego typu programach, ale mi się bardzo spodobała. :-)