Thủ thuật Sharepoint 2010 part 78 pps

With STSADM, the user is required to be a local administrator, a SharePoint Farm Administrator, and have specific SQL Server permissions.. In general, PowerShell simplifies this because

multiple‑Server Farm Install

The multiple-server install process is exactly the same as the single-server install except that the setup application must be executed on every server in the server farm that will host the Office Web Application functionality The other difference is that the PowerShell commands for activating the services on a single server that is also a domain controller may not need to be executed because in a multiple-server install the domain controller is usually a separate physical server

OWA POWERShELL ActIvAtION

PowerShell commands can also be used to create and activate the OWA service applications

The PowerShell commands can be executed from any server in the farm that has the OWA

installed SharePoint administrators are likely to be only now becoming familiar with PowerShell,

as SharePoint 2010 is the first SharePoint version to recommend use of the technology

Powershell Permissions

Historically, SharePoint administrators have used Central Administration and the command-line tool STSADM for administering the SharePoint farm One of the challenges of using these tools was the specific permissions that were required

The SharePoint administrator needed to be a Farm Administrator to access the Central Administration (CA) web site; this meant that the administrator had to be a member of the Farm Administrators Group This membership gave the administrator access to use the CA web site to execute operations against the configuration database through the CA web application These operations were executed

in the security context of the application pool account for the web application, not the administrator This situation differs with the STSADM command environment and PowerShell

STSADM and PowerShell commands are run in the security context of the user executing the com-mands The good news is that this enables commands to be run from any server in the farm because

CA is not required The challenge is that this requires the user to have the necessary permissions to complete the operation the commands are implementing With STSADM, the user is required to be

a local administrator, a SharePoint Farm Administrator, and have specific SQL Server permissions

In general, PowerShell simplifies this because the administrator or user who is executing the PowerShell commands against the SharePoint 2010 farm only requires PowerShell and SQL Server permissions Obviously, because each PowerShell command utilizes the SharePoint object model, additional permis-sions may be necessary for specific PowerShell commands, such as installing SharePoint 2010, Windows file system manipulation, and registry changes Therefore, in general, administrators need to have the following two permissions to execute PowerShell commands:

The user must be a member of the Windows group WSS_ADMIN_WGP on the server being

➤

➤

used to execute the commands

The user must be a member of the SQL Server role called SharePoint_Shell_Access on the

➤

➤

configuration database

At this point in the installation, the administrator should confirm that the WSS_ADMIN_WGP group exists and that the Administrator account has been added to the group The SharePoint_Shell_Access role exists on the configuration database but does not show any members, but keep in mind that the Administrator account is the owner of the role

A PowerShell command called SPShellAdmin has been added to the list of preconfigured SharePoint commands to simplify the management of these roles SPShellAdmin will add and remove Shell Administrators Let’s take a look at this command

1 From the Start menu, type PowerShell, right-click the Windows PowerShell ISE option from the

list, and click Run as administrator The PowerShell Integrated Scripting Environment (ISE) is displayed, as shown in Figure 19-35 This environment provides a better approach to using and investigating PowerShell commands

FIguRE 19-35

Unfortunately, the SharePoint 2010 PowerShell commands are not automatically loaded and registered into the environment like they are when you click the SharePoint 2010 Management Shell shortcut, so the SharePoint commands must be added manually

2 At the PS C:\Users\Administrator prompt inside the ISE window, type the following command to register the SharePoint commands:

Add-PSSnapin Microsoft.SharePoint.Powershell

3 Type Get-Help SPShellAdmin at the shell prompt in the window as before Three separate

com-mandlets are listed, along with their synopses (summaries of their parameter requirements):

Get-SPShellAdmin

Add-SPShellAdmin

Remove-SPShellAdmin

These three commands have a database parameter that allows the administrator to designate

a specific database, because by default the SharePoint_Shell_Access role allows access only to the configuration database Each additional database access required must be given individu-ally Try adding a user to the SharePoint_Shell_Access role using the SPShellAdmin command-let Keep in mind that the syntax for the Add-SPShellAdmin commandlet is as follows:

Add-SPShellAdmin [-UserName] <String> [-database <SPDatabasePipeBind>]

4 Before you can execute the Add-SPShellAdmin commandlet, you need the

by executing the following command:

Get-SPDatabase

The Name, Id, and Type property information should be displayed in the ISE The value of the

Id is the SPDatabasePipeBind value that you will need to include in the Add-SPShellAdmin

commandlet

5 Type and execute the following command Copy the Id value for the SharePoint_config data-base into the command Make sure the sp_admin account exists or utilize another account The command should add the sp_admin account to the SharePoint_Shell_Access role in the SharePoint_config database The results are shown in Figure 19-36

add-spshelladmin -username “contoso\sp_admin”

-database 67256615-0d6f-467f-b17a-9de983c71563

After this brief tutorial, you should be ready to use PowerShell to manually create and activate the OWA service applications, as discussed in the next section

service Creation and activation

Manual activation of the Office Web Applications is only required if the Farm Configuration Wizard has already been executed, as this process creates and registers the service and proxy instances Before executing the PowerShell commands, it is advised that you check the state of your SharePoint farm ser-vices and service applications in the Manage serser-vices on server and Manage service applications pages

in SharePoint Central Administration If the OWA services are not running, or the service applications

do not exist, you will need to perform the following steps

1 Verify that the user executing the PowerShell commands meets the following minimum

requirements:

Is a member of the SharePoint_Shell_Access role on the configuration database

➤

➤

Is a member of the WSS_ADMIN_WPG local group on the computer where

➤

➤

SharePoint 2010 is installed

FIguRE 19-36

2 Open the PowerShell ISE with administrator privileges You can also open the shell environment

by using the SharePoint 2010 Management Shell if you prefer

3 In the PowerShell console, at the command prompt, type and execute the following command

as described in the previous section so that the SharePoint commandlet library is available:

Add-PSSnapin Microsoft.SharePoint.Powershell

4 The environment needs to be configured to execute PowerShell scripts in an unrestricted manner Execute the following command to set policy When prompted with the Execution Policy Change dialog, click Yes

set-executionpolicy unrestricted

5 Next, the service instances must be started for each server that is executing the OWA service applications Execute the following script Replace the sharepoint2010 and server2 names with your specific server names, adding additional servers as appropriate:

$machinesToActivate = @(“sharepoint2010”, “server2”)

$serviceInstanceNames = @(“Word Viewing Service”, “PowerPoint Service”,

“Excel Calculation Services”)

foreach ($machine in $machinesToActivate) {

foreach ($serviceInstance in $serviceInstanceNames){

$serviceID = $(Get-SPServiceInstance | where

{$_.TypeName -match $serviceInstance} | where

{$_.Server -match “SPServer Name=”+$machine}).ID

Start-SPServiceInstance -Identity $serviceID

}

}

6 The next step is to create the service applications and proxies after the service instances have been started The applications and proxies connect the WFE to the service applications Execute the following script to create the applications and proxies:

$appPool = Get-SPIisWebServiceApplicationPool –Name “SharePoint Web Services Default”

New-SPWordViewingServiceApplication –Name “WdView” –AppPool $appPool |

New-SPWordViewingServiceApplicationProxy –Name “WdProxy”

New-SPPowerPointServiceApplication –Name “PPT” –AppPool $appPool |

New-SPPowerPointServiceApplicationProxy –Name “PPTProxy”

New-SPExcelServiceApplication –Name “Excel” -SPIisWebApplicationPool

$appPool |

7 The OWA feature can be manually activated on specific site collections in the farm or activated across all site collections using the following script:

$webAppsFeatureId = $(Get-SPFeature -limit all | where {$_.displayname

-eq “OfficeWebApps”}).Id

Get-SPSite –limit ALL |foreach{

Enable-SPFeature $webAppsFeatureId –url $_.URL }

8 Once the OWA feature is activated, documents will be opened using the corresponding web application, not the desktop application This can be reconfigured so that documents are opened

in the desktop application but not the web application The following two sets of scripts recon-figure the default behavior for all site collections and all document libraries in the finance site, respectively This completes the manual OWA activation You can proceed with testing the install as previously discussed in the “Feature Activation and OWA Testing” section

$webAppsFeatureId = $(Get-SPFeature -limit all | where {$_.displayname

-eq “OpenInClient”}).Id

Get-SPSite –limit ALL |foreach{

Enable-SPFeature $webAppsFeatureId –url $_.URL }

Get-SPWeb –site http://www.demo.com/sites/finance |% {}{$_.Lists}{$_.Update() }|% {$_.DefaultItemOpen = $false}

The Office Web Applications enhance the productivity of SharePoint users and information workers by providing the capability to access, create, and edit Word, Excel, PowerPoint, and OneNote documents using a web browser These applications are deployed to SharePoint Server

2010 and can be installed in single-server or multiple-server SharePoint farms

The installation requires three phases First, the OWA are installed using a setup application Second, the service applications that support this functionality must be created and activated Finally, the OWA feature must be activated for each site collection in the farm that will utilize the functionality SharePoint administrators can rely on the configuration wizards to assist in the configuration of the second and third phases, or use PowerShell commands for these phases