As is his custom, Dan started his session sharing pictures from his home… on Maui.
Once people were appropriately jealous (mere seconds), we were off on a
discussion of SharePoint 2013. In
his quest to demystify the latest in collaboration technology, Dan spoke mostly to infrastructure
and architecture, similar to the STP presentation from Michael Noel. Dan’s approach was
slightly different; however, as he strongly recommended moving to the cloud.
His point boiled down to this: If you have the power needed, go virtual.
Meaning, if you can have a virtual set-up with enough RAM and a fast enough
network to run your environment effectively, then there is no real reason why
you should not switch to the cloud. He mentioned how the new Windows Server 2012 is fast and
reliable, as well as the newest version of Hyper-V. He also mentioned the use of
– quite the trending theme here in Chicago
– as well as third-party hosting services. Again, like Michael,
Dan recommended several different server set-ups. The key takeaway here was
that while it is of course possible to run an entire SharePoint farm on one
server, it’s highly inadvisable. Having at least two servers dedicated to each Web
tier, apps tier, and database tier is recommended. Also, with regard to
outright processing power, Dan believes that the more RAM, the merrier. That
said, he did make the distinction that test servers and development servers do not
necessarily need as much juice as one might think. Dan is also a big supporter
of using a hardware-based load balancer in conjunction with SharePoint 2013’s
request management software-side assistance. This one-two punch helps balance
traffic across servers and will even push traffic away from servers that are
showing signs of slowing.
Another big topic for Dan was the new Distributed
Cache. The distributed cache functions
as a huge cache that tracks all changes on the farm and is spread evenly across
your servers. The two main benefits are populating the newsfeed in the new
social features and providing rolling authentication should you get switched to
another server during the course of your work. Having all this information in a
designated place improves performance and provides a redundant system, as all
the data in the distributed cache is also stored in the content database. While data will get kicked out of the distributed cache once it fills up, the data is still retrievable in the content database. The downside to the distributed cache is that if a server
goes down, the portion of the cache that was on that server will be lost. It can
be rebuilt from the content database but, depending on the size of the cache, this
process can take a long time. If a server is taken down correctly, it will automatically
distribute the information in the distributed
cache from that server to the others, which will save you from losing data.
As far as architecture is concerned, Dan spoke to the Microsoft
suggested architecture, which mirrors that of Office 365. This divides servers based on latency rather than
function. Essentially, Dan recommends that you put all the easy and common
things together, they’re leaving more room for the beefier components of your
environment. Dan’s suggestion is to approach your architecture first evaluating
your organization’s functional needs, then technical considerations (power,
hardware/virtual machine, etc.), and finally, cost. Obviously, it would be best
to have a dozen servers and hundreds of gigs of RAM, but clearly, that’s not a
realistic option for most of us.
Dan ended his session presenting a few best practices for setting up a
new SharePoint deployment. The main message here was to set up generic accounts
with high permission levels. These admin accounts can be used for high-level
functions and can then be disabled until they are needed again. He also
suggested creating an “uber” user, a user who has the appropriate permissions
to make any change, anywhere on the farm. As can be imagined, this account
should have increased security around the password, but once again, the account
should only be active when needed.