Dakota Blog

Ktoś ma ochotę na “mały” quiz? Microsoft prezentuje:

http://www.microsoft.com/click/areyoucertifiable/

Udanej zabawy. :-)

Security is not a things that we do, security is the way that we do things…

Co wspólnego mają NAP 2008 i Exchange 2007 CCR?

Najwyraźniej dzielą się wirtualnym laboratorium. ;)

Jeżeli chcielibyśmy lepiej zrozumieć NAP w Windows Server 2008 i zdecydujemy się na skorzystanie ze specjalnie przygotowanych do tego celu maszyn wirtualnych, to możemy przeżyć chwile zwątpienia.

Po odwiedzeniu strony TechNet Virtual Lab: Understanding NAP in Windows Server 2008, natkniemy się na:

Niby o NAP…. A może jednak o CCR i MNS? ;)

Idziemy dalej…

Tutaj dowiedzieliśmy się, że po zakończeniu VL (Virtual Lab) mającego na celu – jak sama nazwa wskazuje – pomóc nam zrozumieć NAPa w WS2008, będziemy potrafili: zainstalować Windows Server 2003 cluster, skonfigurować Majority Node Set z file share witness i skonfiguować Exchange 2007 CCR.

Może w takim razie pdf z instrukcjami rozjaśni nam o czym w końcu jest ten VL?

Wygląda nieźle. Chyba jednak będzie o NAPie. :)

Przechodzimy do następnej strony….

Nie, niestety… Hmmm… wygląda na to, że jednak dowiem się czegoś o tym CCR i MNS w Northwind Traders. ;)

Następna strona…

Ufff… A jednak NAP. :)

Nie wiem czy takie hybrydowe VL można spotkać częściej, bo już dawno żadnego nie robiłem, ale z tym na pewno nie wszystko jest w porządku. ;)

Microsoft Windows Malicious Software Removal Tool, jest jedną z "poprawek", która od wielu miesięcy instalowana jest na systemach Windows poprzez Automatic Updates. Na ogół zauważamy ją przeglądając listę udostępnionych w danym miesiącu poprawek.

Narzędzie to możemy również ściągnąć bezpośrednio ze strony Microsoft.

Lista złośliwego oprogramowania jakie MSRT jest w stanie usunąć z naszych systemów jest dość obszerna. Znajdują się na niej między innymi takie rodzynki jak Blaster, Sasser, czy też Mydoom. Do najmłodszych co prawda już nie należą, ale wciąż, niestety, można je  znaleźć na wielu systemach.

Aktywność MSRT możemy sprawdzić zaglądając do pliku mrt.log, który znajdziemy w folderze %WINDIR%\debug.

Jego zawartość może przedstawiać się mniej więcej tak:

---------------------------------------------------------------------------------------

Microsoft Windows Malicious Software Removal Tool v2.5, December 2008
Started On Mon Dec 15 10:33:20 2008

Results Summary:
----------------
No infection found.

Return code: 0
Microsoft Windows Malicious Software Removal Tool Finished On Mon Dec 15 10:35:01 2008

---------------------------------------------------------------------------------------

Microsoft Windows Malicious Software Removal Tool v2.6, January 2009
Started On Sat Jan 17 10:57:39 2009

Results Summary:
----------------
No infection found.

Return code: 0
Microsoft Windows Malicious Software Removal Tool Finished On Sat Jan 17 10:59:26 2009

---------------------------------------------------------------------------------------

Nic jednak nie stoi na przeszkodzie aby z MSRT korzystać częściej. Sami możemy uruchomić skanowanie  naszego systemu w dogodnym dla nas czasie. Wystarczy, że wpiszemy mrt w Start > Run.

Wybór rodzaju skanowania:

Tutaj mała uwaga. Po wybraniu opcji 'Full scan', skanowanie mojego systemu trwało ponad 24 godziny (!), a MSRT informował, że analizie zostało poddanych ponad 4 500 000 plików! Nie miałem pojęcia, że jest ich na moich dyskach aż tyle. :) W trakcie skanowania można jednak było zauważyć, że MSRT "zagląda" np. również do archiwów .rar, a następnie do plików .cab znajdujących się w tychże archiwach. Mając to na uwadze, 4,5 miliona plików nie dziwi już aż tak bardzo.

Dostępne informacje podczas skanowania:

Efekt skanowania.

Pozytywny:                                              Już nie tak bardzo pozytywny ;)

Po kliknięciu na "View detailed result of the scan" możemy obejrzeć listę tego co rozpoznaje MSRT, jak i tego co ewentualnie udało mu się usunąć.

Garść uwag...

Zadaniem MSRT nie jest zastąpienie programu antywirusowego. Przede wszystkim wykrywa  tylko część ze znanych programów. MSRT usuwa istniejącą infekcję, a nie chroni przed jej powstaniem.

Standardowo MSRT jest uruchamiany w trybie cichym, a użytkownik zostaje poinformowany tylko w przypadku wykrycia infekcji.

Z MSRT możemy korzystać także z poziomu wiersza poleceń. mrt /? wyświetli okno z listą dostępnych przełączników:

O tym jak ewentualnie wdrożyć Microsoft Windows Malicious Software Removal Tool w firmie, traktuje artykuł "Wdrażanie Narzędzia Microsoft Windows do usuwania złośliwego oprogramowania w środowisku przedsiębiorstwa"

Dla zainteresowanych...

11-02-2009 ukazała się wersja beta czwartej wersji BackTrack.
ISO i VMware image można ściągnąć jak zawsze:

http://www.remote-exploit.org/backtrack_download.html

Kilka z nowości w BackTrack 4 Beta:

- Kernel został uaktualniony do wersji 2.6.28.1 czego rezultatem jest między innymi lepsze wsparcie sprzętowe;
- BackTrack 4 Beta może być uruchamiany poprzez sieć, jeżeli korzysta z kart sieciowych obsługujących PXE;
- Zawiera SAINTexploit (Penetration Testing Tool) i Maltego 2.0.2 (open source intelligence and forensics application);
- W pełni funkcjonalny Unicornscan (information gathering and correlation engine)
- Wsparcie dla RFID;
- Wsparcie Pyrit CUDA;

Dla mniej zainteresowanych:

BackTrack jest bardzo popularną dystrybucją Linuxa, do badania zabezpieczeń i diagnostyki systemów i sieci. BackTrack może być uruchamiany bezpośrednio z CD.

Jak w prosty sposób z poziomu CMD, otrzymać listę wszystkich serwerów terminali (również Citrix) w naszej sieci?

Mamy w systemie programik, który świetnie adresuje powyższe pytanie. Wystarczy, że w CMD wpiszemy qappsrv (zapewne można tę nazwę rozwinąć na coś typu Query Application Server).
Jeżeli stacja z której korzystamy nie znajduje się w domenie, to dodatkowo definiujemy przełącznik /domain.

Opcje są oczywiście dostępne po wpisaniu qappsrv /?

C:\qappsrv /?
Displays the available application terminal servers on the network.

QUERY TERMSERVER [servername] [/DOMAIN:domain] [/ADDRESS] /CONTINUE]

  servername         Identifies a Terminal server.
  /DOMAIN:domain  Displays information for the specified domain (defaults
                          to the current domain).
  /ADDRESS           Displays network and node addresses.
  /CONTINUE          Does not pause after each screen of information.

Efekt powinien byś podobny do poniższego:

C:\>qappsrv
Known Terminal servers
----------------------
TS1
Citrix1
Citrix2
TS2
Citrix3
TS3
Citrix4
Citrix5

Gdyby komuś przyszła ochota na instalację Live Mesh na systemie Windows Server 2008 (nikogo nie oceniam - różnie się ludziom w życiu nie układa ;) ), to może trafić na drobne utrudnienie, którym będzie poniższy komunikat:

[80070659] This installation is forbidden by system policy. Contact your system administrator.

W takim przypadku, problemem może być brak klucza w rejestrze lub konfiguracja tegoż klucza.

Modyfikujemy rejestr następująco:

Lokalizacja: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\

Klucz: Installer

Nazwa: DisableMSI

Typ: REG_DWORD

Wartość: 0

Najprawdopodobniej nie będzie kolejnych części "reklam o niczym", czyli duetu Gates & Seinfeld. Zamiast tego, możemy pooglądać masę wszelakiej maści ludzi, twierdzących, że są PeCetem. :)

No cóż... z marketingowego punktu widzenia, "pecetowa kampania" ma z całą pewnością większy sens. Nietrudno doszukać się w niej bezpośredniej odpowiedzi na reklamy Apple (I'm a Mac, and I'm a PC).

Bardzo dobrze, że Microsoft w końcu zaczął reagować na tego typu ataki i jeszcze lepiej, że robi to w sposób pozytywny. "Pozytywny", tzn. nie kontynuujący negatywnej kampanii jaką stosuje Apple.

Jednak patrząc z czysto rozrywkowego punktu widzenia, zdecydowanie lepiej oglądało mi się wspomniany duecik. :)

Na stronie www.windows.com możemy już obejrzeć drugi odcinek nowej kampanii reklamowej, mającej między innymi "zbliżyć Microsoft do ludzi".

Moim zdaniem ten jest bezapelacyjnie bardziej zabawny i jeżeli następne będą równie dobre, to może 10 milionów dolarów gaży, które zainkasował Seinfeld, faktycznie zaowocują czymś więcej niż tylko zwrotem kosztów inwestycji. ;)
Cała kampania ma pochłonąć, bagatela, 300 milionów dolarów.

Więcej o założeniach i celach kampanii: "Microsoft Kicks off new Windows Campaign with Star Power".

C:\>nslookup 69.69.69.69
Server:  resolver1.opendns.com
Address:  208.67.222.222

Name:    the-coolest-ip-on-the-net.com
Address:  69.69.69.69

;)

Czy to nie wygląda przypadkiem znajomo? ;)

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 w 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. :-)