Default crawled file name extensions and parsed file types in SharePoint Server 2013

Learn which file name extensions SharePoint 2013 crawls by default and which file types it parses by default.

Learn more at:

http://technet.microsoft.com/en-us/library/jj219530(v=office.15).aspx

SharePoint Products Configuration Wizard – Tip

When you will run the “SharePoint Products Configuration Wizard” on a farm that has large databases (greater than 100GB), it’s advisable to change the recovery mode of all SharePoint databases to simple mode, avoiding a possible storage overflow in database log files or disk unit.

After that, adjust the recovery mode of each database following your enterprise rules or the Microsoft recommendation at link http://technet.microsoft.com/en-us/library/cc678868(v=office.15).aspx

Cheers ;-)

Why SharePoint 2013 Content Database grows up fast?

Today (2014.03.07) my DBA colleague got my attention about the fast growth of one of the content database in our SharePoint 2013 farm.

The content DB was normally at 04GB but after something, its size was doubled.

So I started the verification and the first thing that I did was looking for with table inside my Content DB was taking most of the space.

You Can check it from the SQL Server Management Studio. Login to SQL Server Management Studio -> Select your Content DB (Right Click) -> Reports- > Standard Reports -> Disk Usage by Top Tables.

Our report says that the “dbo.AuditData” are taking most of the space inside Content database of our site collection:

My conclusion: if you have enabled something like view auditing, a search crawl that crawls all the content could increase database size because the audit entries are stored inside the content DB. Workflow history events and User Profiles Sync are also stored in the content db and could be another possible explanation for the “mysterious growth”.

I have checked what our customer had set up for Audit in his site, and I have seen that he had selected everything. So if you want to reduce it, you must to decide what really is important for you audit.

More references:

http://technet.microsoft.com/en-us/library/cc678868%28v=office.15%29.aspx

Session: Content database

Content database size estimation

Content database size varies significantly with the usage of the site. Growth factors include the number of documents, number of users, use of versioning, use of Recycle Bins, size of quotas, whether the audit trail is configured, and how many items are chosen for auditing.

If Power Pivot for SharePoint is being used, the Excel files stored in SharePoint Server grow larger, which increases the size of the content database. For more information, see Plan a PowerPivot Deployment in a SharePoint Farm.

For detailed recommendations about how to calculate the size of a content database, see Storage and SQL Server capacity planning and configuration (SharePoint Server 2013).

How to reduce the size of logging database and how to purge the old data from Logging Database

Depending what you have selected to log on SharePoint 2013 logs, the WSS logging database grows very fast and it cause the storage problem most of the time.

In SharePoint 2013, you can selectively collect the ULS and Windows event logs from all the servers in a farm to a central Usage and Health database. The default data retention period is 14 days and bellow, I have my own sample of events selection:

The Logging database stores the following things:

• ULS Logs from 15 Hive\LOGS
• Raw Resources Usage Data

There are two timer jobs used to import and to process the raw data in the database:

1. Microsoft SharePoint Foundation Usage Data Import
2. Microsoft SharePoint Foundation Usage Data Processing

By following PowerShell commands we can check and change the value of retention days for the events selected on this database:

Check settings:

Get-spusagedefinition

Change settings:

Set-SPUsageDefinition 

To reduce the size of the logging database and to purge the old data from the logging database we can follow these steps.

1. Check the retention’s days typing the PowerShell on a SharePoint 2013 Management Shell prompt as administrator:

Get-spusagedefinition

2. Find the Logging Database Name:

Login to Central Administration -> Monitoring -> Configure Usage and health data collection:

Check the name in the “Database Name” of the “Logging Database Server” section:

3. Now you need to find which table is taking most of the space inside the WSS logging Database.

You Can check the same from the SQL Server. Login to SQL Server Management Studio -> Select your logging Database (Right Click) -> Reports- > Standard Reports -> Disk Usage by Top Tables.

Our report says that the “dbo.RequestUsage_*” are taking most of the space inside WSS Logging database, so  you can bring down the retention period of  Page Request Event from 14 to 5 for example.

4. By following the PowerShell below, you will bring down the retentions period of the “Page Requests” from 14 to 5:

Set-SPUsageDefinition -Identity “Page Requests” -DaysRetained 5

5. Run again the PowerShell to check the new value was changed or not:

Get-spusagedefinition

6. After that we need to run the two timer jobs to clean the old data “Microsoft SharePoint Foundation Usage Data Import” and “Microsoft SharePoint Foundation Usage Data Processing”.

Go to Sharepoint Central Administration -> Monitoring -> Configure Usage and health data collection-> Log Collection Schedule:

It will take you to the “Job Definitions” page:

7. Now Click on both the Job Definitions one by one and hit ‘Run Now’ to run the timer jobs:

8. Check if the timer jobs have run with success for all servers of the farm:

9. Once the timer jobs had run with success, you can check and confirm database has released the space. Note that now, I don’t have “dbo.RequestUsage_Partition4″ and “dbo.RequestUsage_Partition3″. It have reduced almost 5GB on my storage.

Alternatively, you can choose bring down all definitions at once time. Below a sample to bring down all definitions to 1 day:

Get-SPUsageDefinition | ForEach-Object {Set-SPUsageDefinition -Identity $_.name -DaysRetained 1}

Once that’s finished, a plain Get-SPUsageDefinition command should confirm that everything’s been set to 1 day.

After that, you can use SQL tools to shrink the database back to a more manageable size on disk. (Reminder, you may not need to have the WSS_Logging database in fully-logged, full recovery mode, which generates larger SQL transaction logs. Simple recovery mode usually works best here and it is the MS recommendation).

You may consider in a large production environments that the best option is to move the Usage and Health database to a separate physical database server using the Powershell below or at least have a separated disk to host this database:

Set-SPUsageApplication -DatabaseServer <DatabaseServerName> -DatabaseName <DatabaseName> [-DatabaseUserName <UserName>] [-DatabasePassword <Password>] [-Verbose]

References:

http://technet.microsoft.com/en-us/library/jj715694.aspx

http://technet.microsoft.com/en-us/library/cc678868(v=office.15).aspx

PowerShell to check all the Farm Solutions Status different of “Deployed”

Initially, that solution was deployed with success on that farm, but for a weird reason that we couldn’t found out the why, that solution begun displaying an error on its status, as described on the screen shot below:

Based on this scenario, we decided to build a PowerShell to check all solutions status on our farms. If it find some solution with error status, it will create a log file pointing the name and the status of the solution and send by email this alert for the administrators.

Here is the PowerShell code:

####################

Add-PSSnapin Microsoft.SharePoint.PowerShell -EA 0

$ServerName = $env:computername

function sendMail($MailMSG) {
#Write-Host “Sending Email”
$attach = new-object Net.Mail.Attachment($MailMSG)

###First, the administrator must change the mail message values in this section
$FromAddress = “adm-web@sharepoint.com.br” #change by your email address
$ToAddress = “adm-web@sharepoint.com.br”      #change by your email address

$MessageSubject = “$ServerName – Alert – Solution Undeployed on Farm”
#$MessageBody = $MailMSG
$MessageBody = “Please verify the attached”
$SendingServer = “smtp.yourcompany.com”         #change by your smt server
###Create the mail message
$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $ToAddress, $MessageSubject, $MessageBody
$SMTPMessage.Attachments.Add($attach)
###Send the message
$SMTPClient = New-Object System.Net.Mail.SMTPClient $SendingServer
$SMTPClient.Send($SMTPMessage)
$attach.dispose()
}

# Get current date and format it to avoid invalid characters such as “/” and “:”

$today=Get-Date -format “MM-dd-yyyy HH.mm.ss”

# Replace with your script location

$Location=”D:\Softwares\CheckFarmSolutionScript”

# Replace with your desired log file location + name

$logFile=”$Location\LogSOLUTIONS.log”

If (Test-Path $logFile){
Remove-Item $logFile -Confirm:$false
}

function List-Solutions()
{
$farm = Get-SPFarm
foreach ($solution in $farm.Solutions)
{

if($solution.Deployed -eq $false){
Write “Solution Verification started at $today” >>$logFile
Get-SPSolution -identity $solution.Name >>$logFile

}
}
}

#call the function List-Solutions

#test if the log file exists, If yes, send an email

If (Test-Path $logFile){

sendMail($logFile)

}
####################

Cannot start service SPAdminv4 on computer – SharePoint 2010 Administration

If you’ve experienced this error (System.InvalidOperationException, “Cannot start service SPAdminv4 on computer ‘.’) after installing/rebooting a SharePoint 2010 server and failing consistently at the SharePoint 2010 Products Configuration Wizard, then this is likely to help:

(1) Browse to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN

(2) In this directory Create a file called “WSSADMIN.EXE.CONFIG“

(3) Populate it with the following:

<configuration>

      <runtime>

<generatePublisherEvidence enabled=“false”/>

      </runtime>

</configuration>

(4) Start the “SharePoint 2010 Administration” services again

Now everything should be working….

This disables checking for CAS (Code Access Security) publisher policy. MSDN article, http://msdn.microsoft.com/en-us/library/bb629393.aspx

More details, read http://blogs.msdn.com/johan/archive/2009/11/12/make-sure-you-have-an-internet-connection-when-using-signed-assemblies.aspx and http://blogs.msdn.com/dsvc/archive/2008/06/24/troubleshooting-startup-issues-with-managed-application-having-authenticode-signature.aspx

HOW TO: Como Habilitar o Developer Dashboard no SharePoint 2010

Developer Dashboard  é um novo recurso do SharePoint 2010 que vem para facilitar a vida do desenvolvedor e do responsável pelo bom desempenho e melhor experiência para o usuário final. Este recurso mostra quanto tempo uma página demorou para ser carregada e quais componentes foram carregados, sendo muito útil quando os usuários reclamam de lentidão, podendo assim, agora classificar o que seria e aonde esta “lentidão”, de forma mais fácil e rápida.

Solução:

Por default, este recurso vem desabilitado. Para habilitar, você pode utilizar o stsadm ou Windows PowerShell.

Para habilitar, usando STSADM, vá em Start > Microsoft SharePoint 2010 Products, clique em SharePoint 2010 Management Shell, e entre com o seguinte valor:

Stsadm –o setproperty –pn developer-dashboard –pv [modo]

Em [modo] , escolha a forma que você quer que ele funcione. Você pode escolher uma das três opções:

• On – significa que o Developer Dashboard  será sempre exibido
• Off – significa que estará desabilitado
• Ondemand – significa que o Developer Dashboard  será exibido, mas não estará ativo, apenas quando precisar você deve ativá-lo clicando no seu ícone.

Ao habilitar este recurso, todas as páginas irão conter um ícone do Dashboard, como mostrado na imagem, porém, só os administradores do Site Collction poderão ver.

Caso tenha escolhido o modo ondemand, você pode habilitá-lo quando necessário apenas clicando sobre o ícone dele.

Figura 1: Representação do ícone

Quando habilitado, ele trará uma página com os resultados para análise.

Figura 2: Exibindo as informações

Agora basta você realizar suas análises.

Conclusão

Esta função é muito útil para os desenvolvedores para que eles possam entregar aplicações que funcionam corretamente sem ter problemas posteriores e também ajuda a detalhar o como a página e as web parts estão se comportando.

Mais referências:

http://larahvidotti.wordpress.com/2011/01/14/como-habilitar-o-developer-dashboard-no-sharepoint-2010/