Sharepoint Portal Server2008. 1. 13. 15:15
Sharepoint Service 3.0의 백업은 Central Administration에서 이루어진다.

Central Administration에서 Operation 탭으로 가면 Backup & Restore라는 메뉴가 있다. 거기에서 Perform a Backup 링크를 클릭하면 백업할 수 있는 화면으로 가게 된다.

사용자 삽입 이미지


그러면, 백업할 수 있는 요소들의 리스트가 뜬다. 여기서 전체를 할 수도 있을 것이고, 선택적으로 할 수도 있다.

사용자 삽입 이미지


그 다음은 백업 옵션을 설정하는 화면이다. 백업 방법(Full & Differential)과 백업 디렉토리를 설정한다.

사용자 삽입 이미지


그러면 백업이 시작되는데, 이 작업은 꽤 시간이 걸리기 때문에, 바로 상태가 나타나지는 않는다. 툴바의 Refresh 버튼을 누르다보면 아래 그림과 같이 계속 상태가 업데이트되게 되는 것을 확인할 수 있을 것이다.

사용자 삽입 이미지



하지만 이렇게 Central Administration 사이트에 들어가서 수동으로 백업을 하는 것은 간편하기는 해도 꽤 귀찮은 일이다. 그래서 STSADM.EXE와 윈도우 스케줄러를 사용해서 백업을 자동화하는 것이 더욱 좋을 것이다.

TechNet사이트의 Window Sharepoint Service 3.0 Library의 "Automate the backup process by using a batch file" 이라는 문서에 자세한 방법이 나와 있는데, 그 step을 소개하자면 아래와 같다.

1. 노트패드를 열어서 아래와 같은 내용을 입력한 다음, WSSBatchBackup.bat라는 이름으로 저장한다. (C:\backup이라는 디렉토리이름은 자유롭게 바꾸면 된다)

@echo off
echo ===============================================================
echo Back up sites for the farm to C:\backup
echo ===============================================================
cd \Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
@echo off
stsadm.exe -o backup -directory "\backup" -backupmethod full -overwrite
echo completed

2. 제어판 -> Scheduled Tasks로 이동해서, 새로운 스케줄을 만든다. 그리고 그 스케줄에서 실행할 파일을 아래 그림처럼 스텝1에서 만든 Batch파일로 지정하는 것이다. 스케줄의 실행 주기는 필요한 만큼 설정하면 된다. (내 개인적으로 매일 백업하도록 설정해 두었다.)

사용자 삽입 이미지


이와 같이 스케줄로 설정해서 자동화시켜두면, 이제 수동으로 백업할 일은 없을 것이다. 그리고 유사시에는 이 백업 파일을 활용해서 빠른 복구가 가능할 것이다.
Posted by kkongchi
Sharepoint Portal Server2008. 1. 5. 21:47
죽어버린 Sharepoint 팀 사이트를 살려라. 사건개요 보기

DB까지는 어떻게 회복을 했다. 그리고 다시 다른 서버에 Sharepoint Service 3.0을 새로 설치하고, 기존 서버를 백업한 파일을 Restore하는 방식으로 Sharepoint 서버를 옮기게 되었다.

여기서, 또 하나의 문제가 발생했다. 서버를 옮길 때에 기존에 있던 모든 계정을 똑같이 만들어줬음에도 불구하고, 기존 계정들과는 다르게 인식이 되는 것이다.

즉, 똑같은 kkongchi라는 계정으로 로그인을 해도 기존에 썼던 게시물은 내가 쓴 것이 아니게 되는 이상한 현상이 벌어지는 것이다. 결국 내가 그전에 썼던 게시물을 수정하거나 삭제하지 못하게 된다. 물론 불편한 대로 쓸 수는 있겠지만, 깔끔하지가 못했다.

그래서 조사해본 결과, 다음 문서를 Microsoft의 Support Knowledge Base에서 찾을 수 있었다.

After you migrate a user from a different Active Directory domain, the user can no longer access Windows SharePoint Services

위 문서는 사실 내 경우와는 좀 다르다고 하겠다. 위 문서는 Sharepoint Service의 MIgration 시에 할 수 있는 것들을 자세하게 다루고 있다. 하지만 아래 쪽에 보면 STSADM 유틸리티를 사용해서 User를 Migrate할 수 있는 방법을 알려주고 있다. 내가 원하는 것은 바로 이것이었다.

stsadm -o migrateuser -oldlogin DOMAIN\user -newlogin DOMAIN\user [-ignoresidhistory]

위 방법을 써서 바로 현재 사용자들과 기존 사용자들을 Sync시킬 수 있었다. 이제 완전히 같은 환경이 된 것이다. 그러나...

To Be Continued...
Posted by kkongchi
Sharepoint Portal Server2007. 11. 22. 22:45
Sharepoint Service 3.0 사이트에서, 상단 검색 창을 이용해서 검색을 하면 이런 에러가 날 수도 있다.

"Your search cannot be completed because this site is not assigned to an indexer. Contact your administrator for more information."

에러 화면은 다음과 같다.

사용자 삽입 이미지


이 문제의 원인은, Sharepoint 웹 애플리케이션을 새로 만들 때 검색 서버를 할당을 하지 않았기 때문이다. 보통은 검색 서버를 할당을 하겠지만, 하지 않았다면 이렇게 검색 기능 자체를 아예 쓰지 못하게 된다.

해결책은? 당연한 말이겠지만, 웹 애플리케이션에 검색 서버를 할당하면 된다. 그런데 이게 조금 찾기가 힘들다. 왜냐하면, 웹 애플리케이션을 만들 때는 그 만드는 화면에서 검색 서버를 할당하는 옵션이 있기 때문에, 웹 애플리케이션 수정 같은 곳에 있지 않겠나 싶어서 찾아보면 그런 메뉴 자체가 없기 때문이다.

방법은 다음과 같다.

1. Sharepoint Central Administration 사이트를 연다.

2. 상단 탭에서 Application Management를 선택한다.

3. Sharepoint Web Application Management 그룹에 있는 "Content Database"메뉴를 클릭한다.

사용자 삽입 이미지


4. 그러면 Content database 리스트가 뜨는데, 검색 기능을 활성화하고자 하는 사이트가 사용하는 database를 선택해서 클릭한다.

사용자 삽입 이미지


5. 그러면 거기에서 Search Server를 할당할 수 있을 것이다.

사용자 삽입 이미지


이 스텝을 그대로 하면, 검색 기능이 활성화될 것이다. Sharepoint Service의 검색 기능은 매우 막강하므로 (워드, 엑섹 등의 오피스 문서의 내용도 인덱싱을 해주므로, 내용으로 검색도 가능하다.) Sharepoint service를 쓴다면 검색 기능을 활성화해놓고 사용하는 것이 좋을 것이다.
Posted by kkongchi
Sharepoint Portal Server2007. 11. 9. 23:21

사내에 개발팀의 Communcation 도구 및 자료 저장소/Wiki라이브러리로 Windows Sharepoint Service 3.0을 사용하고 있다. 관리 책임이 나에게 있던 사이트였지만, 평소에 그다지 신경을 그다지 쓰지는 않았다. 백업이라도 해 뒀어야 하는데..-_-;;

암튼 결국 사고가 터졌다. 약 한달전 사이트가 갑자기 느려지더니 결국 1시간만에 조용히 죽어버렸다... 원인은 하드 디스크의 Bad Block.. 그것도 Sharepoint의 데이터를 저장하는 SQL 데이터 파일에서 발생...

암튼 이 사고로 인해서 죽어버린 Sharepoint Service를 다시 살리는데 아주 고생을 했다. 아래는 나의 그 고생을 기록한 경험담이다..-_-;

1. Suspect 상태의 DB를 살려라
2. 계정을 싱크해라
3. 새로운 서버로의 이전

Posted by kkongchi
Sharepoint Portal Server2006. 3. 24. 17:57

회사에서 Microsoft Sharepoint Portal 서버를 설치하고, 사내 인트라넷 용도로 쓰고 있다. 그런데 서버의 이벤트 로그에 다음과 같은 에러가 계속해서 남는 것을 발견했다.

이벤트 형식: 경고
이벤트 원본: Microsoft SharePointPS Search Service
이벤트 범주: Gatherer
이벤트 ID: 3036
날짜: 2006-03-24
시간: 오후 5:30:03
사용자: N/A
컴퓨터: PORTAL
설명: 콘텐트 원본 <sps://portal.interdev.co.kr/site$$$people>을(를) 액세스할 수 없습니다.
컨텍스트:
http://portal.interdev.co.kr/ 응용 프로그램, Portal_Content 카탈로그
자세히: 액세스가 거부되었습니다. SharePoint 중앙 관리에 있는 기본 콘텐트 액세스 계정이 정확한 계정인지 확인하십시오. 또는 이 URL에 접근하기 위해서 적절한 탐색 계정을 지정해주는 규칙을 추가하십시오.   (0x80041205)

그런데, 기본 콘텐트 액세스 계정은 도메인의 administrator계정이었던지라, 액세스가 거부 되었다는 게 이해가 안 되는 상황이었다. 그래서 Google 검색을 해보니...

http://forums.isaserver.org/m_210038800/tm.htm


이 곳에서 답을 찾았다.


즉,


- don't use other ports then 80 and 443 on the webserver.
- don't use headertranslation
- use different ip-addresses on the webserver to make distinction between sites
- On the SSL-rule use linktranslation to transform the servername to the url-name

지금 에러가 나는 포탈 사이트의 경우, 기본 웹 사이트에 설치하지 않고,

제가 사이트를 새로 만들어서, 호스트 헤더 값으로(즉, portal.interdev.co.kr로 들어오는 경우만)

구분을 했었다. 그게 바로 문제의 원인이었던 것. 즉, 검색 정보를 모으는 Gatherer의 경우 서버의 로컬에서 내부적으로 HTTP요청을 보내서 사이트를 검색하게 되는 건데, 서버 내부에서는 당연히 portal.interdev.co.kr로 보내도 그 서버가 어디 있는지 알 수가 없기 때문에 이런 에러가 나게 되는 것이다.


혹시, Sharepoint Portal 서버에서 이런 에러가 나시는 분들은 참고하시기 바란다.

Posted by kkongchi