Environment Requirements

Enterprise implementations require Windows Authentication within an NT or Active Directory domain. This is essential to a working enterprise configuration. Without a domain, you entirely lose the ability to use SharePoint Team Services (STS) and Analysis Services. Both of these services require Windows Authentication. You also must have a domain to deploy Project Server components, including SQL Server, across two or more boxes. Project Server talks to STS and Analysis Services through COM+ objects that run under Windows identities. These can’t be local machine accounts once a second server is added, because one machine’s local account isn’t recognized by another machine. This is true even when the usernames are the same, as the credentials are passed as machinename\username. On the other hand, a domain account is passed as domainname\username, which can be resolved by any domain member machine.

Working across multiple domains isn’t a problem as long as you establish the proper trust relationships. Without the trusts, you’ll run into the same types of problems you encounter with local machine accounts. The credentials will be rejected. I’ve heard of an implementation that circumvented trusts by using a customized Lightweight Directory Access Protocol (LDAP) solution. Suffice it to say that this is a challenge for very technically skilled folks with plenty of funding, as this isn’t a native capability. Generally speaking, it’s a good idea to keep all your Project Server boxes in the same domain. Users can access the system from any trusted domain.