Co tam Pani w Windowsach?

[MSSQL] SQL 2008 R2 w klastrze: problem z Maintenace Planem: The LoadFromSQLServer method has encountered OLE DB error code 0x80004005

2012-02-28T17:46:00.000+01:00

Co zrobić, kiedy uruchamiamy maintenance plan na SQL 2008 R2 pracującym w clustrze i zamiast prawidłowego wykonania otrzymujemy błąd:

"Executed as user: xxxx. Microsoft (R) SQL Server Execute Package Utility Version 10.50.1600.1 for 64-bit Copyright (C) Microsoft Corporation 2010. All rights reserved. Started: 14:42:28 Could not load package "Maintenance Plans\test" because of error 0xC0014062. Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80004005 (Login timeout expired). The SQL statement that was issued has failed. Source: Started: 14:42:28 Finished: 14:42:43 Elapsed: 15.023 seconds. The package could not be loaded. The step failed."

W Management Studio wchodzimy w SQL Server Agent -> Jobs -> Nazwa zadania i otwieramy właściwości. Przechodzimy do zakładki Steps i klikamy na krok z listy. Edytujemy go. Na samym dole w pozycji Package, przed ścieżką dodajemy znak \ (lub klikamy na [...] i wchodząc w nazwę pakietu w ten sposób backslash sam się pojawi).

Wypada również zajrzeć w konfigurację samego clustra i zależności zasobów dyskowych (Disk Drives -> prawy przycisk na dysku i zakładka Dependencies). Gdyby przypadkiem pojawiła się zależność, na której widnieje nazwa clustrowa, należy ją usunąć.
Po korekcie zależności nie będzie potrzebny już backslash w ścieżce do paczki.

Blog nie umarł...

2012-02-10T17:08:00.000+01:00

... to ja jestem trochę leniwa. No może nie leniwa, ale nie mam jakoś natchnienia na pisanie około-windowsowych rzeczy. Wiem jednak, że blog ma sporo odwiedzających, których serdecznie zapraszam do komentowania i zadawania pytań - nie gryzę, a jakikolwiek odzew od strony czytelników jest przeze mnie mile widziany!

Dziś postanowiłam wrzucić tu kilka linków do artykułów napisanych przeze mnie do nieżyjącego już portalu windowshosting (aktualnie połknięty przez webhosting.pl):

Nie jestem pewna, czy to wszystkie artykuły. Jeśli ktoś znajdzie jakiś brakujący, to proszę o informacje.

Wyprowadzka na Bloggera

2012-01-09T18:16:00.000+01:00

No i stało się. Wyprowadziłam się z własnego hostingu i własnej domeny na Bloggera. Eksport i import wpisów odbył się bezboleśnie.
Wordpress: Narzędzia -> Eksport
Potem przepuszczenie pliku xml przez wordpress2blogger.appspot.com i import w samym Bloggerze.

(prawie)automatyczny failover aplikacji Manage Engine ServiceDesk Plus

2011-10-27T12:30:00.000+02:00

Manage Engine ServiceDesk Plus (niektórzy może jeszcze pamiętają AdventNet ServiceDesk) jak informuje producent jest: "to internetowa aplikacja pomocy technicznej, która pomaga zarządzać komunikacją z jednego punktu. Oferuje zintegrowane zarządzanie zgłoszeniami (zgłaszanie problemów), zarządzanie zasobami, zarządzanie zleceniami zakupu, zarządzanie kontraktem, portal samoobsługowy, oraz bazę wiedzy.". Od strony administracyjnej jest to aplikacja napisana w Javie i przechowująca dane w bazie danych. Do wyboru mamy MySQL oraz MSSQ Server.
Czy aplikacja ta może działać w trybie HA z automatycznym przywracaniem po awarii jednego z serwerów bazy danych? Tak i nie... Ale wszystko da się przecież jakoś obejść :) Opiszę taki przypadek na przykładzie aplikacji działającej wraz a bazą MSSQL Server.

Wyobraźmy sobie taką sytuację. Mamy dwa serwery SRV1 i SRV2. Na SRV1 instalujemy bazę MSSQL, natomiast na SRV2 instalujemy aplikację SD+ i tworzymy tam lustrzany serwer bazy danych. O ile zapewnienie wysokiej dostępności dla bazy danych jest proste (post o konfiguracji mirroringu tutaj), to z samą aplikacją SD+ działająca w takim środowisku pojawiają się problemy. Connection string do bazy znajduje się w pliku mssql-ds.xml (w ścieżce ManageEngine\ServiceDesk\server\default\deploy). W przypadku przepięcia się bazy, zmienia się także connection string i aplikacja tak czy siak nie będzie działać. Co zrobić w takim wypadku? Potrzebujemy podmienić dane w pliku konfiguracyjnym i zrestartować usługę SD+. Ale po co robić, to ręcznie jak z pomocą przychodzi skrypt PowerShella. Aby wszystko działało jak należy musimy przygotować dwie wersje pliku mssql-ds.xml z odpowiednimi wartościami.

Teraz czas na skrypt:

$wybor = read-host "Który serwer SQL jest aktywny: 1 -- serwer2 2 -- serwer1"
if($wybor -eq '1')

{
Copy-Item E:\ManageEngine\ServiceDesk\server\default\deploy\srv2\mssql-ds.xml
E:\ManageEngine\ServiceDesk\server\default\deploy
}

elseif($wybor -eq '2')

{
Copy-Item E:\ManageEngine\ServiceDesk\server\default\deploy\srv1\mssql-ds.xml
E:\ManageEngine\ServiceDesk\server\default\deploy
}
Restart-Service -displayname "ManageEngine ServiceDesk Plus"

Po uruchomieniu otrzymujemy takie oto okno z wyborem:

Po dokonaniu odpowiedniego wyboru skrypt kopiuje plik konfiguracyjny z prawidłowym connection stringiem i restartuję usługę.

Wiem wiem taki failover to wersja dla ubogich, dlatego aktualnie pracuję nad czymś całkowicie automatycznym. Oczywiście podzielę się gotowym rozwiązaniem na tym blogu!

[MSSQL] SQL 2008 R2 wysoka dostępność - mirroring

2011-10-07T13:34:00.000+02:00

Podobnie jak w przypadku log shipping, transakcje w lustrzanych kopiach baz danych są przenoszone z serwera głównego (Principial Server) na serwer pomocniczy, nazywany tutaj serwerem lustrzanym (Mirror Server) – z tą różnicą, że transakcje są zatwierdzanie w momencie, kiedy następują.
Na serwerze głównym znajduje się główna baza danych, gdzie przeprowadzane są transakcje. Serwer główny zapisuje zmiany w głównym dzienniku transakcji i automatycznie przenosi informacje na temat przeprowadzonych transakcji na serwer lustrzany, który dokonuje wpisu w swoim dzienniku transakcji. Następnie serwer lustrzany wysyła potwierdzenie do serwera głównego.
W ten sposób serwer lustrzany zawiera pełną kopię bazy danych ze wszystkimi wykonanymi transakcjami. Należy jednak pamiętać, że nie można tworzyć lustrzanych baz danych z baz systemowych.

W celu zapewnienia wysokiej dostępności możemy skonfigurować dodatkowy serwer zwany serwerem pomocniczym (Witness Server), który monitoruje serwery z główną i lustrzaną bazą danych. W momencie, gdy następuje awaria i przestanie działać serwer główny, serwer nadzorujący wykonuje automatyczne przekierowanie i serwer lustrzany pełni funkcję serwera głównego.

Tryby mirroringu:

Synchroniczny z automatycznym przywracaniem po awarii (Synchronous with automatic failover (high availability)), który gwarantuje wysoką dostępność. Do działania w tym trybie niezbędny jest uprzednio skonfigurowany serwer nadzorujący. Transakcja zostaje uważana za zakończoną na serwerze główny, gdy serwer lustrzany zapisze transakcję w swoim dzienniku i wyśle potwierdzenie do serwera głównego. Serwer nadzorujący kontroluje automatyczne przywrócenie po awarii na serwerze lustrzanym, gdy serwer główny jest niedostępny.

Asynchroniczny (Asynchronous (high performance)) – Zmiany zostają zatwierdzone na serwerze głównym, a następnie transferowane są na serwer lustrzany. W tym trybie, serwer główny zatwierdza transakcje bez oczekiwania na potwierdzenie od serwera lustrzanego. Nie działa tu automatyczne przywracanie po awarii. Jeśli główny serwer przestaje działać, należy ręcznie przekazać jego działania serwerowi lustrzanemu. Tryb ten jest szybszy w działaniu niż tryb synchroniczny, niestety istnieje możliwość, że część transakcji nie zostanie zapisanych na serwerze lustrzanym.

Synchroniczny (Synchronous (high protection)) zapewniający wysoką ochronę – Zatwierdzanie zmian odbywa się na obydwu serwerach. Nie zawiera serwera nadzorującego. Jeśli główny serwer przestaje działać, pełna kopia danych znajdująca się na serwerze lustrzanym zostaje ręcznie wypromowana do działania jako serwer główny. Jeśli natomiast serwer lustrzany przestaje działać, serwer główny przechodzi w tryb offline, a dane nie zostają utracone.

1. Przygotowanie do rozpoczęcia mirroringu.

Przed włączeniem mechanizmu należy wykonać pełną kopię zapasową głównej bazy danych i odtworzyć ją na serwerze lustrzanym z opcją RESTORE WITH NORECOVERY. Lustrzana baza danych będzie znajdowała się teraz w stanie In Recovery.

2. Konfiguracja za pomocą Management Studio.

W SQL Management Studio klikamy prawym przyciskiem myszy bazę danych i w jej właściwościach przechodzimy do strony Mirroring.

Najpierw musimy skonfigurować zabezpieczenia serwera głównego i lustrzanego, a przy wyborze opcji z serwerem nadzorującym – także i jego. W tym celu przyciskami Configure Security.

Na pierwszej stronie kreatora określamy, czy chcemy używać serwera nadzorującego (Witness Server instance), który służy do automatycznego przywracania po awarii w trybie synchronicznym.

Na stronie Principal Server Instance określamy węzeł końcowy (Endpoint), poprzez który główny serwer będzie akceptował połączenia z serwera lustrzanego (i serwera nadzorującego). W pozycji Listener port wpisujemy numer portu, którego chcemy używać.
Należy pamiętać, że jeśli którykolwiek z instancji serwera: główny, lustrzany czy nadzorujący znajduje się na tym samym serwerze, numer portu musi się różnić. Wpisujemy port i nadajemy węzłowi końcowemu nazwę oraz zaznaczamy, czy chcemy szyfrować dane wysyłane przez ten endpoint (Enrypt data sent through this endpoint).

Na kolejnej stronie konfigurujemy instancję serwera lustrzanego. Z rozwijalnej listy Mirror server instance wybieramy żądaną instancję i serwer oraz wciskamy przycisk Connect. Poniżej, podobnie jak na ekranie powyżej konfigurujemy port oraz nazwę węzła końcowego.

Jeśli wybraliśmy opcję z serwerem nadzorującym, wybieramy nazwę jego instancji w pozycji Witness server instance, wciskamy Connect i ponownie konfigurujemy numer portu i nazwę węzła.

Jeśli instancje używają różnych kont w zaufanej domenie jako kont usług SQL, należy je wpisać w pozycje Principal, Witness i Mirror. Jeśli wszystkie instancje używają tego samego konta, klikamy przycisk Next bez wpisywania czegokolwiek.

Na ostatniej stronie czytamy podsumowanie i wciskamy przycisk Finish.
Po zakończeniu zostanie stworzony mechanizm tworzenia lustrzanych baz danych

Jak widać na poniższym screenie baza na serwerze głównym ma status Synchronized, a baza na serwerze lustrzanym Synchronized / Restoring.

UWAGA!

Jeśli wybraliśmy opcję mirroringu bez serwera nadzorującego (tryb asynchroniczny), w przypadku awarii serwera głównego nie jest dostępne automatyczne przywracanie. Jeśli główny serwer przestaje działać, należy ręcznie przekazać jego działania serwerowi lustrzanemu poprzez zapytanie:

USE master GO
ALTER DATABASE [nazwaBazy] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
GO

[MSSQL] Robimy upgrade z SQL 2008 R2 Express to SQL 2008 R2 Standard

2011-08-04T12:28:00.000+02:00

Dziś wpis krótki i przyjemny, dla tych, co zapominają, gdzie kliknąć. Jak wykonać upgrade zainstalowanej instancji SQL 2008 R2 Express do pełnej wersji SQL?
Uruchamiamy instalację pełnej wersji SQL i klikamy na Maintenance, a następnie na Edition Upgrade.

Kilka stron dalej wybieramy instancję, na której chcemy wykonać upgrade z Express na Standard/Enterprise i klikamy dalej.

Po kolejnych dwóch stronach mamy rozpiskę, co zostanie zmienione.

Chwilę potem nasz SQL Express został zastąpiony pełną wersją.

AWStats, Perl i problemy na IIS 7.5

2011-07-22T09:19:00.000+02:00

W czasie instalacji modułu statystyk AWStats na serwerze IIS działającym pod Windows Server 2008 R2 można napotkać kilka problemów. Oczywiście zanim pojawią się problemy należy mieć zainstalowanego na serwerze IIS oraz Perla (ja instalowałam w wersji 5.10.1.1006 w wersji 64 bit). Bibliotekę perl510.dll dodajemy do "Handler Mappings" w IIS. Niestety po zainstalowaniu AWStats na stronie WWW pojawia się błąd:

"HTTP Error 500.0 - Internal Server Error
Calling GetProcAddress on ISAPI filter "C:\Perl64\bin\perl510.dll" failed"

Po kilku chwilach poszukiwania okazało się, że pula aplikacji ma pracować w opcji 32 bitowej. Zatem prawy przycisk myszy na nazwie puli aplikacji | Advanced Settings... | Enable 32-Bit Applications - True | Managed Pipeline Mode - Classic :

Po odświeżeniu strony pojawił się zatem inny błąd:

"HTTP Error 404.17 - Not Found
The requested content appears to be script and will not be served by the static file handler."

Po kolejnych poszukiwaniach okazało się, że zamiast perl510.dll, powinnam użyć jako ISAPI PerlEx30.dll (dostępna w 32 bitowej instalce Perla). Zatem dodałam na nowo moduł ISAPI:

Trzeba pamiętać o jeszcze jednej rzeczy, a mianowicie w "ISAPI and CGI Restrictions" musimy nadać prawo "Allow" dla dodanego poprzednio modułu ISAPI. W przeciwnym wypadku zostaniemy uraczeni błędem:

"HTTP Error 404.2 - Not Found
The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server."

[MS SQL 2005] Jak skonfigurować przesyłanie dziennika transakcji (Logshipping) w SQL Management Studio.

2011-07-21T11:59:00.000+02:00

Przed konfiguracją Log shipping należy stworzyć udział plików na backup logów transakcyjnych, aby nie obciążać serwera głównego i aby zapewnić wysoką dostępność najlepiej jest to zrobić na innym serwerze. Następnie dla każdego serwera pomocniczego należy stworzyć folder, do którego będą kopiowane backupy logów transakcyjnych.

W SQL Management Studio klikamy prawym przyciskiem na nazwę bazy danych, dla której chcemy skonfigurować przesyłanie dziennika i przechodzimy do jej właściwości. Klikamy na stronę Transaction Log Shipping i zaznaczamy Enable this as a primary database In a log shopping configuration.
Poniżej w sekcji Trasaction log backups wciskamy przycisk Backup Settings, aby skonfigurować opcję wykonywania kopi zapasowej logu transakcyjnego

Dalsza część artykułu znajduję się na portalu windowshosting.pl.

Konfiguracja NLB (Network Load Balancing) w Windows 2008 R2

2011-06-02T13:04:00.000+02:00

Po zainstalowaniu funkcji Network Load Balancing otwieramy managera i klikamy prawym przyciskiem wybierając opcję New Cluster.

Dodajemy pierwszy host do naszego klastra. W pozycji host wpisujemy adres IP pierwszego serwera, który chcemy dołączyć do usługi NLB i wciskamy przycisk Connect. Poniżej pojawią się karty sieciowe na danym serwerze. Wybieramy tą, której chcemy użyć dla naszego klastra.

Na kolejnej stronie Host Parameters z rozwijanej listy Priority wybieramy ID. Host z niższym priorytetem obsługiwać będzie cały ruch sieciowy, który nie jest objęty regułą portu.

Na kolejnej stronie wciskamy Add i dodajemy adres IP klastra. Ten adres będzie współdzielony przez wszystkich członków klastra.

Na kolejnej stronie podajemy parametry klastra. Adres IP już podaliśmy wcześniej, więc teraz wpisujemy nazwę FQDN dla klastra. Nazwa musi być oczywiście dodana również do naszego serwera DNS.
Poniżej wybieramy tryb działania klastra: tryb emisji pojedynczej i multicasta lub tryb IGMP.

Teraz czas na konfigurowanie reguł portów. Domyślnie wybrane są wszystkie porty od 0 do 65535. Wciskamy przycisk Edit i konfigurujemy usługę NLB dla IIS czyli portu 80.

W przedziale portów wpisujemy od portu 80 do 80.
Poniżej widzimy dostępne trzy tryby filtrowania: Multipne Host Filtering (wiele hostów), Single host (pojedynczy host) oraz Disable this port range (zablokuj przedział hostów).
W przypadku wybrania Multiple host (wartość domyślna) możemy wybrać jedną z pośród trzech kolejnych opcji: None (wszystkie żądania są rozprowadzane równomiernie po całym klastrze), Single (gdy klient wykona pierwsze żądanie, to wszystkie kolejne sesje są kierowane do tego samego węzła klastra), Network (klienci są skierowani do najbliższego węzła dla swojej podsieci).

Zauważmy, że jest jeszcze jeden parametr - Load. Domyślnie znajduje się on w pozycji Equal. Cóż to takiego? Oznacza to, że cały ruch sieciowy jest dystrybuowany jest równomiernie po hostach. Wartość tą można zmienić na opcję Load weight, ale tylko poprzez wejście do właściwości hosta. O tym poniżej.

Aby zmienić opcję Equal na Load weight klikamy prawym przyciskiem na hoście i wybieramy Host Properties zakładka Port Rules i edytujemy reguły.
Gdy nie chcemy, aby host przyjmował jakikolwiek ruch sieciowy, ustawiamy wartość zero. Jeśli natomiast chcemy aby jakiś host klastra przyjmował więcej ruchu sieciowego niż pozostały, nadajemy mu odpowiednią wartość od 1 do 100.

Teraz czas na dodanie drugiego hosta do klastra NLB. Przechodzimy do managera i klikamy prawym przyciskiem na nazwie klastra wybierając Add Host to Cluster.

Po wykonaniu kroków jak w przypadku dodawania pierwszego hosta, widzimy działającą już usługę NLB:

[TS] Słów kilka o konfigurowaniu RemoteApp

2011-05-30T12:00:00.000+02:00

RemoteApp to przydatna funkcja, jeśli nie chcemy łączyć się z aplikacją udostępnioną na serwerze terminali bez używania zdalnego pulpitu - aplikacje "działają" na komputerze lokalnym (tak naprawdę wykonywane są na serwerze terminali, ale nie trzeba się przebijać przez niepotrzebne okienka) nie obciążając go.

Utwórzmy teraz zdalną aplikację poprzez managera RemoteApp. W panelu Actions klikamy Add RemoteApp Programs.

Na pierwszej stronie wizarda wybieramy z listy aplikację, którą chcemy dodać do listy RemoteApp Programs. W tym przypadku dodajemy kalkulator.

Po udanej instalacji na liście programów widzimy kalkulator.

Klikając prawym przyciskiem na naszej aplikacji możemy zobaczyć kilka dostępnych opcji: m.in. Hide in RD Web Access (ukryj na stronie Remote Desktop Web Access), Create .rdp file (utwórz plik .rdp - o tym poniżej) lub też Create Windows Installer Package.

Uwaga! Opcje wyświetlania aplikacji w RD Webb Access dostępne będą w przypadku zainstalowania takiej roli (o instalacji tutaj).

Po wybraniu opcji utworzenia pliku .rdp przechodzimy do kreatora. Określamy ścieżkę folderu tworzonych w ten sposób pakietów. Możemy również zmienić serwer i port serwera RD Session Host, zmienić opcje bramy RD Gateway oraz przejść do ustawień certyfikatu SSL.

Po przejściu na komputerze lokalnym do wybranej wyżej lokalizacji (domyślnie C:\Program Files\Packaged Programs) widzimy zdalnie udostępnioną aplikację kalkulatora.

Z w ten sposób skonfigurowanego kalkulatora możemy korzystać również poprzez witrynę znajdującą się pod adresem http://nazwaserwera/ts

Obejrzyjmy teraz zakładki z ustawieniami RemoteApp.

Digital Signature - po wybraniu odpowiedniego certyfikatu SSL, możemy nim podpisywać pliki .rdp.

Common RDP Settings -na tej zakładce możemy określić jakie zasoby i programy mają być przenoszone z komputera klienckiego na sesję terminalową.

RD Gateway -na tej zakładce możemy skonfigurować opcje bramy RD Gateway. Domyślnie zaznaczona jest opcja automatycznego wykrywania, ale możemy również określić serwer RD Gateway ręcznie.

RD Sesssion Host Server -zakładka ta służy do konfiguracji serwera RD Session Host.

myLittleAdmin for SQL Azure - pierwszy kontakt

2011-05-16T16:17:00.000+02:00

Jakiś czas temu na łamach portalu WindowsHosting pisałam o aplikacji myLittleAdmin, która pozwala na zarządzanie bazami danych MS SQL poprzez przeglądarkę - takie webowe Management Studio. Teraz czas na test nowego produktu - myLittleAdmin dla SQL Azure. A raczej test instalacji dla Azure, ponieważ cała funkcjonalność MLA pozostaje taka sama.

Instalacja myLittleAdmin dla SQL Azure jest bajecznie prosta. W tym celu rozpakowałam pliki konfiguracyjne na serwerze lokalnym, który ma dostęp do internetu i wyedytowałam plik config.xml. Wpisałam adres serwera SQL w postaci nazwa.database.windows.net i to wszystko. No prawie.
Próbując zalogować się do mojej bazy SQL Azure otrzymałam następujący komunikat:

Ach firewall. Kto o nim nie zapomina? Przechodzimy do naszego serwera SQL Azure i dodajemy regułę do firewalla wciskając przycisk Add.

Teraz nasz serwer www ma dostęp do bazy SQL Azure i możemy cieszyć się zarządzaniem bazami poprzez myLittleAdmin.

Więcej o myLittleAdmin for SQL Azure przeczytacie tutaj:http://azure.mylittleadmin.com/azure/en/. Instalacja i krótki test myLittleAdmin 3.5 znajduje się tutaj.

[RDS] Przegląd zakładek w Remote Desktop Session Host Configuration (exTerminal Services Configuration)

2011-05-12T12:31:00.000+02:00

Oto pierwszy post w nowej kategorii "Kto ogląda zakładki jest piękny i gładki". W dzisiejszym odcinku przedstawiam następcę konsoli Terminal Services, czyli Remote Desktop Session Host dostępną w Windows Server 2008 R2.

Okno konsoli jest podzielone na dwie części: Connections oraz Edit Settings.
W Connections widzimy gotowe połączenie RDP-Tcp. Ustawienia w tym miejscu są stosowane tylko dla jednego protokołu albo dla konkretnej karty sieciowej.
Natomiast ustawienia w Edit Settings to zestaw opcji dla całego serwera terminali.

Connections

Zakładka General

Opcja security layer pozwala na określenie typu szyfrowania dla połączeń terminalowych: RDP Security Layer (standardowe szyfrowanie protokołu RD), SSL (dobre rozwiązanie dla klientów posiadających RDP w wersji niższej niż 6.0 np. Windows XP), Negotiate.

Opcja encryption level pozwala na określenie jak silny ma być algorytm szyfrujący połączeń RDP. Domyślnie jest to wartość Client Compatible.

Ostatnia opcja zakładki - General to Allow connections only from computers running Remote Desktop with Network Level Authentication, pozwala na połączenia tylko dla klientów, których RDP wspiera Network Level Authentication (Windows Vista i wyższe).

Jak widać również na samym dole, mamy możliwość wyboru certyfikatu SSL.

Zakładka Log on Settings

W tym miejscu możemy skonfigurować klientów, aby używali zdefiniowanego używkownika i hasło - Always use the following log on information. W ten sposób użytkownicy mogą się łączyć zdalnie bez podawania loginu/hasła. Możemy również zaznaczyć Always prompt for password, aby używkownik zawsze musiał podać hasło.

Zakładka Sessions

W tej zakładce mamy możliwość określania timeoutów jak i opcji ponownego podłączania się do sesji.
Zaznaczając Override user settings mamy możliwość określania czasu po jakim nastąpi odłączenie zamkniętej sesji użytkownika (End a disconnected session), czas trwania aktywnej sesji (Active session limit) oraz czas nieaktywności użytkownika (Idle session limit).
Zaznaczając Override user settings mamy możliwość wyboru, co stanie się, gdy nastąpił limit sesji lub przerwanie połączenia: odłączenie z sesji (disconnect from session) czy zakończenie sesji (end session).

Zakładka Environment

W tym oknie mamy możliwość określenia jaki program/aplikacja zostanie włączona po zalogowaniu się zdalnie na serwer.

Zakładka Remote Control

Mamy tu możliwość zmian ustawień dotyczących zdalnej kontroli nad sesją (domyślnie zezwalamy na zdalną kontrolę). Do dyspozycji mamy opcje: do not allow remote control (nie zezwalaj na zdalną kontrolę) i use remote control with the following settings (zdalna kontrola z następujacymi ustawieniami): view the session (podglądanie sesji), interact with the session (interakcja z sesją).

Zakładka Client Settings

Tu możemy określić takie opcje jak maksymalna głębia kolorów, czy wybrać jakie funkcje możemy zablokować (lokalne dyski, schowek, dźwięk itp.).

Uwaga, jeśli chodzi o opcje drukarek, to ustawienia znajdują się w:
Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Printer Redirection

Do not set default client printer to be default printer in a session - możemy określić, czy domyślna drukarka klienta jest jednocześnie domyślną drukarką w czasie sesji zdalnej czy też użytkownik ma kożystać z drukarki przydzielonej dla komputera zdalnego.

Do not allow client printer redirection - określamy, czy użytkownicy mogą drukować na swojej lokalnej drukarce będąc na serwerze zdalnym.

Use Remote Desktop Easy Printer driver first - w przypadku włączenia tej polisy RD Session Host próbuje znaleźć sterowniki drukarki klienta przez RD Easy Print. Gdy sterowniki nie zostaną znalezione, użytkownik nie może drukować.

Redirect only the default client printer - polisę włączamy, gdy nie chcemy przekierowywać wszystkich drukarek klienta.

Zakładka Network Adapter

W tej zakładce możemy określić, która dostępna karta sieciowa będzie służyła do zdalnych połączeń oraz czy chcemy określić limit połączeń do serwera terminali.

Zakładka Security

Standardowa zakładka z uprawnieniami do serwera terminali.

Edit settings

Zakładka General

Domyślnie wszystkie trzy opcje są zaznaczone: delete temporary folders on exit (kasuje pliki tymczasowe po wylogowaniu się użytkownika z sesji), use temporary folders per session (w czasie każdej sesji użytkownika jest tworzony nowy katalog tymczasowy), restrict each user to a single session (każdy użytkownik może zostać zalogowany zdalnie tylko na jedną sesję do komputera).

W sekcji User logon mode mamy możliwość określenia, czy zezwalamy na wszystkie połączenia zdalne (ustawienie domyślne - allow all connections), czy też pozwalamy na ponowne połączenie się do wiszącej sesji, ale nie pozwalamy na nowe sesje (allow reconnections but prevent new logons) czy też pozwalamy na połączenie się ponowne do sesji, ale nie zezwalamy na nowe połączenia aż do restartu serwera (allow reconnections but prevent new logons untill the server is restarted). Dwie ostatnie opcje są bardzo przydatne, gdy planujemy prace na serwerze zakończone późniejszym restartem maszyny bez gwałtownego wyrzucenia sesji użytkownika.

Zakładka Licensing

W tej zakładce możemy określić rodzaj licencji: nie sprecyzowana, per urządzenie oraz per user, a następnie podać serwery z licencjami.

Zakładka RD Connection Broker

Jeśli mamy kilka serwerów terminalowych i używamy Connection Brokera, który pozwala na ponowne połączenie się do wiszących sesji na serwerze. Dodatkowo po zaznaczeniu opcji Participate in Connection Broker Load-Balancing mamy możliwość kierowania nowych sesji na serwery mniej obciążone.

RD IP Virtualization

Pozwala na przydzielanie adresów IP dla połączeń zdalnych dla sesji lub dla programu (w Windows 2008 każda sesja otrzymywała ten sam adres IP).

[RDS] Instalacja Remote Desktop Services (zwane kiedyś TerminalServices)

2011-05-11T12:00:00.000+02:00

Naszą przygodę z usługami terminalowymi nazwanymi w Windows 2008 R2 Remote Desktop Services rozpoczynamy od instalacji roli serwera:

Jako iż w tym środowisku testowym nie mam wirtualizacji, instaluję poniższe role:

Remote Desktop Session Host (do tej pory znaną jako Terminal Server);
Remote Desktop Licensing - przez pierwsze 120 dni możemy korzystać z serwera terminali bez licencji.
Remote Desktop Connection Broker - w przypadku instalacji usług terminalowych na kilku serwerach Connection Broker pozwala na połączenie się użytkownika do swojej poprzedniej sesji na danym serwerze.
Remote Desktop Gateway - pozwala na łączenie się użytkowników zewnętrznych będących za firewallem czy NAPem.
Remote Desktop Web Access - pozwala na korzystanie z aplikacji udostepnionych terminalowo przez stronę WWW.

Na kolejnej stronie określamy, czy chcemy pozwolić na połączenia zdalne wszystkim użytkownikom, czy tylko tym posiadającym Windows Vista i nowsze systemy.

Następnie określamy rodzaj licencji. W przypadku wyboru opcji Configure Later mamy możliwość używania dostępów terminalowych przez 120 dni. Oprócz tego dostępne mamy licencje na urządzenie (Per Device) oraz użytkownika (Per User).
W przypadku wybrania licencji Per Device, gdy urządzenie łączy się pierwszy raz do serwera, otrzymuje tymczasową licencję. Przy połączeniu po raz kolejny urządzenie otrzymuje licencję na stałe (o ile oczywiście dysponujemy wolnymi licencjami). Licencja Per User nie jest przypisana do konkretnego użytkownika, a przy tym użytkownik może zalogować się z dowolnego komputera.

Dalej określamy użytkowników i grupy, którym pozwalamy na połączenia zdalne. Domyślnie znajdują się tu administratorzy.

Jeśli w czasie połączenia terminalowego chcemy zezwolić użytkownikom na odtwarzanie muzyki i wideo oraz korzystanie z kompozycji pulpitu w tym Windows Aero i mamy za dużo zasobów na naszym serwerze, nic nie stoi na przeszkodzie, aby skorzystać z tej funkcjonalności:

Na kolejnej stronie używamy zaleceń Microsoft i przechodzimy dalej.

Jeśli zamierzamy korzystać z SSL w czasie sesji terminalowych możemy wybrać gotowy certyfikat SSL, utworzyć nowy lub skonfigurować to potem.

Możemy również od razu utworzyć polityki uwierzytelnienia dla tego serwera RD Gateway. Jeśli nie zrobimy tego teraz, można to wykonać po wejściu do RD Gateway Managera.

RD CAP - określamy użytkowników, którzy mogą łączyć się do tego serwera terminali
RD RAP - określamy którzy użytkownicy mogą łączyć się do danych zasobów.

Zaczynamy od dodania grup:

Tworzymy RD CAP nadając nazwę i określając metodę uwierzytelnienia. Domyślnie jest to hasło (Password), ale możemy również używać kart inteligentnych.

Przechodzimy do RD RAP, nadajemy nazwę i określamy które komputery są dostępne do połączeń zdalnych (na podstawie grupy) lub zezwalamy użytkownikom na połączenia ze wszystkimi komputerami w sieci.

Doinstalowujemy jeszcze NAP i wszystko gotowe do działania.

[IIS/FTP] Tworzenie nowej strony FTP pod Windows 2008 R2 + przeglądopcji.

2011-05-11T08:55:00.000+02:00

Po zainstalowaniu roli IIS wraz z usługą FTP na naszym serwerze, czas dodać pierwszą stronę. Otwieramy managera IIS i klikamy prawym przyciskiem myszy węzeł Sites, wybierając opcję Add FTP Site

Pojawi się okno kreatora – w pierwszej kolejności wpisujemy nazwę nowej strony FTP oraz ścieżkę do folderu, gdzie mają być przechowywane pliki.

Na kolejnej stronie wpisujemy adres IP oraz port, przez który ma działać nasza strona FTP (domyślnie 21). Jeśli chcemy na jednym adresie IP i jednym numerze portu utworzyć kilka stron FTP, należy włączyć opcję Enable Virtual Host Names i wpisać tam nagłówek hosta.
Poniżej można określić,czy zezwalamy na używanie SSL w czasie łączenia się z naszym FTP (Allow SSL), czy nie zezwalamy na jego używanie (No SSL), czy też wymagamy użycia SSL (Require SSL). Przy wybraniu ostatniej opcji w pozycji SSL Certificate wybieramy zainstalowany uprzednio certyfikat.

Na stronie Authentication and Authorization Infromation wybieramy opcje uwierzytelniania użytkownika (Authentication): anonimowe (Anonymous) lub podstawowe (Basic). Poniżej w sekcji Authorization wybieramy, jacy użytkownicy mają mieć dostęp do strony FTP – wszyscy użytkownicy, określone role lub grupy użytkowników czy też określeni użytkownicy.
Ponadto określamy, co tak naprawdę ci użytkownicy mogą robić. Do wyboru mamy opcje odczytu (Read) i zapisu (Write). Następnie klikamy przycisk Finish i strona FTP zostaje utworzona.

Po utworzeniu nowej strony FTP pojawiają się nam w konsoli inne opcje:

Uwierzytelnianie FTP (FTP Authentication)
Zasady autoryzacji FTP (FTP Authorization Rules)
Aktualne sesje FTP (FTP Current Sessions)
Przeglądanie katalogu FTP (FTP Directory Browsing)
Wsparcie zapory ogniowej FTP (FTP Firewall Support)
Ograniczenia adresów i domen IPv4 (FTP IPv4 Address and Domain Restrictions)
Logowanie FTP (FTP Logging)
Powiadomienia FTP (FTP Massages)
Zasady filtrujące (FTP Request Filtering)
Ustawienia SSL (FTP SSL Settings)
Izolacja użytkownika FTP (FTP User Isolation)

Szczegółowe omówienie tych komponentów można przeczytać w moim artykule na łamach portalu WindowsHosting.pl.

[MS SQL] Klastrowanie SQL Server 2008 R2 wraz z Reporting Services(SSRS)

2011-05-10T12:33:00.000+02:00

O ile stworzenie klastra MSSQL 2008 R2 nie jest problemem, to przy sklastrowaniu Reporting Services napotkamy kilka trudności - powszechnie bowiem wiadomo (lub nie), że usługa Reporting Services jest nie klastrowalna. Zaraz, zaraz jak to nie - da się :)

1. Instalacja MSDTC

Przed przystąpieniem do tworzenia klastra MS SQL 2008 R2 musimy zainstalować na gotowym klastrze usługę MSDTC (opis samej usługi tu). W tym celu na Services and applications w Failover Cluster Manager klikamy prawym przyciskiem i wybieramy Configure a Service or Application.

Z gotowej listy usług i aplikacji wybieramy DTC:

2. Instalacja MS SQL 2008 R2 na nodzie 1.

Po włączeniu instalatora wybieramy opcję New SQL Server failover cluster installation.

Postępujemy dalej jak w standardowej instalacji MSSQL wybierając składniki (w tym Reporting Services) i nadając instancji nazwę oraz nadajemy nazwę SQL Server Network Name dla klastra SQL. Ta nazwa posłuży do identyfikacji klastra w sieci (w tym przypadku nazwa to SQL01, natomiast nazwa instancji to standardowo MSSQLSERVER).

Na stronie Cluster Resource Group klikamy Next.

W kolejnym oknie wybieramy dysk clustra, który będzie domyślą lokalizacją instalacji naszej bazy i komponentów.

W kolejnym oknie określamy adres IP dla clustra SQL. Odznaczając DHCP mamy możliwość wpisania adresu IP "na sztywno".

Przechodzimy dalej:

Aż do zakładki, na której określamy konta usług dla SQL Server Agent, SQL Database Engine i SQL Server Reporting Service.

Następnie znów postępujemy jak w przypadku standardowej instalacji SQL.

Jak widać w konsoli Failover Cluster | Services and applications widnieje już SQL Server.

2. Instalacja MS SQL 2008 R2 na nodzie 2.

Po rozpoczęciu instalacji tym razem wybieramy opcję Add node to a SQL failover cluster.

Po zaakceptowaniu postanowień licencyjnych przechodzimy do konfiguracji noda 2. Wybieramy nazwę instancji, którą utworzyliśmy na nodzie pierwszym i przechodzimy dalej.

Na następnej stronie wprowadzamy hasło dla konta na którym działają usługi SQL Server Database Engine oraz SQL Server Agent. Oczywiście nie może to być (jak w tym testowym przypadku) nazwa konta użytkownika, ale konto specjalnie dla SQL. Ale zaraz zaraz, gdzie jest Reporting Services? O tym później...

3. Konfiguracja Reporing Services na nodzie 1.

Włączamy Reporting Services Configuration Manager i wpisujemy nazwę serwera. Po przyciśnięciu Find pojawi się lista instancji Reporting Services. W tym przypadku jest to MSSQLSERVER.

Tworzymy nową bazę danych (Create a new report server database).

Na kolejnej stronie określamy nazwę serwera SQL oraz autoryzację, a potem standardowo URL web service, URL report managera itp.

4. Instalacja i konfiguracja Reporing Services na nodzie 2.

Jak już pisałam wcześniej, Reporting Services jako usługa nie clustrowana nie zainstalowała się na nodzie drugim. No dobrze, ale co się stanie, gdy spróbujemy doinstalować tą usługę na nodzie 2. W tym celu wybieramy New installation or add features to an existing installation.

Wybieramy instancję, do której chcemy doinstalować Reporting Services:

I... Jednak się nie da: The instance selected for installation is already installed and clustered...

Nie pozostaje nic innego jak zainstalowanie Reporting Services jako nowej usługi nowej instancji.

Na karcie Setup Role wybieramy SQL Server Feature Instalation.

Po wybraniu instalacji TYLKO Reporting Services, nadajemy instancji nową nazwę:

Po zakończonej instalacji SSRD włączamy Reporting Services Configuration Manager i wpisujemy nazwę serwera. Po przyciśnięciu Find pojawi się lista instancji Reporting Services. W tym przypadku jest to nowo zainstalowana instancja SSRS.

Przechodzimy do zakładki Web Service URL i zmieniamy Virtual Directory na ReportServer jak na pierwszym nodzie (ponieważ po instalacji będzie tu nazwa ReportServer_NazwaInstancji):

To samo robimy dla Report Manager URL. W pozycję Virtual Directory wpisujemy tylko Reports jak na nodzie pierwszy.

W zakładce Report Server Database wciskamy przycisk Change Database.

A następnie wybieramy Choose an existing report server database. Połączymy się do utworzonej już wcześniej bazy.

Czas na test. O ile strona raportów otwiera się, gdy aktywny jest nod pierwszy, to w przypadku przełączenia klastra na nod 2 zobaczymy następujący błąd: The report server installation is not initialized (rsReportServerNotActivated).

Ponownie wchodzimy do Reporting Services Configuration Manager a następnie do zakładki Encryption Keys i wciskamy przycisk Delete przy Delete Encrypted Content.

Teraz wchodzimy na nod 1 i włączamy Reporting Services Configuration Manager i również przechodzimy do zakładki Encryption Keys. Wciskamy przycisk Backup i przenosimy wygenerowany plik na nod2. Na nodzie 2 w konsoli Reporting Services Configuration Manager w zakładce Encryption Keys wciskamy Restore i wczytujemy plik z noda 1.

Po tej operacji zarówno na nodzie 1 oraz nodzie 2 raporty będa otwierały się pod tym samym adresem.

[MS SQL] Tworzenie i usuwanie baz

2011-01-18T12:48:00.000+01:00

Jak stworzyć nową bazę danych przy pomocy SQL Management Studio

Włączamy SQL Server Management Studio i łączymy się z instancją, w której chcemy dodać nową bazę danych. Klikamy prawym przyciskiem myszy na węźle Databases i wybieramy New Database…

W pozycję Database name wpisujemy nazwę bazy danych, poniżej w pozycji Owner możemy przypisać bazie danych jej właściciela. Aby to zrobić wciskamy przycisk […] i wybieramy jego nazwę. Jeśli chcemy włączyć pełnotekstowe wyszukiwanie w bazie danych, należy zaznaczyć opcje Use full-text indexing.
W sekcji Database files możemy zobaczyć dokładne informacje na temat tworzonej bazy danych:
Logical Name – logiczna nazwa bazy danych i logu transakcyjnego.
File type – typ plików (dane oraz log transakcyjny).
Filegroup – grupa plików w jakiej znajduje się dany plik. O grupach plików będzie można przeczytać dalej.
Initial Size (MB) – rozmiar każdego z utworzonych plików.
Autogrowth – służy to konfiguracji automatycznego przyrostu bazy danych.
Path – ścieżka, gdzie znajdują się pliki danych i logu transakcyjnego. Obydwa pliki domyślnie znajdują się w katalogu Data (C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data). W każdej chwili jednak można zmienić ich lokalizację poprzez wciśnięcie przycisku […] . Pliki te mogą znajdować się w innych folderach, bądź na oddzielnych dyskach.
File name – nazwa pliku (nazwabazy_data.mdf oraz nazwabazy_log.ldf)

Przechodzimy do zakładki Options. W pozycji Collation możemy zmienić rodzaj kodowania językowego. Domyślnie jest on taki sam, jak ustawiony dla całego serwera w czasie jego instalacji.
W pozycji Recovery model możemy wybrać model odzyskiwania danych. Więcej o modelu odzyskiwania danych, w dalszej części artykułu.

Poniżej w sekcji Compatibility level możemy wybrać poziom kompatybilności bazy. Domyślnie jest to SQL Server 2005. Do wyboru mamy jeszcze SQL Server 2000 lub SQL Server 7.0.

Model Odzyskiwania
Przechodząc do właściwości bazy danych i zakładki Options, z rozwijanej listy możemy wybrać jeden z trzech modeli odzyskiwania (Recovery Model):
•   Full – dzięki rozległemu logowaniu oferuje możliwość odtworzenia stanu z dowolnego punktu w czasie i nie ma ryzyka utraty wyników pracy.
•   Bulk logged – uzupełnienie modelu Full, dodatkowo w pliku logu transakcyjnego rejestrowane są operacje bulk (import dużej ilości danych).
•   Simple – jako iż nie oferuje kopii zapasowych dzienników transakcyjnych, bazę danych można odzyskać jedynie z ostatniego pliku kopii zapasowych.

To samo możemy wykonać poprzez zapytanie T-SQL:

USE [master]
GO
ALTER DATABASE [baza2] SET RECOVERY FULL | SIMPLE | BULK_LOGGED WITH NO_WAIT
GO

Autogrowth
Aby zezwolić na powiększanie plików bazy danych i logu transakcyjnego, przechodzimy do właściwości bazy danych i na stronie Files wciskamy przycisk […] w pozycji Autogrowth, a następnie zaznaczamy opcje Enable Autogrowth.
Poniżej mamy możliwość określenia czy plik będzie powiększał się procentowo (In Percent) czy będzie powiększał się w określoną ilość megabajtów (In Megabytes).
Możemy również określić maksymalny rozmiar pliku, zaznaczając opcję Restricted File Growth i określając ilość megabajtów. Jeśli nie chcemy określać maksymalnego rozmiaru, zaznaczamy Unrestricted File Growth.

File Groups
Oprócz głównych plików .mdf i .ldf można utworzyć dodatkowe pomocnicze pliki danych (pliki .ndf). Pliki te służą do odseparowania różnych danych (np. indeksy, procedury składowe, tabele użytkownika mogą znajdować się w innych plikach i na innych dyskach niż tabele systemowe).
Aby stworzyć nową grupę plików przechodzimy do właściwości bazy danych, a następnie do strony Files i wciskamy przycisk Add. W sekcji Database files zostanie dodany nowy plik. Nadajemy mu nazwę oraz z rozwijanej listy w pozycji Filegroup wybieramy New file group (ponieważ w grupie PRIMARY znajduje się główny plik danych).

W kolejnym oknie kreatora nadajemy nazwę nowo utworzonej grupie oraz określamy czy ma być grupą domyślną, gdzie będą zapisywane wszystkie nowo utworzone pliki (aktualną grupą domyślną jest grupa PRIMARY), jak i również, czy grupa ma być w trybie tylko do odczytu (Read-only).

Nową grupę plików możemy również utworzyć na stronie Filegroups. Wciskamy przycisk Add i w pozycji Name wpisujemy nazwę nowej grupy oraz zaznaczamy, czy grupa ma być domyślna i czy ma być w trybie tylko do odczytu.

W przypadku zapytania T-SQL, tworzenie nowej grupy wygląda w następujący sposób:

USE [master]
GO
ALTER DATABASE [moja_baza] ADD FILEGROUP [NOWA GRUPA]
GO

Natomiast dodawanie pliku do nowo utworzonej grupy:

USE [master]
GO
ALTER DATABASE [moja_baza] ADD FILE ( NAME = N’nowy_plik’, FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\nowy_plik.ndf’ , SIZE = 2048KB , FILEGROWTH = 1024KB ) TO FILEGROUP [NOWA GRUPA]
GO

Pozostałe przydatne opcje na stronie Options w sekcji Other options:

AUTO_CLOSE – służy do automatycznego zamykania, gdy baza danych nie jest w użyciu. W momencie, gdy ktoś chce użyć bazy ponownie, baza się otwiera.
AUTO_CREATE_STATISTICS – służy do tworzenia automatycznych statystyk na kolumnach w tabelach.
AUTO_UPDATE_STATICTICS – służy do automatycznego uaktualniania statystyk.
AUTO_SHRINK – służy do automatycznego zmniejszania danych i logu transakcyjnego w przypadku, gdy 25% pliku zawiera niewykorzystane miejsce.

Jak usunąć bazę danych?

Aby usunąć bazę danych klikamy prawym przyciskiem myszy na jej nazwie i wybieramy Delete.
Na głównym ekranie widzimy nazwę bazy danych i jej właściciela. Poniżej możemy zaznaczyć dwie opcje: Delete backup and restore history for database, której zaznaczenie spowoduje usunięcie historii kopii zapasowych i odzyskiwania danej bazy danych oraz opcja Close existing connections, która pozwala na zamknięcie wszystkich aktualnie istniejących połączeń z bazą danych.
Aby usunąć bazę danych należy wcisnąć przycisk OK.

Poniżej znajduje się skrypt tej operacji:

EXEC msdb.dbo.sp_delete_database_backuphistory @database_name = N’moja_baza’
GO
USE [master]
GO
DROP DATABASE [moja_baza]
GO

[MS SQL] SQL Login VS user

2011-01-14T12:30:00.000+01:00

Jaka jest właściwie różnica między loginem , a userem w SQL Server?
Pytanie to pojawiło się kiedyś na moim teście kwalifikacyjnym do pracy, ale również na egzaminie 70-432 trafiłam na pytanie, które gdzieśtam dotyka tej kwestii. Nie powiem jak brzmiało, bo podobno nie wolno ;-)

Ale do rzeczy: dzięki loginowi możemy się zautoryzować w serwerze SQL i otrzymać dostęp do danej instancji. Ale nic poza tym, nie będziemy mogli otrzymać dostępu do żadnej bazy danych. Aby móc korzystać z bazy danych, login musi być połączony z userem, któremu nadamy odpowiednie prawa - ot cała filozofia.

No dobrze, ale jak utworzyć login?

W SQL Management Studio klikamy na węzeł Databases | Security | Logins. Klikamy prawym przyciskiem myszy i wybieramy New Login.

Na głównej stronie określamy czy będzie to użytkownik Windows (użytkownik Active Directory lub lokalne konto), czy będzie to użytkownik SQL. W celu wybrania autoryzacji Windows – zaznaczamy Windows authentication, w przypadku autoryzacji SQL – SQL Server authentication.
W przypadku wybrania autoryzacji SQL, należy wprowadzić hasło dla loginu oraz poniżej wybrać jedną lub kilka z trzech opcji:

Enforce password Policy – hasło nie może zawierać w sobie części nazwy loginu i nie może być krótsze niż 7 znaków oraz powinno zawierać cyfry, duże i małe litery oraz znaki nie alfanumeryczne. Informacje pobierane są z polityki grupowej.
Enforce password expiration – hasło wygasa po przekroczeniu wartości określonej w polityce grupowej.
User must change password at next logon – wymaga zmiany hasła użytkownika przy kolejnym logowaniu.

Sekcje Default Database oraz Default language są widowczne zarówno dla loginu z autoryzacją SQL jak i Windows. W Default Database określamy domyślną bazę danych dla loginu.

Na stronie Server Roles wybieramy role serwerowe, przypisane dla tego loginu

bulkadmin – zezwala na operację masowego wstawiania danych (BULK INSERT),
dbcreator – zezwala na tworzenie, usuwanie, modyfikację bazy danych oraz dodawanie do niej nowych członków (CREATE DATABASE),
diskadmin – zezwala na zarządzanie plikami .mdf i .ldf (ALTER),
processadmin – zezwala na kontrolę procesów (ALTER ANY CONNECTION oraz ALTER SERVER STATE),
securityadmin – zezwala na zarządzanie loginami i uprawnieniami (ALTER ANY LOGIN),
serveradmin – zezwala na konfigurację całego serwera (ALTER SERVER STATE, ALTER SETTINGS, SHUTDOWN),
setupadmin –zezwala na zarządzanie serwerami połączonymi (ALTER ANY LINKED SERVER),
sysadmin – zezwala na pełną kontrolę nad bazami danych (CONTROL SERVER with GRANT),

Na stronie User Mapping zaznaczamy nazwę bazy danych wraz z nazwą użytkownika, który będzie zmapowany do tego loginu (Users mapped to this login), a następnie w sekcji Database role membership for : nazwa_bazy zaznaczamy role, które chcemy nadać:

db_accessadmin – zezwala na dodawanie i usuwanie kont,
db_backupoperator – zezwala na wykonywanie kopii zapasowych,
db_datareader – zezwala na odczyt baz danych,
db_datawriter – zezwala na zapisywanie i modyfikację baz danych,
db_ddladmin – zezwala na modyfikację i usuwanie obiektów baz danych,
db_denydatareader – nie zezwala na odczyt baz danych,
db_dentydatawriter – nie zezwala na zapisywanie i modyfikację baz danych,
db_owner – zezwala na pełną kontrolę nad bazą danych,
db_securityadmin – zezwala na zarządzanie uprawnieniami oraz rolami baz danych,
public – rola domyślna, zapewniająca minimum uprawnień.

Strona Securables służy do przypisywania uprawnień do obiektów zabezpieczanych dla tego loginu. Po wciśnięciu przycisku Search mamy do wyboru obiekty takie jak:

Specific object - określone obiekty (serwery, punkty końcowe [endpoints] oraz poszczególne loginy);
All objects of the types - wszystkie obiekty danego typu (jak wyżej);
The server 'NAZWA SERWERA'

Strona Status służy do nadawania lub odejmowania uprawnień dla loginu do łączenia się z bazą danych (Permission to connect to Database engine) oraz blokowania konta.

Jak stworzyć usera?

Jeśli w poprzednim kroku w User Mapping zmapowaliśmy login dla userwa nie musimy już go tworzyć. W innym przypadku aby stworzyć użytkownika dla bazy danych i przypisać mu odpowiednie uprawnienia do wykonywania zadań w bazie danych należy rozwinąć węzeł z nazwą bazy danych i przejść do węzłów Security | Users. Klikamy prawym przyciskiem myszy i wybieramy New User…
W pozycji User name wpisujemy jego nazwę, natomiast w Login name wyszukujemy skonfigurowany uprzednio login.
W pozycji Default schema przypisujemy użytkownikowi domyślny schemat, natomiast poniżej w sekcji Schemas owned by this User zaznaczamy pozostałe schematy, które mają być własnością tego użytkownika. W sekcji Database role membership, przypisujemy użytkownikowi rolę.

Przejdźmy jeszcze na chwilę do sekcji Securables. Podobnie jak w przypadku tworzenia loginu mamy tu trzy opcje:

Specific object (określone obiekty);
All objects of the types (wszystkie obiekty danego typu);
All objects belonging to the schema (wszystkie obiekty, które należą do określonego schematu);

Sprawdźmy, co kryje się pod typami obiektów:

W przypadku wybrania np. tabeli:

Mamy możliwość określenia, co konkretnie użytkownik może bądź nie może na niej robić. W tym przypadku użytkownik może skasować tą tabelę:

A kto lubi TSQL może użyć skryptu, który tworzy login (oparty na koncie użytkownika windows), mapuje login do użytkownika i bazy danych oraz określa uprawnienia czytania i pisania do bazy:

USE [master]
GO
CREATE LOGIN [FILIPPA\monika] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
USE [AdventureWorks]
GO
CREATE USER [FILIPPA\monika] FOR LOGIN [FILIPPA\monika]
GO
USE [AdventureWorks]
GO
EXEC sp_addrolemember N'db_datareader', N'FILIPPA\monika'
GO
USE [AdventureWorks]
GO
EXEC sp_addrolemember N'db_datawriter', N'FILIPPA\monika'
GO

[IIS 7] Kilka słów o backupie ustawień IIS 7

2011-01-12T13:59:00.000+01:00

Pewnie każdemu (każdemu kto miał oczywiście doczynienia z IIS) zdarzyło się kiedyś, że jedna mała zmiana spowodowała nieodwracalne zmiany w IIS lub w samym serwerze Windows i serwer takowy trzeba było postawić od nowa. Pół biedy gdy mamy pod ręką dobry backup. Gorzej jeśli nagle musimy odtworzyć strony wraz z konfiguracją IIS od początku. A przecież backup ustawień serwera IIS to tylko kilka sekund...

Ale do rzeczy. Co należy backupować, żeby zaoszczędzić sobie stresów i straconego czasu?
1. Pliki witryn internetowych znajdujących się w naszym IIS (domyślnie znajdują się w katalogu C:\inetpub\wwwroot, ale lepiej jest mieć je poza dyskiem C);
2. Pliki konfiguracyjne .NET Framework - web.config, machine.config i co tam jeszcze potrzebujemy (C:\Windows\Microsoft.NET\Framework);
3. Konfiguracja samego IIS (C:\Windows\System32\inetsrv\config);

Zajmijmy się punktem ostatnim. W katalogu config znajdują się trzy pliki konfiguracyjne: administration, applicationHost, redirection oraz katalog schema, w którym znajdują się pliki XML. Aby odtworzyć konfigurację IIS należy najpierw stworzyć ich kopię zapasową. Z pomocą przyjdzie nam polecenie AppCmd:

AppCmd backup NazwaBackupu

Po wykonaniu tego polecenia w lokalizacji Windows\System32\inetsrv\backup\ zostanie utworzony katalog z naszym backupem:

Jeśli chcemy wyświetlić listę wszystkich backupów wystarczy użyć polecenia: AppCmd list backups:

Ale jak odzyskać taką konfigurację IIS w trakcie awarii? Nie ma nic prostszego, wystarczy użyć polecenia

AppCmd restore backup NazwaBackupu

Będąc już w wierszu polecenia możemy również taki backup usunąć używając polecenia

AppCmd delete backup NazwaBackupu

Photosynthem zabawy

2011-01-11T13:54:00.000+01:00

W październiku udałam się na mały urlop do Brukseli (wielkie podziękowania należą się Agatce N., która pozwoliła siedzieć sobie na głowie niemal tydzień i nawet się nie skarżyła!). Miasto małe, zgrabne, przyjemne i wszędzie można dojść piechotą. Wbrew pozorom mają też nierówne chodniki, widać jeszcze nie wszystkim rządzą normy unijne.

W chwilach, kiedy nie padało (bo czasem nawet nie padało!) porobiłam trochę zdjęć. Udało mi się nawet ustrzelić jednego photosyntha na tamtejszym rynku. Ale czym właściwie jest Photosynth? Bardzo przyjemne narzędzie od Microsoftu, które pozwala na tworzenie trójwymiarowych odwzorowań obiektów, gdzie znajduje się fotografujący. Ba, można nawet dojrzeć detale, których nie widzieliśmy robiąc zdjęcie, a ich szczegółowość zależy tylko od aparatu.

Mój pierwszy photosynth można podziwiać tutaj (polecam rzecz jasna powiększenie):

Przy okazji wizyty Belgii podjechałam również do Paryża (bo to przecież tylko 1h 20min pociągiem!). Paryż mnie rozczarował. Za dużo ludzi, za dużo nachalnych handlarzy wszystkim, a metro wygląda jak piekło tudzież scenerie rodem z Fallout 3 (widać nie trzeba bomby atomowej, żeby coś wyglądało okropnie). Nie mniej jednak udało mi się ustrzelić całkiem fajnego photosyntha na terenie Luwru: