Powershell for sharepoint

SharePoint 2010 Cookbook: 5 Best Practices to Configure Diagnostic Logging with PowerShell Commands
SharePoint diagnostic logging is very important, and extremely helpful when we encounter problems with our SharePoint environment. However, diagnostic logging can be ineffective at times, and can even cause SharePoint performance to slow down if it's not managed properly. In this post, I will demonstrate how to configure SharePoint 2010 diagnostic logging, following Microsoft's best practices, in just a few PowerShell commands. After all, it always pays to be prepared for a rainy day.
Challenge:
How can I quickly configure diagnostic logging to make the best use of it?
Solution:
First, verify that you possess the following permissions:
  • SharePoint Farm Administrator
  • Local Server Administrator on all Web servers.
Next, open the SharePoint 2010 Management Shell. From the Start menu, select All Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell.
http://community.bamboosolutions.com/resized-image.ashx/__size/700x0/__key/CommunityServer.Blogs.Components.WeblogFiles/sharepoint-2010/Configure-Diagnostic-Logging-01.png
Here are the five best practices to configure SharePoint 2010 diagnostic logging:
1. Change the drive that logging writes to. By default, diagnostic logging is written to "%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\Logs" which is in the same disk drive and partition that SharePoint 2010 was installed on. This could cause a performance problem if the logs continue to grow, and more logs are being written to the same drive. Therefore, we should configure logging to write to a different drive by using the following PowerShell command. Note: The location that you specify must be a valid location on all servers in the server farm:
Set-SPDiagnosticConfig -LogLocation <PathToNewLocation>
http://community.bamboosolutions.com/resized-image.ashx/__size/700x0/__key/CommunityServer.Blogs.Components.WeblogFiles/sharepoint-2010/Configure-Diagnostic-Logging-02.png

2. Restrict log disk space usage. By default, the amount of disk space that is available for diagnostic logging is unlimited. We should limit the log disk space usage to prevent the disk from filling up. Enter the follwoing two commands in the SharePoint 2010 Management Shell (the usage value is between 1 and 1,000 gigabytes):
Set-SPDiagnosticConfig -LogMaxDiskSpaceUsageEnabled
Set-SPDiagnosticConfig -LogDiskSpaceUsageGB <UsageInGB>
http://community.bamboosolutions.com/resized-image.ashx/__size/700x0/__key/CommunityServer.Blogs.Components.WeblogFiles/sharepoint-2010/Configure-Diagnostic-Logging-03.png

3. Use the Verbose setting sparingly. Sometimes, you might want to configure diagnostic logging to the Verbose level when you are making critical changes. At this level, the system will log every action that SharePoint takes. This can be easily done using the PowerShell command below. Keep in mind, however, that you should change back to higher-level logging afterwards because Verbose logs can consume a lot of space and affect performance.
Set-SPLogLevel -TraceSeverity Verbose
http://community.bamboosolutions.com/resized-image.ashx/__size/700x0/__key/CommunityServer.Blogs.Components.WeblogFiles/sharepoint-2010/Configure-Diagnostic-Logging-04.png

4. Regularly backup logs. The diagnostic logs are very important and could come in especially handy when you least expect it. We should backup logs regularly, especially if we are restricting log disk space usage, because old logs will be deleted without notification. For this article, I have written a PowerShell script to backup SharePoint logs so you can schedule it to run automatically. This script does the following:
  • Check whether any log file exists in the backup location.
  • If there's no log file, merge the last hour of SharePoint log data from all servers and save to the local backup location.
  • If a backup log already exists, merge SharePoint logs from the time the last backup was run until the current date/time.

# PowerShell script to backup SharePoint 2010 diagnostic logs

Add-PsSnapin Microsoft.SharePoint.PowerShell

Start-SPAssignment -Global    # This cmdlet takes care of the disposable objects to prevent memory leak.

$backupLocation = "C:\Backup\ULSLog"    # Replace with your backup location
$today = Get-Date            # Get current date
$todayEdited = Get-Date -format "MM-dd-yyyy HH.mm.ss"    # Get current date and format it to avoid invalid characters such as "/", ":"

# Get the latest backup log file by sorting the file list at the backup location, then select the last item
$lastLogFile= Get-ChildItem $backupLocation\*.* | Sort-Object name | Select-Object -last 1

# If no log file exists at the backup location, merge the last hour of SharePoint log data from all servers.
# In this example, I only get the logs that have level High or above to prevent overload.
# Available levels are: Unexpected, Monitorable, High, Medium, Verbose, VerboseEx

if ($lastLogFile -eq $null)   
{
    write-Host Merging logs from all servers in the last hour
    Merge-SPLogFile –Path "$backupLocation\$todayEdited.log" –Overwrite -Level High
}

else    # If a log file already exists, merge SharePoint logs from last backup run until now
{
    # Format the log file name and convert it to DateTime object
    $lastRunTime = Get-Date $lastLogFile.Name.TrimEnd(".log").Replace(".",":")

    write-Host Merging logs from $lastRunTime until now
    Merge-SPLogFile –Path "$backupLocation\$todayEdited.log" –StartTime $lastRunTime –EndTime $today –Overwrite -Level High
}

Stop-SPAssignment -Global

Remove-PsSnapin Microsoft.SharePoint.PowerShell

write-Host "Finished script."
For your convenience, I have attached both the script and the batch file to run it at the end of this post.
5. Enable event log flooding protection. When this option is enabled, the system will detect repeating events in the Windows Event log and suppress them until conditions return to a typical state.
Set-SPDiagnosticConfig -EventLogFloodProtectionEnabled
http://community.bamboosolutions.com/resized-image.ashx/__size/700x0/__key/CommunityServer.Blogs.Components.WeblogFiles/sharepoint-2010/Configure-Diagnostic-Logging-05.png

Cmdlet name
Description
Resets the Windows trace logging and event logging levels to their default values.
Returns a list of objects or diagnostic levels.
Sets the trace and event level for a set of categories.
Returns results from a Unified Logging Service (ULS) trace log.
Retrieves ULS diagnostic configuration values of the farm.
Returns a diagnostics provider.
Combines trace log entries from all farm computers into a single log file on the local computer.
Creates a new log file.
Starts a new usage log file on the current server computer.
Sets diagnostic configuration settings on the farm.
Enables a diagnostics provider and updates its retention policy.

Event log levels

Level
Definition
None
No logging occurs.
Critical
This message type indicates a serious error that has caused a major failure in the solution.
Error
This message type indicates an urgent condition. All error events should be investigated.
Warning
This message type indicates a potential problem or issue that might require attention. Warning messages should be reviewed and tracked for patterns over time.
Information
Information messages do not require any action, but they can provide valuable data for monitoring the state of your solution.
Verbose
This event log level corresponds to lengthy events or messages.

Trace log levels

Level
Definition
None
No trace logs are written.
Unexpected
This level is used to log messages about events that cause solutions to stop processing. When set to log at this level, the log will only include events at this level.
Monitorable
This level is used to log messages about any unrecoverable events that limit the solution’s functionality but do not stop the application. When set to log at this level, the log will also include critical errors (Unexpected level).
High
This level is used to log any events that are unexpected but which do not stall the processing of a solution. When set to log at this level, the log will include warnings, errors (Monitorable level) and critical errors (Unexpected level).
Medium
When set to this level, the trace log includes everything except Verbose messages. This level is used to log all high-level information about operations that were performed. At this level, there is enough detail logged to construct the data flow and sequence of operations. This level of logging could be used by administrators or support professionals to troubleshoot issues.
Verbose
When set to log at this level, the log includes messages at all other levels. Almost all actions that are performed are logged when you use this level. Verbose tracing produces many log messages. This level is typically used only for debugging in a development environment.

You can use Windows PowerShell to configure diagnostic logging.
To configure diagnostic logging by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
  2. On the Start menu, click All Programs.
  3. Click Microsoft SharePoint 2010 Products.
  4. Click SharePoint 2010 Management Shell.
  5. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:
Set-SPLogLevel -TraceSeverity {None | Unexpected | Monitorable | Medium | High | Verbose} -EventSeverity {None | Information | Warning | Error | Critical | Verbose} [-Identity <Category name...>]  -Verbose
You can use the Identity parameter to specify one or more categories to change — for example, Administration. If you do not specify the value for the Identityparameter, all categories are changed.
To view the current settings, type Get-SPLogLevel, and then press ENTER.
To set all categories back to default levels, type Clear-SPLogLevel, and then press ENTER.


Deployment: In this article we will be seeing how to deploy a wsp file using Power Shell in SharePoint 2010 and how to install, activate, deactivate and uninstall the features.

Steps Involved:

Go to All Programs => Microsoft SharePoint 2010 Products =>SharePoint 2010 Management Shell =>Run as administrator.

1.gif 

Adding the solution:

Add-SPSolution "C:\Users\sjfa\Desktop\WSPTest\WSPTest\bin\Debug\WSPTest.wsp"

2.gif 

You have successfully added the solution; it gives the Name, Solution Id and Deployed status of the wsp file.

The Deployed status is false, we have just added the wsp file but not deployed.

Deploying the solution:

Install-SPSolution -identity "WSPTest.wsp" –GACDeployment

3.gif

Sometimes when you install the solution you may get the following error.

4.gif

How to resolve this:
  • Go to Run.
  • Type services.msc.
  • Services window will open.
  • Start SharePoint 2010 Administration service.
5.gif

Retracting the Solution:

Uninstall-SPSolution -identity "WSPTest.wsp"

Removing the solution:

Remove-SPSolution -identity "WSPTest.wsp"

Installing the feature:

Install-SPFeature "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\WSPTest_WSPContentTypeFeature"

6.gif

Where "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\WSPTest_WSPContentTypeFeature" is the Folder Name Path.

Activating the feature:

Enable-SPFeature -Identity "GUID" -Url "http://servername:2010"

7.gif 

Deactivating the feature:

Disable-SPFeature -Identity "GUID" -Url "http://servername:2010"

8.gif

Uninstalling the feature:

Uninstall-SPFeature -Identity "GUID"


2..Deployment: In my Scenario, I have 2 WSP files:
·         NewSolutionPack.wsp (to add it as first time)
·         UpdateSolutionPack.wsp (to update an exist WSP file)
·         Target web application (http://sps:1)
clip_image001[7]

The steps of deployment are easy:
1. Add solution to Farm Solutions
2. Deploy your solution to a specific web application or to all web applications
3. In case of exists solution, you will upgrade the solution using one of the following options:
a. Retract and delete the old solution, then add and deploy the new one
b. Or, upgrade the existing solution using upgrade method (recommended).

Steps of deployment using STSADM
1. Add solution to Farm Solutions
a. Open cmd (Star > Run > write cmd in box > click ok)
clip_image002[7]
b. Mont the folder that contain stsadm execution file (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN)
clip_image004[7]
clip_image006[7]
c. Enter the following script
stsadm -o addsolution -filename “C:\WSP Deployment\NewSolutionPack.wsp”
clip_image008[7]
2. Deploy your solution
a. To a specific web application
stsadm -o deploysolution -name “NewSolutionPack.wsp” -url “http://sps:1&#8221; –allowgacdeployment -immediate –allowcaspolicies
clip_image010[7]

Check it from Central Administration > System Settings > Manage Farm Solutions

clip_image012[7]
b. To all web applications
stsadm -o deploysolution -name “NewSolutionPack.wsp” -allcontenturls -allowgacdeployment -immediate –allowcaspolicies

clip_image014[7]
3. Upgrade the solution by Retract and delete the old solution, then add and deploy the new one
a. stsadm -o retractsolution -name “NewSolutionPack.wsp” -url “http://sps:1&#8221–immediate
if you want to retract the solution from all web applications, you need to use this
stsadm -o retractsolution -name “NewSolutionPack.wsp” -allcontenturls –immediate
b. stsadm -o deletesolution -name “NewSolutionPack.wsp”
c. stsadm -o addsolution -filename “C:\WSP Deployment\NewSolutionPack.wsp”
d. stsadm -o deploysolution -name “NewSolutionPack.wsp” -allcontenturls -allowgacdeployment -immediate –allowcaspolicies
4. Upgrade the solution by using upgrade method
a. Enter upgrade script
stsadm -o upgradesolution -name “NewSolutionPack.wsp” -filename “C:\WSP Deployment\UpdateSolutionPack.wsp” -allowgacdeployment -immediate –allowcaspolicies
clip_image016[7]
Steps of deployment using PowerShell
1. Add solution to Farm Solutions
a. Open PowerShell (SharePoint 2010 Management Shell)
clip_image018[7]
b. Enter the following script:
Add-SPSolution “C:\WSP Deployment\NewSolutionPack.wsp”
clip_image020[7]
2. Deploy your solution
a. To a specific web application
Install-SPSolution -Identity “NewSolutionPack.wsp” -WebApplication “http://sps:1&#8221-GACDeployment -CASPolicies -Confirm:$false
b. To all web applications
Install-SPSolution -Identity “NewSolutionPack.wsp” -AllWebApplications -GACDeployment -CASPolicies -Confirm:$false
3. Upgrade the solution by Retract and delete the old solution, then add and deploy the new one
a. Uninstall-SPSolution -Identity “NewSolutionPack.wsp” -WebApplicationhttp://sps:1&#8221; -Confirm:$false
if you want to retract the solution from all web applications, you need to use this
Uninstall-SPSolution -Identity “NewSolutionPack.wsp” -AllWebApplications -Confirm:$false
b. Remove-SPSolution -Identity “NewSolutionPack.wsp” -Confirm:$false
c. Add-SPSolution “C:\WSP Deployment\NewSolutionPack.wsp”
d. Install-SPSolution -Identity “NewSolutionPack.wsp” -WebApplication “http://sps:1&#8221-GACDeployment -CASPolicies -Confirm:$false
4. Upgrade the solution by using upgrade method:
Update-SPSolution -Identity “NewSolutionPack.wsp” -LiteralPath “C:\WSP Deployment\NewSolutionPack.wsp” -GacDeployment -CASPolicies -Confirm:$false
For more information about mapping from stsadm to PowerShell, read the full MSDN topic: Stsadm to Windows PowerShell mapping (SharePoint Foundation 2010)

Backup&restore:
The following are examples of different SharePoint PowerShell commands you can use to back up and restore various components of your SharePoint environment.
A complete farm backup followed by a restore:
Backup-SPFarm –Directory \\App01\SharePointBackups -BackupMethod Full 
Restore-SPFarm –Directory \\App01\SharePointBackups -RestoreMethod New
Back up and restore a service application:
Backup-SPFarm –Directory \\App01\SharePointBackups -BackupMethod Full –Item "Excel Services" 
Restore-SPFarm –Directory \\App01\SharePointBackups -RestoreMethod New –Item "Excel Services"
Back up and restore farm configuration information only:
Backup-SPConfigurationDatabase –Directory \\App01\SharePointBackups 
Restore-SPFarm –Directory \\App01\SharePointBackups –RestoreMethod Overwrite –ConfigurationOnly
Back up and restore your SharePoint content databases: 
Backup-SPFarm –Directory \\App01\SharePointBackups -BackupMethod Full –Item ContosoPortal 
Restore-SPFarm –Directory \\App01\SharePointBackups -RestoreMethod New –Item ContosoPortal

Back up and restore a site collection: 
Backup-SPSite –Identity http://App01/Sites/ContosoPortal -Path \\App01\SharePointBackups\PortalSiteCollection.bak -Force 
Restore-SPSite –Identity http://App01/Sites/ContosoPortal -Path \\App01\SharePointBackups\PortalSiteCollection.bak –Force

Export and import a subsite, list, or library:

Export-SPWeb –Identity http://App01/Sites/ContosoPortal/ -Path \\App01\SharePointBackups\SharedDocuments.bak -Itemurl "Shared Documents" -Force 
Import-SPWeb –Identity http://App01/Sites/ContosoPortal/ -Path \\App01\SharePointBackups\SharedDocuments.bak –Force -IncludeUserSecurity
To attach or detach a content database by using Windows PowerShell
  1. Verify that you have the following memberships:
    • securityadmin fixed server role on the SQL Server instance.
    • db_owner fixed database role on all databases that are to be updated.
    • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
    An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 Products cmdlets.
    NoteNote:
    If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.
  2. On the Start menu, click All Programs.
  3. Click Microsoft SharePoint 2013 Products.
  4. Click SharePoint 2013 Management Shell.
  5. At the Windows PowerShell command prompt, type the appropriate command
    To attach an existing content database:
    Mount-SPContentDatabase "<ContentDb>" -DatabaseServer "<DbServer>" -WebApplication http://SiteName
    
    Where:
    • <ContentDb> is the content database to be attached.
    • <DbServer> is the name of the database server.
    • http://SiteName is the name of the web application to which the content database is being attached.
    To detach a content database:
    Dismount-SPContentDatabase "<ContentdBName>"
    
    Where <ContentdBName> is the name of the content database.
    ImportantImportant:
    If you have multiple content databases that have the same name, you must use the content database GUID in this command instead of using the content database name. To retrieve the GUID of the content database, run the Get-SPContentDatabase cmdlet with no arguments.
    The Dismount-SPContentDatabase cmdlet detaches the content database from the web application, but it does not delete the content database from SQL Server. After a content database is detached, you cannot delete it by using Windows PowerShell 3.0. You can only remove it by using SQL Server tools. If you want to delete the content database from SQL Server while you detach it, use the Remove-SPContentDatabase cmdlet instead.

Comments

Popular Posts