Archive
Alto consumo CPU e memória noderunner.exe – SharePoint 2013
CENÁRIO:
Olá!
Apesar de ter montando uma máquina virtual de desenvolvimento com um hardware razoável (gastar menos $$) sofri com consumo excessivo de CPU e memória em um servidor com SharePoint 2013, SQL Server 2008 R2 e Visual Studio 2017 instalado.
ERRO:
Não é um erro, mas é um comportamento pesado para um ambiente de desenvolvimento.
SOLUÇÃO:
Analisando um pouco o comportamento do servidor para descobrir o “vilão” da jogada… notei que o processo “noderunner.exe” estava consumindo muita memória e CPU considerável.
Noderunner.exe é um componente do serviço de busca do SharePoint 2013.
Para ambientes de Dev, podemos reduzir o consumo desse serviço. Principalmente se não estamos usando a busca do SharePoint 2013 no desenvolvimento. Inclusive, desabilitar o serviço.
No caso, eu precisava de um “pouco” de busca… 
Então, utilizei os passos a seguir para reduzir o impacto da busca no consumo de recursos do servidor.
- Rode o cmdlet Powershell abaixo para reduzir o consumo de CPU
Set-SPEnterpriseSearchService -PerformanceLevel Reduced
- Altere o parâmetro “memoryLimitMegabytes” do arquivo “exe.config”. Por padrão, a configuração é “0” – ilimitado.
C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderunner.exe.config
- Reinicie o serviço de busca do SharePoint com o cmdlet a seguir
Restart-Service SPSearchHostController
Agora o servidor ganhou “algum” fôlego.
Informações adicionais: https://docs.microsoft.com/en-us/powershell/module/sharepoint-server/Set-SPEnterpriseSearchService?view=sharepoint-ps
Reduced: Total number of threads = number of processors, Max Threads/host = number of processors
Partly Reduced: Total number of threads = 4 times the number of processors , Max Threads/host = 16 time the number of processors
Maximum: Total number of threads = number of processors
Abraço!
Could not load file or assembly Microsoft.VisualStudio.Shell.15.0
CENÁRIO:
Montando o pipeline de Build e Release automático de um projeto SharePoint Add-in (SharePoint App – SharePoint Online 365) descobri que não tem um template de tarefa de build no Visual Studio Online (VSTS).
Então, parti para construir a tarefa de build vazia (Empty) onde colocamos os comandos para realizar o build.
Eis que ao tentar dar build usando o msbuild.exe me deparo com um erro bem estranho.
ERRO:
“C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets(395,5): Error : Could not load file or assembly ‘Microsoft.VisualStudio.Shell.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.”
SOLUÇÃO:
Depois de algumas (muitas) pesquisas descobri que é necessário adicionar referências no projeto para fazer o build com sucesso. Passos para resolver:
- Adicionar um arquivo “Microsoft.VisualStudio.SharePoint.AddAssemblySearchPaths.targets” na raiz do seu projeto (conteúdo do arquivo mais abaixo)
- Adicionar “<Import Project=”Microsoft.VisualStudio.SharePoint.AddAssemblySearchPaths.targets” />” no arquivo .csproj para importar o arquivo adicionado.
- Pronto, agora é build com sucesso! 😉
Conteúdo do arquivo “Microsoft.VisualStudio.SharePoint.AddAssemblySearchPaths.targets”:
<Project xmlns=’http://schemas.microsoft.com/developer/msbuild/2003′ >
<UsingTask TaskName=”AddAssemblySearchPath” TaskFactory=”CodeTaskFactory” AssemblyFile=”$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll”>
<ParameterGroup>
<SearchPath ParameterType=”System.String” Required=”true” />
</ParameterGroup>
<Task>
<Using Namespace=”System” />
<Using Namespace=”System.IO” />
<Using Namespace=”System.Reflection” />
<Code Type=”Fragment” Language=”cs”>
<![CDATA[
AppDomain.CurrentDomain.AssemblyResolve += (sender, e) =>
{
string assemblySearchPath = Path.Combine(SearchPath, e.Name.Split(‘,’)[0] + “.dll”);
if (File.Exists(assemblySearchPath)) return Assembly.LoadFrom(assemblySearchPath);
return null;
};
]]>
</Code>
</Task>
</UsingTask>
<Target Name=”addAssemblySearchPaths”>
<AddAssemblySearchPath SearchPath=”$(MSBuildExtensionsPath)\..\Common7\IDE\PrivateAssemblies\” />
<AddAssemblySearchPath SearchPath=”$(MSBuildExtensionsPath)\..\Common7\IDE\PublicAssemblies\” />
</Target>
</Project>
Também adicionei o arquivo para download aqui: https://1drv.ms/u/s!Ass2zQvJNjQNguMdQGn53ziBBweFBg
Para resolver essa zica, contei com a ajuda do super http://diegomarques.azurewebsites.net/.
Abraço!
Setup is unable to proceed to the following error(s)
CENÁRIO:
Hoje precisei instalar um VM SharePoint 2013 para fazer um robô de migração/exportação de dados para uma outra aplicação.
Ao instalar o SharePoint 2013 SP1 no Windows Server 2012 R2, logo de cara, me deparo com erro ao instalar os pré-requisitos solicitando .NET 4.5… que já estava instalado no servidor.
ERRO:
Setup is unable to proceed to the following error(s):
This Product requires Microsoft .Net Framework 4.5
SOLUÇÃO:
Depois de algumas pesquisas vi que a MS já lançou um KB para contornar esse problema, onde você irá baixar uma nova DLL e substituir nos arquivos de instalação.
Links para download da nova DLL do instalador:
- SharePoint Foundation 2013 with Service Pack 1 fix
- SharePoint Server 2013 with Service Pack 1 fix
- Project Server 2013 with Service Pack 1 fix
Abraço!
Devo aplicar Cumulative Updates (CU) assim que são disponibilizados?
CENÁRIO:
Essa é uma questão que sempre vem à tona e eu sempre perco o link com informações à respeito. Devo manter meu ambiente sempre o mais atualizado possível?
Para quem não está familiarizado, a Microsoft disponibiliza constantemente updates para seus produtos (que ainda estão no ciclo de suporte – normalmente 10 anos desde seu lançamento).
Nesses updates temos hotfixes, Cumulative Updates (pacote com vários hotfixes) e Service Packs (pacote maior ainda de vários hotfixes). A frequência de lançamento também segue essa hierarquia. Ou seja, são lançados vários hotfixes até que formem um Cumulative Update, e assim por diante.
ANÁLISE:
A Microsoft recomenda o seguinte:
https://msdn.microsoft.com/en-us/library/hh479746(v=sql.120).aspx – Installing Updates for SQL Server 2014 after it has already been installed
“On an installed instance of SQL Server 2014, we recommend that you apply the latest security updates and critical updates including General Distribution Releases (GDRs), and Service Packs (SPs). Individual Cumulative updates and security updates should be adopted on a case-by-case, "as-needed" basis. Evaluate the update, if it’s needed, then apply it. If not, assess the risk of applying or not.”
CONCLUSÃO:
O link mostra informação sobre o SQL Server, mas o mesmo se aplicar ao SharePoint Server e imagino que aos demais produtos Microsoft.
Cumulative Updates devem ser aplicados se necessário. Sua aplicação não deve seguir uma agenda “urgente” de implantação assim que são lançados.
Obviamente que quanto mais atualizado, melhor. Mas no mundo real a aplicação de patch’s não é tão simples em ambiente produtivo.
Como é um assunto que sempre gera bons diálogos. Qual a sua consideração sobre o assunto?
Eu procuro sempre estar no último Service Pack e aplico CU’s à medida da necessidade.
Abraço!
SharePoint 2013 Configuration Wizard Missing Components Language Pack Installation
Olá! J
Cenário:
Após aplicar o SP1 no SharePoint 2013 e também SP1 dos Language Pack instalados precisamos rodar o Configuration Wizard (PSCONFIG) para que o SharePoint consolide as atualizações realizadas. Mas, como nem tudo é como nós queremos nessa vida, tive alguns problemas para conseguir fazer com que o Configuration Wizard rodasse sem problemas.
ERRO:
Ao tentar rodar o Configuration Wizard era apresentado uma mensagem de erro informando que estavam faltando arquivos no SharePoint, embora eu já tivesse aplicado todos os pacotes de Language Pack e seus respectivos Service Pack.
“Some farm products and patches were not detected… Missing on <ServerName>”
SOLUÇÃO:
Procurando por problema similares na web, encontrei que isso poderia ocorrer por razão do serviço de timer parado, mas no meu caso estava rodando. De toda forma, reiniciei o serviço e tentei rodar novamente o Configuration Wizard. Sem sucesso.
O que resolveu foi rodar o seguinte cmdlet no powershell do SharePoint (SharePoint 2013 Management Shell) no servidor que ele apontava com “missing” (faltando) componente:
Get-SPProduct
Pronto! Ao término da execução deste cmdlet, tente rodar novamente o Configuration Wizard. Agora o SharePoint sabe que os componentes estão instalados e não deve reclamar mais a falta destes.
Abraço!
Search has encountered a problem that prevents results from being returned. If the issue persists, please contact your administrator
Olá! J
Cenário:
Após aplicar o SP1 no SharePoint 2013 e começar a validar os sites e serviços existentes da FARM encontrei um problema ao validar o funcionamento da busca/pesquisa dos sites que usam o serviço de busca do SharePoint.
ERRO:
Ao tentar utilizar a busca do site era apresentado o seguinte erro:
“Search has encountered a problem that prevents results from being returned. If the issue persists, please contact your administrator”
E ao pesquisar nos eventos gerados nos logs do SharePoint (ULS), encontrei o seguinte:
“SearchServiceApplicationProxy::Execute–Error occured: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Tried IMS endpoints for operation Execute: Operation sent to IMS failed:
Resource saturation, try again later. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: Microsoft.SharePoint.SPException:
Tried IMS endpoints for operation Execute: Operation sent to IMS failed: Resource saturation, try again later.”
SOLUÇÃO:
O erro do ULS cita, talvez, um problema de “recursos disponíveis”… quando fala de “resource saturation”, mas ao checar a condição do servidor vi que só estava consumindo 10% de memória de RAM e o CPU estava uma utilização bem baixa. Então não pode ser falta de recurso.
Ao pesquisar um pouco mais, percebi que um dos serviços do SharePoint estava “congelado” no estado “Starting”… Ou seja, não conseguiu subir. Tentei reiniciar o serviço, mas sem sucesso. Continuou no estado “Starting”.
Nome do Serviço: Search Host Controller Service
Para corrigir, re-provisione o serviço com esse script powershell:
$sh = Get-SPServiceInstance | ? {$_.TypeName -eq “Search Host Controller Service”}
$sh.Unprovision()
$sh.Provision($true)
Ou este:
$SA = Get-SPServiceInstance | Where {$_.Status -like “Provisioning”}
$SA.Unprovision()
$SA.Provision()
Depois que executar com sucesso, o resultado esperado será o serviço iniciado corretamente e a busca voltará a funcionar.
Abraço!
System.Runtime.InteropServices.COMException: The context has expired and can no longer be used
Olá! 
Cenário:
Ao acessar um ambiente de homologação no cliente o menu de navegação do SharePoint estava apresentando erro.
E ao acessar o Site Settings > Navigation, outro erro explodia na tela.
ERRO:
“System.Runtime.InteropServices.COMException: The context has expired and can no longer be used”
SOLUÇÃO:
Pesquisando na web li algo sobre isso ocorrer por uma falta de sincronismo entre as configurações de “relógio” do SharePoint e às configurações de relógio do servidor.
Não encontrei uma forma mais “adequada” de resolver. Mas ao realizar um iisreset o problema foi resolvido. Se eu encontrar posteriormente uma melhor solução, volto e atualizo este post (conto com sua ajuda tbm! 
).
Procuro evitar iisreset e/ou “boot” no servidor, pois quase sempre há outra forma de resolver. E muitas vezes, formas menos “agressivas”.
De toda forma, resolução inicial:
· Faça um IISRESET no servidor que o problema será resolvido.
Abraço!
SharePoint:DateTimeControl não funciona em formulário customizado. “Sorry, something went wrong”
Olá! 
Cenário:
Precisei customizar um formulário no SharePoint 2013 e ao tentar abrir o calendário para selecionar uma data no DateTimeControl era exibido a mensagem de erro abaixo.
ERRO:
“Sorry, something went wrong”. Ou em português, algo similar a “Desculpe, algo deu errado.”
E ao procurar no ULS (LOGS) do SharePoint, a seguinte mensagem:
“Exception trying get context compatibility level: System.IO.FileNotFoundException: The site http://vmsp2013:80/_layouts/15/iframe.aspx?&cal=1&lcid=1046&langid=1046 could not be found in the Web application SPWebApplication Name=SharePoint – 80.”
SOLUÇÃO:
Demorei um tempo para reparar, mas percebi que a url não estava “correta”. Meu site utiliza “managed path”. Ou seja, seria algo como: http://vmsp2013/sites/meusite.
No SharePoint 2013 foi introduzido o “Host-Named SiteCollection” e acredito que por isso o DateTimeControl só está buscando no “root”. Mas, ainda há casos que precisamos manter compatibilidade antes de migrar para as novas tecnologias.
Enfim, o problema é causado por que NÃO existia sitecollection criada no root da WebApplication. Ao criar a sitecollection o problema foi resolvido, mas é necessário que o usuário tenha acesso a este site para que o controle DateTimeControl funcione.
Abraço!
Decryption failed with error 0
Olá! 
Cenário:
Ao tentar buscar usuários no campo de pesquisa de usuários nenhum resultado é retornado.
Ao investigar os Logs do SharePoint, temos encontramos os erros a seguir…
ERRO:
Decryption failed with error: 0
at
at Microsoft.SharePoint.Administration.SPCredentialManager.DecryptWithApplicationCredentialKey(Byte[] rgbEncryptedPassphrase)
E este outro:
An exception occurred in AD claim provider when calling SPClaimProvider.FillSearch(): Erro durante a descriptografia. Código de erro do sistema 0..
SOLUÇÃO:
Devemos forçar a leitura do AD pela conta do appPool do SharePoint.
stsadm -o setapppassword -password "senha" (em todos os WFE’s)
stsadm -o setproperty -pn peoplepicker-searchadforests -pv "forest:dominio.com.br,dominio\conta,senhaDaConta;" –url <urlWebApp>
Abraço!
This task is currently locked by a running workflow and cannot be edited
Olá! 🙂
Esse post bem rapidinho… O Workflow do SharePoint “trava” as tarefas do tipo de conteúdo “WorkflowTask” para assegurar que a tarefa não seja editada enquanto o processo do Workflow aconcete. E depois que o Workflow termina de rodar, ele tira essa “trava” para que a tarefa seja editável novamente.
Ok! Comportamento esperado… mas, no decorrer do projeto, decidimos que as tarefas não seriam mais utilizadas em um Workflow e passariam as ser simplesmente tarefas atualizadas por outros mecanismos como: Forms Customizados e Event Receivers. Só que nesse caso específico a tarefa em questão herdava o Content Type de “WorkflowTasks” e então eu mesmo preciso tirar essa “trava” que o workflow faz automaticamente.
NOTA: Se sua tarefa herda do Content Type de “Tasks”, isso não é necessário.
Quando for atualizar uma tarefa que herda da “WorkflowTasks” atualize também a coluna do Workflow e assim a tarefa será editável.
item[Microsoft.SharePoint.SPBuiltInFieldId.WorkflowVersion] = 1;
item.Update(); //SPListItem
Pronto, o item será atualizado sem que a mensagem de erro seja apresentada.
Abraço!
Thiago Silva - Especialista SharePoint 