Using Integrated Windows Authentication with Windows SharePoint Services
Microsoft Integrated Windows Authentication supports two protocols to provide challenge/response authentication:
NTLM A secure protocol based on encrypting user names and passwords before sending them over the network. NTLM is required in networks where the server will get requests from legacy clients that do not support Kerberos authentication.
Kerberos A protocol based upon ticketing. In this scheme a user must first provide a valid user name and password to an authentication server. This server grants the user a ticket, which can then be used on the network for requesting other network resources. To use this scheme, both the client and server must have a trusted connection to the domain Key Distribution Center and be compatible with Microsoft Active Directory directory services.
Kerberos also provides a method for creating trust relationships between network domains. These trust relationships can be transitive, mono-directional, or bidirectional. For more information on Kerberos authentication, see Microsoft Internet Information Services (IIS) documentation in Windows Server 2003.
Both NTLM and Kerberos enhance security by encrypting user names and passwords before sending them over the network. By default, virtual servers extended with a version of Windows SharePoint Services earlier than Windows SharePoint Services Service Pack 2 enabled NTLM authentication by default because it is compatible with more clients. Windows SharePoint Services Service Pack 2 and later do not automatically enable NTLM authentication. However, if you choose to use Kerberos authentication, and the application pool account used by Windows SharePoint Services on the virtual server is not the default Network Service, you must complete these steps:
Configure a service principal name for the application pool identity used by the virtual server running Windows SharePoint Services
Configure trust for delegation for Web Parts that access remote resources
Additionally, if the virtual server was extended with a version of Windows SharePoint Services earlier than Windows SharePoint Services Service Pack 2, you must edit the IIS metabase to enable both NTLM and Kerberos authentication.
Configure a service principal name for the application pool identity
Note You must be a domain administrator to complete the steps in this section.
If the application pool identity for the Windows SharePoint Services site is configured to use a built-in security principal (such as NT Authority\Network Service or NT Authority\Local System), you do not have to perform this step. The built-in accounts are automatically configured to work with Kerberos authentication. However, if you use a remote Microsoft SQL Server database it is not recommended that you use a built-in security principal or an account such as domain/computername$.
If you use a remote server running Microsoft SQL Server 2000 and you want to use NT Authority\Network Service as the domain account, you must add the Domain\ComputerName$ entry and configure it with Database Creators and Security Administrators permissions. Doing so allows Windows SharePoint Services to connect to the remote SQL Server computer to create the configuration and content databases.
If the application pool identity is a domain user account, you must configure an service principal name (SPN) for that account. To configure an SPN for the domain user account, follow these steps:
1. Download and install the Setspn.exe command-line tool from the Setspn.exe download page.
2. Use the Setspn.exe tool to add an SPN for the domain account. To do this, type the following line at the command prompt:
setspn -A HTTP/ServerName Domain\UserName
where ServerName is the fully qualified domain name (FQDN) of the server, Domain is the name of the domain, and UserName is the name of the domain user account.
Ref: http://office.microsoft.com/en-us/winsharepointadmin/HA011608071033.aspx
Integrated Windows Authentication (IIS 6.0)
With Integrated Windows authentication (formerly called NTLM, and also known as Windows NT Challenge/Response authentication), the user name and password (credentials) are hashed before being sent across the network. When you enable Integrated Windows authentication, the client browser proves its knowledge of the password through a cryptographic exchange with your Web server, involving hashing.
Important
Integrated Windows authentication is disabled by default if you install Windows Server 2003 Service Pack 1 (SP1) as part of a slipstream installation of a Windows Server 2003 operating system. If you install Windows Server 2003 SP1 by itself, as an upgrade to a Windows Server 2003 operating system, the setting for Integrated Windows authentication is unchanged from its Windows Server 2003 setting. Integrated Windows authentication is enabled by default for Windows Server 2003 operating systems.
Integrated Windows authentication uses Kerberos v5 authentication and NTLM authentication. Kerberos is an industry-standard authentication protocol that is used to verify user or host identity. If Active Directory is installed on a domain controller running Windows 2000 Server or Windows Server 2003, and the client browser supports the Kerberos v5 authentication protocol, Kerberos v5 authentication is used; otherwise, NTLM authentication is used.
Integrated Windows authentication includes the Negotiate, Kerberos, and NTLM authentication methods. Negotiate, a wrapper for Kerberos v5 and NTLM, allows the client application to select the most appropriate security support provider for the situation. Kerberos v5 and NTLM have the following restrictions:
•NTLM can get past a firewall, but is generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.
•Kerberos v5 requires that the client have a direct connection to Active Directory, which is generally not the case in Internet scenarios.
•Kerberos v5 requires that both the client and the server have a trusted connection to a Key Distribution Center (KDC) and be Active Directory–compatible.
•Kerberos v5 requires SPNs for multiple worker processes. If your Web site uses multiple worker processes, you can use Kerberos authentication, but you must manually register service names. For more information about Kerberos and service registration, see Kerberos and service registration later in this topic.
Integrated Windows authentication has the following limitations:
•Integrated Windows authentication is supported by only Internet Explorer 2 and later.
•Integrated Windows authentication does not work over HTTP proxy connections.
Therefore, Integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain and where administrators can ensure that every user has Internet Explorer 2 or later.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true
Microsoft NTLM
Windows Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows operating system and on stand-alone systems.
The Microsoft Kerberos security package adds greater security than NTLM to systems on a network. Although Microsoft Kerberos is the protocol of choice, NTLM is still supported. NTLM must also be used for logon authentication on stand-alone systems. For more information about Kerberos, see Microsoft Kerberos.
NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.
Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user's password is kept. Noninteractive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server.
The following steps present an outline of NTLM noninteractive authentication. The first step provides the user's NTLM credentials and occurs only as part of the interactive authentication (logon) process.
1. (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.
2. The client sends the user name to the server (in plaintext).
3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.
5. The server sends the following three items to the domain controller:
· User name
· Challenge sent to the client
· Response received from the client
6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.
Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.
Ref: http://msdn.microsoft.com/en-us/library/aa378749(VS.85).aspx
Changes to NTLM authentication for HTTPWebRequest in Version 3.5 SP1
Security changes were made in Version 3.5 SP1 that affect how integrated Windows authentication is handled by the HttpWebRequest, HttpListener, NegotiateStream, and related classes in the System.Net namespace. These changes can affect applications that use these classes to make web requests and receive responses where integrated Windows authentication based on NTLM is used. This change can impact web servers and client applications that are configured to use integrated Windows authentication.
Overview
The design of integrated Windows authentication allows for some credential challenge responses to be universal, meaning they can be re-used or forwarded. If this particular design feature is not needed then the challenge responses should be constructed at a minimum with target specific information and preferably also with some channel specific information. Services can then provide extended protection to ensure that credential challenge responses contain service specific information such as a Service Principal Name (SPN). With this information in the credential exchanges, services are able to better protect against malicious use of credential challenge responses that might have been improperly obtained.
Multiple components in the System.Net and System.Net.Security namespaces perform integrated Windows authentication on behalf of a calling application. This section describes changes to System.Net components to add extended protection in their use of integrated Windows authentication.
Ref: http://msdn.microsoft.com/en-us/library/cc982052.aspx
NTLM Authentication Does Not Work If Internet Explorer Is Configured to Use HTTP 1.1 Through Proxy Connections
http://support.microsoft.com/kb/322822
NTLM user authentication in Windows
User records are stored in the security accounts manager (SAM) database or in the Active Directory database. Each user account is associated with two passwords: the LAN Manager-compatible password and the Windows password. Each password is encrypted and stored in the SAM database or in the Active Directory database.
The LAN Manager-compatible password is compatible with the password that is used by LAN Manager. This password is based on the original equipment manufacturer (OEM) character set. This password is not case sensitive and can be up to 14 characters long. The OWF version of this password is also known as the LAN Manager OWF or ESTD version. This password is computed by using DES encryption to encrypt a constant with the clear text password. The LAN Manager OWF password is 16 bytes long. The first 7 bytes of the clear text password are used to compute the first 8 bytes of the LAN Manager OWF password. The second 7 bytes of the clear text password are used to computer the second 8 bytes of the LAN Manager OWF password.
The Windows password is based on the Unicode character set. This password is case sensitive and can be up to 128 characters long. The OWF version of this password is also known as the Windows OWF password. This password is computed by using the RSA MD-4 encryption algorithm. This algorithm computes a 16-byte digest of a variable-length string of clear text password bytes.
Any user account might lack either the LAN Manager password or the Windows password. However, every attempt is made to maintain both versions of the password. For example, if the user account is ported from a LAN Manager UAS database by using PortUas, or if the password is changed from a LAN Manager client or from a Windows for Workgroups client, only the LAN Manager version of the password will exist. If the password is set or changed on a Windows client, and the password has no LAN Manager representation, only the Windows version of the password will exist. (The password might have no LAN Manager representation because the password is longer than 14 characters or because the characters cannot be represented in the OEM character set.) User interface limits in Windows do not let Windows passwords exceed 14 characters. The implications of this limitation are discussed later in this article.
Pass-through authentication
The NetLogon service implements pass-through authentication. It performs the following functions:
· Selects the domain to pass the authentication request to.
· Selects the server within the domain.
· Passes the authentication request through to the selected server.
Selecting the domain is straightforward. The domain name is passed to LsaLogonUser. The domain name is processed as follows:
· If the domain name matches the name of the SAM database, the authentication is processed on that computer. On a Windows workstation that is a member of a domain, the name of the SAM database is considered to be the name of the computer. On an Active Directory domain controller, the name of the account database is the name of the domain. On a computer that is not a member of a domain, all logons process requests locally.
· If the specified domain name is trusted by this domain, the authentication request is passed through to the trusted domain. On Active Directory domain controllers, the list of trusted domains is easily available. On a member of a Windows domain, the request is always passed through to the primary domain of the workstation, letting the primary domain determine whether the specified domain is trusted.
· If the domain name specified is not trusted by the domain, the authentication request is processed on the computer being connected to as if the domain name specified were that domain name. NetLogon does not differentiate between a nonexistent domain, an untrusted domain, and an incorrectly typed domain name.
http://support.microsoft.com/kb/102716
Friday, February 26, 2010
Thursday, February 25, 2010
Workflows
What are workflows?
Workflow is sometimes described as a series of tasks that produce an outcome. In the context of Microsoft SharePoint Products and Technologies, workflow is defined more narrowly as the automated movement of documents or items through a sequence of actions or tasks that are related to a business process. Workflows can be used to consistently manage common business processes within an organization by enabling the organization to attach business logic to documents or items in a SharePoint list or library. Business logic is basically a set of instructions that specifies and controls the actions that happen to a document or item.
Workflows in Office SharePoint Server 2007
Workflows help people to collaborate on documents and to manage project tasks by implementing business processes on documents and items in a Microsoft Office SharePoint Server 2007 site. Workflows help organizations to adhere to consistent business processes, and they also improve organizational efficiency and productivity by managing the tasks and steps involved in business processes. This enables the people who perform these tasks to concentrate on performing the work rather than managing the workflow.
Workflows that are included in Office SharePoint Server 2007
Approval This workflow routes a document or item to a group of people for approval. By default, the Approval workflow is associated with the Document content type, and thus it is automatically available in document libraries. A version of the Approval workflow is also associated by default with the Pages library in a publishing site, and it can be used to manage the approval process for the publication of Web pages.
Collect Feedback This workflow routes a document or item to a group of people for feedback. Reviewers can provide feedback, which is then compiled and sent to the person who initiated the workflow. By default, the Collect Feedback workflow is associated with the Document content type, and thus it is automatically available in document libraries.
Collect Signatures This workflow routes a Microsoft Office document to a group of people to collect their digital signatures. This workflow must be started in a client program that is part of the 2007 Office release. Participants must complete their signature tasks by adding their digital signature to the document in the relevant Microsoft Office program. By default, the Collect Signatures workflow is associated with the Document content type, and thus it is automatically available in document libraries. However, the Collect Signatures workflow appears for a document in the document library only if that document contains one or more Microsoft Office Signature Lines.
Disposition Approval This workflow, which supports records management processes, manages document expiration and retention by allowing participants to decide whether to retain or delete expired documents. The Disposition Approval workflow is intended for use primarily within a Records Center site.
Three-state This workflow can be used to manage business processes that require organizations to track a high volume of issues or items, such as customer support issues, sales leads, or project tasks.
Group Approval This workflow is similar to the Approval workflow, but it uses a designated document library and offers a personalized view of the approval processes in which a user is participating. This workflow provides a hierarchical organization chart from which to select the approvers and allows the approvers to use a stamp control instead of a signature. This solution is available only for East Asian versions of Office SharePoint Server 2007.
Translation Management This workflow manages the manual document translation process by creating copies of the document to be translated and assigning translation tasks to translators. This workflow is available only for Translation Management libraries.
There are two ways in which custom workflows can be created for Office SharePoint Server 2007:
Professional software developers can create workflows by using the Visual Studio 2005 Extensions for Windows Workflow Foundation These workflows contain custom code and workflow activities. After a professional developer creates custom workflows, a server administrator can deploy them across multiple sites.
Web designers can design no-code workflows for use in a specific list or library by using a Web design program, such as Microsoft Office SharePoint Designer 2007 These workflows are created from a list of available workflow activities, and the Web designer who creates the workflow can deploy the workflows directly to the list or library where they will be used.
Ref: http://office.microsoft.com/en-us/sharepointserver/CH101782961033.aspx
Design custom workflows by using SharePoint Designer
http://office.microsoft.com/en-us/sharepointserver/HA102422951033.aspx
The status of a workflow appears as "Failed to Start" when you try to start a workflow from a survey response in Windows SharePoint Services 3.0
http://support.microsoft.com/kb/926370
A declarative workflow does not start automatically after you install Windows SharePoint Services 3.0 Service Pack 1
http://support.microsoft.com/kb/947284
Creating SharePoint Sequential Workflows with Visual Studio 2008
http://msdn.microsoft.com/en-us/library/cc936628.aspx
Workflow is sometimes described as a series of tasks that produce an outcome. In the context of Microsoft SharePoint Products and Technologies, workflow is defined more narrowly as the automated movement of documents or items through a sequence of actions or tasks that are related to a business process. Workflows can be used to consistently manage common business processes within an organization by enabling the organization to attach business logic to documents or items in a SharePoint list or library. Business logic is basically a set of instructions that specifies and controls the actions that happen to a document or item.
Workflows in Office SharePoint Server 2007
Workflows help people to collaborate on documents and to manage project tasks by implementing business processes on documents and items in a Microsoft Office SharePoint Server 2007 site. Workflows help organizations to adhere to consistent business processes, and they also improve organizational efficiency and productivity by managing the tasks and steps involved in business processes. This enables the people who perform these tasks to concentrate on performing the work rather than managing the workflow.
Workflows that are included in Office SharePoint Server 2007
Approval This workflow routes a document or item to a group of people for approval. By default, the Approval workflow is associated with the Document content type, and thus it is automatically available in document libraries. A version of the Approval workflow is also associated by default with the Pages library in a publishing site, and it can be used to manage the approval process for the publication of Web pages.
Collect Feedback This workflow routes a document or item to a group of people for feedback. Reviewers can provide feedback, which is then compiled and sent to the person who initiated the workflow. By default, the Collect Feedback workflow is associated with the Document content type, and thus it is automatically available in document libraries.
Collect Signatures This workflow routes a Microsoft Office document to a group of people to collect their digital signatures. This workflow must be started in a client program that is part of the 2007 Office release. Participants must complete their signature tasks by adding their digital signature to the document in the relevant Microsoft Office program. By default, the Collect Signatures workflow is associated with the Document content type, and thus it is automatically available in document libraries. However, the Collect Signatures workflow appears for a document in the document library only if that document contains one or more Microsoft Office Signature Lines.
Disposition Approval This workflow, which supports records management processes, manages document expiration and retention by allowing participants to decide whether to retain or delete expired documents. The Disposition Approval workflow is intended for use primarily within a Records Center site.
Three-state This workflow can be used to manage business processes that require organizations to track a high volume of issues or items, such as customer support issues, sales leads, or project tasks.
Group Approval This workflow is similar to the Approval workflow, but it uses a designated document library and offers a personalized view of the approval processes in which a user is participating. This workflow provides a hierarchical organization chart from which to select the approvers and allows the approvers to use a stamp control instead of a signature. This solution is available only for East Asian versions of Office SharePoint Server 2007.
Translation Management This workflow manages the manual document translation process by creating copies of the document to be translated and assigning translation tasks to translators. This workflow is available only for Translation Management libraries.
There are two ways in which custom workflows can be created for Office SharePoint Server 2007:
Professional software developers can create workflows by using the Visual Studio 2005 Extensions for Windows Workflow Foundation These workflows contain custom code and workflow activities. After a professional developer creates custom workflows, a server administrator can deploy them across multiple sites.
Web designers can design no-code workflows for use in a specific list or library by using a Web design program, such as Microsoft Office SharePoint Designer 2007 These workflows are created from a list of available workflow activities, and the Web designer who creates the workflow can deploy the workflows directly to the list or library where they will be used.
Ref: http://office.microsoft.com/en-us/sharepointserver/CH101782961033.aspx
Design custom workflows by using SharePoint Designer
http://office.microsoft.com/en-us/sharepointserver/HA102422951033.aspx
The status of a workflow appears as "Failed to Start" when you try to start a workflow from a survey response in Windows SharePoint Services 3.0
http://support.microsoft.com/kb/926370
A declarative workflow does not start automatically after you install Windows SharePoint Services 3.0 Service Pack 1
http://support.microsoft.com/kb/947284
Creating SharePoint Sequential Workflows with Visual Studio 2008
http://msdn.microsoft.com/en-us/library/cc936628.aspx
Wednesday, February 24, 2010
DNS
What Is DNS?
Domain Name System (DNS) is one of the industry-standard suite of protocols that comprise TCP/IP. Microsoft Windows Server 2003. DNS is implemented using two software components: the DNS server and the DNS client (or resolver). Both components are run as background service applications.
Network resources are identified by numeric IP addresses, but these IP addresses are difficult for network users to remember. The DNS database contains records that map user-friendly alphanumeric names for network resources to the IP address used by those resources for communication. In this way, DNS acts as a mnemonic device, making network resources easier to remember for network users.
The Windows Server 2003 DNS Server and Client services use the DNS protocol that is included in the TCP/IP protocol suite. DNS is part of the application layer of the TCP/IP reference model.
DNS in TCP/IP
For more information and to view logical diagrams illustrating how DNS fits with other Windows Server 2003 technologies, see “How DNS Works" in this collection.
By default, Windows Server 2003 DNS is used for all name resolution in a Windows Server 2003 network. In the most typical scenario, when a Windows Server 2003 network user specifies the name of a network host or an internet DNS domain name, the DNS Client service running on the Windows Server 2003 computer of the user contacts a DNS server to resolve the name to an IP address.
Ref: http://technet.microsoft.com/en-us/library/cc787921(WS.10).aspx
How DNS Works?
DNS Domain Names
The Domain Name System is implemented as a hierarchical and distributed database containing various types of data, including host names and domain names. The names in a DNS database form a hierarchical tree structure called the domain namespace. Domain names consist of individual labels separated by dots, for example: mydomain.microsoft.com.
A Fully Qualified Domain Name (FQDN) uniquely identifies the hosts position within the DNS hierarchical tree by specifying a list of names separated by dots in the path from the referenced host to the root. The next figure shows an example of a DNS tree with a host called mydomain within the microsoft.com. domain. The FQDN for the host would be mydomain.microsoft.com.
Understanding the DNS Domain Namespace
The DNS domain namespace, as shown in the following figure, is based on the concept of a tree of named domains. Each level of the tree can represent either a branch or a leaf of the tree. A branch is a level where more than one name is used to identify a collection of named resources. A leaf represents a single name used once at that level to indicate a specific resource.
DNS Domain Name Hierarchy
The previous figure shows how Microsoft is assigned authority by the Internet root servers for its own part of the DNS domain namespace tree on the Internet. DNS clients and servers use queries as the fundamental method of resolving names in the tree to specific types of resource information. This information is provided by DNS servers in query responses to DNS clients, who then extract the information and pass it to a requesting program for resolving the queried name. In the process of resolving a name, keep in mind that DNS servers often function as DNS clients, querying other servers in order to fully resolve a queried name.
How the DNS Domain Namespace Is Organized
Any DNS domain name used in the tree is technically a domain. Most DNS discussions, however, identify names in one of five ways, based on the level and the way a name is commonly used. For example, the DNS domain name registered to Microsoft (microsoft.com.) is known as a second-level domain. This is because the name has two parts (known as labels) that indicate it is located two levels below the root or top of the tree. Most DNS domain names have two or more labels, each of which indicates a new level in the tree. Periods are used in names to separate labels.
DNS Query Types
As shown in the graphic above, a number of queries were used to determine the IP address for www.whitehouse.gov. The query sequence is described below:
1. Recursive query for www.whitehouse.gov (A resource record)
2. Iterative query for www.whitehouse.gov (A resource record)
3. Referral to the .gov name server (NS resource records, for .gov); for simplicity, iterative A queries by the DNS server (on the left) to resolve the IP addresses of the Host names of the name server’s returned by other DNS servers have been omitted.
4. Iterative query for www.whitehouse.gov (A resource record)
5. Referral to the whitehouse.gov name server (NS resource record, for whitehouse.gov)
6. Iterative query for www.whitehouse.gov (A resource record)
7. Answer to the interative query from whitehouse.gov server (www.whitehouse.gov’s IP address)
8. Answer to the original recursive query from local DNS server to Resolver (www.whitehouse.gov’s IP address)
Host (A) resource records
Host (A) resource records are used in a zone to associate DNS domain names of computers (or hosts) to their IP addresses, and can be added manually, Windows clients and servers can also use the DHCP Client service to dynamically register and update their own A resource records in DNS when an IP configuration change occurs. DHCP-enabled client computers running earlier versions of Microsoft operating systems can have their A resource records registered and updated by proxy if they obtain their IP lease from a qualified DHCP server (only the Windows 2000 and Windows Server 2003 DHCP Server service currently supports this feature).
The host (A) resource record is not required for all computers, but is needed by computers that share resources on a network. Any computer that shares resources and needs to be identified by its DNS domain name, needs to use A resource records to provide DNS name resolution to the IP address for the computer.
Most A RRs that are required in a zone can include other workstations or servers that share resources, other DNS servers, mail servers, and Web servers. These resource records comprise the majority of resource records in a zone database.
Alias (CNAME) resource records
Alias (CNAME) resource records are also sometimes called canonical names. These records allow you to use more than one name to point to a single host, making it easy to do such things as host both an FTP server and a Web server on the same computer. For example, the well-known server names (ftp, www) are registered using CNAME RRs that map to the DNS host name, such as “server-1” for the server computer that hosts these services.
Ref: http://technet.microsoft.com/en-us/library/cc772774(WS.10).aspx
Domain Name System (DNS) is one of the industry-standard suite of protocols that comprise TCP/IP. Microsoft Windows Server 2003. DNS is implemented using two software components: the DNS server and the DNS client (or resolver). Both components are run as background service applications.
Network resources are identified by numeric IP addresses, but these IP addresses are difficult for network users to remember. The DNS database contains records that map user-friendly alphanumeric names for network resources to the IP address used by those resources for communication. In this way, DNS acts as a mnemonic device, making network resources easier to remember for network users.
The Windows Server 2003 DNS Server and Client services use the DNS protocol that is included in the TCP/IP protocol suite. DNS is part of the application layer of the TCP/IP reference model.
DNS in TCP/IP
For more information and to view logical diagrams illustrating how DNS fits with other Windows Server 2003 technologies, see “How DNS Works" in this collection.
By default, Windows Server 2003 DNS is used for all name resolution in a Windows Server 2003 network. In the most typical scenario, when a Windows Server 2003 network user specifies the name of a network host or an internet DNS domain name, the DNS Client service running on the Windows Server 2003 computer of the user contacts a DNS server to resolve the name to an IP address.
Ref: http://technet.microsoft.com/en-us/library/cc787921(WS.10).aspx
How DNS Works?
DNS Domain Names
The Domain Name System is implemented as a hierarchical and distributed database containing various types of data, including host names and domain names. The names in a DNS database form a hierarchical tree structure called the domain namespace. Domain names consist of individual labels separated by dots, for example: mydomain.microsoft.com.
A Fully Qualified Domain Name (FQDN) uniquely identifies the hosts position within the DNS hierarchical tree by specifying a list of names separated by dots in the path from the referenced host to the root. The next figure shows an example of a DNS tree with a host called mydomain within the microsoft.com. domain. The FQDN for the host would be mydomain.microsoft.com.
Understanding the DNS Domain Namespace
The DNS domain namespace, as shown in the following figure, is based on the concept of a tree of named domains. Each level of the tree can represent either a branch or a leaf of the tree. A branch is a level where more than one name is used to identify a collection of named resources. A leaf represents a single name used once at that level to indicate a specific resource.
DNS Domain Name Hierarchy
The previous figure shows how Microsoft is assigned authority by the Internet root servers for its own part of the DNS domain namespace tree on the Internet. DNS clients and servers use queries as the fundamental method of resolving names in the tree to specific types of resource information. This information is provided by DNS servers in query responses to DNS clients, who then extract the information and pass it to a requesting program for resolving the queried name. In the process of resolving a name, keep in mind that DNS servers often function as DNS clients, querying other servers in order to fully resolve a queried name.
How the DNS Domain Namespace Is Organized
Any DNS domain name used in the tree is technically a domain. Most DNS discussions, however, identify names in one of five ways, based on the level and the way a name is commonly used. For example, the DNS domain name registered to Microsoft (microsoft.com.) is known as a second-level domain. This is because the name has two parts (known as labels) that indicate it is located two levels below the root or top of the tree. Most DNS domain names have two or more labels, each of which indicates a new level in the tree. Periods are used in names to separate labels.
DNS Query Types
As shown in the graphic above, a number of queries were used to determine the IP address for www.whitehouse.gov. The query sequence is described below:
1. Recursive query for www.whitehouse.gov (A resource record)
2. Iterative query for www.whitehouse.gov (A resource record)
3. Referral to the .gov name server (NS resource records, for .gov); for simplicity, iterative A queries by the DNS server (on the left) to resolve the IP addresses of the Host names of the name server’s returned by other DNS servers have been omitted.
4. Iterative query for www.whitehouse.gov (A resource record)
5. Referral to the whitehouse.gov name server (NS resource record, for whitehouse.gov)
6. Iterative query for www.whitehouse.gov (A resource record)
7. Answer to the interative query from whitehouse.gov server (www.whitehouse.gov’s IP address)
8. Answer to the original recursive query from local DNS server to Resolver (www.whitehouse.gov’s IP address)
Host (A) resource records
Host (A) resource records are used in a zone to associate DNS domain names of computers (or hosts) to their IP addresses, and can be added manually, Windows clients and servers can also use the DHCP Client service to dynamically register and update their own A resource records in DNS when an IP configuration change occurs. DHCP-enabled client computers running earlier versions of Microsoft operating systems can have their A resource records registered and updated by proxy if they obtain their IP lease from a qualified DHCP server (only the Windows 2000 and Windows Server 2003 DHCP Server service currently supports this feature).
The host (A) resource record is not required for all computers, but is needed by computers that share resources on a network. Any computer that shares resources and needs to be identified by its DNS domain name, needs to use A resource records to provide DNS name resolution to the IP address for the computer.
Most A RRs that are required in a zone can include other workstations or servers that share resources, other DNS servers, mail servers, and Web servers. These resource records comprise the majority of resource records in a zone database.
Alias (CNAME) resource records
Alias (CNAME) resource records are also sometimes called canonical names. These records allow you to use more than one name to point to a single host, making it easy to do such things as host both an FTP server and a Web server on the same computer. For example, the well-known server names (ftp, www) are registered using CNAME RRs that map to the DNS host name, such as “server-1” for the server computer that hosts these services.
Ref: http://technet.microsoft.com/en-us/library/cc772774(WS.10).aspx
Tuesday, February 23, 2010
Web.config
The Web.config file is the primary configuration file for any web service. Since the CSF connectors are implemented as web services, their Web.config files must have the proper setting in order for the connectors to function. Each connector relies on the Web.config to be able to find the Common.config, EnterpriseInstrumentation.config, PolicyCache.config, and the location of their own configuration files.
Complete details of the web.config file can be found at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconformatofconfigurationfiles.asp
--------------------------------------------------------------------------
Please Note: All < tags are replaced by [
and > tags are replaced by ]
to avoid HTML errors in post
---------------------------------------------------------------------------
The five sections of the Web.config file that are critical to the operation of the CSF connectors - [configSections], [system.web][httpHanders], [Microsoft.Csf], [microsoft.web.services2], and [appSettings].
[configSections] contains the "Microsoft.Csf" and "Microsoft.Web.Services2" [sectionGroup] tags - these [sectionGroup] tags need to be specified in order for the sections to be used properly. Here is an example:
[configSections]
[sectionGroup name="Microsoft.Csf"]
[section name="ConfigFiles" type="System.Configuration.NameValueSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Custom=null"/]
[/sectionGroup]
[section name="microsoft.web.services2" type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration, Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /]
[/configSections]
[system.web][httpHandlers] this section maps a default path to an object and assembly name. This enables IIS to locate the correct Dll when it receives a call for one of the CSF connectors. Here is an example from the Identity Manager's Web.config file:
[system.web]
[httpHandlers]
[!-- Identity manager handlers --]
[add verb="*" path="OrganizationManager.ashx" type="Microsoft.Csf.Connector.IdentityManager.OrganizationManager, Microsoft.Csf.Connector.IdentityManager" /]
[add verb="*" path="UserGroupManager.ashx" type="Microsoft.Csf.Connector.IdentityManager.UserGroupManager, Microsoft.Csf.Connector.IdentityManager" /]
...
[/httpHandlers]
[Microsoft.Csf] this section specifies the CSF-specific settings, such as the location of the Common.cofig file, and the location of the connector's individual configuration file. Here is an example from the Identity Manager's Web.config file:
[Microsoft.Csf]
[ConfigFiles]
[add key="Common" value="C:\CsfConfig\Common.config" /]
[add key="IdentityManager" value="C:\CsfConfig\IdentityManager.config" /]
[/ConfigFiles]
[/Microsoft.Csf]
[microsoft.web.serivces2] section specifies the location of the WSE Trace files in the [diagnostics] tag - note that the [policyTrace] tag is optional. The [policy] tag hold the path to the PolicyCache.config file. The [security] tag holds the values for using certificates.
[microsoft.web.services2]
[diagnostics]
[trace enabled="true" input="c:\CsfTrace\Identity_InputTrace.webinfo" output="c:\CsfTrace\Identity_OutputTrace.webinfo" /]
[policyTrace enabled="true" input="C:\CsfTrace\Identity_receivePolicy.webinfo" output="C:\CsfTrace\Identity_sendPolicy.webinfo"/]
[/diagnostics]
[!-- security policy configuration --]
[policy]
[cache name="C:\CsfConfig\PolicyCache.config" /]
[/policy]
[!-- Test certification location and flags to allow test certs to work --]
[security]
[x509 storeLocation="LocalMachine" allowTestRoot="true"
allowRevocationUrlRetrieval="false" verifyTrust="false" /]
[/security]
[!-- production certification lookup location
[security]
[x509 storeLocation="LocalMachine"/]
[/security]
--]
[/microsoft.web.services2]
[appSettings] holds the path to the EnterpriseInstrumentation.config file, as well as additional configuration parameters:
[appSettings]
[add key="instrumentationConfigFile" value="C:\CsfConfig\EnterpriseInstrumentation.config" /]
[/appSettings]
Ref: Web.config
http://msdn.microsoft.com/en-us/library/aa306178.aspx
Working with web.config Files in Windows SharePoint Services(V2)
http://msdn.microsoft.com/en-us/library/dd587352(office.11).aspx
Working with Web.config Files (V3)
http://msdn.microsoft.com/en-us/library/ms460914.aspx
You may need to modify Web.config files to make your solution work in the Windows SharePoint Services environment. For example, you might need to add a SafeControl entry, register an HttpModule, or customize SessionState, but a Windows SharePoint Services deployment includes numerous Web.config files, one in each Web application, and one in each front-end Web server.
To make customizing Web.config files easier, Windows SharePoint Services provides two ways to make changes. First, you can declaratively register Web.config entries by creating an XML file that describes a set of Web.config modifications. To do this, you create a custom webconfig.XYZ.xml file in \\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG, where XYZ is a unique ID that you use to identify your solution. For an example that shows how to create a custom Web.config file to change settings, see How To: Add Custom Configuration Settings to Extend a Web Application.
In addition to creating a custom Web.config file, however, you can use the Windows SharePoint Services object model to modify Web.config settings. For an example that shows how to modify settings programmatically, see How To: Use the Object Model to Modify Web.config.
Changes that you define through the object model or through XML are always applied when you create a Web application.
Important:
The Web.config files in the \wpresources folders should not be modified. The settings of these files disallow pages or items that can be compiled. If these settings are changed, the security state for the compiled code differs greatly from the security state for code that runs from the Local_Drive:\Inetpub\wwwroot directory.
Caution:
Changes that you make to Web.config may be overwritten when you install updates or service packs for Windows SharePoint Services, or when you upgrade an installation to the next product version.
How To: Use the Object Model to Modify Web.config
In Windows SharePoint Services 3.0, you can modify Web.config settings by creating an XML file that describes the modifications, or you can perform the same task programmatically by using the SPWebConfigModification class of the Microsoft.SharePoint.Administration namespace, which allows you to dynamically register entities.
Ref: http://msdn.microsoft.com/en-us/library/bb861909.aspx
How To Create the Web.config File for an ASP.NET Application
http://support.microsoft.com/kb/815179
Complete details of the web.config file can be found at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconformatofconfigurationfiles.asp
--------------------------------------------------------------------------
Please Note: All < tags are replaced by [
and > tags are replaced by ]
to avoid HTML errors in post
---------------------------------------------------------------------------
The five sections of the Web.config file that are critical to the operation of the CSF connectors - [configSections], [system.web][httpHanders], [Microsoft.Csf], [microsoft.web.services2], and [appSettings].
[configSections] contains the "Microsoft.Csf" and "Microsoft.Web.Services2" [sectionGroup] tags - these [sectionGroup] tags need to be specified in order for the sections to be used properly. Here is an example:
[configSections]
[sectionGroup name="Microsoft.Csf"]
[section name="ConfigFiles" type="System.Configuration.NameValueSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Custom=null"/]
[/sectionGroup]
[section name="microsoft.web.services2" type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration, Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /]
[/configSections]
[system.web][httpHandlers] this section maps a default path to an object and assembly name. This enables IIS to locate the correct Dll when it receives a call for one of the CSF connectors. Here is an example from the Identity Manager's Web.config file:
[system.web]
[httpHandlers]
[!-- Identity manager handlers --]
[add verb="*" path="OrganizationManager.ashx" type="Microsoft.Csf.Connector.IdentityManager.OrganizationManager, Microsoft.Csf.Connector.IdentityManager" /]
[add verb="*" path="UserGroupManager.ashx" type="Microsoft.Csf.Connector.IdentityManager.UserGroupManager, Microsoft.Csf.Connector.IdentityManager" /]
...
[/httpHandlers]
[Microsoft.Csf] this section specifies the CSF-specific settings, such as the location of the Common.cofig file, and the location of the connector's individual configuration file. Here is an example from the Identity Manager's Web.config file:
[Microsoft.Csf]
[ConfigFiles]
[add key="Common" value="C:\CsfConfig\Common.config" /]
[add key="IdentityManager" value="C:\CsfConfig\IdentityManager.config" /]
[/ConfigFiles]
[/Microsoft.Csf]
[microsoft.web.serivces2] section specifies the location of the WSE Trace files in the [diagnostics] tag - note that the [policyTrace] tag is optional. The [policy] tag hold the path to the PolicyCache.config file. The [security] tag holds the values for using certificates.
[microsoft.web.services2]
[diagnostics]
[trace enabled="true" input="c:\CsfTrace\Identity_InputTrace.webinfo" output="c:\CsfTrace\Identity_OutputTrace.webinfo" /]
[policyTrace enabled="true" input="C:\CsfTrace\Identity_receivePolicy.webinfo" output="C:\CsfTrace\Identity_sendPolicy.webinfo"/]
[/diagnostics]
[!-- security policy configuration --]
[policy]
[cache name="C:\CsfConfig\PolicyCache.config" /]
[/policy]
[!-- Test certification location and flags to allow test certs to work --]
[security]
[x509 storeLocation="LocalMachine" allowTestRoot="true"
allowRevocationUrlRetrieval="false" verifyTrust="false" /]
[/security]
[!-- production certification lookup location
[security]
[x509 storeLocation="LocalMachine"/]
[/security]
--]
[/microsoft.web.services2]
[appSettings] holds the path to the EnterpriseInstrumentation.config file, as well as additional configuration parameters:
[appSettings]
[add key="instrumentationConfigFile" value="C:\CsfConfig\EnterpriseInstrumentation.config" /]
[/appSettings]
Ref: Web.config
http://msdn.microsoft.com/en-us/library/aa306178.aspx
Working with web.config Files in Windows SharePoint Services(V2)
http://msdn.microsoft.com/en-us/library/dd587352(office.11).aspx
Working with Web.config Files (V3)
http://msdn.microsoft.com/en-us/library/ms460914.aspx
You may need to modify Web.config files to make your solution work in the Windows SharePoint Services environment. For example, you might need to add a SafeControl entry, register an HttpModule, or customize SessionState, but a Windows SharePoint Services deployment includes numerous Web.config files, one in each Web application, and one in each front-end Web server.
To make customizing Web.config files easier, Windows SharePoint Services provides two ways to make changes. First, you can declaratively register Web.config entries by creating an XML file that describes a set of Web.config modifications. To do this, you create a custom webconfig.XYZ.xml file in \\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG, where XYZ is a unique ID that you use to identify your solution. For an example that shows how to create a custom Web.config file to change settings, see How To: Add Custom Configuration Settings to Extend a Web Application.
In addition to creating a custom Web.config file, however, you can use the Windows SharePoint Services object model to modify Web.config settings. For an example that shows how to modify settings programmatically, see How To: Use the Object Model to Modify Web.config.
Changes that you define through the object model or through XML are always applied when you create a Web application.
Important:
The Web.config files in the \wpresources folders should not be modified. The settings of these files disallow pages or items that can be compiled. If these settings are changed, the security state for the compiled code differs greatly from the security state for code that runs from the Local_Drive:\Inetpub\wwwroot directory.
Caution:
Changes that you make to Web.config may be overwritten when you install updates or service packs for Windows SharePoint Services, or when you upgrade an installation to the next product version.
How To: Use the Object Model to Modify Web.config
In Windows SharePoint Services 3.0, you can modify Web.config settings by creating an XML file that describes the modifications, or you can perform the same task programmatically by using the SPWebConfigModification class of the Microsoft.SharePoint.Administration namespace, which allows you to dynamically register entities.
Ref: http://msdn.microsoft.com/en-us/library/bb861909.aspx
How To Create the Web.config File for an ASP.NET Application
http://support.microsoft.com/kb/815179
Monday, February 22, 2010
Layouts Folder in SharePoint Server 2007 & WSS3.0
Windows SharePoint Services 3.0 uses the following folder to deliver SharePoint administration pages to each site in the site collection:
%ProgramFiles%\Common Files\Microsoft Shared\Web server extensions\12\Template\Layouts
The layouts folder is a special directory that gets "virtualized" for each SharePoint site. That is, each SharePoint site will have a /_layouts path from the root of the Web. For example http://servername/sites/sitename/_layouts. You can make an ASP.NET 2.0 Web application available under each SharePoint site by deploying the application to the layouts folder. This How To illustrates deploying ASP.NET Web applications in the Windows SharePoint Services 3.0 _layouts folder.
Ref: Deploying ASP.NET Web Applications in the Windows SharePoint Services 3.0 _layouts Folder
http://msdn.microsoft.com/en-us/library/cc297200.aspx
Application _layouts Page Type
Application pages, which are also known as "_layouts" pages, are stored in a site's Microsoft Internet Information Services (IIS) virtual directory and support application implementations. Application pages include pages with names such as create.aspx, settings.aspx, and other similar _layouts pages
Note:
The concept of "layout pages" in Microsoft Office SharePoint Server 2007 is different from the Windows SharePoint Services 3.0 _layouts page type.
These pages are stored in the virtual directory for the SharePoint Web application. The _layouts directory is also virtualized as a subfolder of every SharePoint site, and is exposed in a site collection or subsite, for example, http://MyServer/_layouts/Mysite.aspx or http://MyServer/a/b/c/_layouts/Mysite.aspx.
By default, the _layouts folder is installed in the path C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts.
Note: When you create hard-coded URLs to custom pages that you place within the LAYOUTS directory, specify paths that use the root Web site of the site collection, but that do not include subsites within the path. For example, use /_layouts/pages/MyPage.aspx, not /MySubsite/_layouts/pages/MyPage.aspx. Specifying a subsite in the path prevents the page from being accessed.
Differences Between Application Pages and Content Pages
Application pages are processed differently from content pages, as follows:
· Application pages are not subject to the same restrictions as content pages about where custom code is allowed. In fact, application pages behave much like all other ASPX pages.
· Application pages, unlike content pages, cannot host SharePoint features such as dynamic Web Parts and Web Part Zones.
Ref: Application _layouts Page Type
http://msdn.microsoft.com/en-us/library/aa979604.aspx
How to customize application pages in the Layouts folder in SharePoint Server 2007 and in Windows SharePoint Services 3.0
http://support.microsoft.com/kb/944105
Custom HttpModule Example
The following custom module simply returns a Web page message at the beginning of any HTTP request and another after the request has been processed.
http://msdn.microsoft.com/en-us/library/aa719858(VS.71).aspx
Catching unhandled exceptions in SharePoint
http://blogs.msdn.com/jannemattila/archive/2008/02/04/catching-unhandled-exceptions-in-sharepoint.aspx
Using HTTP Module for SharePoint 2007 (MOSS/WSS) site using FBA And RSA
http://blogs.msdn.com/pranab/archive/2007/12/13/using-http-module-for-sharepoint-2007-moss-wss-site-using-fba-and-rsa.aspx
%ProgramFiles%\Common Files\Microsoft Shared\Web server extensions\12\Template\Layouts
The layouts folder is a special directory that gets "virtualized" for each SharePoint site. That is, each SharePoint site will have a /_layouts path from the root of the Web. For example http://servername/sites/sitename/_layouts. You can make an ASP.NET 2.0 Web application available under each SharePoint site by deploying the application to the layouts folder. This How To illustrates deploying ASP.NET Web applications in the Windows SharePoint Services 3.0 _layouts folder.
Ref: Deploying ASP.NET Web Applications in the Windows SharePoint Services 3.0 _layouts Folder
http://msdn.microsoft.com/en-us/library/cc297200.aspx
Application _layouts Page Type
Application pages, which are also known as "_layouts" pages, are stored in a site's Microsoft Internet Information Services (IIS) virtual directory and support application implementations. Application pages include pages with names such as create.aspx, settings.aspx, and other similar _layouts pages
Note:
The concept of "layout pages" in Microsoft Office SharePoint Server 2007 is different from the Windows SharePoint Services 3.0 _layouts page type.
These pages are stored in the virtual directory for the SharePoint Web application. The _layouts directory is also virtualized as a subfolder of every SharePoint site, and is exposed in a site collection or subsite, for example, http://MyServer/_layouts/Mysite.aspx or http://MyServer/a/b/c/_layouts/Mysite.aspx.
By default, the _layouts folder is installed in the path C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts.
Note: When you create hard-coded URLs to custom pages that you place within the LAYOUTS directory, specify paths that use the root Web site of the site collection, but that do not include subsites within the path. For example, use /_layouts/pages/MyPage.aspx, not /MySubsite/_layouts/pages/MyPage.aspx. Specifying a subsite in the path prevents the page from being accessed.
Differences Between Application Pages and Content Pages
Application pages are processed differently from content pages, as follows:
· Application pages are not subject to the same restrictions as content pages about where custom code is allowed. In fact, application pages behave much like all other ASPX pages.
· Application pages, unlike content pages, cannot host SharePoint features such as dynamic Web Parts and Web Part Zones.
Ref: Application _layouts Page Type
http://msdn.microsoft.com/en-us/library/aa979604.aspx
How to customize application pages in the Layouts folder in SharePoint Server 2007 and in Windows SharePoint Services 3.0
http://support.microsoft.com/kb/944105
Custom HttpModule Example
The following custom module simply returns a Web page message at the beginning of any HTTP request and another after the request has been processed.
http://msdn.microsoft.com/en-us/library/aa719858(VS.71).aspx
Catching unhandled exceptions in SharePoint
http://blogs.msdn.com/jannemattila/archive/2008/02/04/catching-unhandled-exceptions-in-sharepoint.aspx
Using HTTP Module for SharePoint 2007 (MOSS/WSS) site using FBA And RSA
http://blogs.msdn.com/pranab/archive/2007/12/13/using-http-module-for-sharepoint-2007-moss-wss-site-using-fba-and-rsa.aspx
Sunday, February 21, 2010
WEBDAV
Web Distributed Authoring and Versioning (WebDAV) extends the HTTP/1.1 protocol to allow clients to publish, lock, and manage resources on the Web.
Integrated into IIS, WebDAV allows clients to do the following:
Manipulate resources in a WebDAV publishing directory on your server. For example, users who have been assigned the correct rights can copy and move files around in a WebDAV directory.
Modify properties associated with certain resources. For example, a user can write to and retrieve a file's property information.
Lock and unlock resources so that multiple users can read a file concurrently. However, only one person can modify the file at a time.
Search the content and properties of files in a WebDAV directory.
WebDAV Clients
You can access and publish to a WebDAV directory through one of the following Microsoft products or through any other client that supports the industry standard WebDAV protocol. For the specific procedure on how to access and publish through these Microsoft products, consult the specific product's Help.
Windows clients (Windows 2000 and Windows XP): Connect to a WebDAV directory by adding the directory to the list of Network Places and display the contents as if it were part of the same file system on your local computer. Once connected, you can drag and drop files, retrieve and modify file properties, and complete many other file-system tasks. You can also connect using the command-line client (known as WebDAV Redirector). This client allows you to use existing applications across the Web and share files through firewalls and proxy servers.
Internet Explorer (versions 5.0 and 6.0): Connect to a WebDAV directory by opening the target directory as a Web folder and complete the same file-system tasks as Windows clients.
Microsoft Office products (Office 2000 and Office XP): Create, publish, edit, and save documents directly into a WebDAV directory through any application in Office 2000 or Office XP.
Ref: About WebDAV
http://technet.microsoft.com/en-us/library/cc781730(WS.10).aspx
You cannot connect to a document library in Windows SharePoint Services 3.0 or Windows SharePoint Services 2.0 by using Windows shell commands or by using Explorer View
http://support.microsoft.com/kb/841215
Whitepaper - Understanding and Troubleshooting the SharePoint Explorer View
http://www.microsoft.com/downloads/details.aspx?familyid=c523ac7a-5724-48be-b973-641e805588f4&displaylang=en
Integrated into IIS, WebDAV allows clients to do the following:
Manipulate resources in a WebDAV publishing directory on your server. For example, users who have been assigned the correct rights can copy and move files around in a WebDAV directory.
Modify properties associated with certain resources. For example, a user can write to and retrieve a file's property information.
Lock and unlock resources so that multiple users can read a file concurrently. However, only one person can modify the file at a time.
Search the content and properties of files in a WebDAV directory.
WebDAV Clients
You can access and publish to a WebDAV directory through one of the following Microsoft products or through any other client that supports the industry standard WebDAV protocol. For the specific procedure on how to access and publish through these Microsoft products, consult the specific product's Help.
Windows clients (Windows 2000 and Windows XP): Connect to a WebDAV directory by adding the directory to the list of Network Places and display the contents as if it were part of the same file system on your local computer. Once connected, you can drag and drop files, retrieve and modify file properties, and complete many other file-system tasks. You can also connect using the command-line client (known as WebDAV Redirector). This client allows you to use existing applications across the Web and share files through firewalls and proxy servers.
Internet Explorer (versions 5.0 and 6.0): Connect to a WebDAV directory by opening the target directory as a Web folder and complete the same file-system tasks as Windows clients.
Microsoft Office products (Office 2000 and Office XP): Create, publish, edit, and save documents directly into a WebDAV directory through any application in Office 2000 or Office XP.
Ref: About WebDAV
http://technet.microsoft.com/en-us/library/cc781730(WS.10).aspx
You cannot connect to a document library in Windows SharePoint Services 3.0 or Windows SharePoint Services 2.0 by using Windows shell commands or by using Explorer View
http://support.microsoft.com/kb/841215
Whitepaper - Understanding and Troubleshooting the SharePoint Explorer View
http://www.microsoft.com/downloads/details.aspx?familyid=c523ac7a-5724-48be-b973-641e805588f4&displaylang=en
Saturday, February 20, 2010
Discussion Board
The discussion board shows the most recent discussion first, as well as the number of replies for each discussion. That way, you can quickly see which discussions have the most recent activity and which ones are the most popular. Members can also customize their own views of the discussion board.
By default, a new Windows SharePoint Services 3.0 site already has one discussion board set up. This board is called Team Discussion, but you can change its name and other settings or create additional discussion boards.
If your Windows SharePoint Services 3.0 site is set up to receive e-mail, participants can add items to the discussion board from their e-mail application.
Several options are available for customizing the views and behaviors that are specific to discussion boards. When you create a new view for a discussion board, you must base it on an existing view. The following views are provided, by default:
Subject view This view is available only at the top-level folder (the highest level of a discussion board) and is used to view the names of the discussions and other metadata on a particular discussion. The name of each discussion in the board appears as a link in the Subject column that you can click to go to a lower-level folder that displays the replies to that particular discussion.
Note Although it is possible to use a different view for the top-level folder, such as the flat or threaded view, we do not recommend that. Instead, use the subject view or a view that you create based on the subject view.
Flat view By default, this view is available only in folders of the discussion content type. This means that it is not available to the top-level folder. In this view, the subject of the discussion, all replies to the discussion, and other replies are aligned on one side.
Threaded view By default, this view is available only in folders of the discussion content type. This means that it is not available to the top-level folder. In this view, the subject of the discussion is aligned to to one side, all replies to the discussion are indented slightly, and all replies to previous replies are indented even farther. This view makes it easy to see whether a reply was made directly to the subject of the discussion or to a previous reply.
Ref:
Microsoft Office SharePoint Server - Create a discussion board
http://office.microsoft.com/en-us/sharepointserver/HA100867281033.aspx?pid=CH101788391033
Microsoft Office SharePoint Server - Customize a discussion board
http://office.microsoft.com/en-us/sharepointserver/HA100994901033.aspx?pid=CH101237661033
By default, a new Windows SharePoint Services 3.0 site already has one discussion board set up. This board is called Team Discussion, but you can change its name and other settings or create additional discussion boards.
If your Windows SharePoint Services 3.0 site is set up to receive e-mail, participants can add items to the discussion board from their e-mail application.
Several options are available for customizing the views and behaviors that are specific to discussion boards. When you create a new view for a discussion board, you must base it on an existing view. The following views are provided, by default:
Subject view This view is available only at the top-level folder (the highest level of a discussion board) and is used to view the names of the discussions and other metadata on a particular discussion. The name of each discussion in the board appears as a link in the Subject column that you can click to go to a lower-level folder that displays the replies to that particular discussion.
Note Although it is possible to use a different view for the top-level folder, such as the flat or threaded view, we do not recommend that. Instead, use the subject view or a view that you create based on the subject view.
Flat view By default, this view is available only in folders of the discussion content type. This means that it is not available to the top-level folder. In this view, the subject of the discussion, all replies to the discussion, and other replies are aligned on one side.
Threaded view By default, this view is available only in folders of the discussion content type. This means that it is not available to the top-level folder. In this view, the subject of the discussion is aligned to to one side, all replies to the discussion are indented slightly, and all replies to previous replies are indented even farther. This view makes it easy to see whether a reply was made directly to the subject of the discussion or to a previous reply.
Ref:
Microsoft Office SharePoint Server - Create a discussion board
http://office.microsoft.com/en-us/sharepointserver/HA100867281033.aspx?pid=CH101788391033
Microsoft Office SharePoint Server - Customize a discussion board
http://office.microsoft.com/en-us/sharepointserver/HA100994901033.aspx?pid=CH101237661033
Friday, February 19, 2010
Quick Launch
The Quick Launch is displayed on the side of most user-facing pages directly below the View All Site Content link.
You can use the Quick Launch to display section headings and links to different areas of your site in a logical manner. Neither the Quick Launch nor the View All Site Content link is displayed on site administration pages, such as the Site Settings page and the pages on which site administrators create and edit lists, libraries, workspaces, and Web pages. On a Microsoft Office SharePoint Server 2007 site, you can customize the Quick Launch by adding, removing, or reordering, links. You can also hide links to subsites and pages. You can even add links to pages outside the site.
Note To manage navigation for a SharePoint site, you must have the Full Control or Design permission level for the site. You have one of these permission levels if you can access the Sites Settings page for the site and you see the Navigation command under Look and Feel (on non-publishing sites, you will see the Quick Launch and Top link bar commands under Look and Feel instead of Navigation).
You can modify the display of Quick Launch by modifying attributes of the navigation control specified in the default.master file of the deployment (Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\GLOBAL). The default.master file is the Windows SharePoint Services master page that contains templates for site page layout, including the template for the left navigational area used in SharePoint pages.
The master page includes templates for two controls that by default are available for implementation on the Home page, a Microsoft.SharePoint.WebControls.Menu control, which displays the standard Quick Launch view used in the left navigational area, and a Microsoft.SharePoint.WebControls.SPTreeView control, which displays a site folder view. You can select which view to display on site pages through the user interface.
Ref: Customize navigation links on the Quick Launch
http://office.microsoft.com/en-us/sharepointserver/HA102551921033.aspx
How to: Customize the Display of Quick Launch
http://msdn.microsoft.com/en-us/library/ms466994.aspx
Note To manage navigation for a SharePoint site, you must have the Full Control or Design permission level for the site. You have one of these permission levels if you can access the Sites Settings page for the site and you see the Navigation command under Look and Feel (on non-publishing sites, you will see the Quick Launch and Top link bar commands under Look and Feel instead of Navigation).
You can modify the display of Quick Launch by modifying attributes of the navigation control specified in the default.master file of the deployment (Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\GLOBAL). The default.master file is the Windows SharePoint Services master page that contains templates for site page layout, including the template for the left navigational area used in SharePoint pages.
The master page includes templates for two controls that by default are available for implementation on the Home page, a Microsoft.SharePoint.WebControls.Menu control, which displays the standard Quick Launch view used in the left navigational area, and a Microsoft.SharePoint.WebControls.SPTreeView control, which displays a site folder view. You can select which view to display on site pages through the user interface.
Ref: Customize navigation links on the Quick Launch
http://office.microsoft.com/en-us/sharepointserver/HA102551921033.aspx
How to: Customize the Display of Quick Launch
http://msdn.microsoft.com/en-us/library/ms466994.aspx
Thursday, February 18, 2010
Master Page
A master page is an ASP.NET page that has the file name extension .master. Master pages allow you to create a consistent appearance and layout for the pages in your site or application.
Master pages are a feature of ASP.NET 2.0 that work the same way in Windows SharePoint Services 3.0 and Office SharePoint Server 2007 as they do in ASP.NET 2.0. Using master pages, you can create a single page template and then use that template as the basis for multiple pages in an application, instead of having to build each new page from scratch.
Master pages, in order to render in the browser, actually require two separate parts, the master page itself and a content page. A master page defines the common layout and navigation, as well as the common default content, for all of the content pages that are attached to it. A content page is a unique page. When the page is rendered in the browser, the master page supplies the common content and the content page supplies the page-specific content.
First, you create a single master page to define both the look and feel and the standard behavior either for all of the pages in your site or for a specific group of those pages. Then you can create individual content pages that contain the unique content that you want to display on each individual page. The master page is merged with the content pages to produce a final, rendered page that combines the layout from the master page with the content from the content page.
Because there is full design-time support for master pages in Microsoft Office SharePoint Designer 2007, you can see exactly what your finished page will look like while you are in the process of designing it.
Imagine, for example, that you want every page in a site to use the same three-column layout, along with a standard header and navigation menu. In that case, you can create one master page that has the desired layout, and then attach all of the pages in the site to that master page. By creating a single master page, you avoid the work of re-creating the common content for each page. Also, if at any time you decide to change the layout of all of the pages, you need only modify the master page.
Every site in Windows SharePoint Services 3.0 and Office SharePoint Server 2007 that is created from a site definition includes a Default.master that defines the default appearance of the site. In addition, Office SharePoint Server 2007 also includes several custom master pages. These custom master pages, like the Default.master page, include the content placeholders that enable the display of SharePoint content such as lists and libraries and can be used with Office SharePoint Server 2007 to define the look and feel of an entire site. For more information on using master pages with Office SharePoint Server 2007, see the later section What is different about master pages in Office SharePoint Server 2007?
Ref: Master pages
http://office.microsoft.com/en-us/sharepointdesigner/CH100667701033.aspx
Master pages are a feature of ASP.NET 2.0 that work the same way in Windows SharePoint Services 3.0 and Office SharePoint Server 2007 as they do in ASP.NET 2.0. Using master pages, you can create a single page template and then use that template as the basis for multiple pages in an application, instead of having to build each new page from scratch.
Master pages, in order to render in the browser, actually require two separate parts, the master page itself and a content page. A master page defines the common layout and navigation, as well as the common default content, for all of the content pages that are attached to it. A content page is a unique page. When the page is rendered in the browser, the master page supplies the common content and the content page supplies the page-specific content.
First, you create a single master page to define both the look and feel and the standard behavior either for all of the pages in your site or for a specific group of those pages. Then you can create individual content pages that contain the unique content that you want to display on each individual page. The master page is merged with the content pages to produce a final, rendered page that combines the layout from the master page with the content from the content page.
Because there is full design-time support for master pages in Microsoft Office SharePoint Designer 2007, you can see exactly what your finished page will look like while you are in the process of designing it.
Imagine, for example, that you want every page in a site to use the same three-column layout, along with a standard header and navigation menu. In that case, you can create one master page that has the desired layout, and then attach all of the pages in the site to that master page. By creating a single master page, you avoid the work of re-creating the common content for each page. Also, if at any time you decide to change the layout of all of the pages, you need only modify the master page.
Every site in Windows SharePoint Services 3.0 and Office SharePoint Server 2007 that is created from a site definition includes a Default.master that defines the default appearance of the site. In addition, Office SharePoint Server 2007 also includes several custom master pages. These custom master pages, like the Default.master page, include the content placeholders that enable the display of SharePoint content such as lists and libraries and can be used with Office SharePoint Server 2007 to define the look and feel of an entire site. For more information on using master pages with Office SharePoint Server 2007, see the later section What is different about master pages in Office SharePoint Server 2007?
Ref: Master pages
http://office.microsoft.com/en-us/sharepointdesigner/CH100667701033.aspx
Tuesday, February 16, 2010
Customizing SharePoint Sites and Portals (V2)
Introduction
Customization is the ability to change the layout, view, content, and site structure for a group of users such as a department or corporation. To help ensure consistency, Windows SharePoint Services and SharePoint Portal Server 2003 enable only Web Designers and Site Administrators full customization privileges for managing the look and feel of a site.
SharePoint Portal Server enables you to create Web portals that aggregate information from various sources into one convenient page. Team members and users can reach important business information, documents, and applications from one central access point.
The portal architecture and Web Part components determine how a site appears and manage all browser functions. Each portal site consists of reusable and customizable Web Parts that determine how information is presented. Administrators and site owners can use these components to customize how a Web portal looks and functions. You can modify existing Web Parts or create your own to achieve a unique look for your organization's site.
An individual user can also import Web Parts from a catalog or from Microsoft Office System applications to create his or her own personal portal view that organizes and presents only the information he or she wants.
Customizing a SharePoint Site
SharePoint sites are designed to be flexible. You can tailor a site to fit your users' needs by adding or removing pages, changing the appearance of pages, changing the site navigation, and making other customizations.
To customize SharePoint sites, you must have the following rights, which are included in the Web Designer and Administrator site groups:Manage Lists
Add and Customize Pages
Apply Themes and Borders
Apply Style Sheets
Other users of your site cannot gain access to the pages required to perform these tasks unless you specifically assign them to a site group that contains these permissions.
Customizing Web Sites From Within the Browser
You can perform basic customization from within the browser, using links from the Home, Create, and Site Settings pages of the Web site. From the browser you can perform basic customizations such as the following:
Add a list
Change the layout of the home page
Change the picture on the home page
Add a Web Part to a Web Part Page
Change a site's display name (not the URL)
Apply a theme
For more information about customizing Web sites from within the browser, see the Microsoft Windows SharePoint Services Help.
Customizing Web Sites by Using Web Page Editing Tools
Using a SharePoint–compatible Web page editor, such as Microsoft Office FrontPage® 2003, you can perform additional customizations such as the following:
Add borders to pages
Insert graphics
Add components to the home page
Change the navigation of a site
For example, if you create a custom theme for a SharePoint site in FrontPage 2003, and add the theme name to the list of themes in FrontPage 2003, you can edit the list of available themes in Windows SharePoint Services to include your new theme. An XML template called spthemes.xml contains the theme name, style sheet location, thumbnail, preview, and description of each theme that is available through the browser. You use this XML file to render the theme selection page. You can modify this XML file (by opening it in any text editor, such as Notepad) to include a custom theme on the Apply Theme to Web page. For more information about creating a theme and adding it to the list of themes in FrontPage 2003, see the Microsoft Office FrontPage 2003 Help.
Note To edit the spthemes.xml file, you must be a member of the local administrators group for the server.
Ref: Customizing SharePoint Sites and Portals: Part 1
http://msdn.microsoft.com/en-us/library/dd583126(office.11).aspx
Templates and Site Definitions
There are two ways you can customize SharePoint sites. You can use custom templates or create site definitions. Custom templates enable you to customize a site by using the user interface (UI). For example, you can derive a custom list from an existing list, or create a custom list to use as a list template that Site Administrators can choose from a list of available list templates. Windows SharePoint Services stores all custom templates in the content database. You can customize list and site templates from Top-level Site Administration or by using Microsoft Office FrontPage 2003. For more information about using FrontPage to customize SharePoint sites and portals, see Customizing SharePoint Sites and Portals, Part 1.
Site definitions are composed of multiple files located in the file system of each Web server. Site definitions and templates work together to customize a site. Custom templates are always associated with the site definition on which the template is based. A custom template depends on the base site definition in the file system in order to work. A custom template is the difference between a site definition and the state of the site after a template is generated. The template tracks changes to the site definitions that are stored in the configuration database. This article describes the advantages and disadvantages of using custom templates and site definitions and provides guidance about when to choose one over the other, and how to avoid overwriting custom templates and site definitions when installing product updates.
Creating Custom Templates
Now that we know that custom templates track changes to a SharePoint site definition, we can examine the different types of custom templates. List templates track changes to columns, forms, pages, and optionally, changes to the content associated with a specified list. Site templates track changes to site navigation, Web Parts, lists present on a site, and optionally, changes to the content of a single site. You can save an existing site as a site template.
Note There is a 10 MB quota on the total size of the content you can store in a site template. You can determine the size of site content by going to Top-Level Site Administration, and in the Management and Statistics section, clicking View site usage data.
A custom template is persisted as a file with an .stp extension, which is actually a .cab file that you can rename with the .cab file extension and open in Windows Explorer. This file includes one Manifest.xml file in Collaborative Application Markup Language (CAML) that the server generates as a subset of the Microsoft SharePoint Migration Tool (Smigrate.exe) manifest file format. For more information about SMIGRATE, see "Introduction to Templates and Definitions" in the Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).
Let's say that you created a site, customized it by adding lists, events, document libraries, custom Web Parts, and applied a special theme. You want to share this piece of work with other site owners or impose this site template on any subsites. On the Site Settings menu, click Go to Site Administration, and then in the Management and Statistics section, click Save as template. Type a file name using an .stp extension and type a title and description for your site template. You can also select the Include content check box. You save your site as a template in a gallery inside the content database to make it available to other subsites. As long as subsequent subsites are based on the same site definition (for example, on a Document Workspace) and have the identical language of the original site, you can create subsites using this template.
To make the template appear in the list of templates in the Site Creation wizard, you need to export the template to the file system and run the STSADM command tool. To export the template, right-click the template and click Save Target As, and then follow the prompts to save the template. After saving the template to the file system, from a command prompt, type the following:
Copy Code stsadm.exe -o addtemplate -filename "local_drive:\site_template_file_name.stp" -title "Site_Template_Name"
Note You must reset Microsoft Internet Information Services (IIS) before these changes can take affect. After resetting IIS, the Site_Template_Name template becomes available in the site template list during site creation.
You can also export a list template the same way you exported the site template. However, list templates are available only to the site collection of the site from which you exported.
About Collaborative Application Markup Language [CAML]
Collaborative Application Markup Language (CAML) is an XML-based language used for defining collaboration objects for a site. In Windows SharePoint Services, CAML defines sites, lists, fields, views, or forms.
CAML essentially has two major types of elements—those for field rendering and schema definition, and those for page rendering. For example, you can use the page-rendering CAML elements when you need to extract the property of a specific field and render it on a page.
You can also use CAML to define tables in the site database during site provisioning. You can use CAML to customize a SharePoint site and in SOAP messaging to Web services in Windows SharePoint Services to interact remotely with a Windows SharePoint Services deployment. Moreover, you can use CAML in script or code that implements members in the Windows SharePoint Services object model. In this case, you pass CAML strings through method parameters, assign them to properties, or return them by methods and properties.
For more information about CAML, see "Introduction to Collaborative Application Markup Language (CAML)" in the Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).
Ref: Customizing SharePoint Sites and Portals: Using Templates and Site Definitions, Part 2
http://msdn.microsoft.com/en-us/library/dd583127(office.11).aspx
Customizing SharePoint Sites and Portals: Style Sheet Class Reference Tables, Part 3
http://msdn.microsoft.com/en-us/library/dd583128(office.11).aspx
In this article, you'll find Web Part compatibility and style sheet class reference tables to use in your customization
Customization is the ability to change the layout, view, content, and site structure for a group of users such as a department or corporation. To help ensure consistency, Windows SharePoint Services and SharePoint Portal Server 2003 enable only Web Designers and Site Administrators full customization privileges for managing the look and feel of a site.
SharePoint Portal Server enables you to create Web portals that aggregate information from various sources into one convenient page. Team members and users can reach important business information, documents, and applications from one central access point.
The portal architecture and Web Part components determine how a site appears and manage all browser functions. Each portal site consists of reusable and customizable Web Parts that determine how information is presented. Administrators and site owners can use these components to customize how a Web portal looks and functions. You can modify existing Web Parts or create your own to achieve a unique look for your organization's site.
An individual user can also import Web Parts from a catalog or from Microsoft Office System applications to create his or her own personal portal view that organizes and presents only the information he or she wants.
Customizing a SharePoint Site
SharePoint sites are designed to be flexible. You can tailor a site to fit your users' needs by adding or removing pages, changing the appearance of pages, changing the site navigation, and making other customizations.
To customize SharePoint sites, you must have the following rights, which are included in the Web Designer and Administrator site groups:Manage Lists
Add and Customize Pages
Apply Themes and Borders
Apply Style Sheets
Other users of your site cannot gain access to the pages required to perform these tasks unless you specifically assign them to a site group that contains these permissions.
Customizing Web Sites From Within the Browser
You can perform basic customization from within the browser, using links from the Home, Create, and Site Settings pages of the Web site. From the browser you can perform basic customizations such as the following:
Add a list
Change the layout of the home page
Change the picture on the home page
Add a Web Part to a Web Part Page
Change a site's display name (not the URL)
Apply a theme
For more information about customizing Web sites from within the browser, see the Microsoft Windows SharePoint Services Help.
Customizing Web Sites by Using Web Page Editing Tools
Using a SharePoint–compatible Web page editor, such as Microsoft Office FrontPage® 2003, you can perform additional customizations such as the following:
Add borders to pages
Insert graphics
Add components to the home page
Change the navigation of a site
For example, if you create a custom theme for a SharePoint site in FrontPage 2003, and add the theme name to the list of themes in FrontPage 2003, you can edit the list of available themes in Windows SharePoint Services to include your new theme. An XML template called spthemes.xml contains the theme name, style sheet location, thumbnail, preview, and description of each theme that is available through the browser. You use this XML file to render the theme selection page. You can modify this XML file (by opening it in any text editor, such as Notepad) to include a custom theme on the Apply Theme to Web page. For more information about creating a theme and adding it to the list of themes in FrontPage 2003, see the Microsoft Office FrontPage 2003 Help.
Note To edit the spthemes.xml file, you must be a member of the local administrators group for the server.
Ref: Customizing SharePoint Sites and Portals: Part 1
http://msdn.microsoft.com/en-us/library/dd583126(office.11).aspx
Templates and Site Definitions
There are two ways you can customize SharePoint sites. You can use custom templates or create site definitions. Custom templates enable you to customize a site by using the user interface (UI). For example, you can derive a custom list from an existing list, or create a custom list to use as a list template that Site Administrators can choose from a list of available list templates. Windows SharePoint Services stores all custom templates in the content database. You can customize list and site templates from Top-level Site Administration or by using Microsoft Office FrontPage 2003. For more information about using FrontPage to customize SharePoint sites and portals, see Customizing SharePoint Sites and Portals, Part 1.
Site definitions are composed of multiple files located in the file system of each Web server. Site definitions and templates work together to customize a site. Custom templates are always associated with the site definition on which the template is based. A custom template depends on the base site definition in the file system in order to work. A custom template is the difference between a site definition and the state of the site after a template is generated. The template tracks changes to the site definitions that are stored in the configuration database. This article describes the advantages and disadvantages of using custom templates and site definitions and provides guidance about when to choose one over the other, and how to avoid overwriting custom templates and site definitions when installing product updates.
Creating Custom Templates
Now that we know that custom templates track changes to a SharePoint site definition, we can examine the different types of custom templates. List templates track changes to columns, forms, pages, and optionally, changes to the content associated with a specified list. Site templates track changes to site navigation, Web Parts, lists present on a site, and optionally, changes to the content of a single site. You can save an existing site as a site template.
Note There is a 10 MB quota on the total size of the content you can store in a site template. You can determine the size of site content by going to Top-Level Site Administration, and in the Management and Statistics section, clicking View site usage data.
A custom template is persisted as a file with an .stp extension, which is actually a .cab file that you can rename with the .cab file extension and open in Windows Explorer. This file includes one Manifest.xml file in Collaborative Application Markup Language (CAML) that the server generates as a subset of the Microsoft SharePoint Migration Tool (Smigrate.exe) manifest file format. For more information about SMIGRATE, see "Introduction to Templates and Definitions" in the Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).
Let's say that you created a site, customized it by adding lists, events, document libraries, custom Web Parts, and applied a special theme. You want to share this piece of work with other site owners or impose this site template on any subsites. On the Site Settings menu, click Go to Site Administration, and then in the Management and Statistics section, click Save as template. Type a file name using an .stp extension and type a title and description for your site template. You can also select the Include content check box. You save your site as a template in a gallery inside the content database to make it available to other subsites. As long as subsequent subsites are based on the same site definition (for example, on a Document Workspace) and have the identical language of the original site, you can create subsites using this template.
To make the template appear in the list of templates in the Site Creation wizard, you need to export the template to the file system and run the STSADM command tool. To export the template, right-click the template and click Save Target As, and then follow the prompts to save the template. After saving the template to the file system, from a command prompt, type the following:
Copy Code stsadm.exe -o addtemplate -filename "local_drive:\site_template_file_name.stp" -title "Site_Template_Name"
Note You must reset Microsoft Internet Information Services (IIS) before these changes can take affect. After resetting IIS, the Site_Template_Name template becomes available in the site template list during site creation.
You can also export a list template the same way you exported the site template. However, list templates are available only to the site collection of the site from which you exported.
About Collaborative Application Markup Language [CAML]
Collaborative Application Markup Language (CAML) is an XML-based language used for defining collaboration objects for a site. In Windows SharePoint Services, CAML defines sites, lists, fields, views, or forms.
CAML essentially has two major types of elements—those for field rendering and schema definition, and those for page rendering. For example, you can use the page-rendering CAML elements when you need to extract the property of a specific field and render it on a page.
You can also use CAML to define tables in the site database during site provisioning. You can use CAML to customize a SharePoint site and in SOAP messaging to Web services in Windows SharePoint Services to interact remotely with a Windows SharePoint Services deployment. Moreover, you can use CAML in script or code that implements members in the Windows SharePoint Services object model. In this case, you pass CAML strings through method parameters, assign them to properties, or return them by methods and properties.
For more information about CAML, see "Introduction to Collaborative Application Markup Language (CAML)" in the Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK).
Ref: Customizing SharePoint Sites and Portals: Using Templates and Site Definitions, Part 2
http://msdn.microsoft.com/en-us/library/dd583127(office.11).aspx
Customizing SharePoint Sites and Portals: Style Sheet Class Reference Tables, Part 3
http://msdn.microsoft.com/en-us/library/dd583128(office.11).aspx
In this article, you'll find Web Part compatibility and style sheet class reference tables to use in your customization
Monday, February 15, 2010
SharePoint Admin Guides / Documentation
SharePoint Team Services 2001 Product Documentation
http://technet.microsoft.com/en-us/library/dd349940.aspx
Windows SharePoint Services 2.0 Administrator's Guide
http://www.microsoft.com/downloads/details.aspx?FamilyID=A637EFF6-8224-4B19-A6A4-3E33FA13D230&displaylang=en
SharePoint Portal Server 2003 Administrator's Guide
http://www.microsoft.com/downloads/details.aspx?familyid=47405143-F586-4941-92F5-048BF00CF332&displaylang=en
Evaluation for Windows SharePoint Services 3.0 technology
http://technet.microsoft.com/en-us/library/cc287617.aspx
Microsoft Office SharePoint Server 2007
http://technet.microsoft.com/hi-in/office/sharepointserver/default(en-us).aspx
Microsoft Search Server 2008
http://technet.microsoft.com/hi-in/enterprisesearch/ee670396(en-us).aspx
Microsoft Office Project Server 2007
http://technet.microsoft.com/hi-in/office/projectserver/default(en-us).aspx
Forefront Security for SharePoint
http://technet.microsoft.com/hi-in/forefront/serversecurity/bb734828(en-us).aspx
For SharePoint 2010 right now I recommend
Microsoft SharePoint Team Blog
The official blog of the Microsoft SharePoint Product Group
http://blogs.msdn.com/sharepoint/archive/2009/05/07/announcing-sharepoint-server-2010-preliminary-system-requirements.aspx
http://technet.microsoft.com/en-us/library/dd349940.aspx
Windows SharePoint Services 2.0 Administrator's Guide
http://www.microsoft.com/downloads/details.aspx?FamilyID=A637EFF6-8224-4B19-A6A4-3E33FA13D230&displaylang=en
SharePoint Portal Server 2003 Administrator's Guide
http://www.microsoft.com/downloads/details.aspx?familyid=47405143-F586-4941-92F5-048BF00CF332&displaylang=en
Evaluation for Windows SharePoint Services 3.0 technology
http://technet.microsoft.com/en-us/library/cc287617.aspx
Microsoft Office SharePoint Server 2007
http://technet.microsoft.com/hi-in/office/sharepointserver/default(en-us).aspx
Microsoft Search Server 2008
http://technet.microsoft.com/hi-in/enterprisesearch/ee670396(en-us).aspx
Microsoft Office Project Server 2007
http://technet.microsoft.com/hi-in/office/projectserver/default(en-us).aspx
Forefront Security for SharePoint
http://technet.microsoft.com/hi-in/forefront/serversecurity/bb734828(en-us).aspx
For SharePoint 2010 right now I recommend
Microsoft SharePoint Team Blog
The official blog of the Microsoft SharePoint Product Group
http://blogs.msdn.com/sharepoint/archive/2009/05/07/announcing-sharepoint-server-2010-preliminary-system-requirements.aspx
Sunday, February 14, 2010
What is SharePoint?
Windows SharePoint Services 2.0 (WSS 2.0)[v2]
Microsoft Sharepoint Portal Server 2003 [v2]
Windows SharePoint Services 3.0 (WSS 3.0)[v3]
Search Server 2008 [v3]
Microsoft Office SharePoint Server 2007 MOSS [v3]
Forms Server 2007
Microsoft Office Groove Server 2007
Microsoft Office Project Server 2007
Microsoft SharePoint 2010 (currently in Beta)[v4]
Microsoft SharePoint 2010
Described by Microsoft as the "Business Collaboration Platform for the Enterprise and the Web", Microsoft SharePoint 2010 promises to deliver numerous benefits over its predecessor. It is currently in Beta.
Feature highlights include :
New user interface, including the new Office Ribbon.
Web Edit, allowing easy customization of a site.
Silverlight Web Part, allowing rapid integration of rich Silverlight applications.
Rich Theming, allowing simplified skinning of a SharePoint 2010 site
Multiple browser support, including Internet Explorer, Firefox and Safari amongst others.
Enterprise Metadata Management ("SharePoint taxonomy"), which enables a centralized taxonomy
There are also a collection of other new features relevant to IT Professionals, Developers and Partners
Ref: http://en.wikipedia.org/wiki/Microsoft_SharePoint
Microsoft Office SharePoint Server 2007 is an integrated suite of server capabilities that can help improve organizational effectiveness by providing comprehensive content management and enterprise search, accelerating shared business processes, and facilitating information-sharing across boundaries for better business insight. Additionally, this collaboration and content management server provides IT professionals and developers with the platform and tools they need for server administration, application extensibility, and interoperability.
Microsoft Office SharePoint Server 2007 Capabilities
Microsoft Office SharePoint Server 2007 provides a single, integrated location where employees can efficiently collaborate with team members, find organizational resources, search for experts and corporate information, manage content and workflow, and leverage business insight to make better-informed decisions.
Collaboration
Allow teams to work together effectively, collaborate on and publish documents, maintain task lists, implement workflows, and share information through the use of wikis and blogs.
Portals
Create a personal MySite portal to share information with others and personalize the user experience and content of an enterprise Web site based on the user’s profile.
Enterprise Search
Quickly and easily find people, expertise, and content in business applications.
Enterprise Content Management
Create and manage documents, records, and Web content.
Business Process and Forms
Create workflows and electronic forms to automate and streamline your business processes.
Business Intelligence
Allow information workers to easily access critical business information, analyze and view data, and publish reports to make better-informed decisions.
Ref: http://sharepoint.microsoft.com/Pages/Default.aspx
http://sharepoint.microsoft.com/product/details/Pages/default.aspx
Subscribe to:
Posts (Atom)
