One of SharePoint 2013’s advancements was the integration of FAST for SharePoint 2010 into the main architecture.
Those of you who built SP 2010 + FAST recognize the bolt-on arrangement that had a major weakness – moving data between the FAST and SharePoint engines was constrained by essentially one connection. When that locked up, you had little chance to recover without a reboot somewhere.
This was improved considerably in SharePoint 2013, but not eliminated. The crawl servers are still vulnerable when they have a lot of work to do.
Here’s a great post from the Reality Tech folks titled, “Running SharePoint 2013 search within a limited RAM footprint.” It describes how to make the most of a memory-modest SP 2013 server in a Search role. Enjoy!
If you overbooked and missed a session, or that guy behind you with the post-nasal drip drowned out the speaker, here’s your chance to catch up!
PLUS! Vlad Catrinescu published a script to download and neatly organize the videos and PowerPoint decks from the conference. Thanks, Vlad.
Are you developing for SharePoint in a commercial organization? Eager to get coding before a well-thought-out development environment is planned and stood up?
Cool your jets! Avoid the temptation to get started early and begin creating solutions in a Stand-alone SharePoint installation!
DO NOT develop in a Stand-alone SharePoint environment if you’re doing serious work!
Wait for your project team to formalize the environmental architecture and provision real farms in which you will do development, even if a farm consists of a single SharePoint server and separate SQL instance.
I have delivered the bad news to a development team up against a tight deadline that their performance problems and some system errors are the result of the Stand-alone deployment.
For starters, if you have Visual Studio, SharePoint (with a boatload of Services enabled), SQL Express, troubleshooting tools, and the Kitchen Sink running in what is likely a 2-core, 4 GB virtual instance on an over-subscribed virtual host, you are already asking for Big Trouble.
Don’t paint yourself into a corner with a Stand-alone deployment!
Most likely you are unaware (as was I until I researched a bunch of errors) that a Stand-alone deployment will not support all ‘normal’ SharePoint functionality. If you look at the Services status page, you won’t see a clue that anything is amiss!
See these caveats from the authoritative TechNet article on single-server SharePoint 2013 installations:
Consider the following restrictions of this method of installation:
Like the Nanny state trying to save us from ourselves, Microsoft started pushing SharePoint patching into automatic updates.
If your WinTel team and corporate governance folks are in alignment on best practice, they would avoid automatic patching like an Ebola tent without protective gear. If they do allow Windows Update to patch server OSs and applications, you might want to have a little chat with your CIO. But that’s getting off topic.
The reports from system administrators who have been victimized by automatic patching are unpleasant. Learn from them by making sure your SharePoint (and associated) servers are configured for manual patching only! Stop everything else that you’re doing and read this post from Todd Klindt NOW! Don’t Enable Automatic Updates on SharePoint Servers
Long story short, InfoPath 2013 will work in SharePoint Server 2016, and will make migrations easier.
However, Microsoft appears to have kicked the can further down the road, leaving solution architects with more time to either wait for Microsoft to possibly reverse its decision to totally outsource forms development, or align with one of the MS-sanctioned forms + workflow providers and not look back.
See Vlad Catrinescu’s “Absolute SharePoint Blog”