하나 또는 내 최초의 블로그 게시물, SPS에서 고객을 마이그레이션하는 데 다음에 우리는 전체 프로세스를 설명 2003 이끼를. 독자 코멘트를 자세히 요구 왼쪽 그리고 여기.

마이그레이션 프로젝트에 대 한, SPS의 많은 이동 하는 좋은 방법을 찾을 수 있었습니다. 2003 이끼를 통해 문서. 초기 로드 충분히 쉬 웠 다. MOSS에서 새 대상 문서 라이브러리를 만들고 windows 탐색기를 사용 하 여 문서를 이동.

이것은 새 문서 라이브러리:

탐험가 두 개의 창을 열어합니다. SPS에서 첫 번째 포인트 2003 MOSS에서 새 문서 라이브러리에 두 번째. 다음 스크린 샷에서 표시이. 상위 브라우저 내 c에서 실제로 가리키는 유의:\임시 드라이브, 하지만 SPS를 가리키는 그것을 상상할 수 있습니다 2003 문서 라이브러리:

그 후 끌어서 놓기 작업, 내 대상 다음과 같이 보:

지금 그것은 메타 데이터 처리 시간. 우리 라는 "위치가이 문서에 대 한 메타 데이터의 한 열 가정입니다." 우리는 위의 "모든 문서에서 볼 수 있습니다." 위치는 빈 볼. 그것은 데이터 시트 보기를 사용 하 여 위치를 입력 하, 또는 각 문서 속성 하나를 위치를 추가로 이동. 가정해 실용적인 수 없습니다 위치 열 값을 자동으로 할당 되는 최종 사용자가 해야 할이 손으로. 또한, 문서의 수백이 있다 가정 하자 (어쩌면 수천) 그리고 그것이 걸릴 것입니다 많은 메타 데이터를 업데이트 하려면 많은 일. 우리 모두가 알다시피, 아무도 앉아 4 5 일 연속 문서에 대 한 메타 데이터 업데이트에 대 한 작업을 거 야. 대신, 그들은 몇 주 또는 더 긴 기간 동안 그를 탈출 것입니다.. 이 과정을 촉진 하기, 우리는 "태그가 지정 되지 않은 데이터를 만들 수 있습니다." 보기와 같이:

지금, 누군가가 내려 앉아 보내고 그들의 할당 된 일일 시간 또는 마이그레이션된 문서 태그 2, 그들은 "태그가 지정 되지 않은 문서를 사용할 수 있습니다." 그들의 노력을 집중 하는 것 보기:

사용자 태그 문서, 그들은이 목록에서 삭제.

태그 데이터 보기의이 개념 또한 데이터 유효성 검사 문제 사람들에 대 한 포럼에 문의의 클래스와 함께 도울 수 있다. 상자, 이끼에 문서를 업로드 한 사용자를 방지 하기 위해 다음 메타 데이터를 입력 하지 방법이 없습니다.. 특정 사이트 열은 필수 이며 사용자는 저장을 허용 되지 않습니다 지정할 수 있습니다 버튼. 그러나, 사용자 업로드 하는 경우 다음 브라우저를 닫습니다 (또는 문서를 업로드를 사용 하 여 windows 탐색기), 우리 메타 데이터 입력 사용자 강제로 수 없습니다. (다시, 상자 밖으로).

이 방법은 그 상황에 도움이 사용할 수 있습니다.. 우리는 "저조한 태그 데이터를 사용할 수 있습니다." 쉽게 이러한 문서를 식별 하 고 수정할 보기. KPI 커플이 있고 이러한 예외적인 상황을 관리 하기 위해 드릴 다운을 사용 하 여 데이터를 좋은 가시성.

</끝>

내 블로그를 구독.

이번 주, 난 간단한 2 서버 팜에 설치 하는 이끼를 내 팀과 조금 싸 워 왔어. 그것을 통해 간 데, MSDN 포럼에 그리고 다른 곳에서 문제가 사람들이 보고서의 종류에 대 한 큰 감사를가지고.

최종 팜 구성:

• 방화벽 내에 SQL/인덱스/인트라넷 WFE.
• WFE DMZ에.
• DMZ와 내부 서버 간의 방화벽의 일종.

우리는 프로젝트를 시작 하기 전에, 우리는 클라이언트 포트를 열어야 하는 데 필요한 게. 주고받는 동안, 그 동안 이리저리, 우리는 결코 명시적으로 중요 한 두 가지를 말했다:

1. SSL은 인증서가 필요한 것을 의미 한다.
2. DMZ 서버는 도메인의 일부 여야 합니다..

하루에 한, 우리 MOSS를 설치 하 고 데이터베이스와 이끼에 대 한 도메인 계정을 하지 않았다면 만들어진 배웠습니다.. 것 들을 따라 이동 하, 우리는 서 서 하 고 인트라넷 서버에 로컬 계정이 있는 모든 것을 설치.

이 시점에서, 우리는 SSL 인증서에 혼란을 발견 하 고, 슬프게도, 우리의 인프라 사람이 다시와 서 나중에 그 주 계속 DMZ 서버를 설치 하기로. 평균시에서, 우리 솔루션 건축가 비즈니스 물건 앞으로 이동.

주말가 및 클라이언트 인증서를 가져옵니다..

우리의 인프라가 나타나고 DMZ 서버를 도메인에 가입 되지 않은 발견 (제한 된 신뢰 경계 도메인 또는 인트라넷 도메인). 우리 거의 낭비를 1/2 그 날. 만약 우리가 우리를 수렁 누락 된 SSL 인증서 하지 않았다면, 우리는 발견이 이전. 오 오 잘….

또 다른 하루 패스 및 다양 한 보안 위원회, 관심을 당사자와 (그리) 무고 한 구경꾼 모든 동의 그것 DMZ 서버는 인트라넷 도메인 가입 확인 (이것은 한 POC, 어쨌든, 아니 생산 솔루션).

인프라 남자에 관해서 것 들을 마무리. 우리가 성공적으로 통과 하는이 시간에 다 정하게 "SharePoint 구성 마법사로 알려진 현대 결투." 우리는 중앙 관리에 있는 엿 고 … 유 호! … DMZ 서버 농장에 나열 됩니다.. 우리 조금 가까이 그리고 우리 파산 오픈 샴페인 마이트 조금 일찍 실현. WSS 서비스에 붙어 있는 "시작" 상태.

길고도 짧은 이야기, 그것은 우리가 원래 로컬 계정에서 새 도메인 계정을 중앙 관리를 통해 서비스 계정의 id를 변경 하려면 깜 빡 밝혀. 우리는 그랬다, 구성 마법사 re-ran 봐라! 우리는 사업에 있었다.

</끝>

내 블로그를 구독.

비록 그것이 문자 그대로 사실이, 실질적인 문제로 서, DMZ에는 인터넷 웹 프런트 엔드는 도메인에 있어야 합니다. (즉. 일부 독립 실행형 서버는 자체 작은 작업 그룹에서). 그것은 내부 WFE와 동일한 도메인에 있어야 필요가 없습니다.(s) 그리고 다른 서버 (아마 안와), 도메인 해야 하지만.

내 동료와 나 SharePoint 필수 구성 요소를 포함 하는 제안에 시간의 과도 한 금액을 지출. 이 농장 등에 가입 하도록 DMZ 서버 있도록 방화벽 구성의 포괄적인 목록을 포함. 슬프게도, 우리는 어딘가에 말했다 문장 추가 실패, 효과를, "이이 구성의 전체 피 묻은 포인트 DMZ WFE 서버를 허용 하는, 도메인에서, 내부 팜에 가입."

이벤트의 완벽 한 폭풍, 어디 우리가 기본적으로 보였다 왼쪽 오른쪽 모습이 수 있습니다 우리가 하는 때, 공모 과정에서 상당히 늦게 때까지 미국에서이 문제를 숨기기, 따라서 호출에서 날을 방지 내 "나쁜 뉴스를 일찍 말해" 규칙.

한숨.

내 블로그를 구독.