I`ve just finished implementing a SharePoint farm with a back-to-back perimeter topology. The topology consisted of 6 servers (2 Web Front Ends {WFE’s}, 2 Application Servers {App’s} and a 2 node SQL Cluster). The implementation used was with a firewall separating the WFE’s from the APP and SQL nodes.
At first we had configured the firewalls to only allow for SQL, http/https and a few other basic web ports. The installation of the farm went very smooth and didn’t run into any issues until we started creating sites and trying to connect to the Managed Metadata service. If we connected to the Managed Metadata service from the App server we were able to see all the managed terms. From the WFE (Connecting through the site collection) when we tried to manage the term store I would be able to see the managed metadata manage page, but I would always get the error “The Managed Metadata Service [[Managed Metadata Service]] is inaccessible”. I couldn’t figure out why the term store wasn’t editable! In the server logs I found many event 8088’s in there, but not a lot of detail on what the issue was.
Did some research and found many articles with many different solutions:
- Ensure the Application pool account has access to the term store and run an iisreset
- Ensure the Managed Metadata service is running
- Ensure that IIS is using the IUSR account for anonymous access and that the IUSR account has access to the Managed Metadata Database in SQL Server
None of the above worked for me. What was interesting was that from Central Admin I was able to see the termstore, but not from the WFE. This led me to the possibility that there were ports being blocked between the servers. Looked up the ports that SharePoint uses and found this great blog: http://blog.blksthl.com/2013/02/21/tcpip-ports-of-sharepoint-2013/. Here`s an excerpt from the site:
| Protocol | Port | Usage | Comment |
| TCP | 80 | http | Client to SharePoint web server traffic(SharePoint – Office Web Apps communication) |
| TCP | 443 | https/ssl | Encrypted client to SharePoint web server traffic(Encrypted SharePoint – Office Web Apps communication) |
| TCP | 1433 | SQL Server default communication port. | May be configured to use custom port for increased security |
| UDP | 1434 | SQL Server default port used to establish connection | May be configured to use custom port for increased security |
| TCP | 445 | SQL Server using named pipes | When SQL Server is configured to listen for incoming client connections by using named pipes over a NetBIOS session, SQL Server communicates over TCP port 445 |
| TCP | 25 | SMTP for e-mail integration | Cannot be configured |
| TCP | 16500-16519 | Ports used by the search index component | Intra-farm onlyInbound rule Added to Windows firewall by SharePoint |
| TCP | 22233-22236 | Ports required for the AppFabric Caching Service | Distributed Cache… |
| TCP | 808 | Windows Communication Foundation communication | WCF |
| TCP | 32843 | Communication between Web servers and service applications | http (default) To use custom port, see references sectionInbound rule Added to Windows firewall by SharePoint |
| TCP | 32844 | Communication between Web servers and service applications | httpsInbound rule Added to Windows firewall by SharePoint |
| TCP | 32845 | net.tcp binding: TCP 32845 (only if a third party has implemented this option for a service application) | Custom Service ApplicationsInbound rule Added to Windows firewall by SharePoint |
| TCP | 32846 | Microsoft SharePoint Foundation User Code Service (for sandbox solutions) | Inbound on all Web ServersInbound rule Added to Windows firewall by SharePointOutbound on all Web and App servers with service enabled. |
| TCP | 5725 | User Profile Synchronization Service(FIM) | Synchronizing profiles between SharePoint 2013 and Active Directory Domain Services (AD DS) on the server that runs the Forefront Identity Management agent |
| TCP + UDP | 389 | User Profile Synchronization Service(FIM) | LDAP Service |
| TCP + UDP | 88 | User Profile Synchronization Service(FIM) | Kerberos |
| TCP + UDP | 53 | User Profile Synchronization Service(FIM) | DNS |
| UDP | 464 | User Profile Service(FIM) | Kerberos change password |
| TCP | 809 | Office Web Apps | Intra-farm Office Web Apps communication. |
This was awesome, so I opened up the rest of the ports that were needed and I could then view the term store!
So, from there I finished updating some of the features in the site. It came time to start adding users and I kept getting the following error: “Sorry we`re having trouble reaching the server.”.
So, went on another hunt and found a few possible solutions:
- Running a powershell script to update the domains the people picker would look in
- Opening ports for AD Lookups
At first, I thought it would be that the firewall needed additional ports to communicate with the data source the users are located in (This could be Active Directory, AD LDS instances, SQL Memberships, etc) so I opened the following ports:
| Protocol | Port | Usage |
| TCP + UDP | 135, 137, 138, 139 | RPC |
| TCP + UDP | 389 | LDAP |
| TCP | 636 | LDAP GC |
| TCP | 3269 | LDAP GC SSL |
| TCP + UDP | 53 | DNS |
| TCP + UDP | 88 | Kerberos |
| TCP + UDP | 445 | Directory Services |
| TCP + UDP | 749 | Kerberos-adm |
| TCP | 750 | Kerberos-IV |
Once I opened the ports for these services I was then able to select users using the people picker! The issue is that it only found users in the domain I installed SharePoint in. Even though I had configured the profile sync service to import users from other domains, I still had to run the following powershell script:
stsadm.exe -o setproperty -pn “peoplepicker-searchadforests” -pv “forest:[[DOMAIN]],[[DOMAINUSER (from other domain)]],[[PASSWORD]];forest:[[DOMAIN2]],[[DOMAIN2USER]]],[[PASSWORD]]” –url [[URL WEBAPP]]
Once that command was run I was able to query and lookup users in both domains.
