As is his custom, Dan started his session by 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 Windows Azure. Quite the trending theme here in Chicago!
As well as third-party hosting services. Again, like Michael, Dan recommended several different server setups. 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 with 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 Microsoft’s 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 by 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.
~Team Bamboo
