Deploying a Sandbox solution

Problem: I created several wsp packages, unfortunately 1 of the solution projects was marked as a Sandbox solution when the project was created in Visual Studio 2010.  The lookup lists are not deploying correctly in the sandbox solution because I deployed the solution at farm level.

Initial Hypothesis: I notice my lists had strange behaviour.  I check my deployment and 1 of the solutions had not been deployed.  When I deployed the wsp using Powershell (PS> Install-SPSolution ...) it did not error so I had presumed it had installed correctly.  Using PowerShell (PS) I could see the solution holding the list wasn't installed. PS> Get-Solution

Resolution: Retract the solution and remove it from the farm.  Deploy the solution to the Site Collection's solutions and enable the feature/s.  Powershell Commands:

PS> Add-SPUserSolution -LiteralPath D:\packages\.Lists.wsp -Site http://demo.dev

PS> Install-SPUserSolution –Identity Lists.wsp -Site http://demo.dev
PS> Enable-SPFeature –Identity Feature_GeneralLists –url http://demo.dev/

Tip: Update 10 Dec 2010 - If you remove a solution (this also applies to sandbox solutions) (including deactivating the associated features), if the feature deploys content types or site columns, you will need to do an IISreset if you want the content types and site columns removed from the Site Collection (alernatively restart the Web Application so the whole farm is not reset).

Post on deploying fasm wsp's.

Custom Claims Membership Provider

Problem: We have written a custom claims membership provider, it works in development however if fails in the UAT environment.  The Membership provider goes to an LDAP directory (IBM TAM).

Initial Hypothesis: After checking the configuration was correct, I looked at the logs that were informing me that the provider was not returning results.  We can't use wireshark on the UAT environment to verify the call is being made to the LDAP directory.  And the error message is a generic failure message.

Resolution: Use Telnet to check that the WFE/WebService/STS/SharePoint token service can speak to the LDAP directory.
cmd>Telnet 192.168.1.101 389

The Claims web service cannot contact the LDAP directory, most likely cause is the firewall or the windows firewall.  Add a rule to the firewall to allow traffic on port 389.

Deploying packages into production using PowerShell

Problem: Developers build solutions and features for SharePoint 2010 using Visual Studio 2010 (VS), the farm wsp's need to be deployed in UAT, pre-production, production, CI potentially etc.  You don't have VS so you can use stsadm or Powershell.

Initial Hypothesis: This is a walk-thru on deploying your solutions and features in SharePoint 2010.  The main areas are:

1. creating solution files (wsp's);
2. moving them to the target environment;
3. adding the various solutions and features at the appropriate level in your farm (features have 4 steps to get into production namely:

• Add Solution,
• Install Solution,
• Install Feature and
• Activate Feature.

Resolution:

1.> Create wsp's
1.1> Using VS2010, put the project into "Release" mode

1.2.> Next create the package using VS

2.> Copy the wsp located in the bin\Release directory of your VS solution to the farm where CA is hosted.
3.> Add solutions and activate features.
PS> Add-SPSolution D:\Packages\Demo.wsp
PS> Install-SPSolution –Identity Demo.wsp -GACDeployment
PS> Install-SPFeature demo_feature1 -force
PS> Enable-SPFeature –Identity demo_feature1 –url http://demo.dev/sites/demo
Tip: The feature scope requires different parameters.  For example if the feature above ( ) was scoped at Site (Site collection) level, the cmd would be: PS> Install-SPSolution –Identity Demo.wsp -GACDeployment –WebApplication http://demo.dev/
Scoped as web application level
PS>Install-SPSolution –Identity Demo-WepAppScope.wsp -GACDeployment –WebApplication http://demo.dev/sites/demo
Remove a web or site scoped solution
PS> Disable-SPFeature –Identity demo_feature1 –url http://demo.dev/sites/demo
PS> UnInstall-SPFeature demo_feature1 -force
PS> UnInstall-SPSolution –Identity Demo.wsp -GACDeployment
PS> Remove-SPSolution Demo.wsp
Cmd to add the SharePoint snapin, allowing the administration to manage SharePoint
PS> Add-PSSnapin Microsoft.SharePoint.PowerShell

Post on deploying Sandbox solutions.

Update: 27 Feb 2013.  The Install-SPFeature is only used for manual install i.e. not with wsp deployments but when you manually copy the feature files to each WFE.  You can keep the step as it has no negetive impact but it is not required.

Update: 20 May 2013.  This just bit me again.  I have an SP Timer Job scoped to WebApplication, by default when the solution/wsp is deployed, the feature receiver is activate automatically on ALL web applications (including MySites).  Change the Feature xml to include the attribute ActivateOnDefault="FALSE".

Read More:
http://sppowershell.com/2010/06/25/provisioning-sharepoint-2010-with-powershell/
http://msdn.microsoft.com/en-us/library/ms442691.aspx
http://stsadm.blogspot.com/2010/06/deploying-sharepoint-2010-solution.html
http://patrickboom.wordpress.com/2010/05/31/using-powershell-to-deploy-sharepoint-solutions-wsp-2/
http://dotnet.sys-con.com/node/1208275

Powershell - Running as a farm administrator using the SharePoint plug-in on Powershell

Problem: I need to run SharePoint Powershell commands in Production/UAT, I get remote access to the servers however the account is not the SharePoint farm account as the Famr account runns windows services and should not have remote access to the servers. 

Initial Hypothesis: Remote desktop into the WFE server, use the command prompt to launch Powershell using the farm account.  Lastly, add the SharePoint snapin for SharePoint 2010.
Update 6 Dec 2010 - Alternatively, hold down the shift key and right click the program you wish to run, you are given the "run as .." menu option.

Resolution:
1.> Remote desktop into the machine using a remote desktop access account i.e. demo\
2.> Open the cmd prompt and run the following cmd:
cmd > runas /user:demo\farm_admin c:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe
3.> In the new Powershell windows add the PowerShell snapin
ps c:\windews\system32> Add-PSSnapin Microsoft.SharePoint.PowerShell

Read More:
http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/fcb77654-0f13-42e0-b181-6e52242fe9d6  Adding the SharePoint snapin to PowerShell.

DateTime control default behaviour

Problem: The SharePoint date time control's default behaviour is to returns the current date and time when no date has been selected.
Initial Hypothesis: Validate the control to pre insert to check if it is selected, if no date time is choosen don't update the record.
Resolution:  The Property IsDateEmpty returns "false" if the date has been input.
Code:
if (!dtMyBirthday.IsDateEmpty)  { // ... User has delected their birthday date so insert into SQL table or list }

Read More:
http://karinebosch.wordpress.com/sharepoint-controls/datetimecontrol-control/

Changing service account passwords - The Service is unavailable

Problem: Browsers return the following error "Service Unavailable  Http Error 503.  The Service is unavailable." on all SharePoint websites including central admin.

Initial Hypothesis: I changed my password yesterday causing the app polls to fail when logging in.  The domain account used on my development machine required a password change.  Starting the machine causes all the IIS web sites to display the error message "Service Unavailable".  I run various services and application polls using my domain account.  The services can no longer log on.  Application pool cannot be started after the reboot/iisreset.

Resolution:  Change the log on details for the application pools used by IIS that run using the domain account that's password was reset.  Also start the Windows services that run using the windows domain account.

Ensure the SharePoint services running

Installing SharePoint using a dedicated Installation account

Problem: Best practice is to install SharePoint servers using a dedicated install account.  This account is not the farm account.  Once the installation is complete, the installation account should be disabled.  You need to install in the role of the admin account to install correctly. 

Note:  If your install and farm account are the same as is often the case, this post does not apply to you.

Initial Hypothesis:  It is only worth following this post if you are using at least 5 or more accounts for your farm install.  The idea is that the installation account is disabled after installation.

Resolution:  The farm account needs the 2 SQL Server security roles namely: dbcreator and securityadmin.  The farm account still needs local admin permission rights on each Web Front End (WFE) server.  The Installation account does not need any SQL Server permissions.

Using the codeplex AutoSPinstaller.  Launch the installer using a cmd prompt using the runs cmd to run in the farm domain admin priviledge.
cmd> runas /user:demo\farm_admin %windir%\system32\cmd.exe
cmd> D:\SP2010\Script>Launch.bat


You can also do the runas shotcut to change the account installing SharePoint.
Update 6 Dec 2010 - Hold down the shift key and right click the cmd prompt program menu, you are given the "run as .." menu option.

Update: 22 June 2011 - the current version of AutoSPInstaller is 2.5, additionallly the codeplex project is called AutoSPIntaller not SPAutoInstaller as previously named.

AutoSPInstaller - Step-by-step guide: http://blog.lekman.com/2010/11/automated-sharepoint-2010-installations.html