Use of SSP ?
What is The Shared Service Provider(SSP)
What is a Shared Service Provider?
For those of you who don't know what I am talking about a bit of overview. In MOSS 2007 there is this new concept of Shared Services Providers(SSP). The idea being that there are certain services that really make sense to centrally manage and share. A good example being profiles. With a SSP we can import all of the profile information from AD once and then our various web applications can consume the data. So maybe we have http://marketing and http://accounting it doesn't make sense for each one to maintain identical profile information, they should share.
The major services that are handled by the SSP are:
Sometimes the easiest way to think of Shared Services is the Parent vs. Child relationship. The Parent (your SSP) goes out and does all of the work (pulling BDC data, indexing content, hosting My Sites) and the child (your web applications) come to the parents to ask for $5 (request data from the BDC, or view a calculated Excel sheet). Does that help?
Multiple SSPs
One of the most overwhelming things about SSPs for some people planning is how many should I have? It is easy to see from the interface that you are given the opportunity to create more than one. When should you do this?
As a general rule of thumb most companies will use one SSP. This is my default answer. So why do they give you the ability to run multiple SSPs? There are cases where you want separate search or profiles. The most common? Extranet/internet scenarios. Maybe your SharePoint farm hosts two primary web applications. http://portal for your intranet and http://ourcustomers for your extranet. In this scenario you probably want separate search and profiles. And now you have found the reason to have multiple SSPs. You don't want to share information you want unique information for both.
Another advantage of SSPs
Separation of roles. In some medium and large environments it is not uncommon to have one group administering the physical server farm while another group needs to just maintain search. Well the SSP concept makes this very easy. Since the SSP is its own SharePoint site collection you can define a users access so they can NOT access central administration but they CAN access the SSP. And once they get into the SSP you can even limit them. Once inside the SSP you can determine if they can:
Best I can tell if you give them access to the SSP all of the other SSP functions they will have rights to. Guess it needs more testing.
Still this separation of services from the actual administration of the server can be quite useful. Epically in companies where the less access I give a user the better.
Moral of the story
SSPs are very helpful and important to understand. They should be part of your initial planning. They can be secured at a very granular level or they can be give broad access. Just mark this topic down as something else you need to full think through before you start rolling out SharePoint. And when all else fails just have one SSP.
For those of you who don't know what I am talking about a bit of overview. In MOSS 2007 there is this new concept of Shared Services Providers(SSP). The idea being that there are certain services that really make sense to centrally manage and share. A good example being profiles. With a SSP we can import all of the profile information from AD once and then our various web applications can consume the data. So maybe we have http://marketing and http://accounting it doesn't make sense for each one to maintain identical profile information, they should share.
The major services that are handled by the SSP are:
- Profiles and Audiences
- My Sites
- Search
- All of Excel Services
- All of the BDC (Business Data Catalog)
Sometimes the easiest way to think of Shared Services is the Parent vs. Child relationship. The Parent (your SSP) goes out and does all of the work (pulling BDC data, indexing content, hosting My Sites) and the child (your web applications) come to the parents to ask for $5 (request data from the BDC, or view a calculated Excel sheet). Does that help?
Multiple SSPs
One of the most overwhelming things about SSPs for some people planning is how many should I have? It is easy to see from the interface that you are given the opportunity to create more than one. When should you do this?
As a general rule of thumb most companies will use one SSP. This is my default answer. So why do they give you the ability to run multiple SSPs? There are cases where you want separate search or profiles. The most common? Extranet/internet scenarios. Maybe your SharePoint farm hosts two primary web applications. http://portal for your intranet and http://ourcustomers for your extranet. In this scenario you probably want separate search and profiles. And now you have found the reason to have multiple SSPs. You don't want to share information you want unique information for both.
Another advantage of SSPs
Separation of roles. In some medium and large environments it is not uncommon to have one group administering the physical server farm while another group needs to just maintain search. Well the SSP concept makes this very easy. Since the SSP is its own SharePoint site collection you can define a users access so they can NOT access central administration but they CAN access the SSP. And once they get into the SSP you can even limit them. Once inside the SSP you can determine if they can:
- Manage user profiles
- Manage audiences
- Manage permissions
- Manage usage analytics
Best I can tell if you give them access to the SSP all of the other SSP functions they will have rights to. Guess it needs more testing.
Still this separation of services from the actual administration of the server can be quite useful. Epically in companies where the less access I give a user the better.
Moral of the story
SSPs are very helpful and important to understand. They should be part of your initial planning. They can be secured at a very granular level or they can be give broad access. Just mark this topic down as something else you need to full think through before you start rolling out SharePoint. And when all else fails just have one SSP.
GIVE A USER ACCESS TO THE SSP
You are the IT guy. You got a request to install this MOSS thing so people could make web sites or something like that. Ok. After a couple of tries no problem. You got the darn thing installed for them. You create them a site collection and set them on their marry little way. No problems. Then the following week you get another call. “We need to configure search and import some profiles. We need to access the Shared Service Provider to do this. Can you let us in?” OK. Now what?
You could do it the lazy way and cross your fingers they don’t break anything by granting access to the whole web application. That was detailed in my post Become Administrator of the Entire Web Application. But even if you do this you will find they still can’t manage profiles , audiences, permissions, or usage analytics. Bummer. So what should you do?
- Start off by logging into the SSP admin site.
- Now you need to add the user just like you would to any other site. Click Site Actions > Site Settings
- Under Users and Permissions click Advanced permissions
- Click New > Add Users
- Enter your user and put them in a group. Normally I just place them in the Viewers group and hit OK
Now your user can log into the SSP and manage search settings, the Excel Service Settings, and can view the various links list. So how do you give them more permissions? Well in order to do that you need to give them some more access.
- Under User Profiles and My Sites click Personalization services permissions.
- Click Add Users/Groups
- Enter your users name select which permissions you would like to bestow upon them and click Save.
What are all of these different permissions? I am glad you asked. J
- Create personal site gives the user the capability to create and use a My Site. Going deep here will have to be saved for another day but if you want to make that My Site link disappear take away this right from the users. But you didn’t give it to them. Why do they have it? Go back to the manage permission screen. All authenticated users were given this right by default.
- Use personal features is another topic for another day. Essentially though this provides the My Links functionality and allows users to manage their Colleagues.
- Manage user profiles this allows your user to do just that. Get in there and modify the profiles for this SSP. Give them this right and now they can access the links: User profiles and properties, Profile services policies, and My Site Settings.
- Manage audiences you guessed it but now you can click that handy little Audiences link. Once you are there you can set the schedule or define the rules for building those global audiences.
- Manage permissions this will let that user modify Personalization services permissions (the stuff we are doing right now).
- Manage usage analytics this gives the user access to make changes to Usage reporting. Small bug here but if the user doesn’t have this right they can still open up the screen. Then if they make a change and hit ok they get a 403 forbidden error. Reminds you of SPS 2003 doesn’t it. J
So now if you have given the user all of those permissions they should be a happy camper? Depends. If you have MOSS Enterprise then probably not because they still can’t manage the BDC. Yikes! More to do.
- Click Business Data Catalog permissions from the main screen of the SSP
- Click Add Users/Groups
- Enter your user, select their permissions and click Save
Since I will not even claim to understand the BDC I will leave you to use the included explanations on the screen to figure out what to give your users.
What is the use of Features @@ Scope?
What is SharePoint 2010 Features?
- SharePoint Features is part of Packaging and Deployment in SharePoint 2010
- Features make it easier to activate or deactivate functionality in the course of a deployment, and administrators can easily transform the template or definition of a site by simply toggling a particular Feature on or off in the user interface.
- Features are stored under %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES
- The Feature subfolder includes a Feature.xml file and any number of supporting element files.
- Features can be installed/uninstalled using STSADM tool, SharePoint Management Shell, Or Object Model.
Understanding Feature Scope
- Sharepoint 2010 Can be scoped to Farm, Web Application, Site Collection, and Web Site level.
- Feature Scope id defined by Scope attribute in feature.xml
- Sample Feature will look like this
<Feature Id=”F62C96CF-79FD-44be-8882-E9BFBD199184″
Title=”Feature Title”
Description=”Feature Description”
Version=”1.0.0.0″
Scope=”Site”
Hidden=”false”>
</Feature>
Web Site scoped Feature (Scope=”Web”)
- Web Site Scoped feature can be activated at individual Web site level.
- List Instances, Event Receivers, Custom Actions etc are the custom elements for Website scope features.
- It can be activated by STSADM command like ” stsadm “o installfeature “name FeatureFolderName “url http://sharepointserver/site/subsite
- Alternatively open site features page by site actions -> site settings -> modify all site settings ->site features and click activate.
Site Collection scoped Feature (Scope=”Site”)
- Site Collection Scoped feature can be activated at the site collection level.
- It can contains item that can apply to Site Collection as a whole like content types that are shared across the site collection, as well as items that can be activated per site for e.g. List Instances, Event Receivers, Custom Actions etc
- It can be activated by STSADM command like ” stsadm “o installfeature “name FeatureFolderName “url http://sharepointserver/site/sitecollectionname
- Alternatively open site features page by site actions -> site settings -> modify all site settings ->site features and click activate.
Web Application scoped Feature (Scope=”WebApplication”)
- Web Application Scoped feature can be activated at the Web application level.
- It can contains item like administrative web application links, delegate control registrations, document forms registration etc.
- It can be activated by STSADM command like ” stsadm “o installfeature “name FeatureFolderName “url http://sharepointserver
- Alternatively open Manage Web Application Features from Central Administrator Central Administrator -> Application Management -> Manage Application Features and click activate.
Farm scoped Feature (Scope=”Farm”)
- Farm Scoped feature can be activated at the Farm level.
- It can contain number of element like application logic etc which can be applicable anywhere within deployment. It contacts links to /_layouts pages and files, /_admin pages etc.
- It can be activated by STSADM command like ” stsadm “o installfeature “name FeatureFolderName
- Alternatively open Manage Farm Features from Central Administrator Central Administrator -> Operations -> Manage Application Features and click activate.
- Farm scope feature will be activated automatically once it is installed on server.
Need for activation and deactivation
When you deploy site element customizations in a Feature, you can install, activate, and deactivate the Feature by using Windows PowerShell or by using the object model. You can also activate and deactivate a Feature by using the Central Administration Web site.
Flexibility of scope You can activate a Feature for a single scope, including farm, Web application, site collection, or Web site.
Ease of distributed deployment A Feature is easy to deploy to multiple server farms as part of a solution.
Control through the Feature object model The Feature object model enables you to specify the list of installed features within a given scope and to control whether features are enabled at the farm and site levels.
Use solution packages to package Features to deploy to different environments. For example, use a solution package to deploy customizations between developer workstations and an integration farm, and also between either an integration farm or authoring client workstations, and pilot or production farms.
What Files are Used To define Share point Feature.
1- Feature.xml
2-Manifest File (Element.xml)
References
No comments:
Post a Comment