I discovered what I thought was a strange issue with SharePoint 2010. The issue was that anonymous users were unable to post comments on a blog site. To be more specific, this blog site was part of a site collection that was provisioned as a Publishing Portal. Simply stated, the blog site is a sub-site under a publishing portal site. Comments on a blog site are stored as a list. List permissions can be modified “stopping inheritance” to allow anonymous users read/write access to a list. In theory, anonymous users should be able to read/write to a list. This is true except when the site collection is based on a publishing portal. In this specific scenario, anonymous users are prompted for credentials when attempting to post a comment within a blog site. Just like in Moss 2007, SharePoint 2010 has a feature called ViewFormPagesLockdown. This feature prevents anonymous users from gaining access to certain areas of a site. I’m not going to go any further in detail because it’s documented very well by our ECM team here:
http://blogs.msdn.com/ecm/archive/2007/05/12/anonymous-users-forms-pages-and-the-lockdown-feature.aspx
This feature still exists in SharePoint 2010 and is still automatically turned on for Publishing Portal sites. This feature is referred to as lockdown mode and can be turned on or off by enabling/disabling the ViewFormPagesLockdown feature. In this scenario, I want to toggle lockdown mode to off so anonymous users can post comments to the blog site. This is accomplished by using either STSADM or PowerShell. I prefer using PowerShell:
To determine if a site has ViewFormPagesLockdown enabled run the following:
get-spfeature -site http://sitecollectionURL
If ViewFormPagesLockDown is listed, it's enabled.
To toggle lockdown mode to off:
$lockdown = get-spfeature viewformpageslockdown
disable-spfeature $lockdown -url http://sitecollectionURL
If anonymous is already setup, you may need to disable\re-enable anonymous on the site.
I’ve seen more than one major issue affecting multiple service applications due to the same cause. If SharePoint 2010 service accounts don’t have appropriate rights in Active Directory, you may see common things fail like the following:
For Example:
Related to Search: Attempting to search throws “Unable to display this web part” error.
Related to Profiles: Unable to provision user profile synchronization service “local instance” on a server.
For both of these issues, the ULS logs contain the following event:
AuthzInitializeContextFromSid failed with GLE: 5
In SharePoint 2010, most service accounts require some specific access to Active Directory or certain functions will fail. SharePoint 2010 uses AuthzInitializeContextFromSid function. In a service application scenario, this function runs under the context of the associated service account and performs an S4U logon.
From MSDN:
AuthzInitializeContextFromSid attempts to retrieve the user's token group information by performing an S4U logon.
In order to call the AuthzInitializeContextFromSid, the caller “service account” needs to able to read the TGGAU attribute. In Windows 2000 and Windows 2003 domain, members of the Pre-Windows 2000 Compatibility Access group are able read the TGGAU attribute. At a minimum, certain service accounts like the search service account need to be a member of this group. See the resources section for more information.
Resources:
http://msdn.microsoft.com/en-us/library/aa376309(VS.85).aspx
http://support.microsoft.com/kb/842423
This blog is to provide a quick ramp up on SharePoint 2010’s new Shared Service Architecture. Some new concepts are introduced and this is part 1 of a 2 part series on this topic. Part 1 is for describing the components and concepts that are behind this new model. Part 2 will discuss using Shared Services with multiple farms. Special thanks to Sheyi for the knowledge transfer as well as technical review.
Shared Service Basics
Shared Services are the replacement to SSP’s and provide greater flexibility in administering SharePoint. Shared Services have been built into WSS framework unlike its predecessor, SSP’s, which were built into the MOSS framework. In MOSS, the SSP was a one stop shop which contained several shared services like search, profile, excel services for example. This in itself caused a multitude of problems since it’s potentially a single point of failure for multiple services. Also, SSP’s weren’t as flexible when providing specific permissions to manage specific services within an SSP. SharePoint 2010 flattens an SSP so now each service is an independent entity. This will make more sense after reviewing the entire blog.
In SharePoint 2010, A Shared service is a component that does useful work. All Shared Service components are considered part of the Shared Services framework. For Example, Search is considered a shared service and profile is considered a shared service. The number of different shared services available in a farm is dependent on which SKU is used.
For Example: Search Service Application and Profile Service Application comes with SharePoint 2010 Standard and Enterprise SKU. Performance Point Service Application and PowerPoint only comes with SharePoint 2010 Enterprise SKU.
Service Applications
In order to use a Shared Service, a Service Application must be provisioned. A Service Application is a farm level instance, “logical instance”, of a Shared Service. A Service Application consists of the following:
· Administrative interface (Admin Page to manage the associated service application)
· Application Pool
· Database\Databases
· Physical Instance (Actual running process\Web Service running on a physical machine)
Note: Not all Service Applications are the same. Each one is unique and may or may not contain the above components listed.
For Example: SharePoint OOB comes with Excel Shared Service. Until you deploy and create a service application, you cannot consume that shared service.
Service Applications can be provisioned automatically using the Farm Configuration Wizard or manually by using Central Administrator\Manage Service Application page. Power Shell can also be used to create Service Applications.
The following example describes manually provisioning a Service Application using Central Administrator:
1. Create via Service Application Page
2. Creates Excel Proxy and Excel Service Application
3. Note: This will “NOT” start the associated SharePoint service which means the WCF web service will not be created.
4. Start the Excel services from services on server page which will create a physical instance, “web service”
Step 3 deserves some further explanation. After starting a service on a specified server, a virtual directory and corresponding web service is provisioned. Within IIS, all web services reside within the Shared Web Services website.
This is not very intuitive as each virtual directory contains a long GUID. Right click and explore each virtual directory will display the associated web service.
For Example, exploring virtual directory 81dfd03d65544035aa193db1a1fcdc98:
SharePoint 2010 has moved away from asp.net web services (ASMX) to WCF web services (SVC).
Note: All web services reside under the following directory by default:
C:\Program Files\Microsoft Office Servers\14.0\WebServices\
Redundancy Built-in
Multiple application servers can run a physical instance of the same Service Application. This is accomplished by running step 3 above on more than one application server. This provides redundancy in that requests from WFE’s pass through a built in load balancer to locate available application server running a physical instance.
For Example: Two application servers are running the same Excel Service application. If one application server goes down, the built-in load balancer will detect it and future request to Excel Service Application will be directed to application server that is still up and running with the associated physical instance.
Service Application Proxy
Service Applications have a corresponding Service Application Proxy. A Service Application Proxy is an object that a service consumer (web part) uses to connect to a Service Application. A consumer could be considered a web part, OM, or internal code. A web application has no idea how to communicate with a Service Application without a Service Application Proxy.
For example, provisioning a User Profile Service Application looks like the following within Central Administrator\Manage Service Applications page:
Many parts working together
To see how this works together I like the example of running a query from a Search page on a WFE.
Search query is performed and WFE’s search web part talks to service application proxy which uses WCF to connect to Server running physical instance of Service Application on application server. The application server talks to a database. Results are returned from Application Server to WFE and displayed for user whom submitted the query.
Consuming Service Applications in a Single Farm
A SharePoint administrator now has more control over which Service Applications are deployed. For example, if the only requirement is search, only a Search Service Application is deployed. If a SharePoint Administrator wants all 18 Service Applications, that Administrator can provision\deploy all of them. By default, Service Application is consumed at the Web Application level. A single web application can consume multiple search shared services. A single shared service can be consumed by multiple web applications. This is controlled through the use of Service application Proxy Groups. Proxy Groups create mappings between service applications proxies and the web applications that consume them. When a new farm is provisioned, a default proxy group called default is created. Service application proxies are added to this proxy group by default. Proxy Groups are created using PowerShell via the new-spserviceapplicationproxygroup cmdlet. Changing or Adding service applications to proxy groups is possible through using add-spserviceapplicationproxygroupmember cmdlet within PowerShell.
When provisioning a web application, a service connection field provides the ability to specify which proxy group that web application is mapped to.
By default, a web application will only consume service applications that are associated with that particular proxy group. In the screenshot above, proxy group DanCan contains the Excel Service Application2 proxy.
This is extremely flexible so for example:
Proxy Group: DanCan
Service Application Mapping: Search Service Application 1
Web Application: http://ContosoWebTeam
Proxy Group: DQBlizzard
Service Application Mapping: Search Service Application 2
Web Application: http://ContosoHRTeam
All users performing searches from Web Application ContosoWebTeam will only pull search results from Search Service Application 1. All users performing searches from Web Application ContosoHRTeam will only pull search results from Search Service Application 2.
A Web Application isn’t forced to consume all service applications within assigned proxy group. If web application is connected to a proxy group containing 10 Shared Service Application proxies, it’s possible to consume a variable # of Shared Service Applications. It’s up to the Administrator and this is configurable via Central Administrator\Application Management\Configure Service Application Associations. The following screenshot displays a web application ContosoHRTeam associated with DanCan proxy group. DanCan proxy group contains two Application proxies:
A SharePoint administrator no longer wants ContosoHRTeam web application to consume Excel Service Application2.
You can accomplish this in two ways:
1. Modify Proxy Group Membership
To modify proxy group membership, simply select the proxy group name and uncheck the unwanted Service Application. For Example, SharePoint Administrator wants to drop Excel Service Application2 from DanCan Proxy group:
In the above example, Excel Service Application 2 is unchecked so any web applications consuming this proxy group will no longer be associated with Excel Service Application 2. This may not be desirable if multiple web applications are consuming from DanCan proxy group.
2. Modify Service Application associations on Web Application
From the configure service application association page, select the Web Application and choose custom:
Uncheck Excel Service Application 2. This is useful when you only need to change service application associations on web application level. With this method, DanCan proxy group membership is maintained. Also, this provides the SharePoint administrator the option of consuming multiple service applications that span proxy groups.
Rules
Some additional rules to be aware of:
1. A web application can only map to one proxy group by default
2. A service application can map to one or more proxy groups. Another way of saying multiple proxy groups can contain the same service application proxy
3. A proxy group can contain multiple service applications of the same type. So it's possible to have two Excel Service Applications reside in the same proxy group.
Note: This deserves some explanation. By having multiple service applications of the same type reside in the same proxy group doesn't mean a web application will consume from both. Only one will be marked as default and used. Changing which service application is marked as default is possible through Manage Web Application\Service Connections. Within Configure Service Application Associations, set group of connections to custom and set preferred service application as default.
4. Multiple Web Applications can map to the same proxy group
5. A Web Application can consume Service Applications from multiple proxy groups when custom is specified.
Part 2 will focus on service provisioning setup\consumption across multiple farms.
Thx,
Russmax, MSFT
Changing service accounts is simple in SharePoint 2010. This blog briefly discusses how to set this up and what permissions are automatically provisioned behind the scenes.
In the following example, I'm going to change the search service account on an existing Search Service Application to a newly created user account named Dan.
It's fairly simple to change search service accounts. In the following walkthrough, I’m going to replace my existing search service account with a new one named Jon.
Add a managed account
1.) Access Central Administrator and select Security\Configure Managed Account.
2.) Select Register Managed Account link
3.) Input desired account in “domain\username” format.
Note: Inputting the domain as FQDN does not work and produces the following error:
This is a known issue and you must use the netbios name of the domain.
4.) Finally hit OK
Add account as Search Service Account
1.) Access Central Administrator and select Security\Configure Service Accounts
2.) Select Windows Service - SharePoint Server Search and select managed account and hit OK.
That’s it!! So what permissions were granted to Jon after running through these steps? The Jon account was automatically granted the following permissions directly after hitting OK on step 2 above.
On SharePoint 2010 Server hosting Search Service Application
· Added to WSS_WPG local group. This gives the account the appropriate permissions to access registry keys and files required to run search service instance.
· Added as logon account for SharePoint Sever Search 14 service within the services applet.
On SQL Server hosting Search databases and Configuration database
Added to SQL with Server Role as public.
On SQL server, Granted db_owner and public roles on the following:
On SQL Server, granted public and WSS_Content_Application_Pools roles on the following:
Note: This is specific with a search service application. Other non-search shared service applications might permission differently for a service account. Each type of shared service application is unique. As far as what AD permissions are required depends on the type of Shared Service Application. For Example: On a pure Windows 2008 domain, the search service account requires membership to domain users group at a minimum.
Stay tuned.. I’ll be adding more to this blog as I uncover more behind the scenes stuff…
Russ Maxwell, MSFT