walczę z sharepointem od tygodnia. nie jestem nawet w stanie opisać operacji jakie wykonałem bo było ich zbyt dużo – a pomysł był prosty – przenieść bazy WSS na inny serwer. najpierw mała anegdotka która mnie przed chwilą zabiła:
z niewiadomych powodów niektórzy userzy stracili możliwość otwierania plików excel – doc działa, z FF można zrobić 'save as’ ściągnąć i otworzyć, ale jak się otwiera z IE to pojawia się komunikat 'can not open… posibble reasons: file already in use, path not exist…’ dokładnie nie pamiętam a już nie zrobię screenshota… w każdym razie zrobiłem wszystko co mi przyszło do głowy:

  • restart usług
  • modyfikacja/sprawdzenie uprawnień na poziomie site’u
  • weryfikacja uprawnień i wyewidencjonowanie pliq
  • wypicie mocnej kawy
  • rzucanie znanymi przekleństwami i wymyślanie nowych

w eventlogu nic. aż w końcu tak się zdenerwowałem, że postanowiłem przetestować wytrzymałość swojej myszki na gwałtownie przyłożony wektor siły zgodnie z kierunkiem grawitacji. myszka trochę wytrzymała – musiałem wydłubywać qłko bo trochę się schowało. ale działa. najśmieszniejsze właśnie to, że nie tylko myszka bo i arkusze zaczęły się otwierać.
czasem myślę, że powinienem wybrać sobie inny zawód. nie wiem… ogrodnictwo? zawsze lubiłem przesadzać… a może grabarz? … grzebanie też mi dobrze wychodziło… uh. deterministyczny świat wydaje się dużo bezpieczniejszy. a jak mam niby wyjaśnić tą sytuację? oficjalne KB na stronach technet, „solution: knock your mouse down strongly. twice if not working”.

w każdym razie finalnie bazy kontentu przeniesione. baza konfiguracji poszła z dymem. tutaj też ciekawostka: wielkość logu dla bazy config była >12GB. zrobiłem 'shrink files’. log się zmniejszył… do 5ook. czemu to się nie robi automatycznie? czemu jakiś łoś wymyślił, że sharepoint instaluje się z automatu i nic nie da się skonfigurować – nawet kiedy wybierze się tryb farmy? cholerny silnik Windows Internal Database – obligatoryjnie instalowany i obligatoryjnie konfigurowany podczas instalacji – jest praktycznie niekonfigurowalny. lokalnie podłącza się zupełnie intuicyjnym stringiem:
\.pipeMSSQL$MICROSOFT##SSEEsqlquery
nie wiem czy do tego da się dostać zdalnie – być może jakiś klucz w rejestrze? a więc trzeba na każdym kompie z WID instalować express studio. zajebiście wygodne, jeśli by się ktoś pytał. i zgodne z dobrym sposobem zarządzania.
ponieważ jednego WSS rozgrzebałem tak, że już przestała działać strona administracyjna [próbowałem przenieść bazy Admin], więc postawiłem nowego – bo i tak miał być docelowo gdzie indziej. co jest zatem w tym całym configu? całość zawarta jest w bazach kontentu – bo utworzyłem nowe site’y i podłączyłem bazy i hula. strona administracyjna też. połowa sukcesu. potem tylko niedziałające arkusze…
cały czas przegrywam z searchem, który mnie informuje o braq dostępu… już nawet wedle pięknej instrukcji założyłem konto domenowe i jakoś nie za bardzo mu to pomaga. komunikaty błędu nie są dla mnie jasne – i tak na dobrą sprawę nie wiem o którą bazę się pyszczy ani czemu. uuhhh… jakie to wszystko jest po…

eN.

ps. korzystałem z wordpressów, dontnetnuke, drupali i innych wynalazków – i żaden, nawet najprymitywniejszy, nie przebija głupotą i brakiem intuicyjności zarządzania sharepointem. obsługa grup, dodawanie/usuwanie userów, menu zarządzania – generalnie interfejs – kieruje się w WSS jakimiś niezrozumiałymi [dla mnie] pomysłami.

-o((:: sprEad the l0ve ::))o-

Comments (8)

  1. kojn

    Odpowiedz

    Dobra tak na serio … sposób w jaki się za to zabrałeś oczywioście mna wiele do życzenia … ale moze nei bede tu o tym ;) … co do bazy konfiguracji, to jest ona istotna z punktu wiodzenia sitów administracyjnych, złożonych farm, i takich tam … i są inne sposoby na jej przenoszenie ;) …
    Do do interfacu, to faktyczne jest z dupala … bo to idzie z poprzendich wersji jeszcze od sharepointa 2000 … w 2010 jest o niebo lepiej, choć niektóre rzeczy oczywiście pozostłay ..(zostąły te administracyjne) … zabawa zaczyna się jak zaczynasz korzystać z MOSSa i SSP (Shared Service Provider) bo w tedy to już nic nei wiadomo, gdzie co jest i który servis searcha co robi ;) … powodzenia

  2. Odpowiedz

    W poście nieco przekłamałeś, bo nie ma obowiązku używać SQL w wersji Embedded. Możesz równie dobrze używać zwykłego SQL (minus – koszta) lub wersję Express (minus – ograniczenia). Zasadniczo późniejsza praca na zintegrowanej bazie to masakra. Ja dla wygody stosuje backup po STSADM i późniejsze przywracanie site collection. Sprawdza się to, gdy nie masz dużej ilości zewnętrznych rozwiązań. W mojej dotychczasowych doświadczeniach zero problemów.

    Dwie uwagi:
    Komunikaty jakie ci się wyświetlały spotykałem w sytuacji gdy SharePoint wysiadał wydajnościowo przy dużych bibliotekach/listach z zerwanym security na poziomie elementu. Jeśli masz podobny scenariusz to spokojnie możesz liczyć na powrót takowych komunikatów. Jeśli nie to masz szczęście ;)

    A gdzieś natrafiłem na jakimś blogu, na info że shrinkowanie bazy Embedded jest niezalecane. Ja tej wersji na produkcji nie używam więc od siebie nic nie dodam.

  3. Odpowiedz

    „bo nie ma obowiązku używać SQL w wersji Embedded” – no nie ma. ale taki jest niemodyfikowalny default. podczas wizarda instalacji wybralem opcje 'farma – skonfiguruj serwery pozniej’ a jak skonczyl mialem wszystko – od podstawowego site’u, WID, search etc. dziwne – bo spodziewalem sie wylacznie siteu administracyjnego i recznej konfiguracji.
    co do problemow – to jak juz dziala, to dziala…. ale w razie jakichs problemow debugowanie tego nie jest przyjemne.

    @karol: wbrew pozorom ja tez lubie sharepoint’a q: ale ze interfejs projektowal ktos po paczce tramalu chyba niezaprzeczysz…

  4. Odpowiedz

    Windows Internal Database to jest ZŁO WCIELONE ! Postawiłem na tym WSUS to tak zamulał , że nie dało się pracować GRRR. dopiero jak zmigrowałem na MSSQL to WSUS przyśpieszył o 150 tys. % :P

Skomentuj nExoR Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Time limit is exhausted. Please reload CAPTCHA.