Friday, November 9, 2012

Difference between Farm and Sandbox solutions in SharePoint

Farm Solutions:

Farm solutions, which are hosted in the IIS worker process (W3WP.exe), run code that can affect the whole farm. When you debug a SharePoint project whose Sandboxed Solution property is set to "farm solution," the system's IIS application pool recycles before SharePoint retracts or deploys the feature so as to release any files locked by the IIS worker process. Only the IIS application pool serving the SharePoint project's site URL is recycled.

Sandbox Solutions:


Sandboxed solutions, which are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe), run code that can only affect the site collection of the solution. Because sandboxed solutions do not run in the IIS worker process, neither the IIS application pool nor the IIS server must restart. Visual Studio attaches the debugger to the SPUCWorkerProcess process that the SPUserCodeV4 service in SharePoint automatically triggers and controls. It is not necessary for the SPUCWorkerProcess process to recycle to load the latest version of the solution.

How to add WFE(Web Front Servers) in SharePoint 2010

Solution:


You need to join the new server to the farm, then go to Services on Server (in Central Administration) and enable Microsoft SharePoint Foundation Web Application Service. Then you'll see that in IIS your websites and application pools appeared

Managed Accounts in SharePoint 2010

Microsoft SharePoint Server 2010 provides a number of compelling improvements designed especially for the system administrator, of these, commonly overlooked, are Managed Accounts.  A Managed Account is effectively an Active Directory user account whose credentials are managed by and contained within SharePoint.  In addition to storing the credentials of the object, Microsoft SharePoint Server 2010 can also leverage Active Directory Domain Policies to  automatically reset passwords while meeting the requirements established by policy.
How credentials are stored…
Managed Account credentials are encrypted using a farm encryption key that is specified when you run PSConfig[ui].exe at farm creation based on the passphrase.  The passphrase is stored in a secure registry location so that it can only be accessed by the farm account and encrypted so that only the farm account has access (we won’t get into the encryption specifics here). The farm encryption key subsequently, is stored in the Configuration Database.   This scenario is what enables farm administrators to join machines to the farm without specifying the credentials as had to be done in previous versions of the product.
The last sentence of the paragraph above illustrates one of immediate benefits of using Managed Accounts, for example, suppose an administrator would like to create a new Web application using Windows PowerShell and/or SharePoint Central Administration – the administrator only needs to specify the Application Pool account (Windows PowerShell) or select the account in the SharePoint Central Administration user interface as opposed to both having to know the domain\username and associated password.
Example (Windows PowerShell)
$provider = New-SPAuthenticationProvider -ASPNETMembershipProvider "LdapMember" -ASPNETRoleProviderName "LdapRole"
$webApp = New-SPWebApplication -Name "Claims" -ApplicationPool "Claims Application Pool" -ApplicationPoolAccount "CONTOSO\administrator"
  -Url
http://claims.contoso.com -Port 80 -AuthenticationProvider $provider
Get Managed Accounts (SharePoint Central Administration)
  1. To view existing Managed Accounts using SharePoint Central Administration, select Security from the SharePoint Central Administration homepage.
  2. On the Security page select Configure managed accounts under General Security.
  3. The Managed Accounts page will list all Managed Accounts registered in SharePoint.
Register Managed Accounts (SharePoint Central Administration)
  1. To register new Managed Accounts using SharePoint Central Administration, select Security from the SharePoint Central Administration homepage.
  2. On the Security page select Configure managed accounts under General Security.
  3. On the Managed Accounts page select Register Managed Account.
  4. On the Register Managed Account page (see illustration below) specify the credentials and select the password change policies as desired.
CA

Get Managed Accounts (Windows PowerShell)
  1. To view existing Managed Accounts using Windows PowerShell, open the SharePoint 2010 Management Shell and enter Get-SPManagedAccount at the prompt.  For additional information on using the Get-SPManagedAccount CmdLet enter Get-Help Get-SPManagedAccount at the prompt.
ManagedAccount
Register Managed Accounts (Windows PowerShell)
  1. To register Managed Accounts using Windows PowerShell open the SharePoint 2010 Management Shell and use the Set-SPManagedAccount CmdLet (see below for syntax).
Syntax
New-SPManagedAccount [-Credential] <PSCredential> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Configure Managed Accounts (Windows PowerShell)
  1. To configure Managed Accounts using Windows PowerShell open the SharePoint 2010 Management Shell and use the Set-SPManagedAccount CmdLet (see below for syntax).
Syntax
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> [-AssignmentColle
ction <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotif
ication <Int32>] [-PreExpireDays <Int32>] [-Schedule <String>] [-WhatIf [<S
witchParameter>]] [<CommonParameters>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> [-AssignmentColle
ction <SPAssignmentCollection>] [-AutoGeneratePassword <SwitchParameter>] [
-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays
<Int32>] [-Schedule <String>] [-WhatIf [<SwitchParameter>]] [<CommonParamet
ers>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> -ConfirmPassword
<SecureString> -NewPassword <SecureString> [-AssignmentCollection <SPAssign
mentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>
] [-PreExpireDays <Int32>] [-Schedule <String>] [-SetNewPassword <SwitchPar
ameter>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> -ExistingPassword
<SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm
[<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays <Int32>]
[-Schedule <String>] [-UseExistingPassword <SwitchParameter>] [-WhatIf [<Sw
itchParameter>]] [<CommonParameters>]
For additional information on using the Set-SPManagedAccount CmdLet enter Get-Help Set-SPManagedAccount at the prompt.

Difference between Application Server and Web Server 


Application Server:


 Application server maintains the application logic and serves the web pages in response to user request. That means application server can do both application logic maintanence and web page serving. 

Web Server: 


Web server just serves the web pages and it cannot enforce any application logic. Final conclusion is: Application server also contains the web server.

Difference between CLR,CTS and CLS in .Net


CLR....

The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET initiative. It is Microsoft's implementation of the Common Language Infrastructure (CLI) standard, which defines an execution environment for program code. The CLR runs a form of bytecode called the Common Intermediate Language (CIL, previously known as MSIL -- Microsoft Intermediate Language).
Developers using the CLR write code in a language such as C# or VB.Net. At compile time, a .NET compiler converts such code into CIL code. At runtime, the CLR's just-in-time compiler converts the CIL code into code native to the operating system. Alternatively, the CIL code can be compiled to native code in a separate step prior to runtime. This speeds up all later runs of the software as the CIL-to-native compilation is no longer necessary.
Although some other implementations of the Common Language Infrastructure run on non-Windows operating systems, Microsoft's implementation runs only on Microsoft Windows operating systems.

The virtual machine aspect of the CLR allows programmers to ignore many details of the specific CPU that will execute the program. The CLR also provides other important services, including the following:

* Memory management
* Thread management
* Exception handling
* Garbage collection
* Security

CLS...

To fully interact with other objects regardless of the language they were implemented in, objects must expose to callers only those features that are common to all the languages they must interoperate with. For this reason, the Common Language Specification (CLS), which is a set of basic language features needed by many applications, has been defined. The CLS rules define a subset of the common type system; that is, all the rules that apply to the common type system apply to the CLS, except where stricter rules are defined in the CLS. The CLS helps enhance and ensure language interoperability by defining a set of features that developers can rely on to be available in a wide variety of languages. The CLS also establishes requirements for CLS compliance; these help you determine whether your managed code conforms to the CLS and to what extent a given tool supports the development of managed code that uses CLS features.

If your component uses only CLS features in the API that it exposes to other code (including derived classes), the component is guaranteed to be accessible from any programming language that supports the CLS. Components that adhere to the CLS rules and use only the features included in the CLS are said to be CLS-compliant components.

Most of the members defined by types in the .NET Framework class library are CLS-compliant. However, some types in the class library have one or more members that are not CLS-compliant. These members enable support for language features that are not in the CLS. The types and members that are not CLS-compliant are identified as such in the reference documentation, and in all cases a CLS-compliant alternative is available. For more information about the types in the .NET Framework class library, see the .NET Framework Reference.

The CLS was designed to be large enough to include the language constructs that are commonly needed by developers, yet small enough that most languages are able to support it. In addition, any language construct that makes it impossible to rapidly verify the type safety of code was excluded from the CLS so that all CLS-compliant languages can produce verifiable code if they choose to do so. For more information about verification of type safety, see JIT Compilation.

The following table summarizes the features that are in the CLS and indicates whether the feature applies to both developers and compilers (All) or only compilers. It is intended to be informative, but not comprehensive. For details, see the specification for the Common Language Infrastructure, Partition I, which is located in the Tool Developers Guide directory installed with the Microsoft .NET Framework SDK.

CTS.....

The Common Type System (CTS) is a standard that specifies how Type definitions and specific values of Types are represented in computer memory. It is intended to allow programs written in different programming languages to easily share information. As used in programming languages, a Type can be described as a definition of a set of values (for example, "all integers between 0 and 10"), and the allowable operations on those values (for example, addition and subtraction).

The specification for the CTS is contained in Ecma standard 335, "Common Language Infrastructure (CLI) Partitions I to VI." The CLI and the CTS were created by Microsoft, and the Microsoft .NET framework is an implementation of the standard.
 

Difference between Web Site and Web application in ASP.NET


• Development Wise Difference


Web Site
1. We can code one page in C# and one page in vb.net (Multiple programming languages allowed).
2. We cannot call (access) public functions from one page to other page.
3. Utility classes / functions must be placed in a special ASP.NET folder (the App_Code folder)
4. Web Sites do not have a .csproj/.vbproj file that manages the project (the folder that contains the site becomes the project root).
5. In the Web Site project, each file that you exclude is renamed with an exclude
keyword in the filename.
6. Explicit namespaces are not added to pages, controls, and classes by default, but you can add them manually.


Web Application
1. Only one programming language allowed per project (Need to decide on programming language when starting project).
2. We can access public functions from one page to other page.
3. Utility classes / function can be placed anywhere in the applications folder structure.
4. Web Applications are treated like other .NET projects and are managed by a project file (.csproj or .vbproj) .
5. One nice feature of the Web Application project is it's much easier to exclude files from the project view.
6. Explicit namespaces are added to pages, controls, and classes by default.




• Deployment wise difference


Web Site
1. It has its code in a special App_Code directory and it's compiled into several DLLs (assemblies) at runtime.
2. No need to recompile the site before deployment.
3. We need to deploy both .aspx file and code behind file.
4. Small changes to the site do not require a full re-deployment. (We can upload the code file that was changed) 

Web Application
1. web application is precompiled into one single DLL.
2. Site has to be pre-compiled before deployment .
3. Deploy only .aspx page, but not associated code file (the pre-compiled dll will be uploaded) .
4. Even small changes require a full re-compile of the entire site(i.e. if the code for a single page changes the whole site must be compiled) (It requires careful planning to ensure new bugs aren't introduced to the production site when uploading bug fixes or other changes.)




sample format of .CSPROJ file in web application
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <ProjectView>ProjectFiles</ProjectView>
  </PropertyGroup>
  <ProjectExtensions>
    <VisualStudio>
      <FlavorProperties GUID="{349c5851-65df-11da-9384-00065b846f21}">
        <WebProjectProperties>
          <StartPageUrl>CheckboxListTest.aspx</StartPageUrl>
          <StartAction>SpecificPage</StartAction>
          <AspNetDebugging>True</AspNetDebugging>
          <NativeDebugging>False</NativeDebugging>
          <SQLDebugging>False</SQLDebugging>
          <PublishCopyOption>RunFiles</PublishCopyOption>
          <PublishTargetLocation>
          </PublishTargetLocation>
          <PublishDeleteAllFiles>False</PublishDeleteAllFiles>
          <PublishCopyAppData>True</PublishCopyAppData>
          <ExternalProgram>
          </ExternalProgram>
          <StartExternalURL>
          </StartExternalURL>
 

Wednesday, June 29, 2011

SharePoint:error while accessing SSP

Issue:
When i tried to go to default SSP it is showing the below error message:
Service Unavailable
HTTP Error 503. The service is unavailable.

And i thought of creating new SSP and routing it to existing web application
But we see the following error message:

An unhandled exception occurred in the user interface. Exception Information: Invalid URI: A port was expected because of there is a colon (':') present but the port could not be parsed

If we want to find the root cause we need to change the web.config file, but it may cause the space issue in the WFE servers....so what to do.

Resolution:

If you are facing the current issue, check this steps

If its a 503 error, check the credentials of the application pool whether its matching or not change the identity to Built-In accout or specify the particular accout
you can see this in the right hand side of Application pool Actions-->your app-->identity
change the identity

and if you have corrupted SSP or the secon error message you need to do the following steps:

  1. Create new SSP using STSADM command.

Syntax

stsadm -o createssp
   -title <SSP name>
   -url <Web application URL>
   -mysiteurl <MySite URL>
   -ssplogin <user name>
   -indexserver <index server>
   -indexlocation <index file path>
   [-ssppassword <password>]
   [-sspdatabaseserver <SSP database server>]
   [-sspdatabasename <SSP database name>]
   [-sspsqlauthlogin <SQL user name>]
   [-sspsqlauthpassword <SQL password>]
   [-searchdatabaseserver <search database server>]
   [-searchdatabasename <search database name>]
   [-searchsqlauthlogin <SQL user name>]
   [-searchsqlauthpassword <SQL password>]
   [-ssl <yes|no>]
  1. route all the exsting webapplications to the new SSP using central admin.
  2. make the new SSP as default one.
  3. Delete the exsting one using STSADM command.

Syntax

stsadm -o deletessp
   -title <SSP name>
   [-deletedatabases]
   [-force]

thats it its works fine.

Friday, June 17, 2011

SharePoint:Different types of Content Types in SharePoint 2007

These are the different content types available in Sharepoint 2007
Bussiness Intelligence
Custom
Document
Folder
List
Microsoft Project
Page Layouts
Publishing
Special

Wednesday, June 15, 2011

SharePoint:Creating a Form based authentication(FBA)

check this links
http://www.devcow.com/blogs/jdattis/archive/2007/02/23/Office-SharePoint-Server-2007-Forms-Based-Authentication-FBA-Walkthrough-Part-1.aspx
http://www.devcow.com/blogs/jdattis/archive/2007/02/23/Office-SharePoint-Server-2007-Forms-Based-Authentication-FBA-Walkthrough-Part-2.aspx



SharePoint: Configuring Indexing Server

In this section I am gonna tell you how to configure index server. Basically index server is required when configuring SSP (Shared Service Provider) in SharePoint. So we need to have index server configured before configuring SSP. Following are the series of steps to configure index server.
  1. Open Central Administration; navigate to Operations--> Topology and Services--> Servers in Farm.
  2. Click server on which you want to run indexer service.
  3.  Click on Office SharePoint Server Search listed in the service list.
  4.  Fill in the details and in Web Front End And Crawling section select Use a dedicated web front end computer for crawling, select server name from dropdown list, and press OK.



Now you have done with configuring index server, it's time to start it. Click on the 'start' link in the action column in front of Office SharePoint Server Search.
  1. Configure Office SharePoint Server Search Service Settings on server creativitybox’ form will be opened, fill in required fields and press Start

SharePoint: Adding content database to Webapplication

  1. Verify that the user account that is being used to perform this operation is a member of the Farm Administrators SharePoint group. If you are using Windows authentication to connect to SQL Server, the user account must also be a member the SQL Server dbcreator fixed server role on the SQL Server instance where the database will be created. If you are using SQL authentication to connect to SQL Server, the SQL authentication account that you specify when you create the content database must have dbcreator permission on the SQL Server instance where the database will be created.
  2. On the SharePoint Central Administration Web site, click Application Management.
  3. In the Databases section, click Manage content databases.
  4. On the Manage Content Databases page, click Add a content database.
  5. On the Add Content Database page:
    1. Specify a Web application for the new database.
    2. Specify a database server to host the new database.
    3. Specify the authentication method that the new database will use and supply an account name and password, if they are necessary.
    4. Specify the name of the failover database server, if one exists.
    5. Specify the number of top-level sites that can be created before a warning is issued. By default, this is 9,000.
    6. Specify the total number of top-level sites that can be created in the database. By default, this is 15,000.
    7. Click OK.

Tuesday, May 24, 2011

SharePoint:Managed properties in Sharepoint

 Here are some examples of managed properties that are available in MOSS 2007,
  • AssignedTo
  • Author
  • ContentType
  • FileExtension
  • SiteTitle
  • etc..

SharePoint:Limits and details in Moss

For SharePoint Portal Server, here's an extract from the Capacity Planning whitepaper:
It is important to understand the ramifications of the different features and functions of the SharePoint Portal Server solutions to size the system so that the performance of the system is good.
The following table lists some of the SharePoint Portal Server objects and describes their recommended use. "Typical" indicates comfortable and well tested; "maximum" indicates that the system can support that number, but not without some performance ramifications or
special configurations.
An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.
  • Portal sites (full) - typically 2 ... maximum 15 *
  • Portal sites (child) - typically 10 ... maximum 100 *
  • Areas - typically 1,000 ... maximum 10,000
  • Best Bets - typically 1,000 ... maximum 25,000
  • Area depth - typically 5 ... maximum 20 *
  • User profiles - typically 50,000 ... maximum 1,000,000
  • Audiences - typically 500 ... maximum 10,000
  • Audience memberships - typically 500,000 ... maximum 5,000,000
  • SSO credentials - typically 100,00 ... maximum 100,000
  • Search indexes - typically 3 ... maximum 32
  • Content sources -typically 25 ... maximum 250
  • Search scopes - typically 25 ... maximum 250 *
  • Indexed documents per content index - typically 100,000 ... maximum 5,000,000
  • Indexed documents - typically 2,500,000 ... maximum 20,000,000
  • Thesaurus entries - typically 1,000 ... maximum 10,000
  • Alerts - typically 50,000 ... maximum 1,000,000
  • Team sites - typically 10,000 ... maximum 250,000
  • Personal sites - typically 10,000 ... maximum 250,000

SharePoint:Administrations concepts and limits


I frequently get asked for SharePoint scaling limits so I though I would blog an entry I can refer people to.

First an extract from the Capacity Planning section of the Windows SharePoint Services Administration guide which answers general WSS limits questions:

None of these are hard limits enforced by the system. They are guidelines for designing a server that has good overall performance.
  • Site collections (Database scope) 50,000 ... Total throughput degrades as the number of site collections increases.
  • Web sites (Web site scope) 2,000 ... The interface for enumerating subsites of a given Web site does not perform well much
    beyond 2,000 subsites.
  • Web sites (Site collection) 250,000 - You can create a very large total number of Web sites by nesting the subsites. For example, 100
    sites each with 1000 subsites is 100,100 Web sites.
  • Documents (Folder scope) 2,000 ... The interfaces for enumerating documents in a folder do not perform well beyond a thousand entries.
  • Documents (Library scope) 2 million ... You can create very large document libraries by nesting folders.
  • Security principals (Web site scope) 2,000 ... The size of the access control list is limited to a few thousand security principals, in other words users and groups in the Web site.
  • Users ( Web site scope) 2 million ... You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users.
  • Items (List scope) 2,000 ... The interface for enumerating list items does not perform well beyond a few thousand items.
  • Web Parts (Page scope) 100 ... Pages with more than 100 Web Parts are slow to render.
  • Web Part personalization (Page scope) 10,000 ... Pages with more than a few thousand user personalizations are slow to render.
  • Lists (Web site scope) 2,000 ... The interface for enumerating lists and libraries in a Web site does not perform well beyond a few thousand entries.
  • Document size (File scope) 50 MB ... The file save performance degrades as the file size grows. The default maximum is 50 MB. This maximum is enforced by the system, but you can change it to any value up to 2 GB (2047 MB) if you have applied Windows SharePoint Services Service Pack 1.

SharePoint:Patch MOSS / WSS with minimal downtime


I have found this perfect article on my friend's blog and as it is absolutely amazing, and very helpfull I decided to link it here.

Original can be found here: Dirk Van den Berghe SharePoint Blog


preparation tasks:
- create a custom App_Offline.htm file for showing a maintenance page  - Copying this file into the root location of each IIS website used by SharePoint Web Applications will show this message instead of the SharePoint content.
- create a batch file that conveniently copies the App_Offline.htm file to all Web Applications (make sure not to copy it to the Central Admin WebApp)
- create a batch file that conveniently deletes the App_Offline.htm file from all Web Applications
- create a batch file that detaches all content databases for all Web applications with the exception of the Central Admin and SSP Web Apps ( add stsadm -o preparetomove command before detach database if you are still running MOSS SP1 pre-Infrastructure Update)
- create a batch file that attaches the content databases

Now you can start with following steps..



Upgrade process:
1.  Make sure that the hardware load balancers stops the services for WFE1 and only uses WFE2 to service user requests. We have an internal procedure that allows for manipulation of the load balancer. Actually we simply need to stop a custom IIS web site on the WFE server which will cause the load balancer to failover to the second WFE automatically.
Availability Result: Users are still able to access SharePoint content through WFE2.
Timing result: this operation took 2 minutes
2. Install the binaries for your SharePoint upgrade on WFE1. In my case WSS SP2 + MOSS SP2 +  all SP2 versions of the WSS and SharePoint Language Packs and finally installing the June Cumulative Update for WSS and MOSS. When installation completes, reboot the server.
Availability Result: Users are still able to access SharePoint content through WFE2.
Timing result: this operation took 50 minutes
3. Simultaneously install the same binaries on the index server. When installation completes, reboot the server.
Availability Result: Users are still able to access SharePoint content through WFE2.
Timing result: this operation took 40 minutes
OK So far so good. So basically, at this point, I have installed the binaries on 2 servers and I still have 1 to go, which is WFE2 that is still serving the SharePoint sites. I have two possibilities to continue:
- option1: install the binaries on WFE2 and reboot
- option2: run the configuration wizard on the upgraded WFE1 or the index server.
Option 1 will take all the sites down, because the installation of new binaries will stop IIS = Downtime and 404 errors. I cannot redirect my users to the upgraded WFE1, because the configuration Wizard has not run yet. So I am working with option 2
4. on WFE2 I launch my script that sets all my sites in maintenance mode (copies the App_Offline.htm file, that is)
Availability Result: Users are not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
Timing result: this operation took 1 minute
5. on WFE2 I launch my script for detaching all content databases
- this script launches a stsadm -o preparetomove command for each content database (except Central Admin and SSP databases). This command is no longer required if you have at least SP1 with the Infrastructure Update installed.
- this script launches a stsadm -o deletecontentdb command for each content database (except Central Admin and SSP databases)
Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance through WFE2.
Timing result: this operation took 5 minutes ( I had 5 content databases)
6. on WFE1, run the SharePoint Products and Technologies Configuration Wizard.
If the upgrade process fails, investigate the log specified by the wizard, but also check 12-Hive\LOGS\Upgrade.log and the default SharePoint ULS logs. I have already seen that the SharePoint logs are written to the 12-Hive\LOGS folder instead of the location you specified in Central Admin during this upgrade process. After the upgrade your specified Logging location is used again.
Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
Timing result: this operation took 15 minutes
7. Now that the farm configuration databases have been upgraded, your WFE1 is ready to start serving users again as soon as the content databases have been reattached. So, on WFE1 I launch my script to reattach the content databases. If one the operations generate an error, you can find the specific error in the 12-Hive\LOGS\Upgrade.log file.
Availability Result: Users are still not able to access SharePoint content, but they receive a nice page stating that their site is down for maintenance
Timing result: this operation took 10 minutes.
8. Make sure that the hardware load balancers starts the services for WFE1 and stops the services for WFE2 to service user requests.
Availability Result: Users are again able to access SharePoint content through WFE1.
Timing result: this operation took 2 minutes
My upgrade status is now complete with regards to the SharePoint content. My farm is servicing users again through a single Web Frontend Server for the moment, but it is servicing which is my main concern at this point. I no longer have downtime towards my users. If you add up all the minutes, then I have had a downtime towards my users of 33 minutes, which can be considered a small downtime. Now I continue with the rest of the upgrade process.
9. WFE2 is free now to do with whatever I want since it is no longer included in the load balancer pool.
- first, I launch my script to deactivate the site maintenance which simply deletes all App_Offline.htm files
- Next, I Install the binaries for the SharePoint upgrade on WFE2 + Reboot the server
Availability Result: Users are able to access SharePoint content through WFE1.
Timing result: this operation took 50 minutes
10. While WFE2 is installing the new binaries, I can run the SharePoint Products and Configuration Wizard on the index server.
Availability Result: Users are able to access SharePoint content through WFE1.
Timing result: this operation took 6 minutes
11. Run SharePoint Products and Configuration Wizard on WFE2
Availability Result: Users are able to access SharePoint content through WFE1.
Timing result: this operation took 8 minutes
12. Final step: Add WFE2 back into the load balancer pool

Saturday, May 14, 2011

Interview Question in SharePoint

http://programmingsharepoint.blogspot.com/2008/02/sharepoint-interview-questions.html

Sharepoint:Stsadm syntax for feature and webpart deployment

For Feature:

STSADM -o InstallFeature -filename HELLOWorldFea\feature.xml -force


For Webpart:

Stsadm -o addwppack -filename filename [-globalinstall] [-force]

Monday, May 2, 2011

SharePoint:Create a New Page Layout in SharePoint 2007 - Feature-Based

So the requirement presented to me for a client was to take an existing page layout and change a few of the properties to allow it to use some custom styles implemented at the site collection level. To do this, I needed to create a new page layout based on an existing layout, make this part of a feature and pull in all the bits and pieces necessary to deploy this as a feature. Finally, I had to deploy it to the client's testing environment.
Here is how I did it...
First, I was instructed that the Search Main Page was to be used as the starting point. A developer on my team told me the best way to go would be to load up SharePoint Designer, navigate to the appropriate document library and export the file. This didn't work. My requirement was to have the search web part already on the page, the same as the existing search main page. SharePoint Designer killed this web part tag so it came up empty.
Getting a copy of the page layout
1. Better is to go to the site collection you're starting with
2. Select "Site Actions" -> "Site Settings" -> "Modify All Site Settings"
3. Under "Galleries", select "Master pages and page layouts"
4. Find the page layout from the list and open its context menu, select "Send to" -> "Download a Copy"
5. Save the file to the solution location. We won't be using Visual Studio because its not necessary for this evolution.
6. Once the file is saved, reopen the context menu for the page layout file and select "View Properties".
7. Click on the Preview Image and when it appears, right click and save the image to the same location as the aspx file.
Now you have the basic aspx files you will modify and put back into SharePoint as a feature. Open the aspx page in an appropriate editor. I'm assuming you understand enough about aspx to do what you need to do. Make the appropriate modifications and save the file.
IMPORTANT NOTE: If you are like me, you have a desire to 'clean up' the file declarations so you can see what's going on. Don't do this. I haven't figured out why but when I introduced hard returns in the second line (the really long one) of declarations between <% %> sections, it bombed when I reimported it into SharePoint. A guy on the team here thinks there may be a checksum on that line to head off tampering. Dunno but I know when I leave it it works, when I touch it it bombs.
You can also use any editor (Paint.Net works) to change the page layout to look the way you want it to. Change the folder of this file to your feature folder + "\Images". It's required for the page layouts and master pages.
So you should have two files and a subfolder for your feature ready to go.
Now we need to set up the feature to deploy it.
1.
Create two new files in any editor: "feature.xml" and "layoutfiles.xml"
2. Here are the contents of my feature.xml file:
 <Feature  Id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
     Title="Custom Formatted Search Page Layout by Jim"
     Description="Search page with customized style inclusions"
     Version="1.0.0.0"
     Scope="Site"
     Hidden="FALSE"
     xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
   <ElementManifest Location="layoutfiles.xml"/>
  </ElementManifests>
 </Feature>
2.1. Id is a new GUID you generate from Visual Studio.
2.2. Scope means the level where this will be used, not the level at which it becomes available for items below it. So "Site" scope means it will be installed at the site collection level and used at the site level.
3. Here are the contents of my layoutfiles.xml file:
 <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="CustomSearchMain" Url="_catalogs/masterpage" Path="" RootWebOnly="TRUE">
   <File Url="CustomFormattedSearch.aspx" Type="GhostableInLibrary">
    <Property Name="Title" Value="$Resources:spscore,SearchMainTitle;" />
    <Property Name="MasterPageDescription" Value="$Resources:spscore,SearchMainDescription;" />
    <Property Name="ContentType" Value="$Resources:cmscore,contenttype_pagelayout_name;" />
    <Property Name="PublishingAssociatedContentType" Value=";#$Resources:cmscore,contenttype_welcomepage_name#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D4;#" />
    <Property Name="PublishingPreviewImage" Value="~SiteCollection/_catalogs/masterpage/Preview Images/customsearchpage.gif,     ~SiteCollection/_catalogs/masterpage/Preview Images/customsearchpage.gif" />
    <AllUsersWebPart WebPartZoneID="TopZone" WebPartOrder="1">
     <![CDATA[
                     <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
                         <Assembly>Microsoft.SharePoint.Portal, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
                         <TypeName>Microsoft.SharePoint.Portal.WebControls.SearchBoxEx</TypeName>
                         <Title>$Resources:spscore,SearchBoxWP_Title;</Title>
                         <Description>$Resources:spscore,SearchBoxWP_Desc;</Description>
                         <FrameType>None</FrameType>
                         <AllowMinimize>true</AllowMinimize>
                         <AllowRemove>true</AllowRemove>
                         <IsVisible>true</IsVisible>
                         <Width>420px</Width>
                         <GoImageUrl xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/gosearch.gif</GoImageUrl>
                         <GoImageUrlRTL  xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/goRTL.gif</GoImageUrlRTL>
                         <GoImageActiveUrl xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/gosearch.gif</GoImageActiveUrl>
                         <GoImageActiveUrlRTL  xmlns="urn:schemas-microsoft-com:SearchBoxEx">/_layouts/images/goRTL.gif</GoImageActiveUrlRTL>
                         <TextBoxWidth xmlns="urn:schemas-microsoft-com:SearchBoxEx">280</TextBoxWidth>
                         <SearchResultPageURL xmlns="urn:schemas-microsoft-com:SearchBoxEx">results.aspx</SearchResultPageURL>
                         <AdvancedSearchPageURL xmlns="urn:schemas-microsoft-com:SearchBoxEx">~Site/$Resources:cmscore,List_Pages_UrlName;/advanced.aspx</AdvancedSearchPageURL>
                         <ShowAdvancedSearch xmlns="urn:schemas-microsoft-com:SearchBoxEx">true</ShowAdvancedSearch>
                         <DropDownMode xmlns="urn:schemas-microsoft-com:SearchBoxEx">HideScopeDD</DropDownMode>
                         <ShouldTakeFocusIfEmpty xmlns="urn:schemas-microsoft-com:SearchBoxEx">true</ShouldTakeFocusIfEmpty>
                     </WebPart>
                     ]]>
    </AllUsersWebPart>
   </File>
  </Module>
  <Module Name="LayoutPreviewImages" Url="_catalogs/masterpage/Preview Images" Path="Images" RootWebOnly="TRUE">
   <File Url="customsearchpage.gif" Type="GhostableInLibrary"/>  
  </Module>
 </Elements>
3.1. I took most of this from a coleague and from the net. The CData portion gives you the embedded web part already in the top web part zone.
3.2. Notice the gif image parts of the xml. These are whatever the new name is for the gif you edited earlier.
3.3. Notice also the part that says: "contenttype_welcomepage_name". This means that your layout will appear under the "Welcome Page" templates when you go to use it in your site collection. I haven't found much about this on the web yet but I believe if you search on content types and master page libraries, you may find additional options.
Your feature is complete!
Now its time to deploy.
1. Copy your aspx, gif (in its folder) and 2 xml files to the server where you want to deploy and into a new temporary folder.
2. Copy from the temp location to the 12 hive \Template\Features\ folder.
3. Open a command line and run: stsadm.exe -o installfeature -name MyNewPageLayoutFeature -force
3.1. Use the -force option if you've already installed previously.
3.2. the -name value is the name of the folder where the your feature now exists in the 12 hive.
4. Execute iisreset
5. Browse the the appropriate site collection on your server and back to "Site Actions" -> "Site Settings" -> "Modify All Site Settings"
6. Under "Site Collection Administration" select "Site Collection Features"
7. You should see your new feature/page layout. Click to activate.
Use your new layout.
Now, when you go to create a new page, you should see your additional layout. When you select it, you should get your custom layout gif to show users what it will look like.
I can imagine really intricate uses of this for creating custom CRM dashboards or for magically including SilverLight applications in your system. Good Luck!

SharePoint:Editing page layout in publishing site

Steps:

  • Browse to the page
  • Click Site Actions, Edit Page
  • From the tool bar click Page
  • In the drop down list click Page Settings
  • Now pick your Page Layout
  • Click OK

SharePoint - Cannot convert a primitive value to the expected type 'Edm.Double'. See the inner exception for more details If y...

Ad