Before MOSS, Microsoft’s strategy for publishing content on the Web has been based on Microsoft Content Management Server 2002 (CMS). CMS provides a structured way for content authors to add content to a company’s public Web site using professionally formatted layout pages. CMS also provides a formalized scheme where a privileged user must approve any page modification before it can be seen by the Web site’s visitors. In the past, many Microsoft customers have had to choose between CMS and SharePoint Portal Server 2003. While Microsoft released a connector named SPARK that provides a certain degree of integration between CMS and SharePoint Portal Server 2003, these two products are built on very different architectures. This has resulted in frustration because you cannot build a site that fully benefits from both the CMS Web content management features and the SharePoint Portal Server 2003 portal features. Microsoft has decided to discontinue evolving CMS as a stand-alone product and to migrate CMS Web content management features and the CMS customer base over to MOSS. This new strategy allows you to mix Microsoft's best-of-breed WCM features with its portal features in any site within a MOSS farm. If you have worked with CMS in the past, it’s important to note that the CMS concepts of channels and postings are not used in the MOSS WCM infrastructure. Instead, this new WCM infrastructure has been designed using basic WSS 3.0 building blocks such as child sites, page templates, content types, document libraries, and security groups. This newer approach lends itself to building custom solutions that extend the basic MOSS WCM infrastructure using standard WSS components such as custom event handlers and workflows.
Since the WCM features of MOSS are built on top of WSS 3.0, you begin the process of branding a MOSS portal site by customizing master pages to get the basic look and feel you're after. However, MOSS WCM features go further than this by extending WSS with the introduction of a publishing scheme based on page layouts. A page layout provides a structured approach for collecting content from content authors and displaying it on a page within a portal site. Examples of some of the page layouts provided by MOSS out of the box include welcome pages, articles, and news items. Most companies adopting the MOSS WCM features will create their own customized page layouts as well. By default, MOSS WCM features use the basic document approval features of a WSS document library to control when the updated content is shown to the site’s visitors. However, the MOSS WCM infrastructure was designed to make it straightforward to associate custom workflows with the content associated with a page layout in scenarios where you need something more sophisticated than the functionality that comes out of the box. MOSS WCM features provide a framework for document converters. A document converter is a component designed to read content from an external format such as a Word document and convert it into a format that can be displayed within an MOSS content page. Several document converters will ship with MOSS as well as a framework for building and integrating custom document converters. MOSS also supports a WCM feature known as site variations for companies that need to duplicate a site’s content for translation into multiple spoken languages or for targeting different types of rendering devices. For example, imagine you have configured MOSS variation support for German and French in addition to Spanish. MOSS maintains a parallel structure across these three different sites with respect to pages and child sites. When a content author adds a new page to the master variation site maintained in Spanish, MOSS automatically adds the same page into the structure of the other sites as well. MOSS provides several caching options. While MOSS doesn’t allow you to use ASP.NET output caching directives the same way you do in a standard ASP.NET page, it provides a more sophisticated framework to reach the same end. You can enable MOSS output caching at the site collection scope. When using these caching features, you configure caching profiles to control caching page items and complete pages in memory. Developers should take note that MOSS supplies dedicated caches for navigation nodes and content returned from potentially expensive retrieval operations such as standard Windows SharePoint Services queries run using an SPQuery object and cross-site queries run using a SharePoint Portal Server SPSiteDataQuery object.
Talk about various SharePoint topics, code, scripts and knowledge articles
Thursday, August 23, 2007
What is a Shared Service Provider (SSP) ?
Shared Service Providers (SSPs) are a new innovation created for MOSS that represents a critical piece of the fundamental system architecture. An SSP represents a set of services that can be configured a single time and shared across many different MOSS portal sites and WSS sites. Your understanding of SSPs is critical to being able to take advantage of MOSS features and services. After you have finished installing MOSS in a farm, you must explicitly create and configure one or more SSPs in order to take advantage of MOSS features such as user profiles, audiences, personal sites, Excel Services, the Business Data Catalog and search. After you have created initially created an SSP through the WSS Central Administration pages, you can then configure the individual MOSS services you need from the main SSP administration page. This new SSP architecture was designed to replace the Shared Services infrastructure of SharePoint Portal Server 2003 to provide greater flexibility in deployment and configuration. For example, it’s possible to create two different SSPs within the same farm and configure them differently, as shown in Figure 2-3. Each Web application in an Office SharePoint Server 2007 farm along with its Office SharePoint Server 2007 portal sites and Windows oSharePoint Services sites is assciated with exactly one SSP. One Web application can be associated with one SSP while a different Web application can be associated with a second SSP. The search results from within one portal site might be very different from the search results within another portal site if they are associated with different SSPs that have been configured to have different content sources.
This new SSP architecture was designed to replace the Shared Services infrastructure of SPS 2003 in order to provide greater flexibility with respect to deployment and configuration. For example, it's possible to create two different SSPs within the same farm and configure them differently. Each Web application in a MOSS farm along with its MOSS portal sites and WSS sites is associated with exactly one SSP. One Web application can be associated with one SSP while a different Web application can be associated with a second SSP. The search results for within one portal sites might be very different from the search results within another portal site if they are associated with different SSPs that have been configured to have different content sources.
This new SSP architecture was designed to replace the Shared Services infrastructure of SPS 2003 in order to provide greater flexibility with respect to deployment and configuration. For example, it's possible to create two different SSPs within the same farm and configure them differently. Each Web application in a MOSS farm along with its MOSS portal sites and WSS sites is associated with exactly one SSP. One Web application can be associated with one SSP while a different Web application can be associated with a second SSP. The search results for within one portal sites might be very different from the search results within another portal site if they are associated with different SSPs that have been configured to have different content sources.
What is Windows SharePoint Services (WSS)?
Windows SharePoint Services (WSS) is a set of components and services that is considered part of the Windows Server 2003 operating system. All versions of WSS have been designed and created by the Office team to provide the core plumbing infrastructure required by other aspects of SPT. However, licensing and support for WSS is controlled by the Windows platform team, not the Office team. Once you have obtained your licenses to run Windows Server 2003, you already have what need to run WSS as well. The third and latest major version of WSS is currently scheduled to be released in the forth quarter of 2007 along with the 2007 Office System. This release goes by the name of Windows SharePoint Services 3.0 and is often abbreviated as either WSS 3.0 or WSS V3. The previous version of WSS which was released with the Office 2003 System originally did not carry a version number. However, the avoid confusion it should now be referred to as Windows SharePoint Services 2.0 or WSS V2. When progressive SharePoint developers talk about WSS without using a version number, they are talking about the latest and coolest version which today is WSS 3.0. At its core, WSS provides a site provisioning engine that allows companies to create and manage 100s or 1000s of Web sites in a highly-scalable Web farm environment. WSS is based on stateless Web servers and backend storage model based on SQL Server. WSS provides access to its sites through several popular types of browsers as well as through integration points with Microsoft Office desktop applications such as Word, Excel, PowerPoint, Access and Outlook.
To a developer, WSS should be seen as a full-fledged development platform that adds a significant amount of value on top of ASP.NET 2.0. It provides a means to build business solutions using building blocks such as .ASPX pages, ASP.NET controls, Web Parts, custom lists and document libraries, content types, event handlers, custom workflows, features and site definitions. While WSS is a development platform, it also ships with a set of out-of-the-box collaboration services. This makes it relatively painless for a company to quickly construct sites with things like contacts lists, task lists, schedules, document libraries and customized page views without requiring a developer to put everything together. WSS 3.0 enhances the out-of-the-box feature set with the addition of support for blogs, wikis and RSS.
To a developer, WSS should be seen as a full-fledged development platform that adds a significant amount of value on top of ASP.NET 2.0. It provides a means to build business solutions using building blocks such as .ASPX pages, ASP.NET controls, Web Parts, custom lists and document libraries, content types, event handlers, custom workflows, features and site definitions. While WSS is a development platform, it also ships with a set of out-of-the-box collaboration services. This makes it relatively painless for a company to quickly construct sites with things like contacts lists, task lists, schedules, document libraries and customized page views without requiring a developer to put everything together. WSS 3.0 enhances the out-of-the-box feature set with the addition of support for blogs, wikis and RSS.
What SharePoint 2007 means for content management
The third time is the charm for SharePoint 2007, at least when it comes to enterprise and Web content management, according to two Burton Group analysts.
In 2001, Office and SharePoint were quite separate. In the words of Burton Group analyst Guy Creese, "they were really different ways of looking at the world." Two years later, the products combined some lower-level functionality, but the content management server, or CMS, was still a separate product. With the third iteration, Office is a front end into SharePoint and the CMS server is there, along with a tiered architecture.
Moreover, Creese noted, files are no longer constrained to what he called "media-centric silos" -- documents in one system, Web content in another, and so on. "There's now enough content, and it's ubiquitous enough, that it's starting to come together. We're starting to see enterprises move toward process-centric systems," he said, adding that this has the benefit of more closely resembling everyday user tasks.
Creese and Karen Hobert, both Burton Group analysts specializing in collaboration and content strategies, highlighted the single media stack and other SharePoint 2007 content management improvements in a recent Burton Group telebriefing.
Thanks to its link to Office, SharePoint has always been very good at allowing users to create, store and distribute files. Microsoft beefed this up in V3 with support for blogs, wikis and RSS feeds, Creese said.
More attention, though, was paid to the processes of discovering, archiving and analyzing documents. For example, the Office development team incorporated search analytics from Microsoft Research, Creese noted. In addition, SharePoint's leveraging of SQL Server's business intelligence capabilities is a bit more user-friendly, he said. Underneath it all is a robust management layer that keeps everything straight by using Windows Workflow Foundation technology.
Workflow support also makes its way into the new SharePoint Designer, one of two replacements for the design application Front Page. (The other is the Expression suite, which is viewed as an answer to Adobe's Illustrator, Flash and Photoshop.)
In this case workflow refers to the rules and conditions associated to lists or libraries within SharePoint. This is based on the notion that, for every action, there is a serial and parallel action that affects each user differently, Hobert said. A marketing director and a graphics designer may be working on the same campaign, she noted, but that does not mean they both receive the same access and permissions.
"With so many hands in the Web content management kitchen," the ability for developers and administrators to control who does what is critical, Hobert said. "That's where the contributor model comes in. It makes things easier to manage."
The combination of workflow and a single "media silo" in SharePoint 2007 should be enough to compel users of IBM and Oracle content management products to take a look at SharePoint, Creese concluded: "SharePoint is a view to the future of what's going to happen."
In 2001, Office and SharePoint were quite separate. In the words of Burton Group analyst Guy Creese, "they were really different ways of looking at the world." Two years later, the products combined some lower-level functionality, but the content management server, or CMS, was still a separate product. With the third iteration, Office is a front end into SharePoint and the CMS server is there, along with a tiered architecture.
Moreover, Creese noted, files are no longer constrained to what he called "media-centric silos" -- documents in one system, Web content in another, and so on. "There's now enough content, and it's ubiquitous enough, that it's starting to come together. We're starting to see enterprises move toward process-centric systems," he said, adding that this has the benefit of more closely resembling everyday user tasks.
Creese and Karen Hobert, both Burton Group analysts specializing in collaboration and content strategies, highlighted the single media stack and other SharePoint 2007 content management improvements in a recent Burton Group telebriefing.
Thanks to its link to Office, SharePoint has always been very good at allowing users to create, store and distribute files. Microsoft beefed this up in V3 with support for blogs, wikis and RSS feeds, Creese said.
More attention, though, was paid to the processes of discovering, archiving and analyzing documents. For example, the Office development team incorporated search analytics from Microsoft Research, Creese noted. In addition, SharePoint's leveraging of SQL Server's business intelligence capabilities is a bit more user-friendly, he said. Underneath it all is a robust management layer that keeps everything straight by using Windows Workflow Foundation technology.
Workflow support also makes its way into the new SharePoint Designer, one of two replacements for the design application Front Page. (The other is the Expression suite, which is viewed as an answer to Adobe's Illustrator, Flash and Photoshop.)
In this case workflow refers to the rules and conditions associated to lists or libraries within SharePoint. This is based on the notion that, for every action, there is a serial and parallel action that affects each user differently, Hobert said. A marketing director and a graphics designer may be working on the same campaign, she noted, but that does not mean they both receive the same access and permissions.
"With so many hands in the Web content management kitchen," the ability for developers and administrators to control who does what is critical, Hobert said. "That's where the contributor model comes in. It makes things easier to manage."
The combination of workflow and a single "media silo" in SharePoint 2007 should be enough to compel users of IBM and Oracle content management products to take a look at SharePoint, Creese concluded: "SharePoint is a view to the future of what's going to happen."
A Bird’s eyeview of Sharepoint 2007 Architecture
After having installed SharePoint 2007, at the face of it, the localhost URL or http://<> now shows a SharePoint portal website – but there's a way lot more that just happened behind the scenes.
The following steps happened between that double click on the SharePoint 2007 installation, the configuration wizard with 10 steps, and your going to http://<>.
1. A new instance of SQL Express was created on your machine. This is by default identified by <>/OFFICESERVERS.
2. In this new instance, various databases were created. Many of them have a curiously same structure, as they are all the "backends" for various Sharepoint WebApplications.
3. Various Websites were setup in your IIS. All of these, are running on the Sharepoint engine. All of these are running on ASP.NET 2.0. But one of these, is the Sharepoint Central Administration Website. So, a SharePoint WebSite manages other Sharepoint Websites!! This kind of segregation makes production push and deployment of newer sites a lot easier.
4. The Sharepoint Central Administration Website (SCAW). It's got 3 major areas - Home/Operations/Application Management. Home - is a SharePoint page, where you can view/administer various tasks, topology, or add any other WebParts you wish. This is based on the "Blank" template, which presents you with a great whitespace to throw WebParts in. These Administration widgets - are nothing but WebParts themselves!!
SharePoint now has a check-in/check-out mechanism for all front end changes, including a workflow, defined in WWF (Windows Workflow Foundation). Which means, you can plug in your own, or a third party workflow. This behavior is overridable and customizable.
Under Operations – you can do operations that are more "global" in nature. Like managing your web farm, various jobs, backups, database admin etc. This is typically what the Infrastructure/IT guys will mostly use.
Finally under Application Management is where things get fun. Especially fun if you have an environment where you manage multiple websites. Why? Because the organization of various websites within SharePoint, is frankly outstanding.
You have at the top level Web Applications. So you go ahead and create a Web Application (there are a couple created for you out of the box). You have various customizations you can specify in the WebApplication - for instance, what application pool must be used, where should the database live, and a whole lot of other stuff at the same level.
Then under each WebApplication you have "Sites Collections". These Site Collections are - what are individually created for each .. say for instance, department within your organization. You have a fantastic degree of customizability within each one of these. Many templates come out of the box, you could write your own, but in addition you can specify a number of things such as quotas, administrators, security settings, and "self maintainance" information etc.
The following steps happened between that double click on the SharePoint 2007 installation, the configuration wizard with 10 steps, and your going to http://<
1. A new instance of SQL Express was created on your machine. This is by default identified by <
2. In this new instance, various databases were created. Many of them have a curiously same structure, as they are all the "backends" for various Sharepoint WebApplications.
3. Various Websites were setup in your IIS. All of these, are running on the Sharepoint engine. All of these are running on ASP.NET 2.0. But one of these, is the Sharepoint Central Administration Website. So, a SharePoint WebSite manages other Sharepoint Websites!! This kind of segregation makes production push and deployment of newer sites a lot easier.
4. The Sharepoint Central Administration Website (SCAW). It's got 3 major areas - Home/Operations/Application Management. Home - is a SharePoint page, where you can view/administer various tasks, topology, or add any other WebParts you wish. This is based on the "Blank" template, which presents you with a great whitespace to throw WebParts in. These Administration widgets - are nothing but WebParts themselves!!
SharePoint now has a check-in/check-out mechanism for all front end changes, including a workflow, defined in WWF (Windows Workflow Foundation). Which means, you can plug in your own, or a third party workflow. This behavior is overridable and customizable.
Under Operations – you can do operations that are more "global" in nature. Like managing your web farm, various jobs, backups, database admin etc. This is typically what the Infrastructure/IT guys will mostly use.
Finally under Application Management is where things get fun. Especially fun if you have an environment where you manage multiple websites. Why? Because the organization of various websites within SharePoint, is frankly outstanding.
You have at the top level Web Applications. So you go ahead and create a Web Application (there are a couple created for you out of the box). You have various customizations you can specify in the WebApplication - for instance, what application pool must be used, where should the database live, and a whole lot of other stuff at the same level.
Then under each WebApplication you have "Sites Collections". These Site Collections are - what are individually created for each .. say for instance, department within your organization. You have a fantastic degree of customizability within each one of these. Many templates come out of the box, you could write your own, but in addition you can specify a number of things such as quotas, administrators, security settings, and "self maintainance" information etc.
SharePoint 2007: Importing User Profile information
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.
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.
Monday, August 20, 2007
MOSS Web Content Management (WCM) Features
Before MOSS, Microsoft’s strategy for publishing content on the Web has been based on Microsoft Content Management Server 2002 (CMS). CMS provides a structured way for content authors to add content to a company’s public Web site using professionally formatted layout pages. CMS also provides a formalized scheme where a privileged user must approve any page modification before it can be seen by the Web site’s visitors. In the past, many Microsoft customers have had to choose between CMS and SharePoint Portal Server 2003. While Microsoft released a connector named SPARK that provides a certain degree of integration between CMS and SharePoint Portal Server 2003, these two products are built on very different architectures. This has resulted in frustration because you cannot build a site that fully benefits from both the CMS Web content management features and the SharePoint Portal Server 2003 portal features. Microsoft has decided to discontinue evolving CMS as a stand-alone product and to migrate CMS Web content management features and the CMS customer base over to MOSS. This new strategy allows you to mix Microsoft's best-of-breed WCM features with its portal features in any site within a MOSS farm. If you have worked with CMS in the past, it’s important to note that the CMS concepts of channels and postings are not used in the MOSS WCM infrastructure. Instead, this new WCM infrastructure has been designed using basic WSS 3.0 building blocks such as child sites, page templates, content types, document libraries, and security groups. This newer approach lends itself to building custom solutions that extend the basic MOSS WCM infrastructure using standard WSS components such as custom event handlers and workflows.
Since the WCM features of MOSS are built on top of WSS 3.0, you begin the process of branding a MOSS portal site by customizing master pages to get the basic look and feel you're after. However, MOSS WCM features go further than this by extending WSS with the introduction of a publishing scheme based on page layouts. A page layout provides a structured approach for collecting content from content authors and displaying it on a page within a portal site. Examples of some of the page layouts provided by MOSS out of the box include welcome pages, articles, and news items. Most companies adopting the MOSS WCM features will create their own customized page layouts as well. By default, MOSS WCM features use the basic document approval features of a WSS document library to control when the updated content is shown to the site’s visitors. However, the MOSS WCM infrastructure was designed to make it straightforward to associate custom workflows with the content associated with a page layout in scenarios where you need something more sophisticated than the functionality that comes out of the box. MOSS WCM features provide a framework for document converters. A document converter is a component designed to read content from an external format such as a Word document and convert it into a format that can be displayed within an MOSS content page. Several document converters will ship with MOSS as well as a framework for building and integrating custom document converters. MOSS also supports a WCM feature known as site variations for companies that need to duplicate a site’s content for translation into multiple spoken languages or for targeting different types of rendering devices. For example, imagine you have configured MOSS variation support for German and French in addition to Spanish. MOSS maintains a parallel structure across these three different sites with respect to pages and child sites. When a content author adds a new page to the master variation site maintained in Spanish, MOSS automatically adds the same page into the structure of the other sites as well. MOSS provides several caching options. While MOSS doesn’t allow you to use ASP.NET output caching directives the same way you do in a standard ASP.NET page, it provides a more sophisticated framework to reach the same end. You can enable MOSS output caching at the site collection scope. When using these caching features, you configure caching profiles to control caching page items and complete pages in memory. Developers should take note that MOSS supplies dedicated caches for navigation nodes and content returned from potentially expensive retrieval operations such as standard Windows SharePoint Services queries run using an SPQuery object and cross-site queries run using a SharePoint Portal Server SPSiteDataQuery object.
MOSS
What is Microsoft Office SharePoint Server 2007 (MOSS)?
Microsoft Office SharePoint Portal Server 2007 (MOSS) represents a large set of components and services built on top of WSS to provide functionality in areas such as portal and search, Web content management, line-of-business system integration, business intelligence, business process management and records management.
MOSS represents the next generation of several pre-existing Microsoft products including SharePoint Portal Server 2003 (SPS) and Content Management Server 2002 (CMS). One aspect of MOSS that will be particularly appealing to developers is how smoothly it has been integrated with the underling layers of ASP.NET 2.0 and WSS 3.0. Extending the out-of-the-box appearance and functionality of MOSS will be far easier than it has been with SPS and CMS. The Portal Features of MOSS include familiar SPS features such as user profiles, audience targeting, personal sites (aka MySites), enterprise-level search and the single sign-on service (SSO) as well as a new innovation called the Business Data Catalog (BDC). The Web Content Management (WCM) features include professional Web publishing functionality and powerful caching mechanisms to optimize response times and system throughput. The business intelligence features include Excel Services and Report Center. Another valuable aspect of MOSS is its introduction of Records Management support to assist companies who have strict policies with respect to security and privacy and who need to meet compliance levels required by government regulations such as Sarbanes-Oxley.
Microsoft Office SharePoint Portal Server 2007 (MOSS) represents a large set of components and services built on top of WSS to provide functionality in areas such as portal and search, Web content management, line-of-business system integration, business intelligence, business process management and records management.
MOSS represents the next generation of several pre-existing Microsoft products including SharePoint Portal Server 2003 (SPS) and Content Management Server 2002 (CMS). One aspect of MOSS that will be particularly appealing to developers is how smoothly it has been integrated with the underling layers of ASP.NET 2.0 and WSS 3.0. Extending the out-of-the-box appearance and functionality of MOSS will be far easier than it has been with SPS and CMS. The Portal Features of MOSS include familiar SPS features such as user profiles, audience targeting, personal sites (aka MySites), enterprise-level search and the single sign-on service (SSO) as well as a new innovation called the Business Data Catalog (BDC). The Web Content Management (WCM) features include professional Web publishing functionality and powerful caching mechanisms to optimize response times and system throughput. The business intelligence features include Excel Services and Report Center. Another valuable aspect of MOSS is its introduction of Records Management support to assist companies who have strict policies with respect to security and privacy and who need to meet compliance levels required by government regulations such as Sarbanes-Oxley.
Subscribe to:
Posts (Atom)