Thủ thuật Sharepoint 2010 part 78 pps

OWA PowerShell Activation  579 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. 580  CHAPTER 19 the office WeB aPPlicatioNs 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 OWA PowerShell Activation  581 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 SPDatabasePindBind value for the SharePoint_config database. This is obtained 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 services 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 582  CHAPTER 19 the office WeB aPPlicatioNs 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”) OWA PowerShell Activation  583 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 “OfceWebApps”}).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/nance |% {}{$_.Lists}{$_.Update() }|% {$_.DefaultItemOpen = $false} 584  CHAPTER 19 the office WeB aPPlicatioNs SUMMARY 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. . 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. 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. following script. Replace the sharepoint2 010 and server2 names with your specific server names, adding additional servers as appropriate: $machinesToActivate = @( sharepoint2 010”, “server2”) $serviceInstanceNames