Let us say that you are setting up SharePoint 2007 in your organization. Typically your users will access a SharePoint installation through a site collection. Which means, you need to give your users access to a particular site. But where do these users come from? SharePoint 2007 allows you to plug in any kind of authentication using a membership provider, but for many scenarios you will simply install SharePoint 2007 and use it under the default active directory based authentication – a.k.a. 2003 styliee. When you do setup SharePoint 2007, and a site collection in there, and you enter a UserID such as DOMAIN\smalik, you would note that all the nice goo such as my email addy, phone number etc. – typically stuff you would see in outlook gal or active directory, or any other such system doesn’t get pulled in automatically. To pull in that stuff, you need to import the user profile information, and here is how you do it. 1.  Create a Shared Services site (for which you need to setup indexing and search beforehand). Typically in a real deployment scenario, you would want to keep shared services being served by a dedicated machine other than your web heads (a tip I learnt from Scott Hillier – whose excellent Apress book on SharePoint 2007 I am reviewing right now). 2. Once that is created go to that shared services site, and under “User Profiles and My Sites”, click on “User Profiles and Properties”. 3. When in there, you need to setup an import connection. You can create as many connections as you want – which means if you have multiple kinds of authentication going on, on the same physical box – you should have some means of uniquely differentiating each user – if indeed your organization uses two different repositories of users. In most scenarios you would use active directory, but SharePoint will let you import from AD, LDAP, ADR or any BDC (supplementary information only). 4. So go ahead and setup an import connection. Then back at “Configure Profile Import” set up an import schedule with proper user access rights. It is a good idea to setup an incremental import – which performs a full import to begin with.  You can schedule such an import, or you can perform such an import on demand. I like to keep full import unscheduled – and I use that for “wipe out and lets start over” scenarios only. 5. Real world – I imported 48,707 profiles in around 29 minutes – not bad eh? 6. Finally, before you actually start the import, you probably want to map the properties appropriately. So “Email Address” shows up in “Work Email” and so on so forth. Once everything is setup – hit import, and then the incremental job will run at your specified schedule, and your sites in that site collection will begin to recognize users not as “Domain\smalik” but as “Malik, Sahil” with full meta data. Then you can use that information to power hierarchical org charts, searching over the user metabase via SharePoint, membership information to various groups/mailing lists setup on exchange server etc. Quite powerful I must say J

if you are developing a webpart or any sharepoint customized feature,and you would like to send an email through your webpart or custom code,you can achieve this by 2 ways:

1) use normal .net classes to send email (System.Net.Mail namespace).
2) use below code:

using Microsoft.SharePoint.Utilities;

SPUtility.SendEmail(SPContext.Current.Web, false, false,
"to-address@mail.com", "E-mail title",
"E-mail body");

this code will use the configuration of your sharepoint installation (SMTP server configuraiton),in the central administraiton tool.

the benefit of the second choice,you don't need to store any other configuration for your SMTP server on your code,this code will directly use the sharepoint configuration and free your mind of SMTP configurations, if the sharepoint is configured propely and send email notification (throught workflows for example),then you code will work as well

To prevent IE from promting for loging details all the time change the setting in Internet options->Security.

either move the site into  intranet zone and make sure that automatic logon for intranet zone is selected in the custom level options or

change this option to automatic logon with the current user name password.

 

Running MOSS Setup

On every server where MOSS is to be installed, the account you run setup with must belong to the local administrators group. In addition, this account must be a Domain User and be a member of the following SQL server security roles: Logins, Securityadmin & Dbcreator. This account is going to be doing a lot – creating new databases, and also creating new IIS sites – so make sure you have enough permissions! Typically, an account such as the domain administrator is used to run the installation, which addresses all of the security requirements.


SQL Server (SQL_Service)

This account is specified when a new SQL server is being brought online or a new instance installed. It typically is used for running both the SQL Server & SQL Server Agent, however, each can have their own account. For our purposes, we will utilize one account for both SQL Server & the Agent. The account only needs to be a basic Domain Account with no specific permissions set. When SQL Server is installed, all of the other appropriate permissions will be granted to the account.
 

Database Access Account / Farm Account (Farm_Service)

This account serves a few roles. The first is that it is used by MOSS to access the databases… it acts as the account by which the server(s) MOSS is installed on communicates back and forth to SQL with (read/write). Additionally, it is used as the identity for the Central Administration application pool & the WSS Timer service. This account needs to be a Domain Account - but note that it is believed to have to be a local admin on every MOSS box - this is not true, as Spence points out very eloquently.

Shared Service Provider (SSP#_Service)

Each shared service provider can run under its own account, therefore, it is desirable to name the account using a number. This way, if your MOSS farm ends up having a large number of SSPs, you can map the SSPs back to their specific service accounts easily. This account is used for the SSP web services & the SSP timer jobs. The account only needs to be a basic Domain Account with no specific permissions set.
 

Office SharePoint Server Search (Search_Service)

This account is utilized by all of the Shared Service Provider to crawl local & remote content. This account should be a Domain Account & have local administrator permissions on each MOSS server.
 

Default Content Access Account (SSP#ContentAccess_Service)

When a shared service provider crawls content, this is the default account used if a specific account (see below) is not specified for the content source being crawled. This account is specific for each individual SSP. This account should be a Domain Account & have read access to the content sources it needs to crawl.
 

Content Access Account (XXXXContent_Service)

If you have specific content sources that need to be crawled, and you do not want to allow the default content access account to crawl them, then you specify an individual content access account (specified at the time a Crawl Rule is setup). This account is a Domain Account with read permissions specifically on the content source it crawls.
 

Windows SharePoint Services Search Account (WSSSearch_Service)

The WSS Services Search is used only to provide search capabilities within the Help content. If this search feature is desired, then this account should be configured as a Domain Account with no specific permissions.
 

Application Pool Process Account (XXXXPool_Service)

When each application pool is setup, you must specify an account that will be used for that specific application pool’s identity. This account will be used to access the content databases associated with the web application. It is recommended that a new service account is created for each application pool. This should be a Domain Account with no specific permissions. When the account is specified & SharePoint creates the application pool, it automatically grants the account additional needed permissions.

 

More information at 

http://www.datasprings.com/Resources/ArticlesInformation/OverviewonInstallingSharepoint2007/tabid/774/Default.aspx

 

Debugging SharePoint errors is  a pain.  You normally get the the  "An unexpected error has occurred" error message is shown.

Sometime there is nothing in the event log or trace log.

To enable detailed error messages in the browser do the following in web.config 

<SafeMode MaxControls="200" CallStack="false"… />  change to  <SafeMode MaxControls="200" CallStack="true" … />

The customError setting must be changed to "Off":     <customErrors mode="Off"/>

After these changes, the "An unexpected error has occurred" should no longer be shown and you should a standard ASP.NET error page.

Once you have customised a page in Sharepoint designer using data views the list id etc are embeded into the page.

If you the export and import the site, all id become invalid, the code below is how to restamp the customised page with the new Id. 

try

{

//using (SPSite site = new SPSite(SPContext.Current.Site.ID))

using (SPSite site = new SPSite(SiteURL))

{

using (SPWeb Web = site.OpenWeb(WebURL))

{

//This bit of code restamps all the list guid that SPD

//put into the page source for our customised project home page.

//When the site is exported and re-imported all lists get new ID hence the page is

//broken this fixes it for the new site.

byte [] bfile = Web.Files["default.aspx"].OpenBinary();

System.Text.Encoding enc = System.Text.Encoding.ASCII;

string myString = enc.GetString(bfile);

//re-stamp the guids from the default projector site with the new ones that

//have been created in this site.

SPList list = Web.Lists["List Name"];

myString = myString.Replace("69D01208-49F1-43BC-ABF9-550A75BD1A54", list.ID.ToString());

bfile = enc.GetBytes(myString.Replace("???",""));

Web.Files["default.aspx"].SaveBinary(bfile);Web.Files[

"default.aspx"].Update();

 

}

catch (Exception ex)

{

Console.WriteLine("Exception " + ex.ToString());

}

If you see this post it means that BlogEngine.NET 1.3 is running and the hard part of creating your own blog is done. There is only one thing you need to do from this point on to take full advantage of the blog and that is to set up the first author profile. h

Write Permissions

To be able to log in to the blog and writing posts, you need to enable write permissions on the App_Data folder. If you’re blog is hosted at a hosting provider, you can either log into your account’s admin page or call the support. You need write permissions on the App_Data folder because all posts and comments are saved as XML files and placed in the App_Data folder.

Username and password

When you've got write permissions to the App_Data folder, you need to change the username and password. Find the sign-in link located either at the bottom or top of the page depending on your current theme and click it. Now enter "admin" in both the username and password fields and click the button. You will now see an admin menu appear. It has a link to the "Users" admin page. From there you can change the username and password.

On the web

You can find BlogEngine.NET on the official website. Here you'll find tutorials, documentation, tips and tricks and much more. The ongoing development of BlogEngine.NET can be followed at CodePlex where the daily builds will be published for anyone to download.

Good luck and happy writing.

The BlogEngine.NET team