In the previous sections some basic networking issues and their potential impact on EPM system performance were covered. It was mentioned that network performance is the most frequent bottleneck for most EPM solution installations and as such your network architecture and topology demands your attention and careful consideration.
Network Latency and Bandwidth
The network bottleneck may be typically indicated by poor performance or throughput with low CPU utilization on all tiers of the EPM solution, and, in most cases, it is the result of latency rather than bandwidth problems.
Bandwidth is defined as the maximum throughput of a network connection. The greater the network bandwidth, the greater the amount of network data that can be transmitted during a specific period of time. High-bandwidth connections between all server components of your EPM solution are important to the overall EPM system performance. However, if you have a high-bandwidth connection in place between all EPM solution components, but your users experience high network latency, the performance of your EPM system may still be unacceptable.
Latency is defined as the delay that occurs when network packets are transmitted from one network to another or from one segment of a network to another. The delay is measured in milliseconds (ms) and is typically caused by gateway devices such as routers and bridges, which process packets and perform network protocol conversion.
Unfortunately, you may have limited tools available to alleviate the problems related to latency, and that is because network latency is determined by your corporate network topology. Chances are you may be able to do something about inadequate bandwidth between the EPM solution components. You could move the EPM components closer to each other or place them at your corporate data center with a 1Gb Ethernet or fiber connection available between server components. But even then, you may be able to do little about your corporate network topology, the physical location of your network routers and bridges. Fifty milliseconds and higher latency can cause significant increases in project open and save times.
Network bandwidths of less than 10Mbps may indicate the need for Terminal Services server as part of your EPM solution.
For additional suggestions on how to improve network performance, review the Microsoft Project Server 2003 Planning Configuration Guide, Appendix H, "Best Practices for Deploying an EPM Solution."
Using Multiple NIC Cards or NIC Teaming
One of the top 10 recommendations from the Microsoft Customer Architecture Review Team (CART) is to use multiple network interface cards (NICs) on the Project Server database server.
The CART program was initiated in December 2002 by Microsoft as a means of providing detailed recommendations to large customers preparing to deploy Microsoft Office Project Server 2002 and, later on, Microsoft Office Project Server 2003. CART also assists in providing a thorough review of the hardware architecture and configuration that the customer intended to deploy. After completing a number of customer reviews, Microsoft identified a set of technical recommendations that most routinely appeared during these reviews.
The following information is based on recommendations from the CART team. Many of the CART recommendations are documented in the Microsoft Office Project Server 2003 Configuration Planning Guide, Appendix H, "Best Practices for Deploying an EPM Solution," available from http://www.microsoft.com/technet/prodtechnol/office/proj2003/reskit/default.mspx.
The recommendation to use multiple NICs or NIC teaming was frequently made to improve the scalability of the system where CPU and memory on the database server appear underutilized. In high use cases, you may notice a network bottleneck developed at the network interface on the database server machine. This bottleneck is caused by communication traffic from the PWA web server, Project Professional clients, and the Views Processing/Cube Generation system. In the end, all these EPM solution components and clients need to communicate with the Project Server database, and this can cause a high volume of traffic to be sent to a single NIC on the database server. There are multiple ways to mitigate this bottleneck.
Dual NIC Configuration
The most frequently recommended, least expensive, and most easily implemented solution is to add a second NIC to the database server and then configure the EPM solution components to selectively initiate communications with one of these two NIC interfaces. For example, by altering settings in the Project Server registry, you could force all communications from the PWA web server to go to NIC #1 on the database server, while all Views Processing and Cube Generation traffic goes through NIC #2. By doing this, you can successfully spread the network traffic across both NICs and reduce the bottleneck at this point of the EPM system.
Many hardware vendors sell systems generally referred to as NIC teaming or NIC clustering that support the use of multiple NIC interfaces to simulate a single logical NIC. This type of solution can reduce the network bottleneck if used with the database server.
The following URL link is one of the sites that has some useful information and more details on NIC teaming solutions: http://h18004.www1.hp.com/products/servers/networking/teaming.html#switch.
Multiple Network Segments Configuration
The final way to more effectively spread network traffic across various NIC interfaces on the database server is to install multiple network segments to carry different traffic. In this configuration, LAN segment 1 could support traffic between the IIS server(s) and the database server only, while LAN 2 supported traffic between Project Professional clients and the database server. This is an effective but more complex solution to the problem.
Wide Area Networks (WAN)
Latency and bandwidth issues have to be carefully considered in a WAN environment. Many large corporations deploy their EPM solution in a WAN environment. Although bandwidth is an important factor in a WAN environment, latency is usually a much bigger concern for a Project Server 2003based EPM solution deployment.
Network bandwidth and network latency are separate terms. Networks with high bandwidth do not necessarily guarantee low latency. For example, a network path traversing a satellite link often has high latency, even though throughput is very high. It is not uncommon for a network round trip traversing a satellite link to have five or more seconds of latency.
It is important to understand the implication of such a delay. For example, an application designed to send a request, wait for a reply, send another request, wait for another reply, and so on, will wait at least 5 seconds for each packet exchange, regardless of how fast the server is.
Despite the increasing speed of computers, satellite transmissions and network media are based on the speed of light, which generally stays constant, at least as far as we humans can say. As such, improvements in latency for existing satellite networks are unlikely to occur.
The lower the latency delay, the better your WAN performance will be. Latency becomes an issue if you are transporting large amounts of data over the WAN connectionfor example, when a Project Professional user opens or saves a project from or to the Project Server database.
For an EPM solution, WAN performance is generally acceptable if latency does not exceed 30 to 50ms. If your WAN users' connections experience a latency delay above 50ms, you may consider using Terminal Services as part of your EPM solution deployment.
As mentioned earlier in this chapter, network bandwidths of less than 10Mbps may also indicate the need for Terminal Services.
Several TCP/IP tools can be used to get a better idea of what latency your connection is experiencing. The following tools can be useful when troubleshooting your TCP/IP network and finding out what the latency of your WAN connection is:
For more details about how to use these TCP/IP utilities, review the information available at the Microsoft Windows 2000 Resource Kit: http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/cnet/cnbd_trb_ssis.asp.
EPM Solution for Users in Multiple Geographic Locations
The final EPM solution configuration also depends on the geographic distribution of your EPM system users.
If all EPM solution users in your organization are located at a single physical location and have low-latency, high-bandwidth connections to your corporate data center where all EPM solution server components are installed, geographical distribution of your users will probably not play a major role in determining your EPM solution hardware configuration.
On the other hand, if EPM solution users in your organization are spread across different geographic regions, you must take the multiple geographic locations and all their characteristics under consideration when planning your Project Server 2003 hardware configuration.
You also have to evaluate the impact of your users working in multiple time zones. It is highly probable that they will be accessing the Project Server corporate database around the clock and, therefore, leaving little or perhaps almost no time for regular IT maintenance tasks on the server components of your EPM solution. If this is the scenario you are faced with, consider a high-availability EPM system configuration to allow for needed IT maintenance.
If EPM solution users in your organization are spread across different geographic regions, you can consider the following scenario.
Deploy all your EPM solution servers in the same domain and ensure that all server components are connected with high-bandwidth, low-latency LAN connections. For all your EPM system users located wherever, deploy Terminal Services to provide access to the Project Server database through Microsoft Office Project Professional 2003 client.
EPM Solution Deployment in Trusted and Nontrusted Domain Environments and Extranets
To clarify, installing all Project Server 2003 EPM solution components on a single server, perhaps for an initial proof-of-concept project, is fairly simple, provided that you have reviewed the Microsoft Office Project Server 2003 Installation Guide and followed all the steps in the correct sequence. The Microsoft Office Project Server 2003 Installation Guide is available from http://www.microsoft.com/downloads/details.aspx?FamileID=ca99b5e3-0478-4ac3-a230-c4f2d82096c1&DisplayLang=en.
As soon as you start to consider distributed hardware architecture for your EPM solution components, things get much more complex, and you need to be aware of some potential issues and problems. The main reason for this complexity is that Project Server architecture is flexible. In addition, Project Server relies on and integrates with other Microsoft products such as WSS, IIS, and SQL Server 2000.
Several key deployment options are available to you. First, you can deploy all the EPM solution components in a single domain on single or multiple servers. If that is the case, things usually work well, and issues such as user authentication and security are typically of less concern.
Second, you can deploy the EPM solution components across multiple domains. At that point, things become a lot more interesting because you have to start thinking about what accounts, domain or local, to create and use for what, as well as understand trust relationships between your multiple domains.
The ultimate "fun" is to deploy the EPM solution components in a multiple domain environment with corporate firewalls in place and requirements specifying extranet access for your users. Here you need to make sure that your hardware architecture provides safe and efficient access to both internal and external users. The question now is what TCP/IP ports you need to open to provide safe external and internal access for your users. Figure 6.2, for example, demonstrates hardware architecture for your EPM solution components deployed across single and multiple domains.
Figure 6.2. Example distributed architecture for your EPM solution components deployed across single and multiple domains where users are in different domains.
How you define your EPM solution external and internal users, as well as what is considered extranet and intranet, is based on the user's location relative to your corporate firewall.
EPM Deployment in Trusted Domains
You can deploy EPM solution components in a single domain, in multiple domains, or in a workgroup. Regardless of the domain configuration in which you deploy your EPM solution components, you must ensure that all your users can be authenticated when accessing all required resources. The nature of the trust relationships that exist between your domains, in which users and EPM solution components are deployed, affects the ability of all users in your organization to access corporate project data and the Project Server functionality.
In a single domain or a multiple domain configuration in which two-way trust relationships exist between multiple domains, your users are automatically authenticated access to Project Server components and resources, provided that you use Windows authentication. If two-way trust relationships do not exist between your multiple domains, you must create local accounts for each EPM component server in the domain in which the EPM component server requires access.
Maintaining corporate project and resource data in the same domain in which your users are located and defined or in a domain that exists in the same forest (a single domain tree or a group of domain trees grouped together to share resources) as the domain in which the users who need to access the corporate data are located is the easiest way to enable access to your Project Server data. Domains located in a single Active Directory forest also have automatic two-way trust relationships established. You can also manually establish two-way trusts between domains located in different Active Directory forests.
To understand the concepts of Active Directory forests, trees, domains, and organizational units, refer to the following Microsoft TechNet page for more detailed information: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/default.mspx.
Now you see an example of the EPM solution components distributed across three domains that exist in the same Active Directory forest. Project Server components are located in domains 1 and 3, and PWA and Project Professional users are located in domain 2. Figure 6.3 shows users in domain 2 accessing all distributed Project Server components in domains 1 and 3 automatically using Windows authentication because all domains in the same Active Directory forest have two-way trust relationships established.
Figure 6.3. Distributed EPM solution components deployed across three domains in the same Active Directory forest.
When you perform Active Directory synchronization across trusted domains in separate forests, you must reference the domains by using the Fully Qualified Domain Name (FQDN). This is because trusted domains located in different forests do not share the root of the global catalog.
One-Way Trust Relationships
If the domains in which your users and your EPM solution components are located are not in the same forest, the two-way trust relationships between domains are not automatically configured. Make sure that you account for this in your configuration planning.
To enable EPM solution users from a domain in one forest to have authenticated access to project and resource data residing in a domain in another forest, you can establish manually one-way trusts.
Figure 6.4 shows a one-way trust relationship in which domains 1 and 2 are in one forest and share a two-way transitive trust relationship, and domain 3 is in a separate forest. A one-way trust is established between domain 3 and domain 1. Because domain 2 trusts domain 3 by means of a transitive trust relationship with domain 2, users in domain 2 can access Project Server data in domain 3.
Figure 6.4. EPM solution components deployed across three domains in different Active Directory forests with a one-way trust relationship configured between domains in separate forests.
EPM Deployment in Nontrusted Domains
The Project Server 2003 architecture is flexible enough that you can deploy EPM solution components across nontrusted domains. You can also deploy an EPM solution in a Windows workgroup or in a Novell network environment.
Figure 6.5 shows an environment in which EPM solution components are deployed across four domains that do not have any trust relationships configured. In this scenario, EPM solution users do not have authenticated access to the domains in which the EPM solution components are located.
Figure 6.5. EPM solution components deployed across four domains in different Active Directory forests with no trust relationship configured between domains in separate forests.
You need to understand that in general this configuration provides limited Project Server functionality that can reduce the overall security of your EPM solution deployment, and increases administration effort significantly. Use of the Portfolio Analyzer feature is limited, and you have limited ability to publish projects and assignments to the Project Server database.
If you absolutely must deploy Project Server 2003 in a nontrusted domain environment, it is recommended that you create local user accounts on each EPM component server to which users require access. This definitely creates additional administrative overhead, but it allows users in nontrusted domains to access Project Server data. You may also need to give the default IIS anonymous user account (IUSR_ComputerName) permissions on the ViewDrop folder used by the Views Publishing service.
Allowing users to access Project Server data from a nontrusted domain, regardless of the authentication method, is not as secure as requiring users to use Windows user accounts to access Project Server data from trusted domains.
Windows SharePoint Services in a Nontrusted Domain Environment
As was mentioned previously, you can enable users to use the PWA client to work with documents, issues, and risks in a nontrusted domain environment by creating local user accounts on the server running WSS. However, in this scenario, the Project Server database tables are not updated to reflect the additional site content.
SQL Analysis Services in a Nontrusted Domain Environment
Server computers running Project Server 2003, SQL Server 2000, and Analysis Services must all be in the same domain, or in trusted domains, for you to be able to have a full feature set of the Portfolio Analyzer available. Portfolio Analyzer is based on the OLAP cube built and managed by SQL Server 2000 Analysis Services. Because access to the OLAP cube requires Windows authentication, users who attempt to create Portfolio Analyzer views from a nontrusted domain are denied access to the OLAP cube. If you need to allow users from nontrusted domains to access Portfolio Analyzer features, you must explicitly grant them permission to access the computers running SQL Server and Analysis Services through a Windows user account.
If a user in a nontrusted domain attempts to access Portfolio Analyzer from PWA, the error message "Unable to access the Microsoft Portfolio Analyzer OLAP Cube" displays, unless the user can specify a Windows user account on the computer running Analysis Services.
You can enable the user to access the computer running Analysis Services in one of the following ways:
Creating a local Windows user account is not recommended because it allows users from nontrusted domains to access computer servers running SQL Server and Analysis Services, and that creates potential security risks.
For more details about configuring an EPM solution in an extranet and nontrusted domains environment, refer to the Microsoft Project Server 2003 Installation Guide, Chapter 9, "Extranet and Non-Trusted Domain Scenarios." The Microsoft Project Server 2003 Installation Guide is available for download from the Project Server 2003 Technical Library at http://www.microsoft.com/technet/prodtechnol/office/proj2003/reskit/default.mspx.
Extranet Configurations for EPM Solutions
Extranet configurations for EPM solutions enable users outside your corporate firewall to access Project Server data through component servers placed in your demilitarized zone (DMZ) or a computer running Terminal Services. Internal EPM solution users access Project Server data through your corporate intranet behind your corporate firewall.
When providing external access for your EPM solution users, you have two basic choices: provide access via the Internet or by means of a virtual private network (VPN).
It is recommended that you enable external users to access data on the intranet by deploying duplicate computers running Project Server 2003 and WSS, one for extranet users and one for internal users, as shown in Figure 6.6. For external EPM solution users who access corporate project data over a high-latency network connection, provide a Terminal Services in DMZ zone.
Figure 6.6. Distributed EPM solution components deployed for external and internal users.
Users who connect via the extranet access EPM corporate data on the external facing servers running Project Server 2003 and WSS. It is recommended that these servers are deployed with the SSL protocol. Internal users access data on intranet servers. Both external and internal servers use the same SQL Server databases. View Processing and Session Manager services are deployed on only the internal network and do not have to be duplicated in the DMZ. These two EPM solution components are not installed on the extranet computers.
If you decide to use WSS, you need to deploy a second WSS installation outside your corporate firewall and connect to the content database for your existing (intranet) deployment.
For the detailed steps on Project Server and WSS in the extranet environment, review Chapter 9, "Extranet and Non-Trusted Domain Scenarios," in the Microsoft Office Project Server 2003 Installation Guide, available for download from the Project Server 2003 Technical Library at http://www.microsoft.com/technet/prodtechnol/office/proj2003/reskit/default.mspx.
Extranet users must be authenticated before they can connect to the external facing servers running Project Server 2003 and WSS. A VPN solution can be used to provide this connection using Internet Protocol Security (IPSec) with a public key infrastructure (PKI) to provide Internet Protocolbased authentication and encrypted communication.
Users in remote offices can be authenticated by means of user accounts or digital certificates mapped to user accounts. Encryption for Hypertext Transfer Protocol (HTTP) access is provided by means of the SSL protocol.
Project Professional clients require direct open database connectivity (ODBC) connection to the computer running SQL Server 2000 that hosts the Project Server 2003 database tables. A direct SQL Server connection for external users in an extranet scenario is not recommended for a couple of reasons. It requires deploying the computer running SQL Server in the DMZ and opening an inbound port (typically port 1433) to potentially dangerous Internet traffic. Exposing a computer running SQL Server to Internet traffic creates a risk of infection from database-related worms and viruses. The second reason is performance related. Project Professional client is very "chatty," and opening and saving even the average size project this way could take a few minutes. That may not go well with your project managers who are typically busy as well as impatient.
The Portfolio Analyzer feature of Project Server 2003 uses Microsoft Office Web Controls (OWC) to bind directly to the SQL Analysis Services server. To enable users to access OLAP over the extranet, you must do the following:
You can verify the version of the msolap80.dll file in the Program Files\Common Files\System\Ole DB directory. To install OLE DB Provider for OLAP, run ptsfull.exe, located in the msolap\install\PTS\ directory on the Microsoft SQL Server 2000 setup disc.
For more information, see Microsoft Knowledge Base article 279489, "How to Connect to Analysis Server 2000 By Using HTTP Connection," located at http://go.microsoft.com/fwlink/?linkid=20174.
Using Terminal Services As Part of an EPM Solution
Although it is technically possible for Project Professional 2003 users to access Project Server data directly from an extranet environment, this configuration is not recommended for reasons just stated in the previous section. Limitations to this configuration include performance degradation, some feature limitations, as well as potential security risks.
The Terminal Services configuration is an option for organizations that require tight security of their EPM system and do not want to compromise their network security by placing servers in their DMZ network. These organizations can deploy a computer running Terminal Services, or a load-balanced cluster of computers running Terminal Services, to provide connectivity for their external users of Project Web Access 2003 and Project Professional 2003 clients. Figure 6.7 illustrates the EPM solution hardware configuration that includes Terminal Services.
Figure 6.7. Distributed EPM solution components with access for all external users provided via Terminal Services in the DMZ network.
Using Terminal Services to accommodate access for your external users does not create any limitations for your EPM solution component configuration.
A lot of detailed technical information is available for Terminal Services at the Technology Center for Terminal Services: http://www.microsoft.com/windowsserver2003/technologies/terminalservices/default.mspx.