A short while back my Friend Nik asked me if I could outline some details about how the corporate IT farm was structured.

He commented that the email I sent him was pretty handy, so I thought it might make a good blog post for others as well.

——
Nik

Our Portal environment consisted of the following:
(Sharepoint 2010 – adjust OS/Software versions as needed for 2013)

Database Layer:
2 physical machines, with Windows Server 2008 R2 and SQL Server 2008 R2, in a clustered configuration – with storage for the Cluster being provided by a SAN

Sharepoint Layer:
4 Virtual Machines, with Windows Server 2008R2 and Sharepoint 2010 with SP1 and the latest CU
2 of these servers were designated as “App” servers and 2 as “Web Front Ends”

IP addresses:
Each Server needs 1 IP address for general network connectivity.
For our web front ends, we chose to allocate an additional IP per DNS name (it is possible to share the general machine IP address with multiple Non-SSL websites, but when SSL gets involved, you need 1 IP per dns name)
When there is more than one IP per server, you add them on the network adapter on the advanced button where you would normally specify the IP address.
From an IP perspective all IP addresses generally need to be in the same subnet.
At the Sharepoint Machine layer, these are all internal IP addresses, not publicly accessible.

Load Balancing:
If a hardware Load balancer is used, then it would typically get a dedicated IP for the DNS name it is load balancing – this is in addition to any management IP that would be used to manage the load balancer. Here we use an F5 load balancer. There is also a certificate requirement which I’ll talk about below.

Another LB option is Microsoft’s Network Load Balancer – This requires a slightly different config on the servers – I think the WFE’s end up sharing the same IP address per DNS name, but the addition of NLB then needs a second IP on each node and a second network interface so the nodes can communicate through the “back channel”

SSL Certificates:
The rules for SSL are, you need one cert per DNS name (Unless you use what’s known as a wildcard certificate) so for example a.yourcompany.com and b.yourcompany.com would each need a separate certificate, but another option would be to obtain a wildcard certificate that covers *.yourcompany.com, which would then work with all subdomains of yourcompany.com. (a.yourcompany.com, b.yourcompany.com, c.yourcompany.com, etc) I am not a certificate expert, but I have heard there are pros and cons to using a wildcard cert.

SSL certs are requested from within IIS – you have to fill out a few fields, and it will create a text file with the request – this text file then goes to the certficiate authority, they send back the certificate file and you go back into IIS and “complete the certificate request” – note that you do all this on only one of the two WFE’s – and you complete the request on the same box it originated from.
If you are load balancing then your next step is to “Export” the certificate from IIS of the box that has the cert – you will need to give the exported file a password (if not then you are not exporting correctly) copy the exported file (it will have a .pfx extension) to the other node, and “Import” it into IIS – and you’ll be prompted for the password you used.
As far as where the certificate requests go, We had someone on staff here that handled that. On other projects, I’ve used godaddy and also Verisign to get SSL certs. Both have websites where you’d upload the request file, make a payment, validate your identity and your right to create certificates for the domain in question and then receive the certificate.

SSL and IIS – Once you have the certificate in IIS you’ll need to tell IIS which website to assign it to – this is done by right clicking on the site and choosing “Bindings” when you select SSL, you’ll see a drop down of installed SSL certificates.

SSL and a hardware Load balancer – depending on the Loadbalancer used – it might be necessary to provide the certificate to the Load balancer so that it can decrypt traffic to inspect it before sending it forward. In our case I think our team wanted a .pem file – I have instructions somewhere on how to convert that if you need it.

SharePoint installation and Service accounts –
I used the AutoSPInstaller from CodePlex http://autospinstaller.codeplex.com/
In the installer package is a configuration file that you will need to modify to supply different accounts.
This is a great place to get a list of all the accounts you could ever possibly need (though of course it’s possible to re-use the same account, but the installer script spells out all the different places you could possibly want a different account – it’s up to you to choose if you’re going to type in the same thing in several places)
The installation of SP allows for “ Slip-streaming” updates so that the installation can be done all in one step including Service Packs and CU’s (Probably not an issue right now with 2013 since it’s new)

Admin rights – this area is tricky and I can’t say I’m an expert here.
In general, what I’ve found is that there are a LOT of operations during setup and Maintenance that require an account to be in the local administrators group.
The autoSPInstaller documentation actually does a decent job of discussing a few account that need admin on a temporary basis, that can later be removed from the admin group – however – on thing to watch out for is that they would then need to be added back in for things like applying service packs and CU’s

Inbound access to SharePoint from the internet:
UAG –
I know a little bit here – I’m not the UAG guy per say but here’s how it works –
Internally you still have all the same private IP addresses – if you’re using a load balancer then it has an IP for the site you want to “publish” on the internet – this is an internal IP.
UAG is installed on a box somewhere – I would expect to see this in a DMZ, between two firewalls – one on the outside and one between UAG and the internal network.
UAG will need an external, public IP and an internal – UAG will need the SSL certificate if SSL is being used. Here is one area where the wildcard seems to help – you can only have one IP per SSL certificate – unless that certificate is a wildcard – so our UAG box has a wildcard cert for *.mycompany.com and the public DNS of all our sites point to the same Public IP address, the address of the UAG box. (Note that the DNS we use inside the private network is different and internally DNS for each website points to the load balancer for that site, not to the UAG box)

Siteminder –
Just say no…

A note about the number of servers and their roles –
This is all documented by MS – I think it’s pretty typical to do a 2 App 2 Wfe farm as a starting point as it gives some redundancy – you could also do a 1 app 2 wfe, or 1 and 1.
Search in 2013 is pretty awesome so It might be good to dedicate a box or two to that- I still need to read up on the infrastructure there – typically you have one or more crawlers, and then one back end for the crawlers to talk to – here we’ve used the WFE’s as crawlers.

A note about installing in the DMZ –
Some might find it desirable to install some or all of SharePoint in the DMZ – There really shouldn’t be a problem with this so long as all the needed ports are opened up – for example if SQL is in the network, and SP is in the DMZ you’d need SP to be able to talk to SQL (I think that’s port 1433) You’d also need to open ports internally so that internal clients can hit the site, and use webdav for opening files with explorer. If you decided to split SharePoint with some boxes in the DMZ and some on the internal network, you’d need to open ports used by SharePoint for internal communication (I think port 38??? Is used for services)

A note about the “WFE” role –
There really aren’t roles in SP – there is a service in 2010 called something like the “SharePoint Foundation Web Site” or something like that – You can sometimes get away with disabling that (from CA) on the boxes that are “App” server boxes- but there are times when this causes deployments or 3rd party installations to fail. There is no harm leaving it on,but you will then see the websites in IIS on the “App” boxes – so long as you don’t route any traffic to those boxes (from the load balancer for example) then those sites will never spin up and really shouldn’t be a problem.

A note about memory – sizing, etc…
Follow the Microsoft “best practices” where possible – I think they currently recommend 8-16 gb minimum per machine.

A note about log files –
I store these on the D drive – the AutoSPInstaller makes it easy to specify these in advance.

I hope this helps!

It’s funny – I’ve never actually thought about all this at once – It might make a good blog post!

– Jack

As a follow up to this email – Server 2012/IIS 8 supports Server Name Indication which may allow you to share an IP address amongst multiple SSL sites (Browser support varies so it’s not a given)
http://en.wikipedia.org/wiki/Server_Name_Indication