You have everything
installed and a fully functional farm. Before you can invite users to
the party, however, you need to create something for them to access —
web applications, site collections, and webs. The first subsection
takes a brief detour to ensure that these terms are clearly understood.
Then you will walk through the steps to create these items.
Terminology
Don’t skip this section. Even if you
are quite certain you know all the terminology, humor us by reading
this material. Even the most seasoned SharePoint “professional” can
lack an understanding of exactly what each part of the SharePoint
hierarchy represents.
Figure 1
is the SharePoint containment hierarchy. The main thing to understand
as you look at the items is that a one-to-many relationship is
reflected as you work down the list, whereas a many-to-one relationship
is reflected as you work up the list. For example, a content database
can (and often does) contain more than one site collection, but a site
collection can only be located in one content database.
The most commonly misunderstood term is site,
which end users often use when they actually mean web, and which
developers often use when they actually mean site collection. This
leads to utter chaos when it comes to troubleshooting or scaling your
farm because they represent totally different things. As a best
practice, never use the word “site,” and take every opportunity to
encourage your fellow SharePoint admins to do the same if you catch
them using it. Remember site is a four letter word and should be
treated as such.
Web Applications
It’s easiest to think of a web
application as the thing that lives in IIS. This is the address that
your users will enter in their browser. Because it is something users
will work with on a regular basis, you should try to choose a short,
meaningful name. Names like http://portal.contoso.com or http://intranet.contoso.com work much better than a name like http://scificharacter.scifiplanet.scifigalaxy.local.
You want to choose a name that is both memorable to your users and easy
to type. Also, the temptation is to only use the NetBIOS name
http://portal, but that can cause confusion in different ways later.
Best practice is to use a fully qualified domain name from the
beginning.
SharePoint 2010 introduced claims-based
authentication, although many users continued to use the classic
Windows authentication because they had no idea what the new method was
or why they should care about it. In SharePoint 2013, claims-based
authentication is now the standard. Indeed, when creating a web
application using Central Administration, it’s the only available
option. The three seemingly different options — Windows claims,
forms-based authentication (FBA), or Trusted Identity provider — are
just different flavors of claims.
Use the following steps to create the web application http://portal.contoso.com:
1. Return to the home page of Central Administration.
2. Under Application Management, click Manage web applications.
3. From the Ribbon, click New.
WHEN THE NEW BUTTON IS GRAYED OUT
On the Manage web applications page,
generally speaking things work as expected; but every now and then
SharePoint will throw you a curveball. For example, you might find the
New button is grayed out. There are a couple of reasons why this might
be the case. One is if you are not a local administrator on the
SharePoint server but you are a farm administrator. In this case, you
can access central admin but you don’t have the Windows rights to
create a new web application so SharePoint doesn’t display the option.
The second reason is harder to catch and happens only when you are
opening Central Administration from the server itself. When you launch
Central Administration using the shortcut on the Start menu, it
actually runs psconfigui.exe,
which launches IE and disables all the lockdown behavior. If you open
IE and type in the URL for Central Administration, there is a good
chance that the scripts you need run to enable the button will be
grayed out. Moral of the story? Anytime you are troubleshooting the New
button being grayed out, you should RDP into the SharePoint server and
run the shortcut. That is the solution most likely to resolve the
problem.
4. For Port, enter 80. You could use a different port but users often don’t understand URLs with ports, so use the default of 80.
5. For Host Header, enter portal.contoso.com. You want to have more than one web application using port 80, so you have to make them all unique by using host headers.
6. In most
scenarios, all the defaults until you get to Application Pool will be
fine. For this section, select Use existing application pool.
7. From the
drop-down, select Default SharePoint Web App Pool (Contoso\sp_webapp).
If you don’t have that application pool, return to the section,
“Configuring the User Profile Service.” In that section, you created
the my.contoso.com web application, which should create the application pool.
8. In the next section, change the Database Name to WSS_Content_Portal.
The idea here is to ensure that anyone looking at the list of database
names can easily identify the purpose of each web app. A simple naming
convention saves a lot of headaches later.
9. Accept all the other defaults and click OK.
10. After a moment you will get a pop-up window indicating that the application has been created. Click OK to close the window.
Now your web application and content database have been created. Because you just created the host header portal.contoso.com, you need to ensure that you have a DNS entry that resolves portal.contoso.com
to your SharePoint server. As a word of caution, use a host or a record
in DNS. Don’t use an alias or CNAME, as those just lead to trouble.
Because you are using portal.contoso.com
to access the server named Server, if you try to open that URL from the
SharePoint server itself you will get an authentication error. This is
because of a security mechanism called the loopback check that protects you from reflection attacks. There are two ways to work around the issue, both of which are covered at http://support.microsoft.com/kb/896861.
You can review the article and choose which method you prefer. Method 1
is very specific and disables the check just for names you specify,
whereas method 2 turns off the security feature entirely. The choice is
yours but you need to select one for SharePoint to be happy.
To make it easier to manage SharePoint in a multi-server farm, it is recommended that you modify the hosts file on each machine so that each web application points to the local server. You can find the file in c:\windows\system32\drivers\etc\ and it is named just hosts with no extension. Using Notepad, modify it to add an entry to point 127.0.0.1 to portal.contoso.com as shown in Figure 2.
If you have a problem trying to save the file, that is because you have
the user access control still enabled. In that case, you need to run
Notepad as an administrator.
For an automated way to change both the hosts file and the loopback setting using a PowerShell script, see Todd Klindt’s blog post at http://www.toddklindt.com/edithosts.
Site Collections and Webs
Now that you have a web application
sitting there, you need to create a site collection so it has something
to serve up. Site collections are the unit of scale in SharePoint. The
easiest way to think of a site collection is as a bag, because it is
really just a boundary or container. It is not actually content users
can touch. The reason why this “bag” is so important is because it
determines a lot about how your information is stored.
Site collections are a storage boundary and they
are stored in one and only one content database. They cannot span
multiple databases. When you create a site collection it is created in
a database, where it will stay unless you manually move it. If, for
example, you want to limit all your content databases to 40GB because
that is the largest size you are comfortable with, then you need to
ensure that no site collection is larger than 40GB. Similarly, if you
have multiple site collections (and everyone does), then you would need
to apply quotas to those site collections to ensure that the sum of the
site collections doesn’t exceed your 40GB database limit. For instance,
if you had 10 site collections, then you would set your quotas to 4GB
per site collection.
Site collections are the only objects in
SharePoint to which you can apply a storage quota. If you want to limit
a user to storing only 10GB of content in a particular document
library, there is no way to do that. You would have to set that entire
site collection to a 10GB limit. If you have two document libraries and
you want to give each one 10GB of storage, then you have to ensure that
each document library is in its own site collection.
Even if you have no intention of holding users to
limits, quotas are generally recommended for all site collections, as
they serve as a checkpoint and prevent runaway site collections. If a
user calls and says that he is getting warnings or errors because he
has met his quota, it is a simple process for you to increase his
quota, and it gives you a chance to ask, “So what are you doing with
SharePoint that you need so much storage space?” It would be good to
know if he is just backing up his MP3 collection to SharePoint.
Site collections also serve as an administrative
boundary. Site collection administrators are a special group of users
who have complete power over the site collection without necessarily
having any access to other site collections. The Site Settings page
contains an entire menu of configuration options that only a site
collection admin can set. If you have two groups — such as HR and
Accounting, for example — in the same site collection and one of them
approaches you because they need to administer one of these special
settings, you have to do some rearranging. If you make Nicola from
Accounting a site collection administrator, then she can fully
administer the account site as needed but she also has full control
over the entire site collection, including the HR web. You need to
instead move the Accounting web to its own site collection and then
make Nicola an administrator there.
Site collections are also boundaries for
out-of-the-box functionality such as navigation and the various
galleries. This can be a drawback of many site collections. Out of the
box, it is impossible to enforce consistent, self-maintaining
navigation across site collections. The galleries such as the themes,
Web Parts, lists, and solutions are all scoped at the site collection
level. For example, if you need a list template to be available to
multiple site collections, then you have to manually deploy it to each
one.
Site collections also serve as security
boundaries. The All People list and the various SharePoint groups are
all scoped at the site collection level and are not accessible for
reuse outside of the site collection.
Inside of site collections you have one or more
“webs.” A web is the object that is referred to throughout the user
interface as a site. It can also be called a subsite or a subweb.
Again, because the term “site” can be very confusing, whenever possible
refer to these as webs. This is the first object users can actually
touch. You can apply security to it, and it contains all the user
content. Each web has its own lists (libraries are just a special type of list) and all of those lists store items, which refers to the actual content, such as documents and contacts.
All of that is said to remind you not to take
site collections lightly. Create them deliberately and often because
they will keep you out of trouble down the road.
Follow these steps to create that first site collection:
1. Return to the home page of Central Administration.
2. Under
Application Management, click Create site collections. Avoid the
temptation to make fun of the fact that the link says Create site collections even though you can only create one site collection using the link.
3. Confirm at the top of the page that Web Application says http://portal.contoso.com; if not, you can click the link to change web applications.
4. For Title
and Description, enter something helpful or creative. In this example,
use Contoso Portal for Title and leave Description blank.
5. For URL:,
you need to choose the root site collection by selecting the / from the
drop-down. Creating this site collection first is a requirement.
6. The Select
experience version drop-down is interesting. You can choose 2013 or
2010. For this example, choose 2013. Keep this setting in your memory
bank. It is a new twist to SharePoint that you might find handy down
the road.
7. In the Select a template section, choose Team Site.
8. For Primary Site Collection Administrator User Name, enter Contoso\sp_install. In a real-world environment you would use an account that makes sense for the site collection you are creating.
9. For Secondary Site Collection Administrator User Name, enter Contoso\administrator.
Again, in your environment use a better account. The key point is that
every site collection should have both a primary and a secondary owner.
10. While
every site collection in the world should have a quota, you haven’t
learned about them yet so you can leave this at No Quota for the
moment.
11. Double-check all your settings and click OK.
After a minute or so you will get a
message indicating that the site collection was successfully created.
Click the link to dive into the awesomeness that is SharePoint 2013.
