Marat Bakirov

Changing SharePoint 2013 farm passwords

Marat F Bakirov — Fri, 29 Jul 2016 09:09:31 GMT

Another recent case from the customer. What they had is a farm which was deployed with autospinstaller. https://autospinstaller.codeplex.com/ So they have quite a number of accounts for various SharePoint services , windows services and application pools. So how should we change the accounts? The easiest way (that was implemented at the customer) is to have account to be registered as managed accounts. This way you or SharePoint can automatically change passwords for the accounts, and update all relevant records. The managed account can change the passwords in AD or just update the SharePoint records. In our case there were some errors we have not resolved, so we have let the AD admins change the password and then we have changed the things in SharePoint. So what happens after you change the AD account password? If you do nothing, there will be problems. Most likely though you will only notice the problems after you restart the server. The reason is that there are Windows Service registrations on farm computers containing copies of the passwords IIS Pools registrations containing copies of the passwords In some cases (like search or workflow) other entities contain the reference to the password. Managed accounts The benefit of managed account is that SharePoint can automate some of these actions across the farm. Namely - changing the windows service registrations and iis pools registrations. If you choose to change the passwords (and not let them be changed automatically), there are basically 2 ways to do it. Option one - Central Admin Press the edit button Enter new password and press ok below Note that option one - Set account password to a new value will try to change the password in AD first. Option two will just update the relevant services and IIS pools. In some cases you would prefer to use PowerShell. If the account you are changing is also used to run the Central Administration application pool, then your command will kinda fail in the middle cause it will run under the pool that is going to be reset! In this case you can use the Set-SPManagedAccount command https://technet.microsoft.com/en-us/library/ff607617(v=office.16).aspx If you want this command to change the AD password use this format


Set-SPManagedAccount -Identity $username -NewPassword $newpassword -ConfirmPassword $newpassword

If you want to use an existing password - use this one.


Set-SPManagedAccount -Identity $username -ExistingPassword $newpassword  -UseExistingPassword:$true

I have made a script that reads accounts and new passwords from the csv files and updates them in a bulk.


<#
.SYNOPSIS
Changes managed account passwords at the farm.
.DESCRIPTION
Changes accounts using the provided CSV file.
.EXAMPLE
.\changepasswords.ps1    -inputFile "yourfile.csv" -newPasswords:$false
.NOTES
Author: Marat Bakirov
Date: 05 July 2016
#>
[cmdletbinding()]
param(
[string] $InputFile = "accountsandpasswords.csv",
[switch] $newPasswords = $true
)

#################################################### # Configurables #################################################### Add-PSSnapin Microsoft.Sharepoint.Powershell #################################################### # Main #################################################### function Main { $passwords = Import-Csv $InputFile $passwords | foreach { $username = $_.Username $newpwd1 = $_.NewPassword $newpassword = ConvertTo-SecureString -String $newpwd1 -AsPlainText -Force $newpwd1 if ($newpasswords) { Write-Host "changing password for {$username} to a new one" Set-SPManagedAccount -Identity $username -NewPassword $newpassword -ConfirmPassword $newpassword -Confirm:$false } else { Write-Host "changing password for {$username} to an existing one" Set-SPManagedAccount -Identity $username -ExistingPassword $newpassword -Confirm:$false -UseExistingPassword:$true } } } Main How to change other passwords If the account participates in the user profile sync, search or workflow farm, you might need to run additional scripts. User profile sync These accounts are managed and are changed within SharePoint but are also used for the User Profile Sync. So an additional configuration might be required. Good reference can be found here https://blog.zubairalexander.com/managing-passwords-for-service-accounts-in-sharepoint-sql-server/ - section 5 5. User Profile Synchronization Connection Account or https://blogs.msdn.microsoft.com/charliechirapuntu/2013/01/16/sharepoint-2010-service-accounts-passwords-change-guide/ Search crawler account This has an additional impact – the search content account has to be updated in the active directory first and then updated in the search center. https://technet.microsoft.com/en-au/library/dn178512.aspx Workflow and service bus farm accounts On each server in the farm that has workflow installed run the Service Bus PowerShell in the elevated mode. (Note: if the service buspower shell is missing, then skip the procedure for this server). Run the changewfpassword.ps1 script. The script will prompt for the new Password for the svcInsiteWfProd/ svcInsiteWfTest account.


Write-Host "Please enter a new password"
$passwordText = Read-Host
$AccountPassword = ConvertTo-SecureString -String $passwordText -AsPlainText -Force

Stop-WFHost -Verbose Update-WFHost -RunAsPassword $AccountPassword –Verbose Start-WFHost -Verbose Stop-SBHost -Verbose Update-SBHost -RunAsPassword $AccountPassword –Verbose Start-SBHost -Verbose Source code The scripts could be found here https://1drv.ms/f/s!AguWtH15ywzQhI5kUYLXI1Jcmv4Y6Q

Случай - перестала работать команда export-spweb. (А также некоторые размышления о том, почему важна настройка package version и настройка DeploymentServerType)

Marat F Bakirov — Tue, 19 Jul 2016 09:13:40 GMT

Еще один случай, который произошел у последнего клиента. У клиента есть стороннее приложение, в котором создана веб часть и шаблон списка (list template). Судя по всему созданы для Sharepoint 2010 (14) и просто перекомпированы под SharePoint 2013. А может даже и не перекомпилированы. Исходный текст есть но я не имею права ничего менять в решении. У клиента ферма на 4 сервера, 2 - Application Role (APP1 и APP2), 2 - Web Front End (WEB1 и WEB2) APP1 содержит центр администрирования. Еще одно стороннее решение выполняет гранулярный бекап, в котором внутри используется команда Export-SPWeb. Export-SPWeb не работает. Ошибка примерно такая https://social.technet.microsoft.com/Forums/en-US/6b50d0f2-b323-4156-a11a-d3f6ea1492c7/sharepoint-2010-site-collection-export?forum=sharepointgeneralprevious Error: Feature 'blalba-guid' for list template '100' is not installed in this farm. The operation could not be completed. Feature blalba-guid - находится в стороннем решении и развернута! В ходе исследования выяснилось несколько моментов. Первый - стороне решение ставится в 14 Hive. Что - Что? Hive? Файлы из решения были развернуты сюда "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\TEMPLATE\FEATURES\" но НЕ БЫЛИ развернуты сюда "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\FEATURES\" Кажется, что решение просто было скомпилировано с неверной опцией Compatibility (14, а должно быть 15). Думается, что ходить и копировать файлы вручную все-таки не очень хорошая идея, так что нужно как то сказать Sharepointу, чтобы решение поставилось в 15 hive. Проще всего было бы перекомпилировать, но раз такое возможности нет, то можно установить решение вот такое командой. Install-SPSolution -Identity -AllWebApplications -GacDeployment -CompatibilityLevel {14,15} Итак, файлы появляются в 15 Hive. Остается одна проблема - файлы появились только на WEB1 и WEB2. Команда Export-SPWeb на них начала работать, но по-прежнему не работает на APP1/2. Клиент запускать экспорт на фронт ендах не хочет. Там сотни гигабайт, дополнительную нагрузку на фронт енды никто не хочет. Чтобы понять, почему же файлы не появились на веб фронтендах, давайте взглянем еще на одну настройку. Настройка говорит нам, устанавливать ли решение на сервера с ролью Web Front End или ApplicationServer, но как Sharepoint определяет кто есть who? Можно было бы подумать, что это server role. https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spserverrole.aspx Но кажется,что для For SP2013 это не важно. В моем случае самое логичное объяснение в том, что Sharepoint определяет фронт енд как сервер, на котором запущена служба "Microsoft Sharepoint Foundation Web Application" service. То есть если решение развёртывается как "WebFrontEnd" - его файлы развертываются на сервера, на которых служба "Microsoft Sharepoint Foundation Web Application" запущена. Итого все просто - запустить службу Microsoft Sharepoint Foundation Web Application ? Еще один тонкий момент - запуск или остановка этой службы вызывает перезапуск IIS. При этом перезапускается Центр Администрирования. Если запустить перезапуск из центра Администрирования то это может вызывать ошибку. В этом случае запустите команду Get-SPServiceInstance | where {$_.TypeName.Contains('Web Application')} | ft -Property Id,TypeName,Server,Status -Autosize Найдите нужные вам экземпляры службы и запустите их командой Start-SPServiceInstance -Identity command Итак, кейс разрешен. Клиент доволен. То есть мы исправили версию при развертывании и добавили веб роль на серверах приложений. Стоп! Что? Что?? Добавили веб роль на серверах приложений.??? Верно, но при этом мы не нарушили логическую топологию. Служба "Microsoft Sharepoint Foundation Web Application" действительно запущена на серверах APP1 и APP2 но мы из не используем как Web Front Ends. Наш балансировщик просто не в курсе, что на них можно перенаправлять запросы. Просто мы решили проблему заказчика.

Case - broken export-spweb. (Understanding the solution package version and DeploymentServerType)

Marat F Bakirov — Tue, 19 Jul 2016 08:12:51 GMT

Another case from the recent customer support work. The customer had a 3rd party solution with a list template, list and a web part which seemed to be created for SharePoint 14 (2010) originally and simply recompiled. (And I cannot change or recompile the sources). The customer has SharePoint 2013 farm, made of 2 App servers (let us call them APP1 and APP2) and 2 web front ends (WEB1 and WEB2). APP1 also runs central admin. Another 3rd party backup solutions the customer is using is doing a granular SharePoint backup (up to document) and internally uses the Export-SPWEB command. The Export command breaks. Errors are similar to the ones described here: https://social.technet.microsoft.com/Forums/en-US/6b50d0f2-b323-4156-a11a-d3f6ea1492c7/sharepoint-2010-site-collection-export?forum=sharepointgeneralprevious Error: Feature 'blalba-guid' for list template '100' is not installed in this farm. The operation could not be completed. Feature blalba-guid is from the 3rd party solution and it is installed! During investigation I have found out the few reasons. First - the 3rd party solution was installing in the 14 Hive. What? The solution files and features were added to the "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\TEMPLATE\FEATURES\" but NOT added to the "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\FEATURES\" Apparently the solution was compiled with the 14 compatibility option. Probably it is not a good idea to go through all servers and copy the files, so to achieve the result we need to tell SharePoint to deploy the solution to both 14 and 15 hives. Would be simpler if the solution would recompiled with 15 compatibility option, but I could not do it, so I had to run the following command to deploy the solution


Install-SPSolution -Identity  -AllWebApplications -GacDeployment -CompatibilityLevel {14,15}

This made the files to appear at the 15 hive. However, the files were only deployed to the WEB1 and WEB2, and the export command were still not working at the APP1 and APP2, despite the fact that it started to work fine at the WEB1 and WEB2. The customer was really reluctant to run the Export jobs at the Web frontend and thus increasing the load. To understand why the files did not appear at the APP1 and APP2, let us look at another setting: So this setting is telling us if the solution will be deployed to web front end or an application server. But how does SharePoint define which server is the application server? Well you might assume that it is server role. https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spserverrole.aspx For SP2013 it seems that this does not matter. It seems that the Sharepoint defines the web front end as a server that runs a "Microsoft Sharepoint Foundation Web Application" service.

If the solution package deployment type is "WebFrontEnd" - it's assets are deployed to the servers that have the "Microsoft Sharepoint Foundation Web Application" on.

So the solution was simple - start the Microsoft Sharepoint Foundation Web Application service on the server? Simple? One more tricky thing. Starting the service on the server that has a Central Admin - causes IIS to restart, and thus central admin to restart. So we may encounter the problem. In this case run the command


Get-SPServiceInstance | where {$_.TypeName.Contains('Web Application')} | ft -Property Id,TypeName,Server,Status -Autosize

Find the service instance on the server you want it to run on, and then run the


Start-SPServiceInstance -Identity  command

That is all! the case is solved. So we have fixed the version by installing the solution with the correct compatibility levels and also added a Web Role to the application servers. Woah woah woah wait a second. What? Added a Web Role to the application servers??? Yes, however we did not break the farm topology. These servers APP1 and APP2 HAD the "Microsoft Sharepoint Foundation Web Application" service but were NOT used as Web Front ends. Simply the load balancer had no idea they do have the IIS and so the requests were not redirected here. We just solved the problem.

Как более правильно отобразить файловые результаты поиска

Marat F Bakirov — Mon, 18 Jul 2016 09:32:30 GMT

Еще один кусочек знаний с последнего проекта. У клиента была веб часть, которая выглядела точно так же, как и список файлов, но это была веб часть Content Search и она отображала файлы, найденные по определенному критерию на подсайтах. Клиента не устраивало, что ссылки не предлагают открыть Word/Excel, а вместо этого просто предлагают скачать файл. Хочу, говорит, чтобы работало так же, как и просто в библиотеке документов. Начал разбираться. Было несколько причин. Первая - в результатах поиска использовалось управляемой свойство (managed property) Path. Это очень простое свойство, которое выдает путь до объекта. Примерно так https://sp131:82/Documents/excel1.xlsx Но нам нужно было, чтобы ссылки учитывали OWA или Excel Services. Я нашел вот этот пост. https://www.eliostruyf.com/three-useful-managed-properties-for-working-with-office-web-apps/ Кажется это единственный пост, в котором можно найти описание вот этих свойств: • ServerRedirectedURL • ServerRedirectedPreviewURL • ServerRedirectedEmbedURL Итого я использовал ServerRedirectedURL. На полноценной ферме у клиента результат выглядел примерно так :


https://server/_layouts/WopiFrame.aspx?sourcedoc={E526E4B1-6759-448F-B6C6-0C67E942173B}&file=Documents/excel1.xlsx&action=default&DefaultItemOpen=1

А на моей локальной так :


https://sp131:82/_layouts/15/xlviewer.aspx?id=/Documents/excel1.xlsx&DefaultItemOpen=1

Другой важный момент - как работают ссылки. В самой библиотеке документов ссылки пытаются открыть Word/Excel. В результатах поиска этого не происходило. Вообще говоря, есть настройка, которая описывает данное поведение. https://technet.microsoft.com/en-us/library/ee837425.aspx Можно найти в разделе "advanced settings" библиотеки документов. Ссылки в библиотеке документов выглядели так: При настройке "open in the client application".


doc1

При настройке "open in the browser".


doc1

В моем случае клиента устроило, что мы всегда выбираем первый вариант. Итоговый код:




_#= line1 =#_

How to display correct document links in the search results.

Marat F Bakirov — Mon, 18 Jul 2016 08:52:18 GMT

At the recent client project there were an interesting situation. They had a web part that was looking pretty much like a list with the only difference - it was a Content Search webpart and it was supposed to show certain the documents from all subsites. Pretty usual request. However, the client pointed out, that the links are not the same as if they would use the "normal" documents view. The client was not happy that the links suggest to download the file instead of opening in Word/Excel/etc. I have started to look. There were a number of reasons why the links were different. First reason is that they use Path managed property. Path managed property gives what it gives. The path. Like this https://sp131:82/Documents/excel1.xlsx But it does not respect existence of the Excel services or the OWA. So I found this blog post https://www.eliostruyf.com/three-useful-managed-properties-for-working-with-office-web-apps/ That was probably the only one explaining other important managed properties

ServerRedirectedURL
ServerRedirectedPreviewURL
ServerRedirectedEmbedURL

So I have used the ServerRedirectedURL. At the customer environment it returns a link to OWA, like this:


https://server/_layouts/WopiFrame.aspx?sourcedoc={E526E4B1-6759-448F-B6C6-0C67E942173B}&file=Documents/excel1.xlsx&action=default&DefaultItemOpen=1

At my local SharePoint dev single server machine it looked like this


https://sp131:82/_layouts/15/xlviewer.aspx?id=/Documents/excel1.xlsx&DefaultItemOpen=1

Another difference was the way the links work. In the library itself the links tried to open the corresponding app - word or excel or the OWA. In the search results there were no prompt for opening the App. There is a setting that affects this behaviour It is well described in this article https://technet.microsoft.com/en-us/library/ee837425.aspx You can find it under "advanced" settings in the document library, and there are some other system wide settings that affect it. I have looked at the links in the list and found out that the links look like this When the library setting is like "open in the client application".


doc1

When the library setting is like "open in the browser".


doc1

In my case the customer was ok with hardcoding the option one. So the final resulting code was like this




_#= line1 =#_

Как добавить ссылку “Просмотреть библиотеку" к результатам поиска SharePoint Search из файлового источника (File Share)

Marat F Bakirov — Fri, 15 Jul 2016 09:01:52 GMT

На последнем проекте наткнулся на вопрос от заказчика, на который не нашел ответа в интернете. Я думаю, вы знаете ссылку "view library” - она появляется при поиске файлов? У заказчика был настроен поиск по файловому ресуру, и ссылка не появлялась никак. Решение казалось простым, но в интернете я ничего не нашел. Клиент - тоже не нашел. Я думаю, Вы знаете механизм Display Templates, с помощью которых можно переопределить внешний вид результатов поиска. Ссылки определяются в файле Item_CommonHoverPanel_Actions.html Вот эта часть:


if(!Srch.U.e(ctx.CurrentItem.ParentLink) && ctx.CurrentItem.csr_ShowViewLibrary) {
_#-->

_#= $htmlEncode(Srch.Res.hp_ViewLibrary) =#_