MOSS document library and Audiences

Leave a comment

In MOSS you can use audience to target content to different Audiences.  So when two different person access the same URL they will not see the same content.  They will see only the content related to their jobs or needs if the content owner used the audiences to target the content.  This is a cool feature that I should explain more in detail in a different article.  

Audiences can be used in document libraries.  You have to enable audience targeting in the document library settings.  Once this is done a new property will be added to the document where you can specify an audience for the document.   

If you log in with a user not member of an Audience, he will see all the documents even if you have targeted document to specific audiences.  

Audiences will not control the display of the document while you are in the document library or if you add the Web Part that displays the content of the Document Library.   

To display the content of a Document Library based on audiences, you need to use the Content Query Web part.   

In the properties of the Content Query Web Part you can specify to use the audiences to display the content (apply Audience Filtering).  



Form services vs Infopath client

Leave a comment

If you are planning to use infopath form services, Microsoft has published a nice document describing the InfoPath 2007 features that are unavailable in InfoPath Forms.

Security issue in WSS 3.0 and MOSS

Leave a comment

You have to be carefull if you use the Sharepoint Central Administration tool to change the account running the Application Pool used by a Web Application to provide Sharepoint Content. 
The steps are quite simple, you just open the Sharepoint Central Administration, then go to the Operations, and then select Service Accounts (under Security Configuration), then select your Web Application and then type in the new account.
Once the account is changed, Sharepoint will add a new login in SQL granting the new account the required rights to the content database.
The problem is that it will also grant the account the Security admins and Database Creator role on the SQL Server, wich is too much rights for the Account running the application pool used by the Web Application providing Sharepoint content.  These permissions are required by the Account running the Application Pool for the Sharepoint Central Administrationm, not for the application pool used by the content Web applications.
So now as my security best practice, If I change the application pool account running the Sharepoint content application via the Sharepoint Central administration Tool, I will go and remove the Security admins and database creator roles in SQL, for the new account logins.
Also you should remove the rights from the old account because when you are changing the accounts used by the application pools, Sharepoint will not automatically remove the rights from the old account in SQL.