Using Merge-SPLogFile – Consolidate Log files on SharePoint

According to the description of Merge-SPLogFile on Microsoft TechNet:

“Combines trace log entries from all farm computers into a single log file on the local computer.”

Let me explain how you can use this powerful command.

Basic Usage

Lets visualize a simple farm.

As the sample Farm image above we have 2 frontend servers, 1 application server and 1 database server. If you wanted to consolidated the last hour of SharePoint log entries from the front-end server and application server you would open the SharePoint Management Shell on one of the servers and type the following command:

Merge-SPLogFile –Path “E:\SPLogs\MergedLogs.log” –Overwrite

Finding Correlation ID

What the following example show is how to find the log entries for a specific correlation id:

Merge-SPLogFile –Path “S:\SPLogs\MergedLogs.log” –Correlation 3ae2a6c0-da14-43a1-afda-5bb6bbff3d43 -Overwrite

Como fazer "refresh" de PWA – Project Server 2010

Cenário: Você tem 2 farms de Project Server 2010, 1 de Produção e 1 de Homologação e deseja atualizar o ambiente de Homologação com os dados de Produção. Este post irá informar os passos necessaries para tal.

Passos Necessários:

1) Desprovisione o PWA em Homologação:

Abra a Central de Administração do SharePoint 2010;

Acesse a opção “Manage Service Applications”;

Acesse a opção “Project Service Service Application”;

Acesse o menu suspenso junto ao nome do seu “PWA” que está provisionado, e selecione a opção “Delete”;

Uma tela contendo as informações do seu “PWA” será aberta para confirmação da deleção. Confirme clicando no botão “Delete”;

Aguarde enquanto o SharePoint executa a ação informando em tela o progresso;

Ao término do processo, o PWA não existirá mais;

2) Desatachar a(s) base(s) de conteúdo(s) via powershell do Web application que hospedava o PWA;

Abra o SharePoint 2010 Management Shell como administrator do Farm;

Rode o comando: Dismount-SPContentDatabase “<ContentdBName>”

Onde <ContentdBName> é o nome do content database que você deseja desatachar.

Em nosso ambiente usamos o commando: Dismount-SPContentDatabase “DBSPS_PWAContent”

Confirme a solicitação com “Y” e aguarde o resultado:

3) Efetuar o backup Full dos 5 bancos de dados do servidor de SQL de Produção. Em nosso cenário as bases chamam-se:

a) DBSPS_PWAContent – Base contendo os Project Sites – Content Database

b) DBPRS_PWA_Archive – Base de arquivamento do PWA

c) DBPRS_PWA_Draft – Base de rascunho do PWA

d) DBPRS_PWA_Published – Base de publicação do PWA

c) DBPRS_PWA_Reporting – Base de relatórios do PWA

4) Efetuar o restore do backup efetuado no passo 3 dos 5 bancos de dados no servidor de SQL de Homologação. Em nosso cenário as bases possuem os mesmos nomes em Produção e Homologação:

a) DBSPS_PWAContent – Base contendo os Project Sites – Content Database

b) DBPRS_PWA_Archive – Base de arquivamento do PWA

c) DBPRS_PWA_Draft – Base de rascunho do PWA

d) DBPRS_PWA_Published – Base de publicação do PWA

c) DBPRS_PWA_Reporting – Base de relatórios do PWA

5) Ajustar as permissões para os usuários do ambiente de homologação nos 5 bancos de dados restaurados no servidor de SQL de Homologação. Em nosso cenário as usuários são:

a) User_1 (Setup Account), User_2 (Farm Admin), User_3 (AppPool Account) – Owner das bases DBPRS_PWA_xxx;

a) User_1 (Setup Account), User_2 (Farm Admin), User_3 (AppPool Account), User_4 (Excel Service Account), User_8 (Secure Store User account) – Owner das bases DBPRS_PWA_Reporting;

b) User_1, User_2, User_3, User_4 – Owner das bases DBSPS_PWAContent;

6) Atachar a base de conteúdo dos Projects Sites no web application de Homologação:

a) Em nosso cenário a base DBSPS_PWAContent via PowerShell;

Mount-SPContentDatabase “<ContentDb>” -DatabaseServer “<DbServer>” -WebApplication http://SiteName

Onde:

<ContentDb> é o ocontent databaseque sera atachado.

<DbServer> é o nome do servidor SQL.

http://SiteName é o nome do web application para o qual o content database está sendo atachado.

Nosso comando:

Mount-SPContentDatabase “DBSPS_PWAContent” -DatabaseServer “DBxxxxx” -WebApplication http://epmqa.xxxxxxx

O resultado será conforme o print abaixo, onde o mesmo demonstra que existe um site collection:

7) Confira se o site collection chama-se “PWA”

Acesse o Menu “Application Management”:

Acesse o Menu “View all site collections”:

Selecione o Web application, em nosso caso: http://epmqa.xxxxxxx, será mostrado o site collection do PWA que iremos reprovisionar. Em nosso ambiente, o Project Web App chama-se “PWA”:

8) Reprovisionar o PWA

Acessar o menu “Manage Service applications” sob o menu “Service Applications” sob o menu “Application Management”:

Acesse o Menu “Project Server Service Application”:

Acesse o menu “Create Project Web App Site” para reprovisionar o PWA apontando as bases restauradas, já existentes em nosso SQL de homologação:

Preencha os dados corretamente conforme o seu ambiete. Em nosso, os dados relevantes foram o user_3, o nome do PWA como “PWA”, linguagem em inglês e o apontamento do SQL de homologação com os nomes das bases restauradas:

Um vez preenchidos os campos corretamente, confirme no botão “OK” e agurde os recursos iniciarem o processo:

Uma vez iniciado o processo de “reprovisionamento”, o status será atualizado:

Novo status:

Aguarde até o status apresentar que o PWA está provisionado:

Verifique se os projetos estão lincados. Para tal, acesse o site do PWA (em meu cenário: http://epmqa.meudominio.local/PWA), “Server Settings”:

Acesse o menu “Project Sites”:

Se os sites não estiverem todos “lincados”, acesse o menu “Bulk Update Project Sites”:

Acesse o menu “Bulk Update Project Sites”:

Preencha os campos “Previous Site Path”, em meu cenário o campo “Web Application” era “http://epm.meudominio.local” e para o campo “Site URL” o nome do PWA era “PWA”;

Para os campos “New Site Path”, em meu cenário o campo “Web Application” é o novo nome do ambiente, “http://epmqa.meudominio.local” e para o campo “Site URL” o nome do PWA era “PWA”;

Por questões de agilizar o processo, eu desmarquei a opção “Synchronize site permissions”, mas aqui se você deseja sincronizar as permissões do seu PWA com cada site, mantenha esta opção marcada;

Preenchidos os campos, apenas clique no botão “Update” e aguarde o processo que em nosso caso durou cerca de 2 horas para 10k projetos e sites;

Para validar o resultado do “Bulk Update Project Sites”, acesse o site PWA, clique no menu “Server settings”, clique no menu “Project Sites”, o resultado deverá ser:

OBS.: Ofuscamos os nomes dos projetos e sites por motivos de segurança.

Esta é a forma correta de ser efetuado um “refresh” de um ambiente (farm) para outro.

User Profile Synchronization services – Starting (for hours)

Se você estiver configurando em um ambiente de FARM de SharePoint 2013 o serviço de User Profile Synchronization, este post http://www.harbar.net/archive/2012/07/23/sp13adi.aspx é um dos melhores.

Mas em meu post, quero compartilhar com vocês um sintoma comum ao tentar iniciar o serviço de User Profile Synchronization após sua devida e correta configuração descrita no link acima, que é o status deste serviço permanecer em “Starting” por muito tempo, logo, não iniciando o mesmo no servidor que você escolheu para tal.

A resolução deste “problema” é bem simples, bastando apenas que você administrador do Farm, reinicie em TODOS os servidores do Farm, o serviço de Timer do SharePoint 2013.

Unable to change User Profile Service Account

Problem

So you made a mistake by trying to change the service application account for the User Profile Service Application. You try to change it back to your farm account but get an ugly error message saying:

An object of the type Microsoft.SharePoint.Administration.SPWindowsServiceCredentialDeploymentJobDefinition named “windows-service-credentials-FIMSynchronizationService” already exists under the parent Microsoft.Office.Server.Administration.ProfileSynchronizationService named “FIMSynchronizationService”.  Rename your object or delete the existing object.

Solution

This problem is quite easy to fix. As the error message clearly states, there is a job that has already been created when you tried to change the the credentials for the UPS service application previously. However, when the provisioning failed the job never ran (it is a one-time job). This job is responsible for updating credentials on all servers that are running the FIM service.

To fix this, you need to delete the job:

1. Open Central Administration -> Monitoring -> Job Definitions.
2. Browse to the last page
3. Delete the job: Windows Service “FIMSynchronizationService” Credential Deployment
4. Go back to Security -> Configure Service Accounts and reset your UPS service to your farm account.
5. Now go back to the Job definitions page, you will see that a new job with the same name has been recreated.

That’s it!

Error relinking Project Site to Project in Project Server 2010

If you are trying to relink a Project Site with its Project through the option “Edit site address” and you are receiving this error message below:

The first thing that you need to verify is the “web.config” file for your PWA application (e.g.: c:\inetpub\wwwroot\VirtualDirectories\epm.domain.local80\), where the default “globalization fileEncoding” TAG is set up for “UTF-8“.

In my scenario we had changed this TAG to “<globalization fileEncoding=”iso-8859-1″ requestEncoding=”iso-8859-1″ responseEncoding=”iso-8859-1″ />” by our developer to test other options. This kind of configuration prevents the PWA application to read URLs with special characters like “http://epm.domain.loca/PWA/Ações requeridas” (PT-BR).

To solve this problem, just swap to the default/Correct TAG:

<globalization fileEncoding=”utf-8″ />

If you don’t have this scenario, you could try to consult this link: http://pwmather.wordpress.com/2011/07/20/error-relinking-project-site-to-project-in-projectserver-2010-ps2010-project-epm/