UMnieDziala.pl

IIS7, podobnie jak II6 posiada możliwość autoryzacji certyfiaktem cyfrowym do strony.

Podonie jak w IIS 6, jest możliwość logowania za pomocą certyfikatów firm trzecich, jak również logowania certyfikatami skojarzonymi z kontami AD.

Problem pojawia się w momencie gdy chcemy skonfigurować takie rozwiązanie. Dla konfiguracji certyfikatem zewnętrznym do AD można znaleźć w sieci poradniki, ale do konfiguracji z uwierzytelnianiem z AD poradników nie ma. Niby wystarczy zainstalować dodatek do IIS7, włączyć w opcjach site, i już powinno działać. Ale niestety tak nie jest.

IIS7 ma poważne braki w interfejse do konfiguracji certyfikatów. O ile w opcjach całego serwera mamy możliwośc zanza`czenia uwierzytelnienia certyfikatem, to przy pojedynczym katalogu wirtualnym takiej możliwości nie ma. W związku z tym z cmd z podniesionymi uprawnieniami:

notepad %windir%\system32\inetsrv\config\applicationHost.config

Ta opcja jest ustawiana z automatu:

<Configuration>
<System.WebServer>
  <Security>
   <clientCertificateMappingAuthentication enabled="true" />

Wyszukujemy teraz interesujący nas site, np "Default Web Site/owa"

<location path="Default Web Site/owa">
<system.webServer>
  <security>
   <authentication>
    <windowsAuthentication enabled="false">
     <providers>
      <clear />
      <add value="Negotiate" />
      <add value="NTLM" />
     </providers>
    </windowsAuthentication>
    <anonymousAuthentication enabled="false" />
    <digestAuthentication enabled="false" />
    <basicAuthentication enabled="false" />
    <clientCertificateMappingAuthentication enabled="true" />
   </authentication>
  <access sslFlags="Ssl, SslNegotiateCert, SslRequireCert, Ssl128" />
</security>

Gdzie linijkę <clientCertificateMappingAuthentication enabled="true" /> trzeba po prostu dopisać, bo w GUI nie ma.

Jeśli chcemy mieć ClientCertificate + Windows Integrated

<windowsAuthentication enabled="true">
<clientCertificateMappingAuthentication enabled="true" />
<access sslFlags="Ssl, SslNegotiateCert, Ssl128" />

Ostatnio podczas przenoszenia plików użytkowników natknąłem się na typowy problem w-files.

Otóż przenieśliśmy katalogi domowe użytkowników na nowy serwer w2k8 x64. Włączyliśmy shadow copies. Zdefiniowaliśmy kopiowanie backupowe dfs-r do centrali, w celu późniejszego zrzucania stanu na tasiemki. Serwer sobie spokojnie śmigał, i wszystko wydawało się takie idealne. Nawet użytkownicy nie wydawali się niezadowolenia.

Wszystko niestety zepsuł błąd skryptu, który uszkodził strukturę katalogów na macierzy w centrali. Jako że dfs-r działa prawie niezawodnie, szybko dało się odczuć braki katalogów w oddziale.

Ale przecież jest shadow copy, więc nie powinno być problemu. Tak więc postanowiliśmy wejść do shadow copy, i spróbować przywrócić foldery.

I tu pojawił się pierwszy problem - shadow copy udawał, że nie umie znaleźć plików w folderach - wyświetlał się komunikat o ścieżce nie do znalezienia. Hmmm... problem uprawnień. Wobec tego przelogowujemy się i próbujemy jeszcze raz.. znowu nic.

Niestety w oddziale nie było żadnego innego serwera, a tylko stacje klienckie z xp. Wobec tego logujemy się zdalnie na stacje,i próbujemy odzyskać pliki. Jest, udaje się, ale niestety uprawnienia do plików się nie przenoszą.

Próbujemy volrest z w2k3 resource tools, niestety bez skutecznie. Narzędzie nie może sie podpiąć do shadow copy z windows 2008 w2k8 x64.

... chwilka załamania i wizja ręcznego ustawiania uprawnień.... nagle pomysł.., przecież shadow copy sharuje folder udostępniony z tą samą nazwą tylko z przedrostkiem określającym datę... wobec tego wejdźmy do właściwości otworzonej kopi shadow copy i znajdźmy ścieżkę... o, jest.

To teraz tylko robocopy w trybie backup – robocopy /b /COPY:DATSO /s /e /r:1 /w:1 i juz. Tylko kilka godzi stresu dla administratorów, i tylko godzina szukania narzędzia do przeglądania shadow copy : )

Jak wiadomo opcja 249 w DHCP nie przyjeła się - RFC zdefiniowało tę opcję jako opcję 121. W produktach Microsoftu do serii 2003 niestety nie było możliwości wyboru opcjii 121. Aż do momentu pojawienia się 2k8.

I tu niespodzianka. W windows 2008 opcja 121 jest, ale nie ma opcji 249. Co więc zrobić kiedy musimy użyć opcjii 121 w w2k3? ALbo użyć opcji 249 w w2k8? Musimy stworzyć ją sami.

Logujemy się do konsolki netsh:

netsh

dhcp server \\nazwa_serwera

Tworzymy definicje obiektu:

add optiondef  121 "Classless Static Routes - new" BINARY 0

lub dla 249

add optiondef  249 "Classless Static Routes - old" BINARY 0

anastepnie przechodzimy do odpowiedniego scope - tu testowo 192.168.193.0

scope 192.168.193.0

wpisujemy wartosc

set optionvalue 121 binary 100a64c0a8c10110ac16c0a8c101180a0c01c0a8c10118c0a8d5c0a8c101180a0c02c0a8c101180a0c03c0a8c101180a0c04c0a8c101180a0c05c0a8c101180a0c06c0a8c101

Oczywiscie aby sie nie narobic, najprosciej jest wykorzystac GUI istniejacej klasy, i za pomoca polecnia show optionvalue na scope sprawdzic odpowiedni ciag odpwiedzialny za sciezki.

Postanowiłem wykonać upgrade serwera na którym działa ten blog. Zabrałem się do tego jak zawsze najbardziej hardcorowo ze wszystkich możliwych sposobów - tzn. odpaliłem rdesktop, podmapowałem obraz iso za pomocą deamon tools, i wrzuciłem do katalogu. Normalni bym to zrobił 7-zip-em, ale 7-zip nie ma jeszcze obsługi standardu plików iso UFD, który został przyjęty przez Microsoft w Viscie i Longhornie.

Ok, instalator standardowy. Next next next, chce wykonać upgrade. Następnie sprawdzanie poprawności. Oczywiście nie spodobał mu się zainstalowany powershell, oraz deamon-toolsy. Więc usunięcie.

Kolejna próba instalacji, next next next, upgrade. 20 minut zbierania informacji o tym czy upgrade można wykonać. Next.

I tu pojawia się zbieranie informacjo o systemie...... tak 1,5 godiny, na szczęście terminal działa. Restart............godzina..........pół...nie pinguje sie... o co chodzi.....ok, zterminalujmy sie na jakas workstacje w tej sieci.. nic. Ok, po dwóch godzinach sie pinguje. Ale rdesktop nie dziala. Hmmm... Computer Management. Dziala : ) Zobaczmy serwisy. Zobaczmy czy uslugi terminalowe dzialaja. Dzialaja. Ale nie moge sie dostac dalej.. Hmm, www dziala, ale blog juz nie. A strona startowa to strona IIS7. Hmmm... Windows Firewall działa. Wyłaczmy.

........błąd rpc. Echh, i tyle : ) Hmm, musze sie jednak wybrac odwiedzic serwer.

Pol godziny pozniej w koncu podlaczylem komputer. I ku mojemu zdziwieniu ukazal sie ekran instalacyjny, z zaznaczonym Completing Installation(34%).

Po kolejnych 2 godzinach w końcu serwer zadziałał. Ogólnie cały proces instalacj zaczął się o 15, a zakończył o 19:30. Tak anprawde bez potrzeby ingerencji w sam proces upgradu.

Do tego, i co najwazniejsze, upgrade się udał. Wszystkie usługi zaczeły działać poprawnie. No, może oprucz blogu, ale po szybkim upgradzei silnika z asp1.1 do asp 2.0, i on zaczął chodzić.

No i ostatnia sprawa na koniec. Na moim systemie zainstalowany był WIndows 2003 Enterprise R2 VLK. WIęc Windows 2008 postanowił poszukać serwera KMS, i pozostawił sobie na to 3 dni. Jak się okazało nie mam dostępnych kluczy KMS-owych, a tylko klucze MAK. W przypadku w2k3 oznaczałoby to reinstalacje systemu WIndows. ALe w W2k8 można wipisać klucz MAK, a system grzecznie przeprowadzi aktywacje w firmie Microsoft.

Podsumowując - proces upgradu był bardzo prosty. Nawet przy tak skomplikowanym serwerze jak mój - czyli maszyna serwero-administracyjni-developerska, z zainstalowanym IIS, SQL-em, VS, antywirusem McAfee - przebiegł bez problemu, tylko wymagał dłuugiego czasu.

Jesli kiedykolwiek przygotowywaliście obrazy maszyn wirtualnych na szkzolenia, wiecie zapewne jakim problemem jest wgranie tych obrazów na stacje robocze.

Weźmy sytuacje typową: 16 komputerów w laboratorium, 4 GB danych, sieć 100MB

dla uproszczenia powiedzmy że maksymalna wydajność kopiowania to 10Mb/s, a do skopiowania jest 4000MB danych. Daje to 400sekund transferu. 400s*16/60s daje 106 minut na skopiowanie danych.

Możemy oczywiście zoptymalizować algorytm. Z stacji 1 kopiujemy na stacje 2. Później z stacji 1 i 2 kopiujemy na stacje 3 i 4. następnie z stacji 1,2,3,4 kopiujemy na stacje 4,5,6,7,8. Na końcu wykonujemy jeszcze jeden transfer z stacji 1,2,3,4,5,6,7,8 na stacje 9,10,11,12,13,14,15,16. Daje to 4 *400s/60s, czyli ~27 minut.

Czy można szybciej? Oczywiście. Wystarczy wykorzystać multicasty. W odróżnieniu od broadcastów, nie zapychają całej sieci ( o ile switch to umożliwia, ale obecnie już prawie każdy sobie z tym radzi), i jest routowalny ( o ile router to obsługuje).

Długo szukałem darmowego programu który by umożliwiał transmisje plików pod systemem windows.. I udało się. UdpCast

- http://udpcast.linux.lu/exe.html

Wydajność na poziomie 87% wysycenia łącza, przy 16 jednoczesnych transmisjach plików, czyli na poziomie 10.5Mb - zdecydownie szybciej niż SMB/CIFS. I do tego jest stabilny. I działa.

Minęły dwa lata od poprzedniego podgrzewacza. Dwa lata w rozwoju technologii. Dlatego dzisiaj zbudowaliśmy nową, ulepszoną wersję. Do budowy zostało wykorzystanych 5 AP WAP200 Linksys o mocy 200mW na antenach 3dBi oraz 2 AP bazujące na RB532 z podwójnymi kartami athereos i 4 antenkami panelowymi Gigaeter 18dBi. Dla ozdoby zamocowaliśmy jeszcze zdobyczną antenkę JAGI 12 dBi. Kubek został umieszczony na standardowym podgrzewaczu USB.

Sytuacja dość prosta:trzeba dodać obraz knoppixa v.5.1.1.CD do RIS-a. Tym razem z obrazem płyty znajdującym się na serwerze NFS. Niby wszystko działa, postępuje dokładnie tak samo jak przy konfiguracji z obrazem z SMB. Teoretycznie powinno być nawet prościej, jako ze NFS jest standardowo wbudowany w większość dystrybucji. Okazuje się jednak, że w plik miniroot.gz ze strony Manty wbudowanej obsługi NFS nie ma..

Zaraz, zaraz, ja to już kiedyś robiłem. Knoppix ma do tego jakieś sprytne narzędzie do konfiguracji. Chwila googlowania i już. Okazuje się, że najprostszym i najlogiczniejszym poleceniem tworzącym od nowa plik miniroot.gz jest /etc/init.d/knoppix-terminalserver. Wita nas miłym, graficznym kreatorem, gdzie możemy pokazać, które sterowniki kart sieciowych mają być wbudowane w plik oraz tworzy strukturę katalogu /tftproot, którą w prosty sposób można skopiować do katalogu templates RiSa.

Taki oto wspaniały błąd wyrzuca SC Essentials podczas instalacji w trybie frontend-backend. Dla pełnego przedstawienia sytuacji powinienem dodać, że backendem jest tu produkcyjny serwer SQL 2005 SP2 działający na W2k3 Enterprise, a za frontend miał służyć W2k3 Enterprise R2 SP2.

Instalacja SCE jest niby prosta, ale właśnie tytułowy błąd spowodował, że instalacja na zdalnym serwerze okazała sie niemożliwa. Oczywiście, w konfiguracji z wbudowanym serwerem DB wszystko chodziło, ale w takiej konfiguracji jesteśmy ograniczeni tylko do 150 workstacji.

Postanowiłem więc rozwiązać problem. Może wersja reporting services na backendzie jest zła? Okazało się, że reporting services w ogóle nie powinny stać na backendzie, a na frontendzie z podpiętą backendową bazą.

Na frontendzie po zainstalowaniu RS pojawił się tytułowy błąd. Może nie podoba mu się, że RS jest w wersji SP2, a w instrukcji jest wersja SP1? Nie. Może pracuje na złym koncie? Też nie. Może reporting services jest jednak jakoś źle skonfigurowane? Nie, działa.

Hmm.. Zostały narzędzia ostateczne - Filemon i Regmon. Też nic. Kolej na desperackie rozwiązania - czytamy logi - i też nic. Chociaż.. W logach instalacji jest jakaś tajemnicza formułka na początku:

1:22 AM: DiscoverSRSInstanceInformation:  Actual SRS reg location is: SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\Setup
1:22 AM: CheckHttpAddressResponse: WebException Raised. The following error occured : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
1:22 AM: StackTrace:    at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.EnterpriseManagement.SCE.Setup.SrsHelper.CheckHttpAddressResponse(String httpSite)

Hmm... Niby SSL/TLS jest odznaczony w konfiguracji RS, a jednak z jakiegoś powodu je chce widzieć. Usuńmy wiec z IIS-a certyfikat.

O... komunikat się zmienił:

1:29 AM: CheckHttpAddressResponse: WebException Raised. The following error occured : The underlying connection was closed: An unexpected error occurred on a send.
1:29 AM: StackTrace:    at System.Net.HttpWebRequest.GetResponse()

Hmm... To może być jednak to. Po krótkim eksperymencie z certyfikatami okazało się, że SCE próbuje się łączyć do strony https:\\host\Reports zamiast do https:\\host.fqdn.com\Reports i dlatego instalacja nie działa. Szybka generacja poprawnego certyfikatu i po problemie. W końcu to takie oczywiste, że nikomu nie powinno zabrać więcej niż 15 min... Nie mówiąc już o moich 8 godzinach.