Showing posts with label PowerShell. Show all posts
Showing posts with label PowerShell. Show all posts

Thursday, March 28, 2013

How to find SharePoint farm ID in Configuration database


To find Farm ID the following SharePoint Management shell (or PowerShell) command could be used:

$spFarm=[Microsoft.SharePoint.Administration.SPfarm]::Local
$spFarm.Id

Farm ID could be also found in Configuration database by running the following SQL query:


SELECT * From Objects where ClassId = ’674DA553-EA77-44A3-B9F8-3F70D786DE6A’

The '674DA553-EA77-44A3-B9F8-3F70D786DE6A' GUID is always a ClassID for Farm object.

More information here

Wednesday, July 6, 2011

Farm Admin in SharePoint 2010

When you add a user into Farm Administrators group in SharePoint 2007 it automatically added as db_owner for the config database. So, I assumed SP2010 works the same way, but it does not.

When you add a user into Farm Administrators group it is automatically added into WSS_ADMIN_WPG group only. 

Refer to the following article to find out which permissions the group has.
In few words it has permissions to system folders on the SP server.
The account does not have direct access to SQL databases, so there will be problems for any third party tools which work with SharePoint through API

The difference is that when you're working with SharePoint via Central Administration you're actually working with databases under Application Pool account. But when you're working via API (SharePoint Object Model for example) you're working in the context of the account executing API calls. So, to get the API calls working you should grant direct access to SharePoint databases.


If you do not want to grant direct access to configuration database you can use PowerShell command:
Add-SPShellAdmin –username <String>
The command adds the user to the SharePoint_Shell_Access role. In fact, those users who included in the role have db_owner access to the Configuration database.
To get a list of users included into the group execute the following comm and:
Get-SPShellAdmin
Refer to the following article for details about required permissions to run PowerShell.
Refer to the following article for details about the SharePoint_Shell_Access role.

Also if you receive the error message when using STSADM, that may mean you run it under a Farm Administrator user who does not have direct access to SP databases. The error message is the following:

This operation can be performed only on a computer that is joined to a server farm by users who have permissions in SQL Server to read from the configuration database. To connect this server to the server farm, use the SharePoint Products Configuration Wizard, located on the Start menu in Microsoft SharePoint 2010 Products.

Saturday, November 13, 2010

Executing PowerShell script for SharePoint in msi.

If you want to execute PowerShell script in msi written with WIX you may face some problems. Here I explain issues I had in my project:
To execute the script you need to create custom action which runs PowerShell. Note that you cannot run SharePoint Management Shell (at least I didn't find how to do that :). But you can run PowerShell and load SharePoint snap-in inside the script:


<CustomAction Id="PSExecute" Property="PS" ExeCommand="&'[FOLDER]\install-extension.ps1'" Execute='deferred' Return='check'/> 


The script execution may fail due to some reasons. For example, SharePoint Administration service is not running, PowerShell Execution Policy prevents scripts from running, you run msi under account who is not SharePoint Farm administrator. Maybe there are another reasons that I don't know yet ;)

When the script is executed from msi, the PowerShell console is running but you should be a very fast person to catch its output :) So, it is required to add logging into your script. Using Start-Transcript is the only that I'm able to use. Refer to the following post for more information about Start-Transcript.

One more useful thing is "throw 'ERROR'" to abort the script execution if needed. For example SP-GetObject and SP-AddSolution cmdlets may throw errors during execution but they will not cause the script to be completed with error. And installer completes successfully but it actually does not do anything. You can add throw 'ERROR' where is needed and installation ends with Fatal Error.