Online Training On SharePoint
                      

Friday, 30 May 2008

Deploying custom SharePoint site collection with the help of PowerShell in Windows Server 2008

With the availability of the new Windows PowerShell and the IIS 7.0 Windows Management Interface (WMI) in Windows Server 2008 makes the scripted configuration possible for custom SharePoint site collection.

Consider this scenario: An organization is developing a custom site collection that will include various assets, such as file items within IIS virtual directories (for example, style sheets and navigation graphics), list items in SharePoint lists, and document templates in document libraries. When the development and test phases of the project are complete, the assets must be copied or moved to the production environment. If the range of assets is complex, it may be worthwhile to script the movement of these assets from one deployment to another. The PowerShell environment provides all the necessary facilities to make this possible.
Since SharePoint object model can be accessed from inside PowerShell scripts it is possible to build very sophisticated configuration and deployment processes by using PowerShell. When deploying SharePoint Products and Technologies, Windows Server 2008, and IIS 7.0, PowerShell brings several advantages:
Full access to the SharePoint object model: Before the availability of PowerShell, access to the SharePoint object model was only possible through the development of either console or Web applications, written in a .NET language, compiled, and then deployed together with any reference DLLs. In the PowerShell environment, all the namespaces within the SharePoint object model are available by inserting references to the required namespaces. Now Web administrators and developers can develop their own PowerShell scripts to access the object model. And PowerShell scripts are parsed for execution at run time so that no compilation is needed.
Cmdlets: Many cmdlets are currently available to access OS system services and objects. Also, the PowerShell environment is fully extensible; we can build our own cmdlets to perform custom processing and make these available to PowerShell scripts. For example, we can build cmdlets to query and configure SharePoint-enabled Web sites, with access to the both IIS 7.0 Windows Management Interface (WMI) and the SharePoint object model.
Another benefit of PowerShell when we combine it with the SharePoint object model is the ability to quickly build custom SharePoint utilities without having to develop and deploy compiled applications. Combining this technology with Windows Server 2008 and SharePoint Products and Technologies enables a whole new potential set of custom automated deployment and configuration processes by using scripts.

You can also find interesting to read: Getting All the Web Objects URL in a SharePoint farm using PowerShell Scripting

Monday, 26 May 2008

Application Template Demo

Some very good sites to see the demo of the application templates. These sites have all the application templates installed to browse them and get an idea about them :
http://demo.sharepointservers.com/default.aspx
http://www.cjvandyk.com/blog/WSSTemplates/default.aspx
http://www.wssdemo.com/application/default.aspx

Thursday, 22 May 2008

IIS 7.0 with SharePoint Server

IIS 7.0 represents a significant evolution from earlier versions of IIS. While maintaining compatibility with IIS 6.0, several fundamental changes to the underlying architecture of the Web server allow for better functionality and deliver superior management functionality and extensibility.
Some of the most relevant changes for deployments of SharePoint Products and Technologies include:
Request Tracing: IIS 7.0 lets administrators create custom logging of requests to the Web server. This is especially useful in diagnosing error conditions such as memory leaks or frequent worker process cycling. The enabling of this feature can be done quickly and easily, and can greatly improve the ability of administrators to troubleshoot problems with Web applications. Request tracing rules can be configured for any combination of HTTP error codes, time delays, or system events. A log is created that has detailed information on each event that the administrator can review to diagnose the source of the problem.
In deployments of SharePoint Products and Technologies, one area where this can be especially useful is when an object on a page is causing an error. However, the message displayed on the page is not specific enough to determine the type or source of the error (for example, “An unexpected error has occurred”). More detailed analysis can be performed by reviewing the logs created by failed request access rules.
Dynamic configuration and improved availability: In earlier versions of IIS, many changes to Web application settings required full IIS resets to take effect. For 24-hours-a-day, 7-days-a-week operations, this has always presented challenges as the Web sites must be stopped and restarted to make these changes. With IIS 7.0, most of the configuration changes can occur dynamically, and will take effect as soon as the changes are implemented. Additionally, the recycling of application pools is now fully enabled as a task in both the management console and command-line interfaces for IIS 7.0. This new flexibility guarantees that changes to SharePoint Web applications can be implemented quickly with minimal effect on application availability.
New Task-Based Management Console: The IIS 7.0 management console has been completely rebuilt to feature a task-based interface in order to simplify the most frequently required tasks in the configuration and ongoing management of Web sites and applications. The new management console also allows for the management of remote IIS servers, reducing the need to start terminal sessions with those servers. The ultimate result of these improvements is increased productivity for administrators, as they can perform site configuration changes more quickly and intuitively than before. This eliminates the need to traverse through multiple tabs to find the individual items that have to be changed. In most cases, icons exist to perform the most commonly-required tasks in fewer steps than were previously necessary.
IIS 7.0 Command-Line Interface (CLI): IIS 7.0 has a comprehensive set of functions that can be invoked at a command prompt to perform common configuration tasks. This enables a new level of flexibility in creating configuration scripts that can automate Web site and application configuration. The CLI is accessed through AppCmd.exe, which can be accessed at a command prompt or in a batch command file. All key aspects of managing a server that runs IIS are available through this interface, such as the following:
· IIS sites and application pools can be created and configured
· List current applications, requests and worker pools
· Sites can be started and stopped, application pools can be recycled
· Backup and restore IIS configurations
· Export and import configurations
Access to the CLI can also be made through the Windows PowerShell, which contains several cmdlets (pronounced “command-lets”) that can access and manage the operating system.
IIS 7.0 Windows Management Interface (WMI): This consists of .NET namespaces that are used to access and manage IIS 7.0 configurations through a comprehensive set of classes and methods in the .NET Framework. This opens up new integration opportunities with other .NET-connected applications (for example, Windows SharePoint Services 3.0, Office SharePoint Server 2007, other .NET Framework applications). These namespaces can be accessed from inside custom .NET Framework applications or through the Windows PowerShell.
Worker Process Isolation: Worker processes, by default, are isolated in IIS 7.0, eliminating the need to modify IIS 6.0 configurations to enable process isolation (a best practice for environments that have fewer than five SharePoint Web applications).
Modules: In IIS 7.0, functional capabilities are managed through the inclusion of modules that are installed and referenced in configuration files. They give better control over features that are present within the Web Server role. For example, the various alternatives for authentication (that is, Windows integrated, digest, or forms authentication) are individually enabled as modules. Therefore, only those methods that are required for a given deployment of SharePoint Products and Technologies actually have to be installed and configured. This improves the manageability of SharePoint applications in addition to improving their security by reducing attack surface.

See Also: Getting All the Web Objects URL in a SharePoint farm using PowerShell Scripting

Tuesday, 20 May 2008

Changing the properties for default Templates

If we want to change the properties for a specific template we need to modify parameters in the webtemp.xml file.

1. To hide this template to change the hidden parameter and set this parameter to True. By default it is set to False.
2. If you want to change the title there is a parameter called title.

Same way you can change the description, order and images.

This file is located at at Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\1033\XML

Attempt A Question on Site Template: Question On Site Template

Monday, 19 May 2008

Comparing SharePoint Server with ASP.NET

Here are some of Advantages/Disadvantages of SharePoint apps over ASP.Net apps:
Advantages:
1. Many built-in features are available with MOSS which can be used to easily develop complex solutions.
2. Rich Security features which come built in.
3. Integrated with Content Management.
4. Very less efforts required to create basic sites with lot of features.
5. It is quite scalable.
6. OOB Integration with Office products.
7. Rich backup techniques
8. Business process can be integrated with Workflows.
9. Multiple sites can be created with the help of templates.
Disadvantages:
1. It is difficult to add custom code in SharePoint. Features and WSP files take time.
2. Diffcult to solve the problems in development.
3. Creating ASP.net pages is easy then creating web parts.
4. Cost is very high.
5. Performance for ASP.NET apps is much better.
6. Very few experts are there.

Advantages/Disadvantages of ASP.Net apps over SharePoint apps:
Advantages:
1. Here we have lot of control on application in terms of DB, UI.
2. Less cost to build.
3. Easy to develop and deploy.
4. Plenty of resources.
Disadvantages:
1. Takes lot more time to get same functionality as of SharePoint.
2. There is nothing built in. So every solution needs to start from zero.
3. Good DB knowledge is also required to create sites having data.
4. Security needs to build.

kick it on DotNetKicks.com

Wednesday, 14 May 2008

Removing 'My Sites' and 'My Links' from the SharePoint pages

To remove the 'My Sites' and 'My Links' pages from a site collection pages following approach needs to be followed:
1. Go to Central Admin
2. Go To Shared Services
3. Go to Personalization Services Permissions. This is available in the User Profiles and My Sites Section.
Now this will show all the user/groups. Here the permissions can be modified to hide these links.

Monday, 12 May 2008

Creating SSL enabled site collection in SharePoint

Here are the steps to create SSL enabled sites in SharePoint:

1. Go to central admin --> Create or extend a new web application --> Create a new web application.

2. Fill the details such as Web app, DB and App pool name. Select yes to enable SSL on the web application. If you are using host headers for this web app, then enter those too. It is important to set the port to 443, not 80.

3. After the web application has been created, reset IIS and then open up IIS mmc. Scroll to the IIS website that MOSS just created for you and select the right SSL certificate from the available certificates. Go to the Home Directory tab and click Advanced. We need to set the host header and the right IP for port 80. For SSL entries, select port 443 and the IP. Click on the edit button for SSL entries and check the 'Require SSL' box. Also check 'Require 128 bit encryption' to make this more secure.4. Now we can create our first site collection for this web app. MOSS will automatically create a new site collection for us and present us with a "https://.." link upon completion. We are now have a SSL ready web app.

You may also like to read: How to enable SSL for selected pages in MOSS

Thursday, 8 May 2008

Improving SharePoint Site Performance with Static Compression in IIS

The SharePoint sites which are having pages of large site faces the lot of performance issues. The issue sometimes comes because SharePoint page processing pipeline adds a lot of extra weight to the page. It adds certain default files such as core.js, core.css, init.js, and ie55up.js which are required for various reasons. These files can add 500 KB of uncompressed data to the original page size. These extra KBs can add up to 10–20 seconds of download time on slower connections. These files can not be easily removed as Office SharePoint Server requires these files to work properly, and Office SharePoint Server adds them automatically to the page at run time.
One way to improve performance is by doing IIS Compression. IIS can be compressed Statically or Dynamically. IIS 6.0 supports this.
Lets see what is Static Compression is:
Static compression To compress static assets such as .js files, .html files, and others this method is used. Static compression is a very simple process with little or no impact on server load. In this approach, the files are compressed the first time they are accessed, and are kept in a temporary folder and served to the user from the temporary directory from then on. In the case of Office SharePoint Server, all files in _layout directories (for example, .js files and .html files) are compressed. All other files, including files that are static in nature, are not treated as static if they are stored inside Office SharePoint Server. Mostly the large core.js file is compressed, and its size is reduced from about 250 KB to 57 KB. In addition, other system .js files such as init.js and init55up.js are compressed, which solves our biggest problem involving page size.

Wednesday, 7 May 2008

Debugging difference for MOSS Workflows with VS2005 and VS2008

With Visual Studio 2008 the workflow debugging has been made lot easier.

Here are the steps which were required to debug a workflow with VS2005:

1. Write the code
2. Build the workflow project.
3. Copy the latest feature.xml and workflow.xml files to the FEATURE directory.
4. Remove any existing copies of the workflow assembly from the GAC.
5. Add the latest version of the workflow assembly to the GAC.
6. Re-start IIS.
7. Install the feature with SharePoint using stsadm.
8. Activate the feature at a SharePoint site where you intend to perform the debugging.
9. Launch the web browser and go to the list that you want to associate the workflow with.
10. Associate the workflow with the list.
11. Attach the debugger to the correct IIS worker process. (W3WP)
12. Manually start the workflow.
13. Debug the workflow.

With VS 2008 the steps are:

1. Write the code.
2. Press F5 (This will build, deploys files, associates the workflow feature in SharePoint, attaches the debugger to the correct W3WP process, launches the browser).
3. Now Manually start the workflow.
4. And Debug the workflow.

Is It not easy!!!

Sunday, 4 May 2008

Security Model in SharePoint 2007

In order for people to use a MOSS web application, the web application must validate the person’s identity. This process is known as authentication. MOSS is not a directory service and the actual authentication process is handled by IIS, not MOSS. However, MOSS is responsible for authorization to MOSS sites and content after a user successfully authenticates. Authentication happens like this: A user points their browser at a MOSS site and IIS performs the user validation using the authentication method that is configured for the environment. If the user authentication is successful, then MOSS renders the web pages based on the access level of the user. If authentication fails, the user is denied access to the MOSS site. Authentication methods determine which type of identity directory can be used and how users are authenticated by IIS. MOSS supports three methods of authentication:
  1. Windows
  2. ASP.NET Forms
  3. Web Single Sign-On

Windows Authentication is the most common authentication type used in MOSS intranet deployments because it uses Active Directory to validate users. When Windows Authentication is configured, IIS uses the Windows authentication protocol that is configured in IIS. NTLM, Kerberos, certificates, basic, and digest protocols are supported. When Windows authentication is configured, the security policies which are applied to the user accounts are configured within Active Directory. For example, account expiration policies, password complexity policies, and password history policies are all defined in Active Directory and not in MOSS. When a user attempts to authenticate to a MOSS web application using Windows authentication, IIS validates the user against NTFS and Active Directory, and once the validation occurs the user is authenticated and the access levels of that user are then applied by MOSS.
Anonymous access is considered to be a Windows authentication method because it associates unknown users with an anonymous user account (IUSR_MACHINENAME). Anonymous access is commonly used in internet Web sites and in situations where web site users will not have their own user accounts. Since exposing content to unknown users is risky, this configuration is disabled by default. In order to configure anonymous access to a MOSS web application, anonymous access must be enabled in IIS, enabled in the MOSS web application, and the anonymous user account must be provisioned throughout the MOSS Web application. Even when anonymous access is configured, there are still several limitations compared to a Windows user. By default, anonymous users are only allowed to read, and they are unable to edit, update, or delete content. Additionally, anonymous users are not able to utilize personalization features such as Microsoft Office integration, check-in/check-out and email alerts. The ASP.NET Forms authentication method is commonly used in situations where a custom authentication provider is required. In other words, where a custom LDAP, SQL Server, or other type of identity repository will be storing user account information. This is common in extranet environments, such as partner collaboration sites, where it is not practical to create Active Directory user accounts for users or a different type of directory is required. The Web Single Sign-On authentication method is used in environments that have federated identity systems or single sign-on systems configured. In this type of environment, an independent identity management system integrates user identities across heterogeneous directories and provides the user validation for IIS. Some examples of identity management systems with single sign-on capability include Microsoft Identity Information Server with Active Directory Federation Services, Oracle Identity Management with Single Sign-On and Web Access Control, Sun Microsystems Java System Identity Manager, and Netegrity SiteMinder. Large enterprises often implement federated identity models to ease the administration of user provisioning and de-provisioning for systems that span across companies. Single Sign-On systems are used to consolidate user accounts across heterogeneous systems, allowing the end user to authenticate to systems with one set of credentials, rather than to use a different set of credentials for each unique system. In MOSS, it is possible to configure web applications to use a combination of authentication methods. This provides a great deal of flexibility because it makes it possible to serve a web application to different user bases which have different identity requirements. For example, an organization may have a Project Collaboration Web site that is used by employees and partners. For security and compliance reasons, it is necessary to store employee user accounts in Active Directory and partner user accounts in a SQL Server database. In this case, MOSS can be configured to use Windows authentication and ASP.NET Forms authentication. This is achieved by defining various zones and associated authentication methods to the zones. In the example above, an intranet zone would be configured with Windows authentication and an extranet zone would be configured with ASP.NET Forms authentication.

Attempt A Question on: Question on Authentication in SharePoint

Friday, 2 May 2008

Changing the default images for SharePoint

If we want to change the default image for the home page here is the way to achieve it:
1. Open the Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\IMAGES directory.
2. Copy the images that we want to appear on the home pages of our Web sites to this directory.
3. Remove the image files TITLEGRAPHIC.GIF and HOMEPAGE.GIF, which contain the logos used on the left and right sides of the home page, respectively.
4. Rename the new image files TITLEGRAPHIC.GIF and HOMEPAGE.GIF.
5. All sites now display new logos on their home pages

Thursday, 1 May 2008

Showling list of WepParts in a SharePoint Page

To get all the webparts which are available on a SharePoint Page we need to add ‘?contents=1’ at the end of URL. So if your web Page URL is http://Server/Pages/Default.aspx we need to put
http://Server/Pages/Default.aspx?contents=1

This is very helpful when web pages is corrupted becuase of some web part so we are not able to remove the webpart with the usual ways.

You can also find interesting to read Restoring the Closed Web Parts in a SharePoint Page and Error while Modifying the Web Parts in a SharePoint Page


Attempt questions on WebParts:

http://qmoss.blogspot.com/2008/10/question-on-webparts.html

http://qmoss.blogspot.com/2008/10/question-on-web-parts.html

Showing PDF document content in SharePoint

For showing content of pdf files in MOSS we can use Content Editor Web Part. To get this working we need to follow following steps:
1. Add the Content Editor Web Part to SharePoint Page. Then Add a “Content Editor Web part” to your SharePoint page. Now clicck on the “Open the Tool Pane”, click on “Source Editor” to place the HTML source.

2. Place the following piece of code in to the Source Editor:

The src goes to the location where the pdf files are stored. It can be in document library or a UNC Path.

3. Make sure pdf client is installed in the client machines .

You may find interesting to read: How to show movie files in SharePoint Pages

Attempt a question on Web Parts: Question on Web Parts

Related Posts with Thumbnails