Протягом минулого тижня, мій колега і я були робити певну роботу для клієнта в Нью-Йорку. Ми відчували різні аспекти реалізації МОСС, використовуючи їх "стандарт" побудувати робоча станція (на відміну від наших ноутбуків). Роблячи що, Ми зіткнулися з декілька помилок, виконавши такі дії.:

• Відкрийте документ word MS за допомогою провідника windows (в якому використовується протокол WebDAV).
• Внести зміни.
• Зберегти його.

Ми прийшли до розуміння, що кілька разів (зазвичай в перший раз) Ми зберегли документа, зберегти не "палицею." Зберегти не зберігати. Ми б витягнути цей документ, резервного копіювання і наші зміни просто не були там.

Ми не розуміємо випуск кореня на даний момент, але ми порахували, що ми повинні переконатися, що найновіший пакет оновлень для MS Office було встановлено на що робоча станція. IT люди пішов і зробив це. Ми пройшли через тест знову, і ми виявили, що нова проблема. Коли ми зберегли його, Тепер ми отримали цю помилку:

Цього разу, здавалося, що кожна зміна була, Насправді, збережені, Ми відповіли так чи ні питання скрипти.

Ми нарешті довелося поглянути на фактичні версії Office і виявляється, що робочої станції біг MS Office 2000 з пакетом оновлень 3 який виглядатиме у розділі Довідка-> Про як "Office 2002".

Мораль цієї історії: Я завжди буду використовувати Office 2003 як моя версія office мінімальних базових норм при використанні WebDAV та ЛИШАЙНИК.

</кінець>

Підписатися на мій блог.

(В цілях пошуку двигуна, Це помилка в тексті):

Лінія: 11807

Чар: 2

Помилка: Об'єкт не підтримує цю властивість або метод

Код; 0

URL-АДРЕСА: http://sharepoint01/DocumentReview/_vti_bin/owssvr.dll?location=Documents/1210/testworddocument.doc&dialogview=SaveForm

Ви хочете продовжити виконання скриптів на цій сторінці?

В одному або мій перші записи в блогах, Я описав загального процесу ми слідували мігрувати клієнт від SPS 2003 для ЛИШАЙНИКА. Читач залишили коментарі запитували докладно і от.

Для цього проекту міграції, Ми повинні були знайти хороший спосіб, щоб перемістити багато SPS 2003 документи над для ЛИШАЙНИКА. Первісну навантаження була досить просто. Створити нову бібліотеку цільового документа в МОСС і рухатися документи за допомогою провідника windows.

Це нова бібліотека документів:

Відкрийте два вікна дослідників. Точка перший в ССП 2003 а друга на нову бібліотеку документів в MOSS. Наступний скріншот показує це. Зверніть увагу, що top браузера фактично вказуючи на мій c:\Temp їзди, але ви можете собі уявити його вказуючи на SPS 2003 Бібліотека документів:

Після цього перетягнути операція, Моя цільова виглядає наступним чином:

Тепер настав час боротися з метаданими. Припустимо, що у нас є тільки один стовпець метаданих для цих документів, названий "розташування." Ми можемо бачити від «всіх документів" Переглянути пусте місце розташування. Це легко за допомогою перегляду аркуша даних введіть розташування, або навіть піти на властивості кожного документа по черзі додати розташування. Давайте припустимо, що немає практичний спосіб привласнити розташування стовпця значення автоматично і що кінцеві користувачі повинні це зробити вручну. Крім того, Припустимо, що є сотні документів (може бути тисячі) і що вона займе багато багато днів, щоб оновлювати метадані. Як ми всі знаємо, ніхто не збирається сісти і працювати для чотирьох з п'яти днів поспіль оновлення мета-дані для документів. Замість цього, вони будуть перебороти, протягом тижнів або, можливо, довше. Для полегшення цього процесу, Ми можемо створити послугами "без тегів даних" Перегляд, як показано:

Зараз, Коли хтось сидить вниз, щоб витрачати їх виділені щоденний годину або два позначати перенесений документів, вони можуть використовувати "без тегів документи" Перегляд зосередити свої зусилля:

Як користувачі тег документи, вони йдуть до цього списку.

Це поняття афганця нетегованих даних також може допомогти з класу даних перевірки проблеми людей запитати про на форумах. З коробки, немає ніякого способу, щоб запобігти завантаження документа для ЛИШАЙНИКА користувача і введіть не мета-дані. Ми можна вказати, що конкретного сайту стовпця є обов'язковим, і користувач не будете мати можливість push зберегти кнопки. Однак, Якщо користувач завантажує а потім закриває браузер (або провідник windows використовує для завантаження документа), Ми не можемо змусити від користувача введення мета-дані (знову, з коробки).

Такий підхід може використовуватися з цієї ситуації. Ми можемо використовувати "погано тегами даних" Переглянути легко ідентифікувати цих документів та їх виправлення. З'єднайте це з KPI і у вас є хороша видимість на дані з деталізації керувати ці виняткові обставини.

</кінець>

Підписатися на мій блог.

На цьому тижні, Я боролася трохи з моєю командою вийти ЛИШАЙНИК, встановлені в простий два серверної ферми. Пройшовши крізь нього, Я маю велику вдячність види проблем людей доповідь на MSDN форумах і в інших місцях.

Конфігурації остаточний ферми:

• SQL, індекс, інтранет СФФБ всередині брандмауер.
• СФФБ в DMZ.
• Свого роду брандмауер між DMZ і внутрішній сервер.

Перш ніж ми почали проект, ми дозволимо клієнт знати, які порти повинні бути відкриті. Під час дати, ні взяти, вперед і назад над що, Ми ніколи не чітко сказав, що дві важливі речі:

1. SSL означає, що вам потрібен сертифікат.
2. DMZ сервера має бути членом домену.

Один день, ми показали встановити МОСС і дізнався, що облікові записи домену для бази даних та ЛИШАЙНИК не створено. Щоб рухати речі вперед, Ми пішли вперед і встановлений все з локального облікового запису на сервері інтрамережі.

На даний момент, Ми виявили, що плутанина через SSL сертифікат і, на жаль, вирішила, щоб наші інфраструктури хлопець повернутися пізніше на цьому тижні, щоб продовжити установку ДМЗ сервера. Тим часом, Ми рішення архітекторів просунулися вперед зі бізнес речі.

Вихідні йде і клієнт отримує сертифікат.

Нашу інфраструктурою хлопець показує вгору і виявляє, що ДМЗ сервер не вступив до будь-якого домену (периметр домену з обмеженого довіри або інтранет домену). Ми тільки даром майже за 1/2 день, на які. Якщо ми не дозволимо відсутній сертифікат SSL нас загрузнути, Ми б виявили це раніше. Ну що ж….

Ще один день проходить і різні комітети безпеки, зацікавлених сторін та (не так) невинних перехожих всі згоден, що це ОК, щоб приєднатися до сервера DMZ з інтрамережі домену (Це є ПСУ, Як би там не було, не виробництва рішення).

Інфраструктура хлопець приходить упаковка речей до. Цей час ми успішно пройти до сучасної рукавичку, як Ласкаво називають "Майстер конфігурації SharePoint." У нас є можливість зазирнути в центрі адміністрування та … Yee haw! … DMZ сервера зазначено у фермі. Ми виглядати трохи ближче і розумію, що ми зламав відкрити Шампейн трохи кліщ рано. WSS послуги застрягла в на "починаючи" статус.

Коротше кажучи, виходить, що ми забули, щоб змінити відомості про обліковий запис служби за допомогою Центру адміністрування оригінальний локальний обліковий запис на новий обліковий запис домену. Ми зробили, що, знову побіг майстра настроювання і вуаля! Ми були в бізнесі.

</кінець>

Підписатися на мій блог.

Хоча це не правда, буквально, в практичному плані, вікнами на Інтернет web передній край у ДМЗ має бути в домені (тобто. не якийсь автономного сервера в свій власний маленький робочої групи). Він не повинен бути в тому самому домені, що й внутрішня СФФБ(s) та інші сервери (і, ймовірно, не повинні), але вона повинна бути до домену.

Мої колеги і я витратив надмірна кількість часу на пропозиції, які включали SharePoint передумови. Це включало вичерпний перелік конфігурації брандмауера, що дозволить ДМЗ сервер приєднатися до ферми і так далі. На жаль, Ми не змогли додати десь вирок, який сказав:, Щоб ефект, "абсолютно криваві точка ця конфігурація є дозволити ДМЗ СФФБ сервера, у домені, приєднатися до внутрішніх ферми."

Ідеальний шторм події, де ми в основному подивився лівого коли ми дивилися може правильно, змову з метою приховати цю проблему у нас поки досить в кінці процесу, тим самим заважає мені пригадали мій "повідомити погані новини рано" правило.

Зітхання.

Підписатися на мій блог.