Comments 62
Если все это описание — ваш личный труд, то тут совсем недалеко до выпуска печатного издания. Браво!
Админы — счастливые люди. Им не приходится писать под этого монстра.
Меня терзают смутные сомнения, что не бывает SharePoint 2013 Server Enterprise.
Бывает Enterprise CAL и командлет New-SPUserLicenseMapping -License Enterprise
Ошибаюсь?
Бывает Enterprise CAL и командлет New-SPUserLicenseMapping -License Enterprise
Ошибаюсь?
статью ниасилил. не знаю сколько сил было потрачено чтобы это написать. но читать мега-нудно. может если б передо мной стояла задача прямо щас сесть и внедрять — была бы исчерпывающая инструкция. а для общего ознакомления дико много подробностей.
ЗЫ и да, если оно так замороченно развертывается, то оно точно нужно? я даже не знаю где мне найти время на поддержку такого монстра между протяжкой сетей, вправлением панелек в ворде и написанием скриптов для автоматизации… а, и да… ой… уже зовут вправить панельку.
ЗЗЫ автор точно не евангелист майкрософта по части sharepoint'a?
ЗЫ и да, если оно так замороченно развертывается, то оно точно нужно? я даже не знаю где мне найти время на поддержку такого монстра между протяжкой сетей, вправлением панелек в ворде и написанием скриптов для автоматизации… а, и да… ой… уже зовут вправить панельку.
ЗЗЫ автор точно не евангелист майкрософта по части sharepoint'a?
Дарю: https://onedrive.live.com/redir?resid=E74E2842A8A54DC1!39365&authkey=!ALkJSTCHgudlV6Q&ithint=folder%2cdocx
Запись с тренинга по развертыванию. Видео смело можно мотать в ускоренном режиме. Главное смотрите текстовую инструкцию.
ЗЫ. Оно еще более заморочено ставится, чем описано в статье, просто у автора избыток графомании, а по делу мало написано. Для тех кто не хочет заморачиваться есть Office 365.
ЗЗЫ. Автор точно не евангелист. МС сейчас пытается похоронить наземные версии.
Запись с тренинга по развертыванию. Видео смело можно мотать в ускоренном режиме. Главное смотрите текстовую инструкцию.
ЗЫ. Оно еще более заморочено ставится, чем описано в статье, просто у автора избыток графомании, а по делу мало написано. Для тех кто не хочет заморачиваться есть Office 365.
ЗЗЫ. Автор точно не евангелист. МС сейчас пытается похоронить наземные версии.
MS много что хочет похоронить, только заказчики не особо им потакают. А отдельные, по слухам, уже сбегали "в облако" и обратно.
А про англоязычный тренинг можете что-нибудь сказать?
Вообще, как человек, переживший внедрение и два апгрейда Sharepoint в своей компании, и пользующийся им уже почти пять лет, могу сказать следующее: это в принципе неплохая платформа разработки и CMS, но каких-либо решающих преимуществ над другими платформами у неё я не нахожу. Строго говоря, можно сделать свой корпоративный портал, организовать совместную работу и хранилище данных на куче других технологий с аналогичными затратами времени и денег. Или дешевле. И уж точно в разы производительнее на том же железе.
Вы про какие другие платформы говорите?
ВебСфера на порядок более тормознутая и дорогая. У всяких СЭД нет возможности брэндинга.
Битрикс хреново масштабируется как физически, так и в плане информационной архитектуры.
Другая система можнт обойти SharePoint только если точно попадает в потребности. Когда потребности не определены или задача очень общая (типа "сделать портал"), то ничего лучше SharePoint не придумали. И статистика это подтверждает.
ВебСфера на порядок более тормознутая и дорогая. У всяких СЭД нет возможности брэндинга.
Битрикс хреново масштабируется как физически, так и в плане информационной архитектуры.
Другая система можнт обойти SharePoint только если точно попадает в потребности. Когда потребности не определены или задача очень общая (типа "сделать портал"), то ничего лучше SharePoint не придумали. И статистика это подтверждает.
Веб-сферу вряд ли стоит рассматривать как альтернативу шарику, это больше сервер приложений, чем платформа для «портальных» решений. Если сравнивать с чем-то значительно более тормознутым и дорогим от IBM, то уж скорее с Domino. Хотя тоже, Domino — это платформа для разработки ЭДО, а возможность построить на ней корпоративный портал скорее побочная фича. В случае Sharepoint как раз наоборот получится.
> Когда потребности не определены или задача очень общая (типа «сделать портал»), то ничего лучше SharePoint не придумали.
Я целиком согласен с вами в том, что Sharepoint чаще всего применяют как раз там, где клиент не знает, что хочет, но «из коробки» получает брендированную рамку сайта, возможность в дизайнере делать странички, и сохранять контент MS Office. Но справедливости ради, возьмите обычный WordPress, обвешайте его плагинами для интеграции с AD, для работы с контентом MS Office, подключите PHP SDK для SQL Server Reporting Services, и у вас будет аналогичное решение, которое намного менее требовательно как к железу, так и к подготовке специалистов. И к тому же opensource :)
> Когда потребности не определены или задача очень общая (типа «сделать портал»), то ничего лучше SharePoint не придумали.
Я целиком согласен с вами в том, что Sharepoint чаще всего применяют как раз там, где клиент не знает, что хочет, но «из коробки» получает брендированную рамку сайта, возможность в дизайнере делать странички, и сохранять контент MS Office. Но справедливости ради, возьмите обычный WordPress, обвешайте его плагинами для интеграции с AD, для работы с контентом MS Office, подключите PHP SDK для SQL Server Reporting Services, и у вас будет аналогичное решение, которое намного менее требовательно как к железу, так и к подготовке специалистов. И к тому же opensource :)
Вордпресс подойдет для сценария "стенгазеты", когда маленькая группа редакторов и много читателей. Это опять-таки узкий сценарий. В вордпрессе нет календарей, задач и кастомных списков. В вордпрессе нет совместной работы с документами.
Кстати кроме SharePoint практически нигде нет возможностей одновременного редактирования Word документа несколькими людьми.
У меня есть система управления рисками на SharePoint. В списках хранится сложная структура бизнеса заказчика и регулярно проводятся оценки рисков по этой структуре, тоже в списках. Данные по оценкам потом собираются в отчеты. Причем сделано все исключительно средствами SharePoint, без серверного кода, только HTML+CSS+JS(TS). Причем все еще забрендено.
Подскажите на чем еще можно сделать такое же?
Кстати кроме SharePoint практически нигде нет возможностей одновременного редактирования Word документа несколькими людьми.
У меня есть система управления рисками на SharePoint. В списках хранится сложная структура бизнеса заказчика и регулярно проводятся оценки рисков по этой структуре, тоже в списках. Данные по оценкам потом собираются в отчеты. Причем сделано все исключительно средствами SharePoint, без серверного кода, только HTML+CSS+JS(TS). Причем все еще забрендено.
Подскажите на чем еще можно сделать такое же?
В том-то и дело, что в вордпрессе есть и задачи, и календари, и организация совместной работы с документами. Да, там нет возможности *одновременного* редактирования одного документа Word несколькими людьми, или по крайней мере, я об этом не знаю. Но это как раз такая задача, которая в списке киллер-фич находится на последней странице мелким шрифтом. Я в упор не могу придумать бизнес-сценарий, где было бы полезно нескольким редакторам одновременно править документ, вместо того, чтобы делать это по очереди. Какой-нибудь гипотетический большой нормативный документ, каждый раздел которого готовится разными людьми, при этом нет ссылок между разделами, и нет руководителя этого процесса, ответственного за сборку всего документа? Да ну.
> У меня есть система управления рисками на SharePoint… Причем сделано все исключительно средствами SharePoint, без серверного кода, только HTML+CSS+JS(TS)… Подскажите на чем еще можно сделать такое же?
Не совсем понял суть вопроса. Ну сделано и сделано. Систему управления рисками можно сделать на чем угодно. Я видел и на С++ под AS/400. То, что вы реализовали её именно средствами клиентского JS, это особенность архитектуры, а не преимущество. А какие преимущества?
> У меня есть система управления рисками на SharePoint… Причем сделано все исключительно средствами SharePoint, без серверного кода, только HTML+CSS+JS(TS)… Подскажите на чем еще можно сделать такое же?
Не совсем понял суть вопроса. Ну сделано и сделано. Систему управления рисками можно сделать на чем угодно. Я видел и на С++ под AS/400. То, что вы реализовали её именно средствами клиентского JS, это особенность архитектуры, а не преимущество. А какие преимущества?
Мы точно об одном вордпрессе? Или вы считаете все плагины?
Постоянно пользовались при написании документации по проектам.
Даже на wordpress?
Преимущества 0 используются только штатные компоненты. JS используется для кастомизации форм и рисования нестандартных интерфейсов. Это значит, что можно без привлечения программистов модифицировать решение.
Не уверен, что wordpress или bitrix может похвастаться такими возможностями.
Я в упор не могу придумать бизнес-сценарий, где было бы полезно нескольким редакторам одновременно править документ, вместо того, чтобы делать это по очереди.
Постоянно пользовались при написании документации по проектам.
Систему управления рисками можно сделать на чем угодно.
Даже на wordpress?
То, что вы реализовали её именно средствами клиентского JS, это особенность архитектуры, а не преимущество. А какие преимущества?Сорри, думал вы в теме.
Преимущества 0 используются только штатные компоненты. JS используется для кастомизации форм и рисования нестандартных интерфейсов. Это значит, что можно без привлечения программистов модифицировать решение.
Не уверен, что wordpress или bitrix может похвастаться такими возможностями.
> Мы точно об одном вордпрессе? Или вы считаете все плагины?
Нет, я в самом первом посте написал про использование плагинов. Нет никакого смысла придумывать искусственное ограничение про «вордпресс без плагинов», если в реальной жизни ничего не мешает их использовать, кроме желания, ну и денег.
> Постоянно пользовались при написании документации по проектам.
Ок, понял, это именно упомянутый мной сценарий. А если бы не пользовались, это как-то усложнило бы написание документации? Я в упор не вижу плюсов в том, что сидят два человека и правят один и тот же документ. Я только минусы вижу — они могут внести несогласованные между собой правки.
> Сорри, думал вы в теме.
Я в теме, потому и попросил более развернутого ответа.
> Преимущества 0 используются только штатные компоненты.
Согласен, это преимущество.
> JS используется для кастомизации форм и рисования нестандартных интерфейсов. Это значит, что можно без привлечения программистов модифицировать решение.
Не согласен, т.к. без привлечения программистов вы не сможете кастомизировать формы и рисовать нестандартные интерфейсы. Вы же программистов JS, надеюсь, всё-таки считаете программистами? ;)
А еще есть другой немаловажный момент: чтобы спроектировать и настроить всю эту структуру на списках Sharepoint, нужен все равно профильный специалист, и в итоге совершенно не принципиально, будет ли он администратором Sharepoint, или в случае другой платформы — разработчиком WordPress, или там программистом ASP.NET MVC. Не будет за вас бизнес-аналитик или тем более риск-менеджер сидеть и кастомизировать Sharepoint под свои потребности. Поэтому я и говорю, что эффективность решения для оценки надо приводить к более осязаемым «попугаям» — деньгам, человеко-часам и т.д.
Нет, я в самом первом посте написал про использование плагинов. Нет никакого смысла придумывать искусственное ограничение про «вордпресс без плагинов», если в реальной жизни ничего не мешает их использовать, кроме желания, ну и денег.
> Постоянно пользовались при написании документации по проектам.
Ок, понял, это именно упомянутый мной сценарий. А если бы не пользовались, это как-то усложнило бы написание документации? Я в упор не вижу плюсов в том, что сидят два человека и правят один и тот же документ. Я только минусы вижу — они могут внести несогласованные между собой правки.
> Сорри, думал вы в теме.
Я в теме, потому и попросил более развернутого ответа.
> Преимущества 0 используются только штатные компоненты.
Согласен, это преимущество.
> JS используется для кастомизации форм и рисования нестандартных интерфейсов. Это значит, что можно без привлечения программистов модифицировать решение.
Не согласен, т.к. без привлечения программистов вы не сможете кастомизировать формы и рисовать нестандартные интерфейсы. Вы же программистов JS, надеюсь, всё-таки считаете программистами? ;)
А еще есть другой немаловажный момент: чтобы спроектировать и настроить всю эту структуру на списках Sharepoint, нужен все равно профильный специалист, и в итоге совершенно не принципиально, будет ли он администратором Sharepoint, или в случае другой платформы — разработчиком WordPress, или там программистом ASP.NET MVC. Не будет за вас бизнес-аналитик или тем более риск-менеджер сидеть и кастомизировать Sharepoint под свои потребности. Поэтому я и говорю, что эффективность решения для оценки надо приводить к более осязаемым «попугаям» — деньгам, человеко-часам и т.д.
Не согласен, т.к. без привлечения программистов вы не сможете кастомизировать формы и рисовать нестандартные интерфейсы.Зато все остальное можно делать — расширять схему, менять модель расчетов, добавлять логику.
Еще один немаловажный аспект clinet-side-only разработки — ошибка в коде\настройке не валит весь портал.
Не будет за вас бизнес-аналитик или тем более риск-менеджер сидеть и кастомизировать Sharepoint под свои потребности.За нас не будет. Но для себя — вполне. Видел десятки решений, когда сами специалисты структурировали и даже автоматизировали работу.
> Зато все остальное можно делать — расширять схему, менять модель расчетов, добавлять логику.
И это без программистов нельзя делать. Даже банально для настройки вычисляемых столбцов в списке нужны навыки программирования. Вы просто предполагаете, что пользователи вашей системы должны быть и программистами одновременно, хотя бы на уровне скриптовых языков. Упомянутый выше WordPress, если уж на то пошло, также предполагает кастомизацию в визуальных дизайнерах, без погружения в код.
> Еще один немаловажный аспект clinet-side-only разработки — ошибка в коде\настройке не валит весь портал.
Да, только это, скажем так, аспект client-side-only разработки под Sharepoint. Борьба с его фирменной болячкой.
> За нас не будет. Но для себя — вполне. Видел десятки решений, когда сами специалисты структурировали и даже автоматизировали работу.
Конечно же, такое бывает. Риск-менеджер тоже может быть программистом. Он может уметь писать макросы VBA, уметь… да всё, что угодно, уметь. Это хорошо и продуктивно. Но одно дело, когда специалист настраивает под себя свое рабочее окружение, другое — когда он лезет в правила работы корпоративной информационной системы. Это неправильно. В таких случаях должен быть администратор, который за неё отвечает, и в случае шарепойнта настраивает столбцы, вычисления, отчеты и т.д. Если в вашей системе кто-то из пользователей поломает формулу расчета скоринга, кто будет отвечать за это?
И это без программистов нельзя делать. Даже банально для настройки вычисляемых столбцов в списке нужны навыки программирования. Вы просто предполагаете, что пользователи вашей системы должны быть и программистами одновременно, хотя бы на уровне скриптовых языков. Упомянутый выше WordPress, если уж на то пошло, также предполагает кастомизацию в визуальных дизайнерах, без погружения в код.
> Еще один немаловажный аспект clinet-side-only разработки — ошибка в коде\настройке не валит весь портал.
Да, только это, скажем так, аспект client-side-only разработки под Sharepoint. Борьба с его фирменной болячкой.
> За нас не будет. Но для себя — вполне. Видел десятки решений, когда сами специалисты структурировали и даже автоматизировали работу.
Конечно же, такое бывает. Риск-менеджер тоже может быть программистом. Он может уметь писать макросы VBA, уметь… да всё, что угодно, уметь. Это хорошо и продуктивно. Но одно дело, когда специалист настраивает под себя свое рабочее окружение, другое — когда он лезет в правила работы корпоративной информационной системы. Это неправильно. В таких случаях должен быть администратор, который за неё отвечает, и в случае шарепойнта настраивает столбцы, вычисления, отчеты и т.д. Если в вашей системе кто-то из пользователей поломает формулу расчета скоринга, кто будет отвечать за это?
Даже банально для настройки вычисляемых столбцов в списке нужны навыки программирования.нужны навыки экселя, программирования там нет.
Да, только это, скажем так, аспект client-side-only разработки под Sharepoint. Борьба с его фирменной болячкойКак раз в SharePoint эта проблема не так часто проявляется, как в других «портальных» решениях.
Если в вашей системе кто-то из пользователей поломает формулу расчета скоринга, кто будет отвечать за это?Это очень поверхностный взгляд на вещи.
1) Важно не «кто виноват», а кто сможет внести изменения. Заказчик не хочет получить vendor-lock, поэтому скрипты и формулы в Excel для него на два порядка выгоднее, чем серверный код, подписанный ключом.
2) Клиентский код в SharePoint гарантированно ограничивает «площадь поражения». Заказчику выгодна высокая устойчивость инфраструктуры.
3) Клиентский код банально быстрее можно поменять и меньше проблем с деплоем. Это выгодно и разработчику и заказчику.
Так что все в плюсе, даже если заказчик никогда не будет трогать это решение. Хотя по факту заказчик добавлял столбцы и делал логику, там где надо.
> нужны навыки экселя, программирования там нет.
Я не знаю, что конкретно представляет собой ваше решение по управлению рисками. Но в общем случае навыками экселя там не обойтись. Формулы скоринга достаточно громоздкие, и хотя набор действий ограничивается обычно простой арифметикой, количество условий предполагает, что человек, который это настраивает, программист.
> Заказчик не хочет получить vendor-lock, поэтому скрипты и формулы в Excel для него на два порядка выгоднее, чем серверный код, подписанный ключом.
Опять же таки, как и в случае с client-side, не используйте Sharepoint, сделайте опенсурсное решение, и проблема vendor-lock отпадет как класс.
> Клиентский код в SharePoint гарантированно ограничивает «площадь поражения». Заказчику выгодна высокая устойчивость инфраструктуры.
В какой-то мере да, но вы не сможете это продать заказчику как конкурентное преимущество. По крайней мере, среди таких вещей, как общая производительность, продуктивность и т.д., эта архитектурная фича совершенно не принципиальна.
> Клиентский код банально быстрее можно поменять и меньше проблем с деплоем. Это выгодно и разработчику и заказчику.
И здесь речь идет про Sharepoint. В общем случае это далеко не всегда так.
А еще далеко не последнюю роль играет безопасность. Если у вас правила валидации данных висят только на клиенте (а при подобной архитектуре наверняка так и есть), то и при ошибках в скриптах, и при шаловливых ручках пользователей есть возможность хорошо испортить данные.
Я не знаю, что конкретно представляет собой ваше решение по управлению рисками. Но в общем случае навыками экселя там не обойтись. Формулы скоринга достаточно громоздкие, и хотя набор действий ограничивается обычно простой арифметикой, количество условий предполагает, что человек, который это настраивает, программист.
> Заказчик не хочет получить vendor-lock, поэтому скрипты и формулы в Excel для него на два порядка выгоднее, чем серверный код, подписанный ключом.
Опять же таки, как и в случае с client-side, не используйте Sharepoint, сделайте опенсурсное решение, и проблема vendor-lock отпадет как класс.
> Клиентский код в SharePoint гарантированно ограничивает «площадь поражения». Заказчику выгодна высокая устойчивость инфраструктуры.
В какой-то мере да, но вы не сможете это продать заказчику как конкурентное преимущество. По крайней мере, среди таких вещей, как общая производительность, продуктивность и т.д., эта архитектурная фича совершенно не принципиальна.
> Клиентский код банально быстрее можно поменять и меньше проблем с деплоем. Это выгодно и разработчику и заказчику.
И здесь речь идет про Sharepoint. В общем случае это далеко не всегда так.
А еще далеко не последнюю роль играет безопасность. Если у вас правила валидации данных висят только на клиенте (а при подобной архитектуре наверняка так и есть), то и при ошибках в скриптах, и при шаловливых ручках пользователей есть возможность хорошо испортить данные.
Но в общем случае навыками экселя там не обойтись.
Excel + PowerPivot, формулы на языке DAX. При желании освоить можно за несколько дней. Это на несколько порядков проще, чем разобраться в коде на C#.
Опять же таки, как и в случае с client-side, не используйте Sharepoint, сделайте опенсурсное решение, и проблема vendor-lock отпадет как класс.А зачем повторять функционал, который уже есть в SharePoint? Там уже используются версии, согласования, представления, часть логики реализовано в Workflow. Надо это все повторить в своем решении? Использовать SharePoint выходит дешевле.
В какой-то мере да, но вы не сможете это продать заказчику как конкурентное преимуществоИменно это и продаю. Продается очень хорошо. У крупных компаний SharePoint уже есть. А вот поднять новые серверы и кастомное рещение может быть проблематично.
И здесь речь идет про Sharepoint. В общем случае это далеко не всегда так.О каком «общем случае» идет речь? Разработка с нуля? Какой в ней смысл, когда SharePoint уже имеет нужный функционал?
Если у вас правила валидации данных висят только на клиенте (а при подобной архитектуре наверняка так и есть), то и при ошибках в скриптах, и при шаловливых ручках пользователей есть возможность хорошо испортить данные.Доступ ограничен правами SharePoint, для сложных форм обработка делается в Workflow. Залить невалидные данные невозможно, поправить валидные — тоже. Кроме того в SharePoint отслеживается кто внес изменения, есть логи аудита. Если кто-то решит «пошалить» — быстро лишится работы.
Atlassian Confluence, вместо Project Server — JIRA.
Обойдётся ощутимо дешевле, а при правильном подборе плагинов/модов способна заменить часть функционала — самую часто используемую часть.
Обойдётся ощутимо дешевле, а при правильном подборе плагинов/модов способна заменить часть функционала — самую часто используемую часть.
Если в компании меньше 250 человек, то выгодно покупать Office 365. Комплект Business Essentials, который включает в себя SharePoint Online + Exchange Online + Lync + Yammer + Delve + Office Online обойдется примерно в 400 рублей на пользователя в месяц, Project Lite добавить к ним — еще 400. То есть около $10 в месяц.
Jira+Confluence в облаке на 100 человек получится $750 в месяц, то есть $7,5. Но для честного сравения надо еще добавить Jira Core, чтобы приблизиться к функционалу шарика. Получится $1050 в месяц. Те же деньги, а функционала не больше.
Для компаний от 250 человек выгодно покупать EA\EAS. В EAS входят виндовс, офис, Windows Server CAL, Exchange CAL, SharePoint CAL, Lync CAL и еще чето-там.
Поэтому для крупных компаний для развертывания SharePoint надо заплатить только за серверы. Сервер SharePoint стоит примерно 100к рублей по EA, SQL Std Core — 250к. Итого 350к — 1М рублей в зависимости от количества серверов.
Jira+Confluence серверный вариант стоит $30к долларов, что сильно больше 1М рублей.
Jira+Confluence может оказаться выгоднее только если отказаться от всей MS-инфраструктуры. Ни одна крупная компания на это не пойдет.
Jira+Confluence в облаке на 100 человек получится $750 в месяц, то есть $7,5. Но для честного сравения надо еще добавить Jira Core, чтобы приблизиться к функционалу шарика. Получится $1050 в месяц. Те же деньги, а функционала не больше.
Для компаний от 250 человек выгодно покупать EA\EAS. В EAS входят виндовс, офис, Windows Server CAL, Exchange CAL, SharePoint CAL, Lync CAL и еще чето-там.
Поэтому для крупных компаний для развертывания SharePoint надо заплатить только за серверы. Сервер SharePoint стоит примерно 100к рублей по EA, SQL Std Core — 250к. Итого 350к — 1М рублей в зависимости от количества серверов.
Jira+Confluence серверный вариант стоит $30к долларов, что сильно больше 1М рублей.
Jira+Confluence может оказаться выгоднее только если отказаться от всей MS-инфраструктуры. Ни одна крупная компания на это не пойдет.
Шикарная статья.
С одной стороны разжёваны все аспекты, с чувством, с ритмом, с расстановкой.
С другой, достаточно академический тон освежается лирическими вставками.
С одной стороны разжёваны все аспекты, с чувством, с ритмом, с расстановкой.
С другой, достаточно академический тон освежается лирическими вставками.
Не обольщайтесь, далеко не все аспекты разжеваны. Это иллюзия объема. Если написано много, кажется что написано все.
Например пропущена немаловажная часть — патчинг и настройка Distributed Cache, без которого все будет тормозить.
Ничего нет про настройки веб-приложений, Host-Named Site Collections и DNS.
Ничего нет про поиск и профили, без них взрослый шарик превращается в Foundation.
Ничего нет про конфигурацию SQL, а это 90% быстродействия шарика.
Вообще ставить шарик лучше с помощью AutoSPInsaller, он содержит фиксы и воркэраунды примерно для 150 проблем, руками сделать все не получится, замучаться можно.
Например пропущена немаловажная часть — патчинг и настройка Distributed Cache, без которого все будет тормозить.
Ничего нет про настройки веб-приложений, Host-Named Site Collections и DNS.
Ничего нет про поиск и профили, без них взрослый шарик превращается в Foundation.
Ничего нет про конфигурацию SQL, а это 90% быстродействия шарика.
Вообще ставить шарик лучше с помощью AutoSPInsaller, он содержит фиксы и воркэраунды примерно для 150 проблем, руками сделать все не получится, замучаться можно.
Написано много, потому мало кто дочитал до конца.
Все эти вещи вынесены в следующие главы...
Все эти вещи вынесены в следующие главы...
В какие следующие главы? Все, что я описал выше, надо проделать еще до создания первого сайта.
Ок, разберем по пунктам.
- Distributed Cache — настраивается уже пофилиально, ПОСЛЕ их интеграции в ферму. В статье предполагается, что новичок только поднял ферму. Он еще даже не настраивал PeoplePicker, т.е. пока невозможно прописать даже права для других лесов/доменов. О чем речь?
- Настройки веб-приложений, Host-Named Site Collections и DNS поверхностно обсуждаются в Главах 2 и 3 и, планировалось, что будут расспотрены в главах 8 и 10.
- Поиск (строго ИМХО) для новичка есть смысл прикручивать, когда в ферме есть хоть какой-то контент, иначе ЧТО искать для теста? Краулер потом можно в любой момент запустить руками, на качестве поиска это никак не отразится. Потому и приберег для главы 8. Профили — туда же, см. п.1. Великолепно накручиваются хоть через месяц после деплоя, когда приходит понимание, зачем они собственно нужны.
- Статья писалась не как вольный пересказ 331-го курса, а по принципу от простого к сложному, с промежуточными «успехами». Новичкам легче сперва поставить в минимальной комплектации, получить результат вместе с позитивом («я это сделал!») и потом докручивать плюшки. А не как в оффкурсах — сначала забивать пару суток теорией и потом пытаться что-то по-быстрому поднять на лабе.
- Аналогично, будущая (если уже будет) глава 10. Насчет всегда ли «сиквелл» — узкое место для любых кейсов, я бы поспорил.
Distributed Cache — настраивается уже пофилиальноБред какой-то, вы в курсе что такое DC и как он используется в шарике?
Настройки веб-приложений, Host-Named Site Collections и DNS поверхностно обсуждаются в Главах 2 и 3 и, планировалось, что будут расспотрены в главах 8 и 10.То есть сейчас кто-нибудь пойдет и создат по вашей статье несколько веб-приложений, а вы потом предложите мигрировать в HNSC?
Поиск (строго ИМХО) для новичка есть смысл прикручивать, когда в ферме есть хоть какой-то контент, иначе ЧТО искать для теста?Профили, файловые шары. А еще на поиске работают социальные фичи, docid и cross-site publishing.
Статья писалась не как вольный пересказ 331-го курса, а по принципу от простого к сложному
Скорее похоже от банального к бесполезному. Реально похоже на пересказ примитивного гайда, разбавленный графоманией.
Насчет всегда ли «сиквелл» — узкое место для любых кейсов, я бы поспорил.«Узкое место» это когда мы говорим о пропускной способности. Сейчас мы говорим о скорости работы, а она сильно зависит от скорости SQL Server.
Не нашел ваших публикаций на эти темы.
Кстати при попытке правки статьи (нужно поменять местами ошибочно размещенные пару иллюстраций с хабрастореджа) происходит падение окна Google Chrome при нажатии Ctrl+V:
Добрый день, AllanStark!
Я из MS. Мои коллеги очень впечатлены вашим постом и хотели бы с вами связаться)
Подскажите, пожалуйста, как можно это сделать?
Спасибо!
Я из MS. Мои коллеги очень впечатлены вашим постом и хотели бы с вами связаться)
Подскажите, пожалуйста, как можно это сделать?
Спасибо!
Стоит ли написать именно о практическом применение шарика? Списки, библиотеки, Workflow, автоматизация процессов. В виде кейсов, может.
Например, недавно запустили процесс управления актами о браке на производстве. Большой Workflow, задействующий много подразделений — создание акта контролерами, принятие решения руководителем отдела качества, согласование с Техотделом, определение причин/виновных/корректирующих действий ответственным подразделением/цехом, калькуляция затрат нормировщиком экономического отдела, решение по отнесению затрат главным инженером, автоматическое создание претензий по актам входного контроля и дальнейший контроль результатов обработки претензий. Прозрачно, оперативно, измеряемо, контролируемо. Плюс реальная оптимизация физических процессов посредством удаления всех сомнительных действий и сущностей. )
Или процесс планирования и управления платежами. План платежей по статьям, месяцам, создаваемый бюджетодержателями. Платежные документы, загружаемые инициаторами, согласование, проверка и сопоставление с планом экономическим отделом, согласование генеральным директором, исполнение бухгалтерией. Можно выгружать платежки в 1С, создавая отсутствующих контрагентов. Прозрачно, оперативно, измеряемо, контролируемо — посмотрел в плане платежей, что денег осталось в этом месяце по статье "расходные материалы" еще на пять лампочек, запросил счет у поставщика, получил его по электронной почте, загрузил в систему и сиди жди уведомления по той же почте об исполнении.
Или там всякие примитивные процессы по регистрации входящих и исходящих документов, рассмотрения, служебные записки, резолюции, предписания, исполнения, регистрация и контроль доверенностей. Или договоры — совместная работа, обсуждение, согласование частично последовательное, частично параллельное, архив.
Или различные заявки/запросы в отдел ИТ, в электро-механических цех, учет оборудования и контроль работ, перемещения, замены расходных материалов.
Например, недавно запустили процесс управления актами о браке на производстве. Большой Workflow, задействующий много подразделений — создание акта контролерами, принятие решения руководителем отдела качества, согласование с Техотделом, определение причин/виновных/корректирующих действий ответственным подразделением/цехом, калькуляция затрат нормировщиком экономического отдела, решение по отнесению затрат главным инженером, автоматическое создание претензий по актам входного контроля и дальнейший контроль результатов обработки претензий. Прозрачно, оперативно, измеряемо, контролируемо. Плюс реальная оптимизация физических процессов посредством удаления всех сомнительных действий и сущностей. )
Или процесс планирования и управления платежами. План платежей по статьям, месяцам, создаваемый бюджетодержателями. Платежные документы, загружаемые инициаторами, согласование, проверка и сопоставление с планом экономическим отделом, согласование генеральным директором, исполнение бухгалтерией. Можно выгружать платежки в 1С, создавая отсутствующих контрагентов. Прозрачно, оперативно, измеряемо, контролируемо — посмотрел в плане платежей, что денег осталось в этом месяце по статье "расходные материалы" еще на пять лампочек, запросил счет у поставщика, получил его по электронной почте, загрузил в систему и сиди жди уведомления по той же почте об исполнении.
Или там всякие примитивные процессы по регистрации входящих и исходящих документов, рассмотрения, служебные записки, резолюции, предписания, исполнения, регистрация и контроль доверенностей. Или договоры — совместная работа, обсуждение, согласование частично последовательное, частично параллельное, архив.
Или различные заявки/запросы в отдел ИТ, в электро-механических цех, учет оборудования и контроль работ, перемещения, замены расходных материалов.
Красивый site workwlows.
Жаль, что из коробки подобные вещи без дополнительного украшательства интерфейсов и форм (доп. программинг и дезигнерство) будут практически неюзабельны…
Новичку бы простейшее что-то показать, как рассылка документов приказов автоматом по группам при помещении нового дока в библиотеку отработает. Да как воркфло в дезигнере удобнее править.
А Вы сразу красивые схемы рисуете, с кучей ветвителей и циклов...
Жаль, что из коробки подобные вещи без дополнительного украшательства интерфейсов и форм (доп. программинг и дезигнерство) будут практически неюзабельны…
Новичку бы простейшее что-то показать, как рассылка документов приказов автоматом по группам при помещении нового дока в библиотеку отработает. Да как воркфло в дезигнере удобнее править.
А Вы сразу красивые схемы рисуете, с кучей ветвителей и циклов...
Если есть хорошие кейсы — обязательно пишите.
Очень вовремя. Наша кампания хардкорно внедряет SP силами внутренней ИТ службы, вы нам много человеко-часов сберегли, спасибо!
Автор, снимаю перед вам шляпу за топик и жду остальные части!
Спасибо за статью, возможно будет полезно добавить про изменение архитектуры в SharePoint 2016:
http://itband.ru/2016/01/sharepoint-server-2016-new/
Ведь начинающий внедренец скорее всего выберет именно его, а старый и кривой 2013-й.
http://itband.ru/2016/01/sharepoint-server-2016-new/
Ведь начинающий внедренец скорее всего выберет именно его, а старый и кривой 2013-й.
Автор, а будет ли топик о том что стало круче/легче/быстрее/облачнее в SP 2016 ??
Уже который день зачитываю данный труд… Многое разжевано довольно хорошо, отдельное спасибо за лирические бонусы. По моему мнению упущен момент установки и настройки IIS. По умолчанию он не ставится с Windows server и стандартная установка его не подходит как я понимаю для SP. Нужно либо тупо (это не про меня) ставить всё, либо выбрать нужные компоненты.
Огромное спасибо! А планируется продолжение?!
Большое спасибо за статью.
Подскажите когда можно ожидать продолжение, о котором шла речь в самом конце (главы с 6 по 13)?
Подскажите когда можно ожидать продолжение, о котором шла речь в самом конце (главы с 6 по 13)?
Про SharePoint прочитал по диагонали — пробую понять, нужен ли он нам, но бонусная лирика прекрасна и заслуживает отдельной публикации. Почему-то вспомнил Юрия Бригадира после прочтения.
Случайно попал на статью. Меня больше интересует источник лирики. Дайте произведение пожалуйста.
Sign up to leave a comment.
Баллада о SharePoint