Windows sharepoint services как удалить

Обновлено: 07.07.2024

Недавно мне пришлось обновлять WSS 3.0 на Sharepoint Foundation 2010. Хочу поделится опытом, а также рассказать о проблемах, которые Microsoft «прячет» от нас.
Предисловие:
Windows Sharepoint Services был установлен как Stand-alone сервер, использует Windows Internal Database Engine. Хочу обновить ферму до Sharepoint 2010 Foundation. Остальное — под катом. Кому интересна финальная рабочая процедура – в нижнюю часть статьи.

Microsoft приводит полное (как сперва кажется) руководство к данной процедуре тут.

Вкратце, Microsoft предлагает следующую процедуру:
1) С диска/дистрибутива Sharepoint 2010 Foundation устанавливаем все необходимое ПО (prerequisites)
2) Устанавливаем Sharepoint 2010 Foundation
3) После установки выбираем обновление существующей фермы WSS 3.0
4) Готово.
Жаль, но все оказывается не так просто.

В описании поддерживаемых/неподдерживаемых путей обновления сказано, что Sharepoint 2010 Foundation НЕ поддерживает Windows Internal Database Engine. Тогда первое, что приходит мне в голову: установить на сервер SQL Server Express 2008 и при обновлении указать его.
ВНИМАНИЕ! SQL-сервер должен быть обязательно x64 архитектуры, на x32 инсталлятор Foundation базы разворачивать отказывается.

Собственно я так и поступаю, но, оказывается, при обновлении НЕВОЗМОЖНО изменить SQL-сервер. В окне обновления Sharepoint 2010 выбран сервер Windows Internal Database, инсталлятор успешно начинает обновление и выпадает в ошибку о том, что ему не хватает прав на SQL-сервере. Что ж, странно…

При этом инсталлятор «убивает» ферму WSS 3.0. Дальнейшие действия, как с помощью портала администрирования, так и с помощью утилиты stsadm, абсолютно невоможны.

Как восстановить работоспособность WSS 3.0? Я решил восстановить WSS 3.0 сразу на SQL-сервер, чтобы попробовать In-Place Upgrade еще раз:
1) С помощью оснастки SQL Server Management Studio подключаемся к Windows Internal Database и делаем бекап баз SharePoint_Config и SharePoint_AdminContent_xxxx-xxxx-xxxx-xxxx-xxxxxxxxx (именно эти 2 базы WSS использует для хранения настроек). Базу данных с содержимым (название WSS_Content по-умолчанию) я просто отсоединяю (detach).
2) Далее я переустанавливаю WSS (удаляю, ставлю заново, ставлю все Service Pack). В процессе установки указываю инстанс SQL-сервера (в расширенном режиме), а не Windows Internal Database.
3) После завершения установки и обновления я останавливаю службы WSS 3.0, подключаюсь SSMS к SQL-инстансу и наблюдаю там 2 базы: новую SharePoint_Config и SharePoint_AdminContent… Они мне не нужны, поэтому смело их удаляю и разворачиваю бекапы этих баз на SQL-инстанс (в моем случае SQL Server Express 2008 R2).
4) Стартую службы WSS. При этом WSS отлично работает, как раньше.

Кажется вот оно – можно обновляться, теперь проблем не будет, все же ведь на SQL-сервере. Я еще раз запускаю Мастер обновления WSS -> Sharepoint 2010. И, о чудо, теперь в окне визарда указан SQL-инстанс. Нажимаю «Next» и… опять ругается на недостаток прав на инстансе Windows Internal Database. «Как?!» — думаю я. Значит, помимо всего, WSS хранит имя сервера/инстанс где-то в базе.

Через несколько запросов я нашел таблицу и строки, где это хранится: база SharePoint_Config, таблица dbo.Objects.
Следующим запросом мы можем изменить эти данные:
USE [SharePoint_Config]
ALTER TABLE dbo.Objects
SET Name=’NEW INSTANCE NAME’
WHERE Name=’OLD INSTANCE NAME’
SET Name=’NEW SERVER NAME’
WHERE Name = ‘OLD SERVER NAME’

Повторно запускаю визард обновления. И, ура, первый шаг успешно проходит без ошибок, связанных с базой. Но, к сожалению, на втором этапе я получаю ошибку ERR Exception: System.ArgumentException: Error during encryption or decryption.
Решения, приведенные в этом KB от Microsoft не помогают. Варианты, которые я нашел в Интернете (удалить Administration Portal узел в IIS, удалить App Pool в IIS) не помогают.
Я принимаю решение развернуть все заново, методом детача баз, а не In-Place Upgrade.

Для этого я снова восстанавливаю WSS-сервер по описанной выше процедуре и:
1) Сохраняю все настройки сайтов Sharepoint (в моем случае это 1 сайт site).
2) Теперь я удаляю WSS и ставлю «чистый» его вариант (только шаги 1 и 2 вышеописанной процедуры).
3) Удаляю SharePoint 2010 Foundation
4) Делаю ребут
5) Заново устанавливаю SharePoint 2010 Foundation в Stand-alone режиме. Инсталлятор после завершения установки предлагает мне обновить существующую («чистую») ферму WSS – соглашаюсь. На этот раз обновление происходит без проблем.
6) В центре администрирования SharePoint 2010 Foundation создаю сайт с настройками, которые я записал в п.1. Прошу визард использовать существующий IIS-узел Site (который был создан в WSS). В качестве БД содержимого указываю новую БД на SQL-инстансе (WSS_Content_Temp), которую я потом удалю.
7) Присоединяю (attach) базу WSS_Content к SQL-серверу.
8) По данному мануалу обновляю и присоединяю базу с содержимым к SharePoint 2010 Foundation командой:
cd “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Bin”
stsadm –o addcontentdb –url site –databasename WSS_Content –databaseserver NEWSERVER\NEWINSTANCE
9) Проходит процесс обновления. После него удаляю базу WSS_Content_Temp из узла в центре администрирования SharePoint.
10) Вуа-ля.

В общем и целом мне неясно 2 вещи: почему инсталлятор не проверяет необходимые требования и выдает абсолютно не соответствующие действительности ошибки? Но это скорей риторический вопрос…

Так случилось, что ранее действующий SharePoint Server 2010, стал неким препятствием для другой действующей платформы (установленной на этом же сервере параллельно). Пришлось его удалить.

Вариант безболезненного удаления описан здесь:

но, как обычно, что-то пошло не так, в процессе удаления инсталятор вывалился с ошибкой и более не заработал, соответственно сервер корректно не удалился и далее никакие штатные варианты удаления не помогли.

Соответственно далее потребовалось хирургическое вмешательство в процесс:

1

2

C:\Program Files\Common Files\Microsoft Shared\Web Server Extension\14

3

Но это еще не все, здесь требуется удалить так называемый Instance on a SQL Server, иначе журнал будет полон ошибок сообщающих нам о том, что связка приложение-база SharePoint нарушено.

Варианты удаления, можно посмотреть здесь:

Если Instance удален успешно (в моем случае удалился без проблем и с первого раза), снова перезагружаем сервер.

На этом удаление SharePoint Server закончено, более нет никаких препятствий для действующей платформы и ошибок в журналах Windows, что непременно радует.

P.S. В завершении можно пройтись, например, каким-нибудь CCleaner (или альтернативной утилитой) по реестру и удалить все ключи связанные с теперь уже бывшим сервером SharePoint, действие не обязательно, но для частоты эксперимента полезно.

Всем хорошей работы .

Share this:

Понравилось это:

Sorry, the comment form is closed at this time.

О сайте

В этом блоге, я пишу заметки о своей, как повседневной жизни, так и жизни и работе в сфере IT технологий. Собираю интересные ссылки, выражаю свои мысли и прочее… В основном посты посвящены, Управленческим моментам и решениям, различным продуктам Microsoft и VMWare, которые я эксплуатирую многие годы, Nix, MacOS, сетке, и другим интересным вопросам и задачам, с которыми приходится ежедневно сталкиваться и иметь дело. Здесь приведены не только мои посты, но и посты, которые были найдены мною на безграничных просторах интернета. Все написанное здесь, было проделано мною или моими коллегами при моем непосредственном участии на виртуальных машинах или в продакшин среде, о чем свидетельствуют комментарии в текстах. Всем удачи в работе.

SharePoint.exe это исполняемый файл, который является частью Microsoft Team Foundation Server 2010 - ENU Программа, разработанная Корпорация Microsoft, Программное обеспечение обычно о 63.03 MB по размеру.

Расширение .exe имени файла отображает исполняемый файл. В некоторых случаях исполняемые файлы могут повредить ваш компьютер. Пожалуйста, прочитайте следующее, чтобы решить для себя, является ли SharePoint.exe Файл на вашем компьютере - это вирус или троянский конь, который вы должны удалить, или это действительный файл операционной системы Windows или надежное приложение.

Является ли SharePoint.exe вирусом или вредоносным ПО?

SharePoint.exe безопасен, или это вирус или вредоносная программа?

Первое, что поможет вам определить, является ли тот или иной файл законным процессом Windows или вирусом, это местоположение самого исполняемого файла. Например, такой процесс, как SharePoint.exe, должен запускаться из, а не из другого места.

Для подтверждения откройте диспетчер задач, выберите «Просмотр» -> «Выбрать столбцы» и выберите «Имя пути к изображению», чтобы добавить столбец местоположения в диспетчер задач. Если вы обнаружите здесь подозрительный каталог, возможно, стоит дополнительно изучить этот процесс.

Еще один инструмент, который иногда может помочь вам обнаружить плохие процессы, - это Microsoft Process Explorer. Запустите программу (не требует установки) и активируйте «Проверить легенды» в разделе «Параметры». Теперь перейдите в View -> Select Columns и добавьте «Verified Signer» в качестве одного из столбцов.

Если статус процесса «Проверенная подписывающая сторона» указан как «Невозможно проверить», вам следует взглянуть на процесс. Не все хорошие процессы Windows имеют метку проверенной подписи, но ни один из плохих.

Наиболее важные факты о SharePoint.exe:

Если у вас возникли какие-либо трудности с этим исполняемым файлом, перед удалением SharePoint.exe необходимо определить, заслуживает ли он доверия. Для этого найдите этот процесс в диспетчере задач.

Найдите его местоположение (оно должно быть в C: \ Program Files \ Microsoft Team Foundation Server 2010 \) и сравните размер и т. Д. С приведенными выше фактами.

Кроме того, функциональность вируса может сама влиять на удаление SharePoint.exe. В этом случае вы должны включить Безопасный режим с поддержкой сети - безопасная среда, которая отключает большинство процессов и загружает только самые необходимые службы и драйверы. Когда вы можете запустить программу безопасности и полный анализ системы.

Могу ли я удалить или удалить SharePoint.exe?

Не следует удалять безопасный исполняемый файл без уважительной причины, так как это может повлиять на производительность любых связанных программ, использующих этот файл. Не забывайте регулярно обновлять программное обеспечение и программы, чтобы избежать будущих проблем, вызванных поврежденными файлами. Что касается проблем с функциональностью программного обеспечения, проверяйте обновления драйверов и программного обеспечения чаще, чтобы избежать или вообще не возникало таких проблем.

Согласно различным источникам онлайн, 4% людей удаляют этот файл, поэтому он может быть безвредным, но рекомендуется проверить надежность этого исполняемого файла самостоятельно, чтобы определить, является ли он безопасным или вирусом. Лучшая диагностика для этих подозрительных файлов - полный системный анализ с Reimage, Если файл классифицируется как вредоносный, эти приложения также удаляют SharePoint.exe и избавляются от связанных вредоносных программ.

Однако, если это не вирус, и вам нужно удалить SharePoint.exe, вы можете удалить Microsoft Team Foundation Server 2010 - ENU со своего компьютера, используя программу удаления, которая должна находиться по адресу: C: \ Program Files \ Microsoft Team Foundation Сервер 2010 \ Microsoft Team Foundation Server Сервер 2010 - ENU \ setup.exe. Если вы не можете найти его деинсталлятор, вам может потребоваться удалить Microsoft Team Foundation Server 2010 - ENU, чтобы полностью удалить SharePoint.exe. Вы можете использовать функцию «Установка и удаление программ» на панели управления Windows.

  • 1. в Меню Пуск (для Windows 8 щелкните правой кнопкой мыши в нижнем левом углу экрана), нажмите Панель управления, а затем под Программы:
    o Windows Vista / 7 / 8.1 / 10: нажмите Удаление программы.
    o Windows XP: нажмите Установка и удаление программ.
  • 2. Когда вы найдете программу Microsoft Team Foundation Server 2010 - ENUщелкните по нему, а затем:
    o Windows Vista / 7 / 8.1 / 10: нажмите Удалить.
    o Windows XP: нажмите Удалить or Изменить / Удалить вкладка (справа от программы).
  • 3. Следуйте инструкциям по удалению Microsoft Team Foundation Server 2010 - ENU.

Наиболее распространенные ошибки SharePoint.exe, которые могут возникнуть:


• «Ошибка приложения SharePoint.exe».
• «Ошибка SharePoint.exe».
• «SharePoint.exe столкнулся с проблемой и должен быть закрыт. Приносим извинения за неудобства».
• «SharePoint.exe не является допустимым приложением Win32».
• «SharePoint.exe не запущен».
• «SharePoint.exe не найден».
• «Не удается найти SharePoint.exe».
• «Ошибка запуска программы: SharePoint.exe».
• «Неверный путь к приложению: SharePoint.exe».

Аккуратный и опрятный компьютер - это один из лучших способов избежать проблем с Microsoft Team Foundation Server 2010 - ENU. Это означает выполнение сканирования на наличие вредоносных программ, очистку жесткого диска cleanmgr и ПФС / SCANNOWудаление ненужных программ, мониторинг любых автозапускаемых программ (с помощью msconfig) и включение автоматических обновлений Windows. Не забывайте всегда делать регулярные резервные копии или хотя бы определять точки восстановления.

Если у вас возникла более серьезная проблема, постарайтесь запомнить последнее, что вы сделали, или последнее, что вы установили перед проблемой. Использовать resmon Команда для определения процессов, вызывающих вашу проблему. Даже в случае серьезных проблем вместо переустановки Windows вы должны попытаться восстановить вашу установку или, в случае Windows 8, выполнив команду DISM.exe / Online / Очистка-изображение / Восстановить здоровье, Это позволяет восстановить операционную систему без потери данных.

Чтобы помочь вам проанализировать процесс SharePoint.exe на вашем компьютере, вам могут пригодиться следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Единый рейтинг риска безопасности указывает на вероятность того, что это шпионское ПО, вредоносное ПО или потенциальный троянский конь. Это антивирус обнаруживает и удаляет со своего жесткого диска шпионское и рекламное ПО, трояны, кейлоггеры, вредоносное ПО и трекеры.

Обновлено ноябрь 2021 г .:

Мы рекомендуем вам попробовать это новое программное обеспечение, которое исправляет компьютерные ошибки, защищает их от вредоносных программ и оптимизирует производительность вашего ПК. Этот новый инструмент исправляет широкий спектр компьютерных ошибок, защищает от таких вещей, как потеря файлов, вредоносное ПО и сбои оборудования.

скачать


(опциональное предложение для Reimage - Cайт | Лицензионное соглашение | Политика конфиденциальности | Удалить)

Недавно мне пришлось обновлять WSS 3.0 на Sharepoint Foundation 2010. Хочу поделится опытом, а также рассказать о проблемах, которые Microsoft «прячет» от нас.
Предисловие:
Windows Sharepoint Services был установлен как Stand-alone сервер, использует Windows Internal Database Engine. Хочу обновить ферму до Sharepoint 2010 Foundation. Остальное — под катом. Кому интересна финальная рабочая процедура – в нижнюю часть статьи.

Microsoft приводит полное (как сперва кажется) руководство к данной процедуре тут.

Вкратце, Microsoft предлагает следующую процедуру:
1) С диска/дистрибутива Sharepoint 2010 Foundation устанавливаем все необходимое ПО (prerequisites)
2) Устанавливаем Sharepoint 2010 Foundation
3) После установки выбираем обновление существующей фермы WSS 3.0
4) Готово.
Жаль, но все оказывается не так просто.

В описании поддерживаемых/неподдерживаемых путей обновления сказано, что Sharepoint 2010 Foundation НЕ поддерживает Windows Internal Database Engine. Тогда первое, что приходит мне в голову: установить на сервер SQL Server Express 2008 и при обновлении указать его.
ВНИМАНИЕ! SQL-сервер должен быть обязательно x64 архитектуры, на x32 инсталлятор Foundation базы разворачивать отказывается.

Собственно я так и поступаю, но, оказывается, при обновлении НЕВОЗМОЖНО изменить SQL-сервер. В окне обновления Sharepoint 2010 выбран сервер Windows Internal Database, инсталлятор успешно начинает обновление и выпадает в ошибку о том, что ему не хватает прав на SQL-сервере. Что ж, странно…

При этом инсталлятор «убивает» ферму WSS 3.0. Дальнейшие действия, как с помощью портала администрирования, так и с помощью утилиты stsadm, абсолютно невоможны.

Как восстановить работоспособность WSS 3.0? Я решил восстановить WSS 3.0 сразу на SQL-сервер, чтобы попробовать In-Place Upgrade еще раз:
1) С помощью оснастки SQL Server Management Studio подключаемся к Windows Internal Database и делаем бекап баз SharePoint_Config и SharePoint_AdminContent_xxxx-xxxx-xxxx-xxxx-xxxxxxxxx (именно эти 2 базы WSS использует для хранения настроек). Базу данных с содержимым (название WSS_Content по-умолчанию) я просто отсоединяю (detach).
2) Далее я переустанавливаю WSS (удаляю, ставлю заново, ставлю все Service Pack). В процессе установки указываю инстанс SQL-сервера (в расширенном режиме), а не Windows Internal Database.
3) После завершения установки и обновления я останавливаю службы WSS 3.0, подключаюсь SSMS к SQL-инстансу и наблюдаю там 2 базы: новую SharePoint_Config и SharePoint_AdminContent… Они мне не нужны, поэтому смело их удаляю и разворачиваю бекапы этих баз на SQL-инстанс (в моем случае SQL Server Express 2008 R2).
4) Стартую службы WSS. При этом WSS отлично работает, как раньше.

Кажется вот оно – можно обновляться, теперь проблем не будет, все же ведь на SQL-сервере. Я еще раз запускаю Мастер обновления WSS -> Sharepoint 2010. И, о чудо, теперь в окне визарда указан SQL-инстанс. Нажимаю «Next» и… опять ругается на недостаток прав на инстансе Windows Internal Database. «Как?!» — думаю я. Значит, помимо всего, WSS хранит имя сервера/инстанс где-то в базе.

Через несколько запросов я нашел таблицу и строки, где это хранится: база SharePoint_Config, таблица dbo.Objects.
Следующим запросом мы можем изменить эти данные:
USE [SharePoint_Config]
ALTER TABLE dbo.Objects
SET Name=’NEW INSTANCE NAME’
WHERE Name=’OLD INSTANCE NAME’
SET Name=’NEW SERVER NAME’
WHERE Name = ‘OLD SERVER NAME’

Повторно запускаю визард обновления. И, ура, первый шаг успешно проходит без ошибок, связанных с базой. Но, к сожалению, на втором этапе я получаю ошибку ERR Exception: System.ArgumentException: Error during encryption or decryption.
Решения, приведенные в этом KB от Microsoft не помогают. Варианты, которые я нашел в Интернете (удалить Administration Portal узел в IIS, удалить App Pool в IIS) не помогают.
Я принимаю решение развернуть все заново, методом детача баз, а не In-Place Upgrade.

Для этого я снова восстанавливаю WSS-сервер по описанной выше процедуре и:
1) Сохраняю все настройки сайтов Sharepoint (в моем случае это 1 сайт site).
2) Теперь я удаляю WSS и ставлю «чистый» его вариант (только шаги 1 и 2 вышеописанной процедуры).
3) Удаляю SharePoint 2010 Foundation
4) Делаю ребут
5) Заново устанавливаю SharePoint 2010 Foundation в Stand-alone режиме. Инсталлятор после завершения установки предлагает мне обновить существующую («чистую») ферму WSS – соглашаюсь. На этот раз обновление происходит без проблем.
6) В центре администрирования SharePoint 2010 Foundation создаю сайт с настройками, которые я записал в п.1. Прошу визард использовать существующий IIS-узел Site (который был создан в WSS). В качестве БД содержимого указываю новую БД на SQL-инстансе (WSS_Content_Temp), которую я потом удалю.
7) Присоединяю (attach) базу WSS_Content к SQL-серверу.
8) По данному мануалу обновляю и присоединяю базу с содержимым к SharePoint 2010 Foundation командой:
cd “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Bin”
stsadm –o addcontentdb –url site –databasename WSS_Content –databaseserver NEWSERVER\NEWINSTANCE
9) Проходит процесс обновления. После него удаляю базу WSS_Content_Temp из узла в центре администрирования SharePoint.
10) Вуа-ля.

В общем и целом мне неясно 2 вещи: почему инсталлятор не проверяет необходимые требования и выдает абсолютно не соответствующие действительности ошибки? Но это скорей риторический вопрос…

Читайте также: