Send email to a user, getting it from a ‘Person or Group’ field November 10, 2009
Posted by rehmangul in Blogroll, MOSS, MS SharePoint Sever, development, event handlers, sharepoint, sps.Tags: Coding SharePoint, Custom Sharepoint, customise, email server, moss customisation, SharePoint Customization
add a comment
First, we have to read from “Person or Group” field.
It could be a “Person or Group” field that allows one user to be selected.
It could be a “Person or Group” field that allows multiple users to be selected.
If its a single user, get user, get his email address, send him email.
If there are multiple users, get each of them one by one, get their email addresses, send them emails.
Do not copy/paste the code; and if you do, look for the typos 
using System.Net.Mail;
SPList myList = myWeb.Lists["myListNameHere"];
SPFieldCollection allMyListFields = myList.Fields;
foreach(SPListItem myItem in myList.Items) //go through all the items
{
foreach (SPField myField in allMyListFields) //go through all the fields
{
if (myField.GetType() == typeof(SPFieldUser)) //check if the field is Person or Group field i.e. SPFieldUser
{
Type fieldType = myField.GetFieldValue(myItem[myField].ToString()).GetType();
if (fieldType == typeof(SPFieldUserValueCollection)) //check if the field allows multiple selection of users
{
string emailToFieldValues = myItem[myField].ToString();
SPFieldUserValueCollection emailToUsers = new SPFieldUserValueCollection(myItem.Web, emailToFieldValues.ToString());
foreach (SPFieldUserValue emailUser in emailToUsers)
{
SPUser emailThisUser = emailUser.User;
string emailAddress = emailThisUser.Email.ToString();
SPUtility.SendEmail(myWeb, true, true, emailAddress, emailSubject, emailBody);
}
}
else
{
SPFieldUserValue emailToFieldValue = (SPFieldUserValue)myField.GetFieldValue(myItem[myField].ToString());
SPUser emailToUser = emailToFieldValue.User;
string emailToAddress = emailToUser.Email.ToString();
SPUtility.SendEmail(myWeb, true, true, emailToAddress, emailSubject, emailBody);
}
}
}
}
Hope this helps–
MVP Award July 3, 2009
Posted by rehmangul in Uncategorized.2 comments
I am happy to share the news that Microsoft has announced MVP [Most Valuable Professional] award for me for the third consecutive year….
https://mvp.support.microsoft.com/profile/rehman
It’s been a gratifying experience…..
Approaches to Backup and Restore a Sharepoint Farm April 29, 2009
Posted by rehmangul in Blogroll, MOSS, MS SharePoint Sever, sharepoint, sps.Tags: central administration, configuration wizard, configuration wizard errors, Custom Sharepoint, customise, errors, fix, integration, MOSS, moss customisation, moss errors, move from testing to production, move to another farm, Service Unavailable, SharePoint Customization, sharepoint errors, sharepoint farm, stsadm, tips and tricks, workarounds
add a comment
It is important to understand the differences between MOVING, MIGRATING or UPGRADING a farm:
http://technet.microsoft.com/en-us/library/cc262370.aspx
I’ll slightly touch these at the bottom of this article. Mainly, I am going to discuss approaches how can you MOVE from one farm to another.
MOVING to another farm:
If you are moving from a test farm to a production farm, this involves MOVING a farm. You must have similar hardware (32-bit or 64-bit which ever) and you must have similar software (version of sharepoint, windows, all software updates) and you must have similar topology (server names, number of servers) on the farm you are MOVING to.
The reason is becasue the configuration database and the Central Admin database contain computer-specific information. For that reason, you can only move to a new farm if you can configure it to be exactly the same as your original farm. Configuration database will not work for a new environment where topology, server roles or software updates are different.
Okey, if you do not have the same hardware, software or topology, then what to do? Then you should move everything in the farm except Configuration and Central Admin databases, and configure the new farm on your own, wihout expecting this to be done by the restore procedure, since we are not restoring configuration database. OR, you should consider MIGRATING or UPGRADING:
http://technet.microsoft.com/en-us/library/cc262370.aspx
So, let talk about MOVING to another farm. Microsoft says this is the way to “Move to another farm”:
http://technet.microsoft.com/en-us/library/cc261918.aspx
This page has a lot of information, hidden and obvious, I wish to consolidate it here:
There are three possible ways through which you can Backup and Restore your farm (note that I said backup/restore, not move):
- STSADM
- Central Admin
- Sql Server (lets ignore DPM and the others for the time being)
But there is only one way to MOVE your farm to another farm and that is:
- Sql Server (tools)
MIGRATING to another farm using STSADM and Central Admin (tools) is regarded as obsolete. That means if you are moving to a new or different farm, you should not use Central Admin or STSADM command. So, moving or migrating whatever you may want to call it (because here it just means moving to a different environment), STSADM and Central Admin approach is obsolete. (I couldn’t find anywhere where Microsoft supports/permits you to MOVE to another/different/new farm using STSADM or Central Admin).
http://technet.microsoft.com/en-us/library/cc262281.aspx (Migrating through Central Admin (Obsolete))
http://technet.microsoft.com/en-us/library/cc263236.aspx (Migrating through STSADM (Obsolete))
We can restore our farm using STSADM and Central Admin, only on the SAME farm from which the backup was taken i.e. no new farm is involved at all:
http://technet.microsoft.com/en-us/library/cc261704.aspx (Restore using STSADM)
http://technet.microsoft.com/en-us/library/cc262928.aspx (Restore using Central Admin)
If you will use Central Admin, you will select “Same Configuration” option for the “Type of Restore” radio button. And for STSADM, you will use “overwrite” value for “-restoremethod” parameter. Using Central Admin, you can take farm level backup but it will not let you restore Central Admin and Configuration databases saying that “Central Admin and Configuration databases cannot be restored from this user interface”.
Now the only way left while moving to a new farm is SQL Server (tools):
http://technet.microsoft.com/en-us/library/cc261918.aspx
After we have reached this decision, remember that there could be two possibilites:
- Your new farm on which you are restoring may have different specs from the farm from which the backup is taken from. Specs means server names, software updates, number of servers.
- Your new farm may have exactly the same specs as the farm from which the backup is taken from.
If you plan to move Config and Central Admin databases, your new farm MUST have the same specs. If your new farm has different specs, then you should not move Config and Central Admin databases.
“Move to another farm” (http://technet.microsoft.com/en-us/library/cc261918.aspx) provides a step by step procedure to move to a new farm, and it assumes that sharepoint is already installed on the destination farm, which essentially means that Configuration and Central Admin databases are already created. So, if you have the same specs for your new farm, you can go ahead and overwrite Config and Central Admin databases, this will restore the configuration from the backup set.
Now it could be the case that you can live without moving Configuration and Central Admin databases to the new farm i.e. you will configure the new farm by yourself and you dont need to transfer Config and Central Admin databases from your old farm. So, what will you move then:
- Content Databases
- SSP Databases
- Search Databases for SSPs
- Search Databases
However, above databases can also be restored using Central Admin and STSADM approaches.
Summary: Moving to a new farm involves SQL Server and a farm with similar specs, otherwise do not move Config and Central Admin databases.
If you are looking to Move only the Content Databases, here is the one stop shop:
http://technet.microsoft.com/en-us/library/cc262792.aspx
MIGRATING to another farm:
If you are changing from 32-bit hardware to 64-bit hardware, this will also be a MIGRATION process (i.e. change in hardware specs as mentioned earlier). If you are planning to change your existing SharePoint Server 2007 platform to Windows Server 2008 (platform), you might have to change to 64-bit hardware. And to upgrade Microsoft Office SharePoint Server 2007 to a 64-bit environment, you must migrate existing servers to a new farm. You cannot upgrade Office SharePoint Server 2007 directly from the 32-bit edition of Office SharePoint Server 2007 to the 64-bit edition.
http://technet.microsoft.com/en-us/library/dd622865.aspx
UPGRADING a farm:
Upgrade is when you are moving to a different version of SharePoint Server e.g. from SharePoint 2003 to SharePoint 2007.
If you are moving just the database server (all databases including Config and Central Admin) and not the whole farm, look here:
http://technet.microsoft.com/en-us/library/cc512725.aspx#Section1
If you wish to ditch the farm level backup/restore and just move your website (site collection) to the new farm (and save yourself a lot of hassle), have a look here:
http://rehmangul.wordpress.com/2009/04/18/sharepoint-site-backup-and-restore/
After release of SP2 and CU for April, you can safely backup and restore your site collections to a new farm, without worrying about absolute URL issues:
Hope this helps….
SharePoint Service Pack 2 April 29, 2009
Posted by rehmangul in Uncategorized.Tags: Custom Sharepoint, MOSS, moss customisation, service pack, SharePoint Customization, sharepoint errors, tips and tricks, workarounds
add a comment
Sharepoint Service Pack 2 (SP2) is now released:
Note this:
“A new preupgradecheck operation is added to stsadm tool. It can be used to scan your server farm to establish whether it is ready for upgrade to SharePoint Products and Technologies “14″.“
SharePoint Site Backup and Restore April 18, 2009
Posted by rehmangul in Blogroll, MOSS, MS SharePoint Sever, development, error, sharepoint, sps.Tags: Custom Sharepoint, customise, errors, fix, integration, Internet Explorer Errors, MOSS, moss customisation, moss errors, Service Unavailable, SharePoint Customization, sharepoint errors, sharepoint site backup and restore, tips and tricks, workarounds
7 comments
If you are moving your site from testing to production, site backup and restore (using STSADM command line tool) is the way to go. Other ways include SQL Server, Sharepoint Designer, DPM etc. However, site backup and restore using STSADM is probably the easiest and fastest one.
Backup the site using the following STSADM Command:
Stsadm –o backup –url http://<server name>:<port> -filename <path\name to be used for the backup file>
Example:
Stsadm –o backup –url http://vanillargk:5555 –filename e:\backup5555.bak
After the backup has been completed, “Operation Completed Successfully” message should be displayed.
Create a new Web Application for restoring the site:
Go to Central Administration -> Application Management -> under SharePoint Web Application Management -> click Create or Extend Web Application. Fill in the required information, click Ok and wait until the progress continues.
Once the new web application is created, run the following STSADM command and restore the site using the backup file created above.
Stsadm –o restore –url http://<server>:<port> -filename <path\name of the backup file>
Stsadm –o restore –url http://vanillargk:6666 –filename e:\backup5555.bak
Restored site should be up and running.
If it is not (and you are receiving weird errors in your browser), keep reading:
Now it could be the case that you have customized your site. So, we must deploy those customizations properly for the site to work as expected. This is typically a scenario while moving your site from Testing to Production environment. First you have to add the solutions (if any created) to the farm.
Add a Solution to the SharePoint Farm:
Add the solution package to the farm by running the following commands. Make sure full path of WSP file is supplied.
stsadm –o addsolution –filename <path to mysolution.internet.test.wsp>
Deploy the Solution to the restored site:
Now we need to deploy the newly added solution to our restored site. Click the solution name and select ‘Deploy’ button from top. Select the appropriate web application in the deployment settings and click OK. This will take several minutes to deploy mysolution.internet.test.wsp resources (list templates, features, assemblies, master pages, styles). Once the solution has been deployed, reset IIS to ensure all deployed changes are picked up by the web application.
You can also deploy the solution from the command line with the following SharePoint admin command.
stsadm -o deploysolution -name mysolution.internet.test.wsp -url <site> -immediate -allowgacdeployment –allowcaspolicies
Make sure all your assemblies (DLLs) are available in Global Assembly Cache (GAC) usually placed at c:\windows\assembly.
Activate features installed by mysolution.internet.test.wsp solution package:
Go to the newly restored site, click Site Actions, click Site Settings, click Site Collection Features. Click Activate button to activate any Site Collection Feature.
Go to the newly restored site, click Site Actions, Site Settings, Site Features.
Click Activate button to activate any Site Features.
Update Web.Config file:
It will be usually a case that your solution package will deploy a few DLLs with it. So we need to add all those Safe Control entries, Assembly Bindings, Keys and any other web.config changes to our newly restored sites’s web.config. Weird browser errors that I mentioned above usually appear due to these missing entries in web.config, specially when you are restoring on the same machine/server…….As assemblies will already be there in the GAC if the restore operation was performed on the same machine….you just need to make web.config entries to the restored site…..adding and deploying of the solution could be skipped. So lets do the copy paste operation from the old web.config to the new web.config. Just compare the two web configs and copy/paste the missing entries into the new.
Web.config file could be found at the following path:
<drive letter>:\Inetpub\wwwroot\wss\VirtualDirectories\<port number>\web.config
Example:
C:\Inetpub\wwwroot\wss\VirtualDirectories\6666\web.config
Usually these changes will include Safe Controls, AssemblyBindings, PageParserPaths and Keys etc. After making these changes your site should be ready in Production.
If you are worried about the bad habit of Moss saving absolute URLs for the page layout in the properties of a publishing page, then relax, solution is already in the market:
Hope this helps…
P.S. If you need to know more, important information in the comments below.
