. 何小碩's profileGet More... ExperiencePhotosBlogListsMore ![]() | Help |
Get More... Experience這是我的知識庫 我把所有在客戶端遇到的問題 所找到的資料統一蒐集在我的部落格 方便我後續的查閱 也藉此方便對 MOSS 有興趣的人來這找尋想要的資料 感恩哩 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
July 05 How to configure Project Server 2007 for Timesheets Management – A Complete Guide!Our main service is providing nearshore outsourcing to customers around the globe. It is very important for us to track effort spent as much detailed as possible, and report it to our customers, usually on a weekly basis. After trying with other tools and not being 100% satisfied, we decided to take advantage of Microsoft tools and start using Project Server 2007 for time management here in our company. I spent some hours doing research about this topic, and I found different articles and posts explaining just one chapter at a time, without finding a complete guide to install and configure this tool for this particular goal. Even after we followed all the steps found around several sources, we were still not able to generate the reports with the time spent by the resources selected for this pilot, due to some issues with the browser and also with the Cube (Project integrates with Analysis Services) used for populating the data. Then after several hours of effort with one of our Senior developers, we had our Project Server running and some of our team members were able to enter their timesheets using Project Web Access, a web interface exposed by this technology. Using Project Server also enabled us to integrate Sharepoint workspaces for centralizing project documentation, risks, issues and tasks, with project schedule, costs and time management that we can also publish through web so our customers can have a snapshot of the project anytime. We can generate customized reports through Pivot Tables and Analysis Services integration. Having this said, this is a powerful tool with a complete set of features, ideal for small, medium or enterprise organizations. Some features such as the web interface are really helpful for our nearshore software development practice, enabling both customers and remote teams to access the data everywhere. These are the steps you should follow in order to install and configure Project Server 2007 for timesheet management: 1. Install Sharepoint Server 2007 in a brand new Virtual Machine with Windows Server 2003. Step by step and different deployment scenarios can be found here: http://technet.microsoft.com/en-us/library/cc197758.aspx#section2 2. After installed, the project web access is located in a url like http://servername:port/PWA 3. Add a few domain users to the Project Server using the Server Settings / Security / Manage Users link. 4. Add your team members into Project Server resources list, using the Resources Center. These will be the team members you will allocate to each project and task. 5. Even when you can do almost everything from the Project Server web interface, it is faster to use your desktop version of Office Project 2007 to create projects, tasks and allocate resources. This requires the PM to have MS Office Project 2007 Professional version installed (Standard doesn´t support it) 6. To connect your Office Project to the Project Server 2007, you need to configure it through the Enterprise Options under the Tools menu. 7. Create a test project using the Project Center link / Add Project. 8. After adding a few test tasks, you must assign the team to the project and each task. This will allow the team members to see the assigned tasks and a. Go to Build Team From Enterprise b. Select the task(s) c. Go to Assign Resources d. Select the resources you want to assign. You can set costs and effort allocated. 9. Project Server requires timesheets periods to be defined (in most of the cases these will be mapped to each week of the year). You should go through each link in the Timesheets section under the Server Settings section. There is a complete ebook for this topic which you should download and read from here http://technet.microsoft.com/en-us/library/cc197478.aspx 10. Once the timesheets periods have been defined, your team member should be able to view the assigned tasks after login into the PWA with his credentials. 11. Each resource will be responsible for creating the timesheet and reporting it. The timesheet can be populated with the assigned tasks, or can be blank and then populated using the Add New Line link 12. Resource should submit his timesheet. These will be usually automatically approved unless you configure it. The timesheet cannot be updated except for the admin, once it is submitted. Once all of this is done, the database will have the data but you won´t be able to retrieve it using the reports yet. First, you need to configure this feature, otherwise you will see just a blank page when clicking the Data Analysis link In order to configure the Reports follow these steps: 1. Go to Create Server Settings, Views, New View, and select Data Analysis as the view type 2. Select your Data Analysis Services. If is it not populated you should go to check if Analysis Services was installed and all services are running. 3. Configure the settings and the data view properties (just follow the sections in the screen) 4. Configure the fields you want to display in the default timesheet view 5. Add the project server URL to the list of Local Intranet sites in your browser settings. 6. Configure your browser settings to allow ActiveX. 7. Configure your browser settings to allow Data Sources across domains. And that´s all! So if you follow these steps then you will be able to take advantage of Project Server reporting features: I hope this guide is useful and ping us if you face any issues when using this powerful tool ! So far we are really satisfied with it. Post written by - Marcelo Lopez, Project Manager @ UruIT Global IT Services June 25 Free MOSS Web Part - Hide Controls via JavaScriptNote2: Only works with MOSS 2007 sorry as you WSS guys do not have audiences targeting This is my small contribution to the SharePoint world. It is a web part that once added to a web part page, allows you to customise the display by adding JavaScript to selectively hide controls on the page . Ever needed to hide a field from display/edit for a certain audience? Well here is a way do it without requiring SharePoint Designer and having to break a page from it’s site definition (unghosting). Before and after shots below (look ma - no top button!) To fully understand what is being done here, I suggest you read my series of articles on the use of JavaScript in SharePoint. Part 3 in particular will show you how to safely add this web part to pages with editing disabled (NewForm.aspx, EditForm.aspx and DispForm.aspx) The full series can be found here: Part 1, Part 2, Part 3, Part 4, Part 5 and Part 6. Kudos to Jeremy Thake for feedback and some code contribution. Despite being seriously metrosexual, he is otherwise otherwise very cool :-P. Now two important warnings: Warning 1: This is an alpha quality release and I may never touch it again Warning 2: This web part should NOT be considered as a security measure and thus used in any security sensitive scenario (such as an extranet or WCM site). JavaScript by its very nature can be trivially interfered with and thus other methods (server side) should be employed in these scenarios to prevent interference at the browser. You can download by reading the disclaimer and clicking the button below.. THIS CODE IS PROVIDED UNDER THIS LICENSE ON AN “AS IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER Use at your own risk! To install perform the following commands
To remove/reinstall perform the following commands
ref: http://www.cleverworkarounds.com/2008/03/13/free-mosswss-2007-web-part-hide-controls-via-javascript/ June 22 MOSS 2007 開發Development EnvironmentSharePoint development environment configuration depends on the processes, type of engagements and type of work. The most popular solution that addresses the development scenarios is using local SharePoint farm, separated from the production servers, with the single installations of the SharePoint server on the development boxes. This provides isolation for builds, tests, and debugging across different teams, projects and production environments. The local environment is mostly isolated by development box and is installed on the host server or on virtual server. The following procedure is an overview of the steps that are required to create a typical SharePoint development environment. Development Box installation
Chose development tools There are varieties of tools that can make development fast and easy - from commercial to open source and Microsoft products. Microsoft recommends to use “Visual Studio extensions for Windows SharePoint Services” (VSeWSS), which simplify code-up solutions for SharePoint (e.g. Web Parts, List Definitions, Site Definitions, etc) via UI and allows reverse-engineering existed site to extract definitions for SharePoint entities. The disadvantages of VSeWSS are: 1) not intuitive for beginners; Others 3-rd party tools, which simplify development, are: 1. Management Tools • SharePoint Spy (http://www.echotechnology.com) These tools help to manage services of SharePoint farm and get detailed information about configuration settings. For example, screenshots of SharePoint Analyzer (left) and SharePointSpy (right)
2. Visual Studio Tools • STSDev to create project files (http://www.codeplex.com/stsdev) These tools create Visual Studio projects with the SharePoint 12-hive structure, and provide build settings to build/deploy/retract WSP packages directly from IDE. STSDev is the best tools to create a variety of projects - from simple features and Web Parts to Custom Workflow projects:
3. Development Tools
4. Other Tools • U2U CAML Builder - editor for CAML queries (http://www.u2u.net) Such tools give your additional flexibility in everyday development stuff, providing different editors, log viewers and analysers to make SharePoint development easier and faster. Setup Deployment environment Configure Continuous Integration (CI) system to build SharePoint solution, compile output to WSP packages, prepare deployment scripts and deploy WSP to Test Environment. Team Foundation Server (TFS) is one of the recommended tool for this task. There are several articles describing how to adopt SharePoint solution for CI, setup builds and configure TFS Deployer to deploy SharePoint packages across different environments: As to SharePoint Visual Studio Templates, CodePlex has a “SPTemplateLand” project that provides “12-hive” structure for SharePoint projects and deployments. Configure testing environment The following diagram depicts the most common development environment, which is recommended by “SharePoint Guidance patterns & practices” team.
The staging environment represents the target production environment as closely as possible from the perspective of topology (for example, the server farm and database structure) and components (for example, the inclusion of the Microsoft Active Directory service and load balancing, where applicable). In the next part we will describe the backup strategy to provide disaster recovery for SharePoint Farm MOSS 2007 邏輯架構佈署OverviewPlanning and installing SharePoint Farm across enterprise network is not a trivial task. SharePoint is rarely installed in an isolated environment, and usually it interferes with the organization strategy and existing infrastructure. Many factors may affect farm design, performance, scalability and redundancy - from hardware devices in organization network, to network topology. As a result, leveraging and finding compromises among those factors helps to build consistent, reliable and flexible environment. In this document you will find the configuration recommendations regarding different SharePoint areas. All information is represented in the set of recommendations about different actions you need to undertake or pay additional attention when you install and configure your SharePoint environment. We tried to structure all section to follow the natural flow of SharePoint installation from the scratch - from pre-installing analysis requirements to post deployment actions. We plan several whitepapers in our “Best Practices” series, and we are interested which topis you would like to see in our next SharePoint publications. Please send us your comments and suggestions via this form. IntroductionOrganizations adopting SharePoint face a variety of tasks - from planning, strategy, infrastructure and architecture design, UI Design, migration, and to development. All these tasks imply flexible infrastructural baseline before actual work starts. However, in reality we face the outdated environment and misconfigured farms that are not ready to implement new requirements. In such cases, baseline architecture becomes foundation stone of all SharePoint projects.
“Architectural Planning”Plan your farm and network communications before starting actual installation. The first thing to start is designing SharePoint architecture across corporate network. This includes understanding network structure, examining network devices and choosing the right SharePoint topology to fit the existing infrastructure and new requirements. Examine corporate network Start from description of the existing network design, location of all applications and system servers. Microsoft Visio 2007 and “Network Diagram” template is a good instrument for this task. Record the location and information of corporate system servers, like Domain Controllers, File Servers, Mail Servers, Application and others. Dont’ forget about network services - firewalls, proxies, and etc. For example, locations of ISA Servers across corporate network - IP address, list of open ports and the administrative user. The best way to maintain “Network Diagram” document is to update the single diagram that covers topology of all domains and how they are connected. The following diagram demonstrates the Visio document descibing the servers and devices across organization.
This diagram will give a holistic view of the existing topology and ensure quick access to information across different domains. Examine network devices All network devices in the topology play a vital role of how SharePoint performs and interacts among different servers. Information about locations and settings of all routers, switches, and accelerators become very important in planning server locations. For example, location of different WAN and XML accelerators across network affects SharePoint server organization and configuration. Presence of different network devices affects the connection bandwidth and latency between farm’s servers, and thereby, affects the choice of appropriate SharePoint Farm topology. Network Load Balancers (NLB), routers and switches will affect how fast network response, therefore the farm should be designed with the least impact of these devices. Refer to the following links for the detailed information about WAN accelerators, NLB and other network devices across SharePoint farms:
Network administrator is a friend The IT administrator is the person who should participate in farm configuration from the very beginning. This person will be responsible for the configuration of all network servers and devices across corporate network. Most of the SharePoint Farm topologies cross the bounds of domains and from the very beginning specific protocols and ports must be open. The best way to maintain current situation is to have a separate document, shared with administrator, with the description of protocols and ports to open across network services. Detailed information about system accounts and list of ports is available in the following articles:
Measure network latency Network response time is one of the important factors that can affect SharePoint farm design. Ideally, you need to measure the latency between SharePoint servers and users in order to reorganize servers according the smallest response time. Network latency is the key point to determine which of the proposed scenarios to implement in the current SharePoint deployment. (Latency is the time required for a packet to travel from one point on a network to another). Use the Ping tool (ping.exe) to measure latency for:
Do not forget to divide the round-trip result by two, because all measures are one way only, not round-trip. Compare results to the data below, and adopt environment to have latency lower those values.
The critical bandwidth for any SharePoint farms is 1.5 Mbps (T1) with 500ms latency. Overstepping these values will increase the page-load times dramatically, in 4 times at least. Refer to the diagrams in the “Plan for bandwidth Requirements” document, for more details about the bandwidth and latency results under different conditions. Available network bandwidth and latency influences geographic deployments significantly. Data transfers across WAN links that span multiple cities, states, provinces, countries, or continents requires really fast lines to provide adequate response time, so design such topologies thoroughly. More details for bandwidth requirements available in the following article http://technet.microsoft.com/en-us/library/cc262952.aspx Become familiar with SharePoint farm communications Before discussing servers’ redundancy and farm topologies let us review farm servers and how they communicate with each other. The following picture from from “Planning an Extranet Environment for Office SharePoint Server” TechNet article illustrates the communication channels within a server farm and which servers handle client’s request.
When a user issues a query, the query is sent to a Web server. The Web server communicates with the query server to build a list of results, and then communicates with the computer running Microsoft SQL Server to extend the list of results with summarization text, URLs, and security trimming. In parallel, the Web Server gets page data from SQL Server and renders them on fly. This diagram will help in understanding which roles to use on farm servers. Plan a baseline topology Analyse the existing infrastructure and plan a SharePoint topology for redundancy. The term redundancy is often misinterpreted to be synonymous with availability. Redundancy refers to the use of multiple servers in a load-balanced environment for any of several purposes, such as to improve farm performance, to scale out to accommodate additional users, and to improve availability. There are several different topologies - from three to six servers in farm, which can be used as a baseline. Which one to choose depends on the level of redundancy and available hardware. Not all clients can afford topology with six or ten servers in farm due to budget limitation or data centre capabilities. Finding the compromise between numbers of servers, type of hosting and servers’ roles become critical task, because this choice will affect performance and extensibility of the SharePoint farm for several years ahead. Three Servers Farm The minimum availability for the farm with few servers can be achieved with “3-servers farm” topology. In the current topology Web and Application Servers locate together on the one box and the database is on another box. The remaining, third, server gives a choice of which server role make redundant - Web server role or the database server role.
The farm with the two Web Servers provides redundancy of the Web and Application roles, improving the overall performance. A drawback of this design is that your data is not redundant (left farm). In other case, farm with two Database Servers (cluster) provides data redundancy, increasing availability of critical data, but users might suffer from temporary loss of access, when Web Server unavailable (right farm). The “3-servers farm” is one of the most questionable farms in terms of redundancy and performance. This limitation in the number of servers cannot provide redundancy of Query Server and high performance at the same time. Redundancy can be achieved with Query Roles on both Web App servers. In this case, Database Server is the only place for Index Role, but this will hinder the overall performance. The Index Role is very CPU and HDD consuming role and that is why database servers are not very optimal place for this role. Alternative solution is to assign Index Role to the Web Server with the Query Role, but this will not work effectively, because in this case, index will not be propagated to another Query Server in farm. If performance is one of the priorities then consider using Query Server and Index Server Roles on different Web Application Servers. This is flexible design in terms of extensibility, because with the new servers in farm changing roles of Index and Query servers is not required. Interestingly, a TechNet article (http://is.gd/8QbS, page 26) explains, that a Query Server can’t be used with Web Applications server for 3-servers farm. The reality is that, Web App and Query Role together are super common, more common than not (one of the reasons is that Query Server doesn’t use Network-Load Balancer - it uses its own algorithm). What they actually mean in the TechNet article is that having the Index on database server is not at all a recommended solution. Four Servers Farm Additional, forth server will add redundancy either for Data Server or for Web Server. However, it does not help much with performance. Current topology suffers from the same “3-servers farm” drawbacks - no place for Index Server with Query Role redundancy. Five+ Servers Farm The most common and highly available server farm topology is “5+ servers farm”, the farm with the middle tier server.
This middle tier server solves all issues of three and four servers topology by providing the dedicated tier for Index and Application roles. Additional servers in farm will extend middle tier, by assigning new roles to those servers - Excel Calculation Services Role, and Microsoft Office Project Server 2007 Role. The following table summarize farm topology:
To optimize the overall performance of five and more servers SharePoint Farm, configure a dedicated Web Server for crawling content, especially when crawling a server farm that contains more than 500 gigabytes (GB) of content or crawling content over the WAN. To ensure that user requests are not affected by content crawling, remove the dedicated Web server from the network load balancing rotation. This is especially important in global environments in which the off-peak hours of a regional farm (when crawl jobs are likely to be schedule) coincide with the peak hours of the central farm. Plan extranet topology Choose the topology based on requirements for external users. This topology will provide a basis of network extensibility for applications servers and communications between them. The simplest topology is “Edge firewall topology”, which is represented by following diagram, from TechNet article.
This topology applicable for the small farms, when there is no need to separate internal services from corporate network and secure communications between server farms. All remote users are separated from farm by ISA server which plays a role of remote proxy. For the big farms, when security of communications is a priority, the recommended topology is “Back-to-back perimeter topology”. This is very flexible and adaptable topology for network changes.
The main advantage of this topology is that it isolates the server farm in a separate perimeter network. Layers logically separate all servers and communications are under control - any security damages affect only specific layer, not the entire farm. External user access is isolated to the perimeter network and users can be isolated in different AD for remote and corporate access. There are some other extranet topology variations, but mostly all of them are based on “Back-to-back perimeter topology” with some modification.
Detailed information about farm topologies can be found in the following documents:
“Logical Planning”Plan site collections Plan number of site collections and sub sites in advance - content, location, security. Start with the single site collections and several sub sites rather then creating several site collections, and try to avoid new site collection if there are no requirements for this. The reason of such structure is that each new site collection works as a new application, with isolated scope to features, templates and search. Maintaining such structure is much easier than several site collections. Organize site collection across several content databases Do not end up with one big content database, because data optimisation will cause troubles in this case. For the small and development environments, single content database might be a preferable choice. However, for the large farms create several content databases and organize site collections among them. Having several content databases with sites helps to address the following:
More details about site collections in several content databases available in the following blog post: http://msmvps.com/blogs/laflour/archive/2008/10/14/tips-to-create-a-site-collection-in-new-content-database.aspx Script actions Prefer to script installation and SharePoint Farm configuration actions: setting roles, creating web sites and site collections, etc. Configuring successful farm from the first attempt has a change to fail due to complexity of SharePoint. Running scripts to repeat all actions will save time when something went wrong and new server installation is required. In the next part we will review the actual SharePoint installation and the basic farm configuration. 客戶端專案開發廠商開發環境說明Virtualization in SharePoint farm is one of the key design factors that simplify server availability by providing number of additional servers that might not be available over physical server models, or solution become very expensive. Microsoft officially supports SharePoint farm in virtualized environment since mid 2007. The following virtualizations technologies are supported: Hyper-V, Virtual PC, Virtual Server and 3rd party providers like VMware. One of the key factors for virtualization is that performance of virtualized farm is competitive to the physical farm. Microsoft tests shows: Virtualize SharePoint Web Role Web front-end servers are responsible for the content rendering and have comparatively lower memory requirements and disk activity than other roles, what makes them is an ideal candidate for virtualization. Choose disk type for Query Role The query role is responsible for a search performed by users is a good candidate for virtualization. The disk type choice for this role depends on the size of propagated index and the rate of index propagation. Consider using Index Role on physical server The Index server role in a SharePoint farm is often the most memory-intensive role, what makes it less ideal candidate for virtualization. Virtualized Index server role might be appropriate for development environment, small farm or farm with small content usage. Do not virtualize Database role SharePoint database role is the least appropriate role for virtualization in production scenarios, mainly due to the highest amount of disk I/O activity and very high memory and processor requirements. However, it is very common to see the SQL Server virtualized in test farms, quality assurance (QA) farms, and smaller SharePoint environments. Do I need to virtualize Application role? The decision of virtualizations the application roles, such Excel Services and InfoPath Services, depends on the roles usage. Those roles can be easily virtualized, because they are similar to Web Roles and mostly CPU intensive. When necessary, those servers can be easily moved to dedicated physical servers. Virtualized scenario sample The following picture demonstrates the common virtualized scenario of SharePoint Farm.
Common deployment scenarios for the SQL role in a SharePoint farm may have multiple farms, both physical and virtual, use a single database server or database cluster, further increasing the amount of resources consumed by the role. For example, in the picture above, the sample SharePoint environment illustrated maintains a two-server SQL cluster that is used by several virtual farms and one production farm. Use proper number of CPU Do not use more virtual CPUs than physical CPUs on the virtual host computer - this will cause performance issues, because the hypervisor software has to swap out CPU contexts. Use proper amount of RAM Plan to allocate the memory on virtual sessions according the next rule - divide the total amount of RAM in the server by the number of logical processors (physical processors multiplied by number of cores) in the host server. This will align allocated memory along with NUMA sessions. Otherwise it will provide performance issues. Plan to use physical drives In virtual scenarios front-end Web servers or Query servers disk performance is not as important as it would be physicals servers of the Index role or a SQL Server database. A fixed-size virtual disk typical provides better performance than a dynamically-sized disk. Consider using hardware load balancing Hardware load balancing provides the best performance, comparing with the software load balancing. It offloads CPU and I/O pressure from the WFE’s to hardware layer thereby improving availability of resources to SharePoint. Examples of Hardware: F5 BIG IP, Citrix Netscaler, Cisco Content Switch. Software load balancing examples are Windows Network load balancing, Round Robin load balancing with DNS. It is a trade-off between cost and performance. (Additional details are here) Be careful with snapshot feature on virtual servers Using snapshots for the backup might cause you troubles, because SharePoint timer service might be unsynchronized during the snapshot process, and once the snapshot is finished, errors or inconsistencies can arise. So, consider backups over the snapshots for the production environments. Measure virtualized environment performance After you complete your virtualized environment installation and configuration measure how fast you environment operates and optimize it to the best performance. Measure the following parameters: Mode details about virtualized performance counters can be found in this post Refer to the following document for more details regarding virtualization: http://technet.microsoft.com/en-us/library/cc816955.aspx In the next, final part we will describe the post deployment steps, which should be done to clear farm from temporary stuff and make your farm ready for production.
This entry was posted on Monday, June 22nd, 2009 at 8:37 am and is filed under Administration, Technical. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. June 17 When you install the 2007 Microsoft Office servers Service Pack 2, the product expiration date is activated incorrectly(KB 971620)Source: Microsoft Support During the installation of the 2007 Microsoft Office servers Service Pack 2, a product expiration date is activated incorrectly. This means that any of the products that are listed in the "Applies to" section will expire 180 days after Service Pack 2 is deployed, as if it were a trial installation. The activation of the expiration date will not affect the regular function of these products until the expiration date passes, 180 days after Service Pack 2 is deployed. If the product expires, it will not affect data, configuration, or application code. However, it will make the Office Server product inaccessible for end-users. This issue occurs because of the installation of the 2007 Microsoft Office serve... This issue occurs because of the installation of the 2007 Microsoft Office servers Service Pack 2. All installations of this service pack will result in this issue. To resolve this issue manually, type the product key on the Convert License Type... To resolve this issue manually, type the product key on the Convert License Type page. To do this, follow these steps:
June 14 What every SharePoint administrator needs to know about Alternate Access Mappings (Part 1 of 3)Hi folks, this is Troy Starr again from the Windows SharePoint Services Test team. Today I'd like to talk about one of the most powerful, but often one of the least understood, features in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. That feature is called Alternate Access Mappings. Around here, we just call it "AAM" for short. At the most basic level, AAM tells SharePoint how to map web requests (for example, browsing to the homepage of a SharePoint site) to the correct web application and site so that SharePoint can serve the correct content back to you. It then tells SharePoint what URL the users should be taken to as they interact with SharePoint. Seems simple enough, doesn’t it? Those of you who are familiar with developing web applications in Internet Information Services may be wondering right now why we need such a feature since IIS can tell you what the URL of an incoming web request is. The major reason we need this is that there are common Internet deployment scenarios where the URL of a web request received by IIS is not the same URL that the end user entered. These are most common in reverse proxy publishing and load balancing scenarios. How is this possible? Let's consider a reverse proxy scenario. A reverse proxy is a device that sits between end users and your web server. All requests to your web server are first received by the reverse proxy device, and if those requests pass the proxy's security filtering, the proxy will forward the requests on to your web server. Reverse proxies can perform advanced functionality such as receiving a web request over the Internet via SSL (HTTPS), but forward the request to the your server via HTTP. This is referred to as off-box SSL termination. They can also forward the request to a different port number than it was originally received on and can even change the HTTP Host header field. If SharePoint were base its links off of the URL of the request it received, the links that end users click on could be the incorrect "internal" URL rather than the correct "public" URL. SharePoint is compatible with a variety of reverse proxy servers, but for this example we'll take a look at a publishing rule from Microsoft's reverse proxy software - Internet Security and Acceleration Server 2006. ISA Server 2006 includes a SharePoint publishing wizard that walks you through creating a publishing rule for SharePoint. Once the rule is created, you can modify it at any time. (The following images show a slightly modified publishing rule where the "Forward the original host header" option is turned off to help demonstrate the flexibility of AAM. If we left the "Forward the original host header" option turned on, the public hostname would also serve as the internal hostname when configuring AAM.) The first two dialogs show the "listener" and "public name" properties of the rule, which define what URL users will use to access your SharePoint site. Remember that this URL is really the URL of your reverse proxy server, which will forward the request to your SharePoint server. The end user's URL is comprised of the public protocol, the public hostname, and the public port number.
The next two dialogs show the "to" and "bridging" properties of the rule, which define what URL the reverse proxy server will use to forward the request to your SharePoint server.
The SharePoint server's URL is comprised of the internal protocol, the internal hostname, and the internal port number.
Great - we've properly set up this reverse proxy server to receive web requests from end users at https://www.contoso.com and forward them to your SharePoint server at http://sharepoint.dmz.contoso.com. We're halfway there! The next step is to configure your SharePoint web application and AAM to match the publishing rule above. To do this, we'll extend an existing web application to an additional IIS Web site just for your reverse proxy's publishing rule. Note that you're also able to create a new web application from scratch for this publishing rule - the fields you'll need to fill out are the same in either case. Browse to your WSS 3.0 Central Administration site and click on the Application Management tab. Next, click "Create or extend Web application" and then click "Extend an existing Web application." Select the web application that you wish to use, and then fill out the port, host header, and SSL fields based on the internal URL properties that we defined above. In the URL field, enter the public URL that we defined above. Finally, you'll want to select an AAM Zone to assign this extension of your web application to. There are a maximum of 5 zones available in each web application. We'll use the Internet zone in this example, but you're free to use any available zone. All of the zones provide the same functionality, although the Default zone will always be used for certain features such as sending administrative e-mail messages to site collection owners. When you're finished, click OK to create the IIS Web site. Next, you'll want to verify that your public URL was created correctly in AAM and then add your internal URL. Unless your internal URL is the same as your public URL, this is an extra step that you must perform manually. To do this, browse to your WSS 3.0 Central Administration site and click on the Operations tab. Next, click "Alternate access mappings." Click the Alternate Access Mappings selector drop-down and select the web application that you're publishing through your reverse proxy server. You should now see the AAM URLs assigned to your web application.
As you can see, the public URL from the reverse proxy publishing rule has been assigned to your web application's Internet zone. The final touch is to add the internal URL from the reverse proxy publishing rule to your web application's Internet zone. To do this, click "Add Internal URLs" in the AAM toolbar, type in the internal URL, and select the same zone that you used for the public URL. In this case, that was the Internet zone. When you're finished, click Save. You should now see the additional URL is assigned to your web application, in the same zone as the public URL of your reverse proxy publishing rule.
All done! Now, when a user browses to https://www.contoso.com, the web request will be received by the proxy server and forwarded to http://sharepoint.dmz.contoso.com. SharePoint will then receive the web request, see that the URL of the request is http://sharepoint.dmz.contoso.com, find that this URL is assigned to the Contoso web application, and return the content from that web application. In addition, because the http://sharepoint.dmz.contoso.com URL is assigned to the Internet zone, SharePoint will also generate links on the pages using the public URL for that zone - https://www.contoso.com. This ensures that end users are taken to the proper URL when clicking on links on the page. Load balancers work similarly, especially if they overwrite the end user's original URL with the URL of the individual web server that the request is being load balanced to. To address this, just add each individual web server's URL to AAM as an internal URL and associate them all to the same zone as end user's public URL. I hope that this introduction to Alternate Access Mappings was helpful to you. Please feel free to post comments to this blog entry with any questions you may have about AAM. I will be posting another blog entry soon covering common AAM mistakes and how to avoid them.
Troy Starr Published Tuesday, March 06, 2007 5:19 PM by sptblog How to configure ssl for whole site with output caching enabledI ran into a new situation which i haven't thought about before. What if you have a public facing anonymous sharepoint site and you want to add a ssl cert for the whole site + you have output caching enabled with VaryByHeaders set to User-Agent. Most of us would handle this situation by inserting the ssl cert to the extended anonymous iis website. Situation: Cache flushed, first user hits https://www.contoso.com and then the second user goes to http://www.contoso.com and gets all the links pointing to the https site. This is because IIS + output caching is related to one IIS website at the time (one w3wp.exe process). Here's how to go around this issue. Extend the website once more and put it with the same host header as the anonymous site but map it to port 800. This is because IIS does not allow two websites with same port & host header (obviously). Then add the SSL cert to this new website. The picture below describes why.
Port 800 never get hits but the website responds to the https requests. Published Monday, March 03, 2008 6:05 PM by jukka SharePoint Server 2007 articles, fixes and updatesSearch and Indexing UNC FolderIn this post I will show you how to configure search by creating a content source that should be indexed and a search scope to limit the results when searcing. I will also show you how to customize the Search Center and adding a tab with a custom search and search results page. I will walk you though how to set up searchscopes and content sources (such as fileshares). We will begin by creating a content source and a search scope This will presume that you’ve got a network share with files and folders, e.g. the share “\\whatever\someShare” mapped against Z:\ on your local system. 1. Open SharePoint Central Administration and the Shared Services Provider admin site. Creating a scope to narrow down the search results to only file shares Posted 11-16-2006 3:17 AM by Tobias Zimmergren |
人的一生總是要有一些可以留念的東西
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|