it-flow.pl

Podczas ostatnich potyczek z Windows 7 i Cross realm zauważyłem ciekawą rzecz. W przypadku wykorzystania interfejsu hosta poprzez maszyny wirtualne (Bridged connection) z stacji hosta na którym jest zainstalowany VMware można uruchomić Wiresharka i śledzić ruch przesyłany z maszyn wirtualnych w świta. Jedynie w celu wyczyszczenia zbędnego ruchu warto użyć filtru ip.addr=Adres_IP. Jest to o tyle przydatne, że nie trzeba się bawić w zdalne łapanie ruchu. Niby oczywista rzecz a przez kilka dni męczyłem się w zdalne łapanie ruchu czy przełączanie między kontami na jednej stacji.

Migracje, migracje i jeszcze raz migracje. Od pewnego czasu siedzę i staram się poprawić i udoskonalić stare usługi, zaktualizować systemy, itd.

Jedną z bardziej interesujących rzeczy jest migracja z Windows XP do Windows 7. Jak to zwykle bywa jednym z częstszych problemów jest odpowiednia konfiguracja systemów do współpracy z trustem między REALM-em MIT Kerberos a Active Directory.

W Windows 7 Microsoft wprowadził sporo zmian część z nich dotyczy konfiguracji samego logowania do REALMu.

Główne zmiany to:

• Uproszczenie konfiguracji samego REALMu na stacjach klienckich
• Wyłączenie przestarzałych mechanizmów szyfrowania (DES-CBC-{CRC,MD5})- źródło
• Wprowadzenie odpowiedniego szablonu polis do konfiguracji REALMu

Po instalacji Windows 7 i wpięciu systemu do domeny rozpocząłem konfigurację REALMu. Po małym przeglądnięciu kilku stron amerykańskich uniwersytetów okazało się, że konfiguracji realmu w Windows 7 nie przeprowadza się już za pomocą ksetup.exe:

ksetup.exe /addkdc nazwa_realmu nazwa_serwera_kdc_dla_podanego_realmu

ksetup.exe /domain nazwa_domyslnej _domeny

Dla ułatwienia Microsoft utworzył odpowiedni szablon polis:

Na początku zainteresowałem się tylko dwiema opcjami:

• Define interoperable Kerberos V5 realm settings – opcja odpowiada za odpowiednią konfigurację realmu oraz serwerów KDC, które ma wykorzystać klient. W Windows XP konfiguracja tych ustawień dobywała się za pomocą ksetup.exe
• Require strict KDC validation – sprawdza pewne obostrzenia dotyczące certyfikatu serwera KDC.

Dodatkowo skusiłem się na ustawienie DefaultLogonDomain na nazwę mojego Realmu. Jak większość pamięta od Visty z ekranu logowania zniknęła możliwość wyboru domeny/realmu logowania. Aktualnie użytkownik ma się logować za pomocą User Principal Name (login@nazwadomeny). Ustawnie DefaultLogonDomain pozwala logować się do domyślnej domeny/realmu za pomocą samego loginu

Jeśli, ktoś nie chce konfigurować tych ustawień za pomocą GPO to może wykorzystać odpowiedni wpisy w rejestrze

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
“DefaultLogonDomain”=”Nazwa_Realmu”

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos]
“MitRealms_Enabled”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\MitRealms]
“Nazwa_Realmu”=”<f>0×00000008</f><k>serwer_kdc_1;serwer_kdc_2</k>”

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
“KdcValidation”=dword:00000002

W przypadku trzeciego ustawienia (Define interoperable Kerberos V5 realm settings) między <f></f> podajemy w postaci hex-a listę opcji, które mają być wykorzystane podczas odpytywania serwerów KDC w danym realmie:

• 0×00 None – brak flag
• 0×01 SendAddress – pozwalaj na adresy IP w generowanych ticketach
• 0×02 TcpSupported – serwery kluczy akceptują ruch TCP, wymagany przy dużych pakietach
• 0×04 Delegate – każdy w realmie jest zaufany do delegacji
• 0×08 NcSupported – podany realm wspiera Name Canonicalization

Przepraszam za trochę lakoniczne tłumaczenie, więcej informacji o opcjach w technecie.

Jeśli po konfiguracji nie udaje się zalogować do systemu. Występuje komunikat błędny login lub hasło, to najprawdopodobniej serwery kluczy wykorzystują mechanizmy DES-CBC-CRC lub DES-CBC-MD5, które w Windows 7 i Windows Server 2008 R2 zostały domyślnie wyłączone. Włącznie mechanizmów najlepiej wykonać za pomocą GPO:

Tutaj taka drobna uwaga, którą podał Tomek Onyszko na wss.pl. W niektórych przypadkach warto wyłączyć AES128 i AES256 jeśli nie jest on wykorzystywany.

Po zmianie tych ustawień można się poprawnie zalogować używając MITowskiego realmu. Niestety po zalogowaniu na użytkownika nie zostały nadrzucone polisy oraz sam użytkownik nie miał dostępu do serwerów będących w domenie Windows. Co prawda w logach DC widać, że zaszło mapowanie użytkownika z realmu na użytkownika w AD jednak polecenie klist nie wyświetla wymaganych ticketów.

Po trzech dniach spędzonych przy Wiresharku postanowiłem zapytać na wss i jak zwykle w sprawach związanych z Kerberosem Tomek Onyszko okazał się być bardzo pomocny. Nie wiem jak mu podziękować bo gdyby nie jego pomoc to nadal ślęczałbym nad ekranem z dumpem wiresharka.

Poniżej postaram się krótko opisać gdzie tkwił problem.

W przypadku zaufania między domenami czy realmami, komputer odpytuje odpowiednie serwery kluczy w celu pozyskania odpowiednich ticketów, które później będzie wykorzystywał do uzyskania dostępu do konkretnych serwerów. W tym poście nie będę tego jakoś szczególnie opisywał (dobry materiał na kolejny post). W skrócie jeśli klient nie dostanie ticketu z serwera kluczy z jednej domeny to prosi o odpowiedni ticket Granting Services, który pozwala mu odpytać kolejny serwer kluczy odpowiedniej domeny.

Tak robił XP, który jest aktualnie na stanowiskach:

Powyższy zrzut ekranu obrazuje prośbę klienta o odpowiedni ticket na potrzeby dostępu do miejsca gdzie leża polisy:

1. Klient prosi o TGS serwera KDC w realmie, w którym uwierzytelnił się użytkownik
2. Serwer kluczy dla danego realmu zwraca informacje PRINCIPAL_UNKNOWN – informacja o określonym SPN znajduje się w innym serwerze kluczy ( w moim przypadku kontrolerze domeny z którą zestawiony był trust realm )
3. Klient prosi o TGS (krbtgt/nazwa_realmu) ticket jest wymagany by klient mógł rozmawiać z zaufaną domeną
4. Serwer kluczy w naszym realmie odsyła odpowiedni ticket
5. Klient prosi kontroler domeny o określony ticket dla cifs/nazwa_kontrolera (strzałka 3 na zdjęciu), wykorzystując ticket, który otrzymał w kroku czwartym.
6. Serwer zwraca odpowiedni ticket.
7. Klient przystępuje do komunikacji z serwerem plików.

W przypadku Windows 7 spraw wyglądała trochę gorzej ponieważ, system pomijał prośbę o TGS (krbtgt, oraz o odpowiedni ticket w zaufanej domenie i przeskakiwał na NTLM):

Jak widać na powyższym zrzucie ekranu klient:

1. Pyta serwer kluczy dla wykorzystywanego realmu
2. Serwer zwraca odpowiedź o braku Principala o określonej nazwie (2)
3. Klient próbuje wykorzystać NTLM by dostać się do zasobów.
4. Próba w dalszej części kończy się fiaskiem.

Po pomocy Tomka okazało się że problem ten można rozwiązać poprzez wskazanie systemowi klienckiemu jakie nazwy realmow/lasow ma przeszukiwać. Można to skonfigurować w GPO ( pierwsze zdjęcie w wpisie) Use forest search order. Po dopisaniu tam nazwa_realmu, nazwa_domeny_ad, klient zaczyna odpytywać kontroler. Jedynym minusem który tutaj występuje jest brak zapytania ok określony  TGS (krbt/…) jednak ticket ten zostaje pobrany na samym początku podczas logowania do domeny. Po ostatniej zmianie klient zaczyna poprawnie funkcjonować:

• pobierane są polisy dla użytkownika
• można uzyskać dostęp do określonych zasobów dyskowych w zaufanej domenie.

Przyznam się, że problem jest dość ciekawy i w wolnej chwili trzeba się będzie trochę bardziej w niego zagłębić. Ale wcześniej muszę sobie skonfigurować wirtualnej środowisko by nie bawić się w zamazywanie zrzutów z Wiresharka. Przy okazji może uda mi się opisać proces konfiguracji Cross Realm Trusta.

Jak zwiększyć dostępność usługi DHCP w naszej sieci? Z pomocą przychodzą nam dwa rozwiązania:

- reguła 80/20

- klastrowanie usługi DHCP

W przypadku klastra sprawa jest prosta:

• instalujemy kilka węzłów przyszłego klastra
• tworzymy wspólny zasób na potrzeby klastra.
• tworzymy klaster dla usługi DHCP

W przypadku reguły 80/20 konfiguracja jest trochę bardziej skomplikowana. Poniżej postaram się w kilku zdaniach opisać działanie i konfigurację tej reguły.

80/20 w założeniu ma zwiększyć dostępność usługi DHCP w przypadku awarii jednego z serwerów. Ogólnie rzecz ujmując 80% niezarezerwowanych adresów jest przydzielana przez jeden serwer a reszta poprzez drugi.

Jakie korzyści niesie konfiguracja reguły 80/20?

Jak można szybko zauważyć w przypadku naszej konfiguracji cała reguła wymaga od nas poprawnej konfiguracji wykluczeń. Podczas działania obu serwerów reguła nie wnosi nic poza drobnym odciążeniem Serwera 1. Sytuacja zaczyna robić się ciekawa gdy awarii ulegnie serwer 1. Wtedy tylko 20% niezarezerwowane adresów może zostać przydzielonych z drugiego DHCP. Jeśli nasza sieć jest duża to 20% adresów bardzo często może pokryć tylko cześć pomieszczeń lub kilka pięter dużego budynku. Na szczęście po awarii lub celowym wyłączeniu serwera administrator może usunąć wykluczenie z drugiego serwera i tym samym udostępnić do dystrybucji wszystkie wolne adresy, które przynależą do skonfigurowanego zakresu. Jeśli serwer 1 zacznie znowu funkcjonować to administrator musi ponownie nałożyć nowe wykluczenie na drugim serwerze.

Dlaczego cały czas mówisz o niezarezerwowany adresach, co z rezerwacjami?

W przypadku rezerwacji administrator jest zmuszony do utrzymania identycznych rezerwacji na obu serwerach. Tak jak pisałem w poprzednim wpisie o wykluczeniach, serwer DHCP na systemie Windows może rozdawać zarezerwowane adresy, które leżą w wykluczonej części. Tak więc administrator jest zmuszony to utrzymania spójnej listy rezerwacji. Dobrze jest napisać odpowiedni skrypt do tworzenia rezerwacji na obu serwerach.

Kiedy nie trzeba usuwać wykluczenia?

Jeśli w naszym zakresie mamy 200 adresów a mniej niż czterdzieści jest przydzielanych bez rezerwacji to wtedy nie ma potrzeby usuwania wykluczenia.

Czy muszę ręcznie usuwać wykluczenia?

Nie. Jeśli potrafisz napisać proste skrypty to np. za pomocą batch-a, vbscript-a, powershell-a da się napisać proste skrypty uruchamiane w harmonogramie zadań. Działanie skryptu ogranicza się do:

• Sprawdzenia czy serwer jest dostępny:
• Jeśli dodatkowy serwer jest niedostępny to usuwamy wykluczenie.
• Jeśli serwer jest dostępny to nakładamy wykluczenie na nadmiarowe adresy.

Jak skonfigurować serwery?

1. Instalujemy na dwóch serwerach usługę DHCP
2. Konfigurujemy na obu serwerach ten sam zakres adresów oraz niezbędne opcje
3. Na pierwszym serwerze wykluczamy 20% końcowych adresów
4. Na drugim serwerze wykluczamy 80% początkowych adresów.
5. W razie potrzeby na obu serwerach wpisujemy te same rezerwacje.

Skonfigurować klaster usługi DHCP czy wykorzystać regułę 80/20?

To zależy:>

Jeśli masz już w sieci zainstalowany klaster typu Failover i nie jest on zbyt mocno obciążony to można na nim skonfigurować usługę DHCP, która domyślnie będzie przetwarzana przez aktualnie niewykorzystywany węzeł.  Jeśli nie posiadasz w sieci serwerów działających w klastrze FO to bardziej opłacalna będzie konfiguracja reguły 80/20. Usługa DHCP nie obciąża zbyt mocno systemu więc można ją uruchomić nawet na małej maszynie wirtualnej. Dodatkowo reguła 80/20 nie wymaga posiadania dostawowej przestrzeni dyskowej na kolejnym serwerze.

W Siódemce wprowadzono natywne wsparcie dla obrazów VHD i dodatkowo całkiem ładnie zintegrowano VirtualPC z Explorerem. Niestety domyślnie Windows 7 nie wspiera Virtual Server 2k5 R2:/ Innymi słowy nie za bardzo mamy jak uruchomić nowy laucher dla kursów MOC:/ Podczas instalacji VS2k5 dostaniemy komunikat typu:

Mimo komunikatu instalacja zakończy się sukcesem. Niestety po ponownym uruchomieniu komputera system nie będzie mógł podnieść usługi vssrvc.exe, ponieważ zostanie ona uznana za niekompatybilną. Rozwiązanie problemu, które udało mi się znaleźć polega na wyłączeniu, na czas instalacji, części opcji mechanizmu zgodności.

Szybkie Now how:

1. Na starcie instalujemy IIS, jest do jeden z dodatków systemu, który możemy doinstalować przez dodaj usuń programy.
2. Po zainstalowaniu IIS odpalamy jako administrator gpedit.msc.
3. W drzewie polis przechodzimy do Konfiguracja komputera –> Składniki Systemu Windows –> Zgodność aplikacji.
4. Następnie włączamy odpowiednie ustawienia, nie wszystkie z ustawień są wymagane. Obecnie nie miałem czasu dochodzić, które poza widocznymi na zdjęciu mogą być nie skonfigurowane:
5. Po konfiguracji w/w opcji przechodzimy dalej do gałęzi  Konfiguracja komputera –> System –> Rozwiązywanie Problemów i diagnostyka –> Diagnostyka zgodności aplikacji.
6. Wyłączamy klucze zgodnie z poniższym rysunkiem:
7. Zamykamy gpedit.msc
8. Uruchamiamy wiersz poleceń jako administrator i wpisujemy: gpupdate /force
9. Restartujemy komputer, czasami gdy komputer nie zostanie zrestartowany Asystent zgodności aplikacji uruchomi się podczas instalacji.
10. Uruchamiamy instalator Virtual Server 2k5 R2
11. Po zakończeniu instalacji przechodzimy do katalogu gdzie zainstalowaliśmy VServer (Domyślnie: C:\Program Files\Microsoft Virtual Server\
12. Zmieniamy nazwę pliku vssrvc.exe na np. vssrvc7.exe
13. Za pomocą Run As uruchamiamy regedit i modyfikujemy wszystkie klucze rejestru, które zawierają wpis vssrvc.exe na  vssrvc7.exe.
14. Uruchamiamy ponownie komputer
15. Cofamy wszystkie zmiany z kroku 4-6

Czy Virtual Server 2005 będzie jeszcze w pełni wspierany przez Windows 7 tego nie wiadomo. Osobiście wydaje mi się, że nie. Wynika to z faktu, że nie jest to usługa dedykowana na desktopy. Poza tym V Server nie posiada niektórych dodatków, które pojawiły się w nowym Virtual PC.

Producenci płyt głównych coraz częściej implementują w swoich płytach możliwość tworzenia FakeRaidu. Ostatnio zaopatrzyłem się w komputer stacjonarny i przez pewnie okres czasu udało mi się przetestować FakeRaid, szczególnie jego niezawodność.

Na początku po zakupie pierwszej płyty głównej spiąłem wszystko w Raid1. W celach testowych zainstalowałem system, oprogramowanie, etc. Po kilku dniach zapragnąłem zmienić układ chłodzenia procesora. Niestety nowy wentylator wymagał wykręcenia płyty głównej. Po zmianie mocowania chłodzenia do procesora włożyłem płytę główną, złożyłem komputer w całość i uruchomiłem. Jak się okazało płyta Asusa po wyjęciu z obudowy jakimś cudem stwierdziła, że jest nowa i wróciła do domyślnych ustawień. Jeszcze przed startem biosu wiedziałem, że trzeba zmienić tryb w jakim działają złącza SATA na Raid. Niestety po ponownym uruchomieniu raid1 został poprawnie wykryty przez komputer, tzn. występowała  odbudowa. Niestety system nie wstał:( Szybkie próby naprawy systemu za pomocą bootrec i kreatora naprawy nie przyniosły pozytywnego skutku.

Po  tygodniu z kilku powodów zmieniłem płytę główną z Asusa na Gygabita. Po zmianie płyty wymagana była budowa nowego mirrora i instalacja nowego systemu. Oczywiście nawet przez myśl mi nie przeszło, że wszystko zadziała bez reinstalacji systemu :] Przez kolejny tydzień często zmieniałem dyski między różnymi portami SATA co często kończyło się ponowną instalacją całego systemu.

Po dwutygodniowej zabawie postanowiłem zrobić te same roszady za pomocą raidu systemowego. Po zainstalowaniu Windows 7 przyłączyłem jeden wolumin raid0 i jeden raid1 na tych samych dyskach.  Po tygodniu użytkowania nie zauważam żadnej różnicy między raidem realizowanym tylko przez system a fakeRaidem, który też częściowo jest wykonywany przez system. Tzn. właściwie jest jedna różnica:)  W przypadku stripingu wydajność spadła jednak jest to spowodowane dołożeniem kilku innych partycji w innej konfiguracji:]

Podczas ostatniego tygodnia zdarzyło mi się przepiąć oba dyski na zupełnie inną płytę, zmieniać porty do których były podpięte. Jak na razie nie zdarzyła się sytuacja, w której system powiedziałby “Przepraszam ale nie mogę się uruchomić” :> Raz wymagana była odbudowa mirrora jednak sytuacja ta nie uszkodziła systemu. Chodził on wolniej przez klika godzin jednak potem wrócił do siebie.

Zatem jeśli planujesz instalacje FakeRaidu to warto się nad tym zastanowić, szczególnie gdy często zmieniasz konfiguracje sprzętową komputera.

Piątego maja na serwerach root zostanie dokonana zmiana protokołu DNS na DNSSec [Źródło]. Jeśli ktoś posiada w swojej infrastrukturze Windows Server 2003, to rezultat testów obsługi pakietów większych niż 512 bajtów (nslookup -q=txt rs.dns-oarc.net.) może wyglądać  tak:

Włączenie wsparcia większych pakietów jest dość proste i odbywa się za pomocą komendy:

dnscmd NazwaServera /config /EnableEdnsProbes 1

Po odświeżeniu konfiguracji serwera DNS, około 30-40 sec, powinniśmy dostać lepsze wyniki:

Jeśli mimo zmian w konfiguracji usługi DNS nadal otrzymujemy pakiety nie większe niż 512 bajtów, to należy sprawdzić czy nasza zapora nie odcina większych pakietów.

Sytuacja dość prosta i czasem spotykana w różnych organizacjach.

• Mamy sobie sieć:10.10.0.0/16.
• Tworzymy na serwerze DHCP zakres dystrybucji adresów (Scope) 10.10.1.0-10.10.3.254.
• Na ten zakres narzucamy wykluczenie 10.10.1.0-10.10.3.254.
• Do bazy DHCP dodajemy kolejne rezerwacje dla odpowiednich hostów.
• I mamy usługę, która rozdaje adresy tylko dla osób z odpowiednim adresem MAC.

Aby rozwiać wątpliwości niektórych osób, rezerwacje są ważniejsze od wykluczeń. Informacje o tym fakcie można znaleźć w KB196066. Tak, wiem parę osób zaraz zarzuci mi informacją, że przecież w Windows Server 2008 R2 nie można dodawać rezerwacji spoza zakresu KB2005980. Na szczęście dodawanie rezerwacji z poza zakresu nie oznacza dodawania rezerwacji z przestrzeni, która została wycięta poprzez wykluczenie.

W skrócie, od Windows Server 2008 R2 nie można dodać rezerwacji adresu 10.10.0.10 do bazy serwera DHCP, jednak dodanie rezerwacji dla 10.10.2.100 jest możliwe.

Nie lubię diagnozować problemów z replikacją. Zazwyczaj problemy te są proste do zidentyfikowania i poprawienia, jednak czasem człowiek wyrywa sobie włosy z głowy.

W jednej z domen, którą zarządzam mam mieszane środowisko Wind2k3 i Win 2k. Zazwyczaj wszystko pięknie chodzi, co często usypia moją czujność i pozwala mi zapomnieć o niektórych maszynach na długi czas ( czasem w końcu trzeba wgrać poprawki). Po ostatnich przenosinach, podmiankach, wymianach, readresacjach…, które odbyły się o dziwo bez problemu od pewnego czasu w logach pojawiały się Eventy 1311, 1566. Osoby zajmujące się Active Directory stwierdź – haha standardowe problemy How to troubleshoot intra-site replication failures. No i wszystko fajnie przeszedłem całą standardową procedurę omijając kroki, które mnie nie dotyczą, czyli ogólnie: repadmin …, net stop lsass …, netdom resetpwd …, net start lsass. Po restarcie wszystko działa jak poprzednio , replikacja nadal Access Denied. Wireshark mówi, że kontrolery się komunikują jednak DC wyraźnie stwierdza ze KCC nie może zbudować topologii replikacji.  Repadmin stwierdza, że wszystko spięte, połączenia istnieją, itd.  Jak się okazało rozwiązaniem problemu była aplikacja łatki Q819249.

In Windows 2000, the Knowledge Consistency Checker (KCC) uses the Intersite Messaging service to help it build the spanning tree topology for Microsoft Active Directory directory service replication. In a very small percentage of cases, Intersite Messaging may not complete building the hash table that it passes to the KCC. When the KCC uses this hash table in its calculations, this may generate the KCC logging event ID 1311 in the Directory Services event log.
This problem typically occurs in environments with large numbers of sites, domain controllers, and domains.

W sumie niewiele brakło a zadałbym pytanie na WSS. Jednak stwierdziłem, że skoro od pewnego czasu interesuję się AD to trzeba sobie z problemami radzić samemu <taniec szczęścia>.

Cztery lata używania systemów innych niż Windows odbijają dość mocne znamię Szczególnie gdy ktoś przez spory okres czasu bardziej zaprzyjaźniał się z konsolą niż z X-ami. Mimo iż od około trzech lat cały czas zaprzyjaźniam się z “oknami” to nadal zdarza mi się korzystać z wiersza poleceń.

Tak, w systemach Windows jest coś takiego jak wiersz poleceń. Microsoft wypuszczał i wypuszcza masę narzędzi ułatwiających pracę w konsoli. Cześć z tych narzędzi nie jest domyślnie instalowana w systemie dlatego wiele osób nie wie o ich istnieniu.

Ostatnimi czasy spotkałem się z kilkoma pytaniami od studentów i znajomych, które dotyczyły  odpowiednika unixowej komendy tail. W przypadku systemów Windows Server do 2003 i systemów klienckich do Windows XP sprawa była dość prosta. Wystarczyło pobrać  Windows Resource Kit Tools. Po zainstalowaniu i uaktualnieniu ścieżki Path o odpowiednie wpisy można było korzystać z komendy tail.

Jedynym minusem tej komendy jest brak możliwości definiowania ilości wierszy, które mają zostać wyświetlone.  Opcja –f działa bardzo dobrze i poprawnie wyświetla informacje dopisywane do pliku.

A co z Windows Server 2008, Vista i 7?

W tych systemach te same czynności możemy wykonać za pomocą powłoki Powershell.

Odpowiednikiem komendy tail –f nazwa_pliku jest Get-Content nazwa_pliku –wait.

Co ciekawe da się też wyświetlać określoną ilość linii: Get-Content nazwa_pliku | select -last 2.

Jak widać osoby które lubią konsole wcale nie mogą narzekać na brak poleceń i możliwości jej wykorzystania. Owszem bazowy asortyment poleceń nie jest duży jednak można go rozszerzyć za pomocą dodatkowych paczek, powłok i programików z rożnych stron.

Kilka dni temu skusiłem się na zakup uaktualnienia VMware workstation z 6.5 do 7. Na stronie vmware jest opis nowych dodatków, które zostały zaimplementowane w Workstation 7. Mnie najbardziej interesowało wsparcie dla Windows 7 jako systemu hosta i gościa.

Sama aktualizacja przeszła dość szybko. Niestety co pewien czas przytrafiały mi się różne problemy z siecią, które często ignorowałem. Pewnego dnia okazało się, że połączenie się do nowej sieci czy zestawienie VPN na systemie hosta potrafiło całkowicie zawiesić system.  Po kilku godzinach wpadłem na pomysł by powyłączać mechanizmy mostka, które dorzuca VMware do połączeń sieciowych. Jak się okazało wyłączenie tej funkcji spowodowało usunięcie problemu z zawieszającym sie systemem jednak uniemożliwiło wykorzystanie mostkowanego połączenia w maszynach wirtualnych.  Niestety mam kilka maszyn, które po prostu muszą być podpięte bezpośrednio do tej samej siec co host.

W niedzielny wieczór (hmm w sumie to już była 4 nad ranem) okazało się, że po instalacji VMware i restarcie systemu należy się zalogować na konto administratora i poczekać, aż workstation7 doinstaluje niezbędne komponenty.  Jeśli pominiemy ten krok to może się okazać, że co pewien czas mogą się pojawiać dziwne problemy z maszynami wirtualnymi.

PS

Aktualnie przymieszam się napisać coś więcej o tym problemie na community VMware by utwierdzić się w przekonaniu, że faktycznie problem wygenerowałem sobie sam wykorzystując do instalacji zwykłe konto i UAC:(