We are in the process of deploying sharepoint 2013, and I have a question on deploying the web server roles. Where should they be ideally placed, on the internal network or on the DMZ. If they are placed on the DMZ, can the web server roles be on workgroups or do they have to be always on the domain. Can you join a work group computer to sharepoint farm, I assumed it always had to be on the domain. Majority of our sharepoint users will be internal, but we have external partners who we want to access the sites as well, thats why we are thinking DMZ. Any advise on the above questions

They should be placed wherever it makes most sense for you in your specific circumstances. Generally a DMZ is a better idea. Please see Plan security hardening for SharePoint 2013 for the ports and protocols that need to be available between all servers in the farm, regardless of the network where they reside. Using an Active Directory domain for a SharePoint farm is a requirement for your service accounts in SharePoint 2013. See Account permissions and security settings in SharePoint 2013. The farm doesn't need to use your internal corporate domain, it could be a resource domain specifically for the DMZ. This domain should trust your internal domain so your users can access the farm. i.e. a one-way trust (DMZ trusts CORP, but not vice versa). You can also have servers in the farm be members of different domains, so for example you could place the WFE servers in the DMZ and join them to the resource domain but have the application and SQL servers on you lan joined to your corporate domain. For this to work you will certainly require a one-way domain trust. Jason Warren Infrastructure Architect Habanero Consulting Group habaneroconsulting.com/blog

Thanks for your great reply. So the web servers need to be part of some domain then, if its the same domain as the other sharepoint servers , or in a trusted domain. So the web server roles cannot be in a non-domain like a workgroup, correct ? Also can you divide the web server roles such as for internal use put the web server roles in the internal network, and the web server roles for external users in the DMZ. Can you divide in this way in sharepoint.

Yes, you do not want to use workgroup servers and provided all the servers in the farm can communicate, you can have "internal" WFEs and "external" WFEs. Each WFE is capable of serving requests for every web application in the farm, it's just a matter of forwarding the users to the appropriate WFE using DNS or network devices. Jason Warren Infrastructure Architect Habanero Consulting Group habaneroconsulting.com/blog

Thanks again. So if we move our web servers to the DMZ, is there a list ports that we need to open to allow traffic from the web servers to rest of servers in the farm. Such as would we need sql ports to be opened as well for dbase access. Is there a list or link.

Please see Plan security hardening for SharePoint 2013 for the ports and protocols that need to be available between all servers in the farm, regardless of the network where they reside. As per my original message ;) Jason Warren Infrastructure Architect Habanero Consulting Group habaneroconsulting.com/blog

Thanks for the post, but I am still not sure on what ports i need opened on the firewall if the web server is on the DMZ for example: DMZ Internal Web server >>>>> Firewall wall >>>>>>APP server >>>>>>sq; servers From looking at some of the diagrams, it mentions that the web server needs to access to the sql server, index, and query servers as well as SMTP and DNS and AD. So would I need ports opened for SQL, LDAP, SMB etc. As that seems quite a lot of ports to be opened for the web server. Internal to DMZ (outgoing) should be fine as we are allow all outbound. Any advise, or is there a list of ports I can be provided with. Thanks

Yes, that is correct. You need those ports. The WFEs communicate with every other server in the farm, as well as your Active Directory, DNS, and SMTP servers. This includes all supporting infrastructure services such as LDAP, Kerberos (if you're using it), etc. I believe SMB is only if you are indexing fileshares. It does seem like quite a lot for a web server, however a SharePoint WFE is not just a web server. Here is the list of ports: TCP 80, TCP 443 (SSL) Custom ports for search crawling, if configured (such as for crawling a file share or a website on a non-default port) Ports used by the search index component TCP 16500-16519 (intra-farm only) Ports required for the AppFabric Caching Service TCP 22233-22236 Ports required for Windows Communication Foundation communication TCP 808 Ports required for communication between Web servers and service applications (the default is HTTP): HTTP binding: TCP 32843 HTTPS binding: TCP 32844 net.tcp binding: TCP 32845 (only if a third party has implemented this option for a service application) Ports required for synchronizing profiles between SharePoint 2013 and Active Directory Domain Services (AD DS) on the server that runs the Forefront Identity Management agent: TCP 5725 TCP&UDP 389 (LDAP service) TCP&UDP 88 (Kerberos) TCP&UDP 53 (DNS) UDP 464 (Kerberos Change Password) For information about how to synchronize profiles with other directory stores, see User Profile service hardening requirements, later in this article. Default ports for SQL Server communication TCP 1433, UDP 1434. If these ports are blocked on the SQL Server computer (recommended) and databases are installed on a named instance, configure a SQL Server client alias for connecting to the named instance. Microsoft SharePoint Foundation User Code Service (for sandbox solutions) TCP 32846. This port must be open for outbound connections on all Web servers. This port must be open for inbound connections on Web servers or application servers where this service is turned on. Ensure that ports remain open for Web applications that are accessible to users. Block external access to the port that is used for the Central Administration site. SMTP for e-mail integration TCP 25 Jason Warren Infrastructure Architect Habanero Consulting Group habaneroconsulting.com/blog